Starten Sie LiveConfig bitte mal neu. Melden Sie sich dann als "admin" an und gehen auf "Serververwaltung" -> "Datenbanken". Wird dort "Status: verbunden" angezeigt?
Ist evtl. beim Upgrade irgendwas schief gelaufen? Führen Sie ggf. mal das Programm "mysql_upgrade" aus (als root)
Welche Datenbank *genau* verwenden Sie? Die bei Debian 11 mitgelieferte MariaDB 10.5.x?
Werden bei einer (erfolglosen) Passwortänderung über LiveConfig irgendwelche Meldungen in /var/log/liveconfig/liveconfig.log protokolliert?
Nur so ein Gedanke: Die angenehmste Lösung wäre natürlich, dass die Hashes bei erfolgreicher Passworteingabe automatisch aktualisisiert werden.
Sehe ich persönlich auch so, wird aber leider nicht klappen.
LiveConfig bekommt nichts davon mit, wenn sich ein virtueller FTP-Benutzer anmeldet - das läuft komplett im pam_userdb ab. Das greift wiederum nur lesend auf die passwd-Datenbank zu.
LiveConfig kennt die Passwörter auch nicht im Klartext (um die pauschal neu zu setzen): nach dem Anlegen/Aktualisieren des Hashes wird das Klartext-Passwort im LC gelöscht.
Also, der Hintergrund dürfte nun klar sein.
Alte pam_userdb-Versionen haben ausschließlich nur DES-Passwörter unterstützt. Besonders schlimm sind da immer alte CentOS-Versionen betroffen, da es dort keinen bequemen Upgrade-Pfad wie bei Debian/Ubuntu gibt.
Da CentOS 6 ja nun langsam aber sicher ausstirbt, und wir Ubuntu 14 LTS auch nicht mehr offiziell unterstützen (das würde noch bis April 2024 dauern!), sollte eine Umstellung keine Auswirkungen haben.
Die interne Ursache (warum das auf manchen Systemen klappt und auf anderen nicht) liegt eventuell in der zugrundeliegenden Crypto-Bibliothek. Modernene OpenSSL-Builds enthalten gar kein DES mehr, wie das mit GNU-Crypto aussieht weiß ich ehrlich gesagt gar nicht.
Viele Grüße
-Klaus Keppler
Ich habe das eben mal geprüft: LiveConfig ruft bei "LC.crypt.crypt()" eine crypt-Variante von OpenSSL auf. Bislang war diese offenbar immer identisch mit der (nicht-portablen) POSIX crypt()-Funktion, welche pam_userdb für den Passwortvergleich nutzt.
(wir testen das ja automatisiert durch - auf jeder unterstützten Distibution wird u.a. auch ein virtueller FTP-User angelegt und ein Login mit diesem durchgeführt)
Wir planen nun, LC.crypt.crypt() auf die POSIX-Variante umzustellen, müssen aber prüfen dass das bei alten Systemen keine Probleme macht. Parallel prüfen wir, ob sich die alten Hashes übergangsweise weiter nutzen lassen - alternativ werden dokumentieren wir man auslesen kann, welche Accounts betroffen sind.
Update folgt in Kürze...
Ein anderer Kunde hatte uns auch schonmal von diesem Problem berichtet - allerdings können wir das leider nicht reproduzieren.
Je nach Systemkonfiguration kann es sein, dass nach dem Upgrade keine "alten" crypt()-Hashes mehr für die Passwortprüfung beim proftpd funktionieren (um genau zu sein: im Modul pam_userdb.so).
Ändern Sie testweise mal in der Datei /usr/lib/liveconfig/lua/vsftpd.lua die Zeile 675 ab, und ersetzen darin "crypt(...)" durch "crypt_md5(...)":
pwd = LC.crypt.crypt_md5(pwd)Anschließend bitte LiveConfig neu starten, dann das Passwort eines virtuellen FTP-Accounts noch einmal ändern und damit dann die Anmeldung versuchen.
Wir prüfen aktuell ob es möglich ist, dass pam_userdb.so auch die "alten" Hashes weiterhin akzeptiert. Laut man-Page zu pam_userdb sollte mit der PAM-Option "crypt=crypt" ja eben ein "crypt()"-Passwort akzeptiert werden - tut es aber nicht. 
Ein Login ist jedenfalls per SSH über web6 nicht möglich, er sagt immer "Falsches Passwort". PW für Hauptbenutzer geändert, keine Änderung.
Viele Grüße
-Klaus Keppler
Die Arbeiten kommen gut voran:
$ curl -k -H "Accept: application/json" \
-H "X-API-Key: xxxxx" \
-H "Content-Type: application/json" \
-X POST -d '{"id":"localhost"}' \
"https://127.0.0.1:8443/api/v1/servers"
{"detail":{"id":[B]"Name bereits in Verwendung"[/B]},"status":400,"success":false,"title":"Bad Request"}
$ curl -k -H "Accept: application/json" \
-H "X-API-Key: xxxxx" \
-H "Content-Type: application/json" \
-H "[B]Accept-Language: en[/B]" \
-X POST -d '{"id":"localhost"}' \
"https://127.0.0.1:8443/api/v1/servers"
{"detail":{"id":[B]"Name already in use"[/B]},"status":400,"success":false,"title":"Bad Request"}
Die folgenden APIs sind bereits fertig:
Wir planen weiterhin am 31.01.2022 die erste Beta-Version bereitzustellen, die dann parallel zu einer bestehenden LiveConfig 2.x-Installation getestet werden kann.
Da jede einzelne Eingabemaske und jede einzelne API-Funktion angepasst werden müssen, und wir im Zuge des Umbaus auch unzählige Detailverbesserungen vornehmen, wird die "Beta-1" im Funktionsumfang natürlich noch recht beschränkt sein. Aber ich kann jetzt schon sagen: die Arbeit lohnt sich.
Viele Grüße
-Klaus Keppler
oder die gewünschte PHP-Version vor den Standard-Suchpfad stellen:
PATH="/opt/php-7.4/bin:$PATH" php /var/www/admin/priv/roundcubemail-1.5.1/bin/installto.sh /var/www/admin/apps/webmail/Unsere PHP-Pakete enthalten (eigentlich) durchaus mbstring.
Der Roundcube-Updater wird ja i.d.R. immer mit der PHP-CLI-Version der Distribution ausgeführt, daher muss da das Paket "php-mbstring" (Debian/Ubuntu) installiert sein.
Viele Grüße
-Klaus Keppler
In der Datei /usr/lib/liveconfig/lua/web.lua finden Sie in Zeile 890 das hier:
value = string.gsub(value, "%%PHP%%", code)
Fügen Sie danach einfach folgende Zeile hinzu:
value = string.gsub(value, "%%USER%%", opts.user)
Anschließend LiveConfig noch neu starten.
Damit wird %%USER%% durch den Benutzernamen (=Vertragsnamen) ersetzt.
Hallo,
derzeit werden nur diese beiden Platzhalter (%%HOME%%, %%PHP%%) ersetzt.
Wozu bräuchten Sie denn den Vertragsnamen? Wir können den gerne ins nächste Update aufnehmen (ist nur eine Kleinigkeit)
Viele Grüße
-Klaus Keppler
Dann MySQL mal neu starten, und das MySQL-Log auf Fehler hin beobachten.
(LiveConfig kann da nichts machen, dieser Fehler hat alleine mit MySQL zu tun)
/dev/simfs deutet auf OpenVZ hin. Da hat die Ausgabe von "df" nichts zu bedeuten, es kann sein dass der entsprechende Host voll ist.
Versuchen Sie einfach mal, eine 1 GB große Datei anzulegen:
dd if=/dev/zero of=/test.dat bs=1M count=1024Google-Suche nach "Got error -1 from storage engine", erster Treffer.
Festplatte voll?
Ja, die Datei ist quasi statisch - können Sie einfach kopieren.
Wenn die Datei /etc/liveconfig/lclogparse.conf (noch) existiert, dann können Sie den Service so wieder aktivieren:
cp /usr/lib/liveconfig/lclogparse.service /lib/systemd/system/
systemctl daemon-reload
systemctl enable lclogparse
systemctl start lclogparseLiveConfig "kann" diesen Dienst gar nicht direkt deaktivieren, evtl. war das mal eine Servermigration oder LiveConfig-Deinstallation.
Diese Meldung alleine hilft leider nicht weiter, die sagt nur dass während des Upgrades dieses Paketes irgendein Fehler aufgetreten ist. Die eigentliche Meldung steckt(e) dann weiter oben in dem ganzen Upgrade-Output.
Es kann sein, dass das nur eine Kleinigkeit war (z.B. dass der Dienst nach dem Upgrade nicht neu gestartet werden konnte). Uns sind da jedenfalls bislang keine Probleme bekannt oder anderweitig gemeldet worden.
Viele Grüße
-Klaus Keppler
Hallo,
unsere PHP-Pakete für Debian/Ubuntu wurden eben aktualisiert - und zwar alle: PHP 5.6/7.0/7.1/7.2/7.3.
(die Versionen 7.4 und 8.0 wurden im Rahmen der normalen Updates bereits kürzlich aktualisiert).
Alle Pakete enthalten somit den Patch für PHP-Bug #81026 (CVE-2021-21703).
Es handelt sich um einen Bug in PHP-FPM, der es Angreifern ermöglicht, durch Ausnutzung anderer (weniger kritischer) Fehler schlimmstenfalls root-Rechte zu erlangen. Betroffen sind demnach alle PHP-Versionen, welche mit FPM laufen (also ab Version 5.3).
Ein Exploit hierzu wurde noch nicht veröffentlicht, das dürfte aber nur eine Frage der Zeit sein. Wir empfehlen daher dringend allen Admins, die PHP-Pakete entsprechend zu aktualisieren.
(die PHP-Pakete für CentOS aus dem Remi-Repository sind übrigens auch schon gepatched)
Viele Grüße
-Klaus Keppler
Das ist wie mit dem Adventskalender, ein bisschen Spannung muss doch erhalten bleiben. 