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!

Danke für die Info!

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!

Zitat von Sumeragi

Das stimmt so nicht. SET PASSWORD kann bei MySQL 8 verwendet werden. Die Empfehlung lautet aber ALTER USER zu verwenden.

Bei der MySQL 5.7 Dokumentation wird angeführt, dass SET PASSWORD mit =PASSWORD('auth_string') in MySQL 8.0 entfernt wird und dann nicht mehr zulässig ist. Dies ist so auch im Manual für MySQL 8.0 angegeben und erklärt dann auch den Fehler. Die Zeile ist für ein Upgrade auf MySQL 5.7 geeignet, nicht aber für ein Upgrade auf MySQL 8.0. Daraus resultieren dann auch Folgefehler... Dies fiel bei mir nicht auf, da eben der Dienst nicht richtig startete und ich danach alle weiteren Schritte händisch gemacht hatte.

Schaut man sich einmal MySQL 8 an, gibt es in der mysql.user Tabelle keine Spalte mit Password mehr. Diese lautet nun authentication_string, was dann auch die Fehlermeldung erklärt

Es scheinen mir eher kleine Anpassungen notwendig, um ein automatisiertes Upgrade auf MySQL 8.0 durchführen zu können. Im Zweifelsfall sollten manuelle Schritte (wie hier) aber auch gehen.

Alles anzeigen

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

das problem ist mit PD-Admin v4.84 behoben!

Ein kleiner Teil unserer Server laufen noch in dieser Konstellation! Der Großteil läuft auf 64Bit mit aktuellstem Centos inkl. der Reihe 6.

Leider ist so ein Betriebssystemwechsel inkl. Upgrade der Reihe nicht eben gemacht, ist aber zeitnah geplant!

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:

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:

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:

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!

Nee, das ist ja das Problem, es kommt kein Output und das Script wird nicht fertig! Ein Strace auf den Prozess bleibt stehen!

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.

Kann das Problem auf einem Testserver bestätigen!

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!

Danke für die Info...

Also scheint es so als muss ich mir hier doch etwas Eigenständiges zusammen bauen...

Schade, dass es mit den Bordmitteln nicht funktioniert...

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

Top, läuft mit der 4.68 wieder!

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