/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.
Das können wir so nicht bestätigen. Wir hatten in den letzten Tagen auf anderen Systemen ein ähnliches Problem mit den LE Zertifikaten, die beide Zwischenzertifikate enthielten und nach einem "force renew" nur noch das aktuell gültige. Alle Probleme waren dann gelöst.
Das halte ich für ausgeschlossen: die von LiveConfig über Let's Encrypt abgerufenen Zertifikate enthalten derzeit immer beide Zwischenzertifikate (das ist derzeit der Standard bei Let's Encrypt). Da muss also irgendwo der Certbot im Spiel gewesen sein (möglicherweise wurde das betroffene Zertifikat mal über den Certbot oder eine andere Drittsoftware mit einer anderen Zertifikatskette angefordert, und LiveConfig hat bei einer späteren Zertifikatsbestellung für die selbe Domain dann auch die "kürzere" Chain zugewiesen bekommen).
Das mitgelieferte "ISRG Root X1" ist nicht abgelaufen (das gilt noch bis 2024), sondern das Zertifikat mit dem dieses unterschrieben wurde (DST Root X3) ist am 30.09.2021 abgelaufen (siehe Erklärung im Blog).
Wir werden aber kurzfristig eine Möglichkeit einbauen, die bevorzugte Zertifikatskette im LiveConfig auszuwählen.
So oder so müssen eventuelle Probleme aber i.d.R. beim jeweiligen Client behoben werden.
Viele Grüße
-Klaus Keppler
Alle von Let's Encrypt ausgestellten Zertifikate enthalten seit vielen Monaten bereits die "neue" Kette an Zwischenzertifikaten (also "R3" und "ISRG Root X1"). Eine Neuausstellung würde daran nichts ändern.
Details werden gerade per Ticket geklärt.
(gelöscht)
Wer Probleme mit wget oder curl unter Debian 9 hat, muss lediglich das System aktualisieren (GnuTLS in älteren Versionen hat Probleme mit dem abgelaufenen DST Root X3, auf aktuellen Debian9-Installationen passt aber alles).
