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. 
Eine reine DNS-Verwaltung von Domains (also "ohne Webspace") ist mit LiveConfig nicht möglich.
Webspace wird rein technisch auch schon für Weiterleitungen benötigt (irgendein Webserver muss ja konfiguriert werden, um Anfragen entsprechend weiterzuleiten).
Zum Ändern der Standard-Version: https://www.liveconfig.com/de/…d-php-version-%C3%A4ndern
Wenn die Distribution PHP 7.4.x mitbringt, dann gibt es eigentlich keinen dringenden Grund, statt dessen das PHP 7.4.x von LiveConfig zu installieren. Auch wenn die Versionsnummer der Distributions-Variante kleiner ist, enthält dieses dennoch alle relevanten Sicherheitspatches.
Im Zweifelsfall kann man aber über "Serververwaltung" -> "Web", Box "PHP-Versionen" eine nicht mehr gewünschte PHP-Version ausblenden (Checkbox "darf nicht für neue Konfigurationen ausgewählt werden" aktivieren).
Viele Grüße
-Klaus Keppler
Bitte prüfen Sie zuerst einmal, was da an DynDNS-Updates hereinkommt.
(geht z.B. via /var/log/liveconfig/access.log - da nach "update" suchen)
Es gibt hirntote DynDNS-Clients, die sekündlich einen Lösch- und danach einen Update-Auftrag schicken. Wäre es "nur" eine sekündliche Aktualisierung dann wäre das kein Problem (LiveConfig ignoriert idempotente Aufträge). Aber ein "Löschen" und "Neuanlegen" ist eben was anderes. Wenn der BIND nun etwas länger braucht als der Client die Updates reinschickt, kann's knallen.
Wir haben bereits ein Rate-Limit für DynDNS-Updates vorbereitet (die technischen Voraussetzungen sind in v2.13 enthalten), der Rest sollte nächste Woche folgen.
Viele Grüße
-Klaus Keppler
Dann müssen wir genau unterscheiden um was für Zertifikate es geht.
Alle gültigen Zertifikate (d.h. innerhalb der letzten 90 Tagen ausgestellt) enthalten die Chain aus "R3" und "ISRG Root X1" (signiert von DST). Daran ändert sich auch mit einem Renewal nichts.
Sollte es noch andere abgelaufene (ungültige) Zertifikate geben, dann stellt sich da ja die Frage nach dem Grund. Sind die Zertifikate "Karteileichen" (aus früheren LC-Versionen, wo LE-Zertifikate nicht automatisch mit der Domain gelöscht wurden), dann ist da auch kein Renewal möglich (da keine Validierung mehr möglich ist).
Aber auch unabhängig davon stellen diese alten (abgelaufenen) Zertifikate per se erstmal kein Problem dar. Wenn auf einem Server ausgehende SSL-Verbindungen zu Let's-Encrypt-Zielen nicht klappen, haben wir ja zwei mögliche Ursachen identifiziert:
Andere Probleme sind uns bislang nicht bekannt, aber mit den vorgenannten Themen hatte auch niemand gerechnet. Sollte es also darüber hinaus noch reproduzierbare Fehler geben, bitte immer her damit. Ohne konkrete Fehlerbeschreibungen können wir aber auch nicht helfen. Wichtig ist immer:
Bei Probleme mit eingehenden Verbindungen brauchen wir einen konkreten Domainnamen, bei ausgehenden Verbindungen sollte man das z.B. mit folgendem Befehl testen:
openssl s_client -connect letsencrypt.org:443 -showcerts -servername letsencrypt.orgWir haben eben die Preview (2.13.0) noch mal aktualisiert. Damit werden die Ablaufdaten der Zwischenzertifikate (Let's Encrypt) korrigiert und somit wieder richtig angezeigt.
Ähm... also bei dem betroffenen Server liegen jetzt unter /etc/apache2/sites-enabled/ keine Verlinkungen mehr sondern die originalen .conf Dateien. Und diese werden bei einer Änderung im LC auch nicht überschrieben sondern nur die im Verzeichnis /etc/apache2/sites-available.
Das sieht irgendwie nicht so ganz gewollt aus.
Danke für den Hinweis, ist im aktuellen Preview-Update (20211005.4) korrigiert. Ein anschließender Aufruf von "/usr/lib/liveconfig/lcservice.sh fix-symlinks" korrigiert das wieder (betrifft nur Systeme wo die Preview 20211004.x installiert war).
Nach einem "force renewal" war denn der Spuk vorbei. Wenn uns das hier nicht hilft... aber ein neu erzeugtes Zertifikat in Liveconfig sieht erstmal so aus, als ob es was bringt.
Um das noch einmal klar zu stellen: ein reines Renewal ändert NICHTS an der Liste der Zwischenzertifikate. Weder mit LiveConfig, noch mit irgendeinem anderen ACME-Client.
Beim Abruf des Zertifikats kann der CA-Server optional verschiedene Chain-Listen als Alternative anbieten. LiveConfig nimmt aktuell immer die von der CA empfohlene (Standard-)Chain.
Offenbar verhält sich der "win-acme" da anders.
Wie bereits erwähnt bereiten wir eine Möglichkeit vor, optional ebenfalls eine andere Chain auszuwählen.
iOS-Geräte sollten mit der Standard-Chain übrigens allgemein keine Probleme haben, höchstens einzelne Apps die mit veralteten oder kaputten SSL-Bibliotheken gebaut sind.
