Beiträge von tobiw

    PD-Version: 4.97

    Update von Reihe 8 SE 402 zu 403


    Wird das SE-Update gemacht, erscheint ( nur in Reihe 8 ) folgender Update-Fehler:


    | ROUNDCUBEMAIL wird upgegradet.

    |

    mysql: [Warning] Using a password on the command line interface can be insecure.

    ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/usr/local/pd-admin2/var/mysql.run/mysql.sock' (2)


    Wird das RCM-Update manuell via dem Shell-Skript im SE-Ordner gemacht erscheint folgender Fehler:


    mysql: [Warning] Using a password on the command line interface can be insecure.

    mysql: [Warning] Using a password on the command line interface can be insecure.

    What version are you upgrading from? Type '?' if you don't know.

    Executing database schema update.

    ERROR: SQLSTATE[HY000] [2054] The server requested authentication method unknown to the client

    ERROR: Failed to connect to database


    Bei Reihe 6 (MySQL 5.7) taucht der Fehler nicht auf!

    Hallo Zusammen,


    teste gerade die neue Funktion der RBL-Listen seit PD-Admin 4.95:


    - Verbesserung: In /opt/pdadmin/etc/rbl.conf kann der Hostname einer
    DNS-Blacklist (z.B. zen.spamhaus.org) hinterlegt werden. Eingehende
    Verbindungen werden von smtp_greylist.pl gegen diese Blacklist
    geprueft.


    Habe die zen-Liste getestet, funktioniert auch soweit! Habe nun eine weitere Liste hinzugefügt. Laut meinen Tests wird nur die erste Liste berücksichtigt!

    Wie ist diese Funktion implementiert? Ist hier nur eine Liste vorgesehen?


    Viele Grüße!

    Super! Habe eine ähnliche Änderung des Skripts temporär auch bei mir vorgenommen, dann hat der Import hier soweit funktioniert!


    Hast recht, hatte da nicht im Detail nachgeschaut. Habe es im Anschluss des SE-Upgrades auch mit "set password for root@localhost='$MPW';" gemacht, damit hat es dann auch funktioniert!


    Habe es nun auch soweit am laufen. Kurz zusammengefasst mein Feedback dazu.


    Problem war, dass MySQL 5.7 mit "mysql_native_password" arbeitet und Version 8 mit "caching_sha2_password". Somit funktionieren die importierten Passwörter aus der "mysql_privileges.pl" nicht. Eine Möglichkeit ist die default_authentication wieder auf "mysql_native_password" global zu setzen oder dieses entsprechend per user in der Datenbank.

    Habe mich für die neue Standard-Authentifizierung entschieden, musste aber entsprechend alle Passwörter der MySQL-Benutzer neu setzen (Benutzer waren durch das Perl-Skript ja bereits angelegt).

    Wichtig noch: Habe den root-Benutzer aus dem erstellten Export "mysql_user.yaml" vor dem Reimport entfernt, sonst wird beim Import dieser wieder überschrieben mit dem Hash aus 5.7 und es ist danach kein Login mehr in den MySQL-Server möglich.


    phpMyAdmin und Roundcubemail funktionierten nach dem Update auch nicht mehr (selbst auf einer aktuellen PHP-Version). Hier war in der .htaccess im Root-Verzeichnis noch ein SetEnv "PHP5_VERSION 7.3.99" gesetzt. Nach Aktualisierung hier aber alles Tiptop!


    Ansonsten konnte ich bisher keine gravierenden Fehler feststellen. Was mir aufgefallen ist, dass via PMA bei einem SQL-Benutzer keine globalen Rechte gesetzt werden können. PMA schmeißt hier dann einen SQL-Fehler. Aber dafür gibts ja zum Glück noch die CMD!

    Habe soeben das Upgrade auf Reihe 8 einmal via den beiden Dateien "mysql_privileges.pl" und "dump_databases_for_upgrade.sh" manuell versucht und einmal automatisiert via dem Skript "mysql_upgrade.sh", welches ja letztendlich beide oben genannten Dateien nutzt!


    Generell funktioniert das Upgrade bis zu einem bestimmten Punkt (ausgenommen spezifische Variablen, die in der my.cnf gesetzt worden sind, welche dann den Server nicht starten, müssen vorher entfernt werden):


    Der neue MySQL-Server startet, jedoch kann das alte root-Passwort nicht mehr so in neueren MySQL-Versionen gesetzt werden:


    MPW=$(cat /opt/pdadmin/etc/mysql_rootpw.conf)

    /usr/local/pd-admin2/bin/mysql -e "set password for root@localhost=password('$MPW');"


    Hier muss dann mit "ALTER USER" das Passwort gesetzt werden, was dann auch schließlich klappt!

    Gescheitert ist aber letztendlich das Upgrade, da das Skript "mysql_privileges.pl" nicht mit MySQL 8 kompatibel zu sein scheint. Beim Import der zuvor exportierten Dateien gibt es folgende Fehlermeldungen beim Import:


    Use of uninitialized value $exists in concatenation (.) or string at /root/mysql_privileges.pl line 121.

    vadmin localhost --

    -- create user 'vadmin'@'localhost' identified by 'fhajfh493^F*Yhvndkk-3i' --

    -- update mysql.user set Password=? where user=? and host=? --

    DBD::mysql::st execute failed: Unknown column 'Password' in 'field list' at /root/mysql_privileges.pl line 49.


    Daher ist mein Upgrade bisher an diesem Punkt gescheitert! Gibt es hier evtl. eine aktualisierte Version der Datei "mysql_privileges.pl" oder ne Idee?

    Denke du hattest das gleiche Problem (kein Login im DB-Server, fehlende Passwörter...), da das Skript nicht korrekt importiert hat!

    Moin Zusammen,


    nutze auf allen Servern die Reihen 6. Nun brauche ich für gewisse Anwendungen min. MySQL 8. Auf welche Reihe ist es sinnvoll zu upgraden (eure Erfahrungen wären hier gut!).

    Laut SE-Update sind ja die Reihen 8 und 9 noch experimentell. Nutzt ihr diese produktiv?

    Reihe 7 macht für mich keinen Sinn, da ja MariaDB 10.2 bereits kurz vor EOL steht und ich mir dann mit den Upgrades evtl. doppelte Arbeit mache!


    Viele Grüße

    Umgebung: pd-admin version v4.83, 32-bit, SE-Version 0.385 (Series: 3)

    Server ist ein Centos 6 64 bit


    Im Reseller-Menü (Administrator) kann keine optionale IP hinzugefügt werden:


    Software error:

    Code
    Undefined subroutine &main::lock_table called at /opt/pdadmin/www/administrator/administrator.cgi line 3894.

    For help, please send mail to the webmaster ([no address given]), giving this error message and the time and date of the error.

    Das gleiche Problem tritt auch bei einer manuellen Passwort-Änderung für einen Endkunden im Administrator-Menü auf:


    Software error:

    Code
    Undefined subroutine &main::check_param_passwd called at /opt/pdadmin/www/administrator/administrator.cgi line 5169.

    For help, please send mail to the webmaster ([no address given]), giving this error message and the time and date of the error.



    Edit: Das Problem tritt in allen Konstellationen auf, welche mit Passwort-Änderungen bzw. Setzung zutun hat!

    Hallo Zusammen,


    habe folgenden Fehler beim Neuanlegen einer Email-Adresse im Customer-Bereich:


    Software error:

    Code
    Undefined subroutine &main::check_param_passwd called at /opt/pdadmin/www/customer/customer.cgi line 4358. at /opt/pdadmin/www/customer/customer.cgi line 312

    For help, please send mail to the webmaster ([no address given]), giving this error message and the time and date of the error.



    Umgebung: pd-admin version v4.83, 32-bit, SE-Version 0.385 (Series: 3)

    Server ist ein Centos 6 64 bit


    Könnt ihr den Fehler reproduzieren? Habe diesen auf allen Servern in oben genannter Konstellation!

    Danke, Problem ist mit 4.83 behoben! Die Umstellung auf 64-bit ist in kürze inkl. Serverupgrade geplant!


    Gibt es ne schnelle Möglichkeit, die Statistiken für AWstats und Webalizer nachzuberechnen (also vom 23.6 bis heute)? Es wird beim Durchlauf von "/opt/pdadmin/bin/stats_awstats.pl" nur der aktuelle Tag berechnet!

    Hallo Zusammen,


    wir nutzen auf allen PD-Admin-Servern die SE-Version 0.385 sowie die aktuellste PD-Admin_Version v4.82.

    Als Betriebssystem kommt Centos 6 und 7 alle 64Bit zum Einsatz. PD-Admin wird auf Centos 6 in 32Bit genutzt, auf Centos 7 in 64Bit.

    Jetzt haben wir das Problem, dass seit dem 23. Juni alle Access-Logs der einzelnen vhosts (BSP: /home/user/logs/www.domain.de-access.log) nicht mehr generiert werden, allerdings nur in der 32Bit Variante unter Centos 6. Unter Centos 7 mit PD-Admin 64Bit läuft alles wunderbar. Am 22. Juni ist die SE 0.384 und die PD-Version 4.82 erschienen, welches ich auch zeitnah vermutlich installiert habe (sorry kann dieses nicht mehr ganz genau nachvollziehen).

    Der Prozess httpd_log.pl (inkl. ein strace) bleibt hängen und es tut sich nichts!


    Habt ihr auch evtl. den Fehler (zumindest bei den 32Bit Maschinen)? Aufgefallen ist dieses, da keine aktuellen Statistiken in AWstats mehr generiert werden.

    Klar, kann man so machen, jedoch wird dann jeweils immer ein neuer eigenständiger vhost in der Config und kein ServerAlias erstellt. Somit explodiert irgendwann die Config bei sehr vielen Domains, und wie du bereits sagst, der Administrationsaufwand! Zusätzlich belegt jede Domain einen Lizenzzähler!

    Hallo Zusammen,


    habe soeben PD-Admin 4.74 inkl. aktueller SE 6.0.374 installiert und alles auf dehydrated umgestellt.

    Leider übernimmt das Skript "/opt/pdadmin/bin/letsencrypt" nur die Hauptdomains und vernachlässigt immer noch sämtliche Co-Domains. Habe vorher, wenn Codomains existierten, diese via certbot-auto generiert, also an PD-Admin vorbei. Dieses hat auch problemlos funktioniert. Dieses klappt nun auch mittels dehydrated selbst, allerdings überschreibt "/opt/pdadmin/bin/letsencrypt" beim nächsten Cron-Durchlauf wieder die Domains und die Codomains fliegen wieder raus!


    Wie macht ihr das mit den Codomains? Bekomme ich das irgendwie auch mit PD-Admin Bordmitteln hin? Wir nutzen sehr viele Codomains bei vielen Seiten!

    /opt/pdadmin/www/administrator/administrator.cgi --version


    [Thu Sep 24 11:55:24 2020] administrator.cgi: "my" variable $mxadd masks earlier declaration in same scope at /opt/pdadmin/www/administrator/administrator.cgi line 5757.

    pd-admin version v4.67

    (c) 1999 - 2020 by Bradler & Krantz GmbH & Co KG

    Hallo Zusammen,


    habe soeben auf 2 Servern ein Update auf PD-Admin 4.67 gemacht (SE 6-3.66 und 6-0.365), nun funktioniert bei beiden Servern kein PHP via FPM mehr.

    Im Browser wird der PHP-Quelltext ausgegeben. CGIwrap funktioniert noch einwandfrei.

    Im Apache-Log erscheint nur ""GET /info.php HTTP/1.1" 304".


    Könnt ihr das nachvollziehen bzw. habt ihr dieses auch bereits bemerkt?


    Nachtrag:


    Auf beiden Servern funktioniert seither auch der mod_status nicht mehr, erreichbar via SERVERNAME/server-status (not found). Dieser hat seit etlichen Jahren und Updates sauber funktioniert! die httpd.conf sieht allerdings gut aus!

    Nutze den Apache 2.4.



    Nachtrag 2:


    Die Fehler sind behoben (FPM sowie mod_status), sobald ich den Apache von 2.4 auf 2.2 wechsele, scheint also irgendwas mit dem Apache 2.4 nicht korrekt zu sein