Sorry wenn ich hier nochmal einhake, bin ich der einzige mit der
LibClamAV Warning: Cannot dlopen libclamunrar_iface: libclamunrar_iface.a: cannot open shared object file: No such file or directory - unrar support unavailableWarning?
Der Hotfix behebt diese Warning nicht.
Kann ich bei mir mit selben Versionen auf Centos 7 nicht bestätigen.
Allerdings wie in einem anderen Posting von mir beschrieben, bei allem was irgendwie mit ClamAV zu tun hat ständig die Meldung
LibClamAV Warning: Cannot dlopen libclamunrar_iface: libclamunrar_iface.a: cannot open shared object file: No such file or directory - unrar support unavailableHast Du versucht ihm beinhart manuell das RPM paket rein zu jagen?
hat bei mir zueletzt funktioniert.
Beim Update auf SE 0.428 (von 0.427) kamen seitens Clamav sehr viele Meldungen wie folgt
LibClamAV Warning: Cannot dlopen libclamunrar_iface: libclamunrar_iface.a: cannot open shared object file: No such file or directory - unrar support unavailableBei den Roundcube relevanten Schritten kam diese Meldung:
Updating database schema (2020020101)... [FAILED]
ERROR: Error in DDL upgrade 2020020101: [1025] Error on rename of './roundcubemail/cache' to './roundcubemail/#sql2-415a-3' (errno: 152)Ich kann momentan nicht viel meckern, danke für alles. Ad hoc würde mein einfallen:
- Durchgängigere IPv6 Unterstützung. Man kriegt es zwar im großen und ganzen hingebastelt, scheitert aber dann letztendlich an der pd-admin Oberfläche, die dann via ipv6 Zugriff die Lizenz wohl nicht validieren kann.
- DKIM: Vielleicht könnte man hier den Selector selbst wählen?
- 2FA: Integration von Authenticator Apps anstatt E-Mail als zweiten Faktor
Ich denke ich kenne den Fehler. Also zwar nicht an dieser Stelle und nicht im Zusammenhang mit pd-admin, aber ich hatte das schonmal bei einer Webanwendung und einem PC eines Kunden. Es war dann in Zusammenhang mit einem Browser Plugin bei ihm, ich glaub irgendsoein Safe Surf Plugin von AVG. Nachdem ich das rausgeschmissen habe, ging alles.
Wie sieht es aus wenn du unterschiedliche Browser probierst bzw. das ganze mal in einem Privaten Tab (ohne geladene Plugins) versuchst?
PD-Admin selbst ist kein DNS Panel.
Also irgendwo (vermutlich bei dem Anbieter wo die Domain registriert ist) wirds einen DNS Zugang geben oder zumindest einen Ansprechpartner, wo man den Wunsch nach einem neuen Record einwerfen kann.
Bei der Gelegenheit noch der Hinweis dass der vorgeschlagene DNS Record den Tag "t=y" enthält. Damit ist der Record im Test Modus und für den Produktivbetrieb weitestgehend sinnlos, weil die meisten Empfänger ihn ignorieren werden.
Das sollte also dann aus dem Record entfernt werden.
Vielleicht hilft es jemandem mal:
Ich hatte auf einem Server eine kleine Rewrite Rule, die Reqeusts auf Bilder an ein Bildererzeuger/Resizer-Script von mir umbiegt:
RewriteRule ^newsletterimage/(.*)$ newsletter/resizeimage.php?src=$1 [L,QSA]Das hat nach einem der letzten SEU Updates nicht mehr funktioniert, wenn der Bildname der hier in meinem Fall übergeben wird (und zum Teil des Rewrites wird) ein Leerzeichen oder andere Sonderzeichen enthielt. Ging vorher jahrelang klaglos. Im Error Log kam die Meldung "Rewritten query string contains control characters or spaces".
Gemäß https://webmasters.stackexchan…trol-characters-or-spaces hat sich hier etwas in den letzten Apache Versionen geändert. Eine Regel wie diese muss nun lauten
RewriteRule ^newsletterimage/(.*)$ newsletter/resizeimage.php?src=$1 "[L,QSA,B= ?,BNP]"Daniel Bradler , in dem Zusammenhang könnte man vielleicht den Download Link unter https://www.pd-admin.de/download.php anpassen. Der zeigt nämlich auch auf die 32bit Version, mit der man dann letztendlich bei einer Neuinstallation auf einem modernen System in genau den Fehler rein läuft. Das hat ein paar Neu-Interessenten (nach Empfehlung von mir) schon öfter etwas abgeschreckt.
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.gzIch 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.
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.
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.
