Beiträge von tobiw

    Update von SE 0444 zu 0445:


    | installierte Version: 0444

    | auf dem Server verfügbar: 0445


    Versionsmuster

    SE 0.444 . . . .: 59473

    Neue Dateien . . . . .: 3003

    Ge�nderte Dateien. . .: 8


    Gefunden . . . . . . .: SE 0.444

    Lade die Server-Umgebung (SE) herunter (ca. 350 MB)

    ** Resuming transfer from byte position 939769889

    % Total % Received % Xferd Average Speed Time Time Time Current

    Dload Upload Total Spent Left Speed

    100 213 100 213 0 0 2754 0 --:--:-- --:--:-- --:--:-- 2802


    Prüfe tar-File

    found 0444 in tar file

    Die aktuelle Version 0444 ist bereits installiert.


    tar tfz se-8-0.445.tar.gz | head -1 | cut -c2,4-6

    0444

    Selbige bei verschiedenen Versionen von Centos, Rollback auf Version 027 löst Problem:


    /usr/local/pd-admin2/bin/clamdscan: error while loading shared libraries: libssl.so.3: cannot open shared object file: No such file or directory

    /usr/local/pd-admin2/bin/sigtool: error while loading shared libraries: libssl.so.3: cannot open shared object file: No such file or directory

    /usr/local/pd-admin2/bin/sigtool: error while loading shared libraries: libssl.so.3: cannot open shared object file: No such file or directory

    simscan versions cdb file built. /var/qmail/simcontrol/simversions.cdb

    /usr/local/pd-admin2/bin/clamdscan: error while loading shared libraries: libssl.so.3: cannot open shared object file: No such file or directory

    /usr/local/pd-admin2/bin/sigtool: error while loading shared libraries: libssl.so.3: cannot open shared object file: No such file or directory

    /usr/local/pd-admin2/bin/sigtool: error while loading shared libraries: libssl.so.3: cannot open shared object file: No such file or directory

    Reihe 8 SE 0.406


    Nach erfolgreichem SE-Update schlägt im Anschluss die Dovecot-Konfiguration fehl:


    | se-update.sh done

    |

    |

    | regenerating dovecot configuration

    |

    default_process_limit = <1000>

    mail_max_userip_connections = <50>

    Bestehende Konfiguration wird nach dovecot.2022-08-05-21:40:33 verschoben ...

    OK.

    Konfigurations-Template wird kopiert ...

    OK.

    Datenbankpassword wird ermittelt ...

    VADMINPASSWORD=xxx

    OK.

    Datenbankzugriff wird eingerichtet ...

    OK.

    andere Variablen werden gesetzt ...

    OK.

    Berechtigungen werden angepasst ...

    OK.

    certificate found, enable ssl/tls

    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)


    Der MySQL 8 Server braucht ein wenig Zeit, um vollständig zu starten bzw. um Verbindungen zuzulassen. Das SE-Skript ist hier zu schnell (nachdem der SQL-Server gestartet wurde).

    Das Archiv pdadmin_v4_64.tar.gz beinhaltet Dateien zuletzt modifiziert Ende Juni (Erscheinungsdatum v 4.98). Wurde hier evtl. das Archiv nicht auf 4.99 aktualisiert?

    Nach dem erfolgreichen Update auf Version 4.99 wird die Versionsnummer nicht erhöht:


    /opt/pdadmin/www/administrator/administrator.cgi --version | head -n1

    pd-admin version v4.98

    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!