Beiträge von tbc233

Ich habe jetzt sehr lange nach einem Problem gesucht:
Mein erster und bisher einziger Rocky Linux Server (Rocky Linux 9.1 Blue Onyx) hatte immer wieder Probleme, https Verbindungen aufzubauen - zum Beispiel via wget oder curl. Es kamen immer wieder Zertifikatsfehler (unknow authority).

Nach einem "dnf reinstall ca-certificates" funktionierte es stets wieder.

Beispiel:

# curl https://www.github.com
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Zuerst dachte ich an einen Bug seitens Rocky Linux, bin hier aber nicht vorangekommen.

Jetzt bin ich einen Schritt weiter: Es scheint an der wöchentlichen Ausführung von /opt/pdadmin/bin/update_host_certificate.sh zu liegen.

Dieses Script schreibt das Hostzertifikat nach /etc/ssl/cert.pem (in der Gegend von Zeile 45). Diese Datei ist unter Rocky Linux aber ein Symlink auf /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem und scheint somit eine wesentliche Rolle beim gesamte CA Setup von Rocky Linux zu spielen. Durch dieses Überschreiben geht wohl die ganze Geschichte kaputt, durch das "dnf reinstall ca-certificates" wird das wieder auf Normalstand gebracht und es geht wieder bis zum nächsten Lauf von update_host_certificate.sh

Vielleicht könnte das PD-Admin Team diese Geschichte prüfen. Ich glaub nicht dass ich hier selbst etwas tun kann, zumal mir der Zweck warum dieses Script das Host Zertifikat nach /etc/ssl/cert.pem kopiert, gar nicht klar ist.

Zur Info, der Workaround scheint soweit zu funktionieren.

Er ist in die inzwischen erschienene pd-admin Version 4.106 noch nicht eingearbeitet.

Gemäß pd-admin Support ist dies ein mittlerweile bekanntes Problem. Lösung wurde mir genannt (noch nicht probiert):

# wget http://download.pd-admin.de/pdadmin_v4-32bit-crypto,ssl.tar.gz
# tar -C/ -xf pdadmin_v4-32bit-crypto,ssl.tar.gz

Ich habe einen älteren Server, bei dem ich die 32 bit Version von pd-admin nehmen muss, wegen zu alter glibc.

Der Server hatte pd-admin v4.103 und 4-0.412. Also Versionsstände halbwegs aktuell, vorher nie Probleme gehabt.

Heute Update auf SE 0.418 und pd-admin v4.105. Ergab bei Aufruf der pd-admin Oberfläche, aber auch zum Beispiel bei Aufruf von /opt/pdadmin/bin/httpd_vhosts.pl

Software error:

Can't load '/opt/pdadmin/lib/mysql.so' for module DBD::mysql: libssl.so.0.9.7: cannot open shared object file: No such file or directory at PERL2EXE_STORAGE/DynaLoader.pm line 230.
 at /opt/pdadmin/www/administrator/administrator.cgi line 91
Compilation failed in require at /opt/pdadmin/www/administrator/administrator.cgi line 91.
BEGIN failed--compilation aborted at /opt/pdadmin/www/administrator/administrator.cgi line 91.

Ich habe diese Fehlermeldung schonmal beobachtet, als ich auf einem neueren Server versehentlich die 32bit Version von pd-admin erwischt habe. Hab mir hier aber dann nichts weiter gedacht (funktionieren hätte es aber eigentlich trotzdem müssen denke ich) und die 64 bit Version drüber gemacht. Das kann ich aber wie gesagt auf diesem Server nicht.

Im ersten Schritt hab ich dann mal /opt/pdadmin aus einem Backup von der Vornacht wieder hergestellt. Fehler bestand dann immer noch!

Erst als ich das /usr/local/pd-admin2 Verzeichnis von vor dem update wieder rück-umbenannt habe, hat wieder alles funktioniert. Aber natürlich nun mit dem alten Versionsstand. Ich verstehe nicht, warum ein Zurückstellen der Serverumgebung dieses pd-admin Problem behoben hat...

Gibt es hier irgendein Problem im Zusammenspiel zwischen 32bit Version von pd-admin und der Umgebung 0.418?

Ich hab jetzt auf einem Server, auf dem die letzten Updates ohnehin noch anstanden, es beobachtet:

Mittels "crontab -e" habe ich eine Zeile eingefügt

# das ist ein Test

- Anschließend SE Update gemacht. Die Zeile war anschließend noch drin.

- Dann pd-admin via http://download.pd-admin.de/pdadmin_v4_64.tar.gz und update.sh durchgefürt.

--> Zeile ist nun verschwunden.

Ich lag also insofern falsch dass es nicht die Standardumgebung, sondern pd-admin ist. Aber passieren tut es.

EDIT: Habe Thread Titel auf die neue Erkenntnis angepasst.

Also dass bei den Cronjobs ganz allgemein was gemacht wird, weiß ich ganz sicher. Ich hatte früher ja mal einen Server mit der Free version (< 10 Domains) und da hab ich den get_license Job entfernt, da ohnehin sinnlos. Der war aber nach jedem Update dann wieder da.

Ich möchte mich mal wieder beim PD-Admin Team bedanken. Es ist wirklich toll, dass so schnell auf aktuelle CVEs reagiert und dabei sogar stets auf möglichst hohe Abwärtskompatibilität (Patch Backports bis PHP 5.4!) geachtet wird.

Mir ist grad folgendes aufgefallen:

Ich hatte in der Crontab von root ein paar eigene Jobs drin, diese waren vorübergehend mit # auskommentiert. Weil ich grad Zeit hatte, habe ich die Standardumgebung upgedatet. Danach waren diese Einträge weg.

Kann es sein, dass die Update Routine auskommentierte, eigene Cronjobs raus wirft?

Einen Zusammenhang mit der Systemzeit sehe ich nicht, zumal Du diese ja vermutlich manuell oder via ntp nun zumindest im laufenden Betrieb wieder korrigiert hast.

Meiner Erfahrung nach kann es zu dem Fehler kommen, wenn Du auf einem "eher modernen" System die 32bit Version installierst. Ich würde an Deiner Stelle mal die 64bit Version von pd-admin runterladen und drüber rasseln lassen.

Zitat von WebTeufel

oh ja, an $_SESSION habe ich irgendwie in dem moment gar nicht gedacht, da es in dem sinne keine "Benutzerverwaltung" gibt

Sessions kann man auch ohne eine Benutzerverwaltung verwenden.

Zitat von WebTeufel

was "Session Hijacking" angeht, kann man die Session nicht an die IP z.b binden? oder evtl noch was dazu zusätzlich

Wenn Du PHP Sessions in der üblichen Standardeinstellung verwendest, dann wird ein Cookie gesetzt. Das ist schonmal relativ sicher da sich ein Cookie nicht so leicht hijacken lässt wie ein URL Parameter.
Wenn Du bei der Variante mit einer eigenen Tabelle fürs Speichern der Sitzungswerte bleibst (wie gesagt, ich würds mir nicht antun), kommt es halt auf Deinen Benutzerkreis an ob es Sinn macht die IP hier als Kriterium zu verwenden. Aufgrund NAT und Carrier Grade NAT (zb. in Mobilfunknetzen) können die IP Adressen mitunter während dem Rumklicken variieren, umgekehrt können hinter einer öffentlichen IP tausende User sitzen.

Ein anderes Kriterium um sicher zu sein dass es auch wirklich der selbe User ist wie beim letzten Request wäre ein Cookie das Du manuell setzt. Aber dann kannst auch wirklich gleich eine PHP Session verwenden.

Natürlich kannst Du Dir in einer Tabelle einen Datensatz anlegen, mit irgendeinem kryptischen Identifier oder einer UUID, wo Du alle Werte speicherst die Du für die aktuelle Benutzersitzung bzw. den aktuellen Vorgang brauchst. Aber es erscheint mir aufs erste Mal drüber lesen etwas umständlich. Securitymäßig ist sowas auch umstritten (je nachdem wie sensibel die Daten sind mit denen der User da hantiert), erlaubt es doch quasi "Session Hijacking" wenn jemand diese URL in die Finger bekommt.

Warum machst Du nicht einfach eine PHP Session auf? Die sind genau für sowas da. Session starten mit session_start() und dann kannst Du zb. $_SESSION['datum'] setzen und damit arbeiten.

Ich kann mich irren, aber ich glaube mich zu erinnern dass es dazu kommen kann wenn man auf einem eher modernen System die 32 bit Variante installieren möchte.

Hast Du die 64bit Variante

http://download.pd-admin.de/pdadmin_v4_64.tar.gz

genommen?

Eine Bearbeitung meinerseits kann ich defacto ausschließen.

Ich hab jetzt auch leider die Installationsdateien nicht mehr, um in das tar von damals reinzuschauen ob die Datei bei der Auslieferung schon so war.

hmmm - sehr schräg, hier war ein backslash ganz am Beginn der /service/apache24/run:

\#!/usr/bin/bash

if [ ! -e "/etc/real-hostname" ]; then
  hostname $(/opt/pdadmin/bin/hostname.pl)
else
  hostname $(cat /etc/real-hostname)
fi

killall -9 httpd >/dev/null 2>&1
rm /usr/local/pd-admin2/httpd-2.4/logs/httpd.pid
ulimit -n 64000
cmd=(
   exec /usr/local/pd-admin2/httpd-2.4/bin/httpd
      -D NO_DETACH
      -DSSL
)
"${cmd[@]}"

Nachdem ich diesen entfernt habe, ist nun Ruhe.

Ein Fehler ist mir geblieben, den ich mir nicht erklären kann:

supervise: fatal: unable to start apache24/run: exec format error

Dadurch läuft Apache24 nicht, zumindest bis zum ersten manuelle oder planmäßigen Aufruf von httpd_vhosts.pl
Der supervise Fehler bleibt aber bestehen.

Im Moment kapier ich noch nicht, was dem System an dieser run Datei (bzw. run-v2) nicht passt...

Ich hab jetzt mal manuell das Paket via Quelle https://repo.almalinux.org/alm…1.0.2o-4.el8_6.x86_64.rpm installiert, damit scheint es soweit zu funktionieren.

Hallo,

Die pd-admin Installation auf Rocky Linux 9.1 bricht mir mit dem eh nicht unbekannten Fehler

Error: Unable to find a match: compat-openssl10

ab. Bei Rocky Linux 9.1 habe ich combat-openssl10 nicht mehr zur Verfügung, nur mehr compat-openssl11. Dieses habe ich auch installiert, das behebt mir den Fehler aber nicht.

Hat jemand einen Tipp?

Lösen sich die betroffenen Domains DNS-mäßig noch auf die alte Domain auf? Ich hab da was im Kopf, dass das abgefragt wird beim generieren. Ich kann mich aber irren.

Ich hab auch mal versucht, die Host Dienste per ipv6 zugänglich zu machen. Da ich keine andere Möglichkeit kenne, habe ich es wie von Dir angedacht so gelöst, dass ich einen eigenen Container in die template Datei eingefügt habe.

Grundsätzlich hats funktioneirt, allerdings wirft das administrator und das customer Interface dann einen Lizenzfehler wenn man per ipv6 daher kommt. Weil die Lizenz ist ja auf die ipv4 Adresse ausgestellt und das wird an dieser Stelle geprüft.

Mir fällt auf, dass meine /home/mysql/$HOSTNAME.err Logfiles teilweise ganz schön fett geworden sind. Hauptursache sind Zeilen wie diese

2022-10-04T00:30:01.497239Z 55985 [Note] Aborted connection 55985 to db: 'vadmin' user: 'vadmin' host: 'localhost' (Got an error reading communication packets)
2022-10-04T23:00:05.914856Z 59778 [Note] Aborted connection 59778 to db: 'vadmin' user: 'vadmin' host: 'localhost' (Got an error reading communication packets)
2022-10-05T00:30:02.338012Z 59832 [Note] Aborted connection 59832 to db: 'vadmin' user: 'vadmin' host: 'localhost' (Got an error reading communication packets)
2022-10-05T23:00:05.903515Z 61884 [Note] Aborted connection 61884 to db: 'vadmin' user: 'vadmin' host: 'localhost' (Got an error reading communication packets)
2022-10-06T00:30:01.427975Z 61939 [Note] Aborted connection 61939 to db: 'vadmin' user: 'vadmin' host: 'localhost' (Got an error reading communication packets)

So eine Meldung entsteht jeden Tag um 23:00 Uhr und um 00:30 Uhr. Mit welchem Cronjob dass zusammenpassen würde, erschließt sich mir allerdings nicht.

Jedenfalls hab ich das auf so gut wie allen pd-admin Servern.

Hat das sonst noch jemand?

Ich hab schon vor längerem aufgegeben, hier selbst herum zu justieren. Ich finde es geht einfach zu viel Zeit drauf um ein zufriedenstellendes Ergebnis zu erzielen (und es auch aufrecht zu erhalten).

Daher hab ich vor ein paar Jahren entschieden, dass Leute machen zu lassen, die das hauptberuflich tun und mach das - je nach individuellem Kundenbedarf - über spamexperts.com

Die machen einen guten Job und die Preise sind fair. Integriert wird das ganze via MX Eintrag je Domain.