Gehört die betroffene Domain einem "eigenen" Kunden, oder ist da möglicherweise noch ein Reseller dazwischen?
Aktuell ist hier ein Issue offen, dass man Domains von Reseller-Kunden zwar in der Suche angezeigt bekommt, aber nicht direkt "hineinspringen" kann.
Hallo,
unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 8.3.26 und 8.4.13 aktualisiert.
Zudem steht ab sofort der erste "Release Candidate" für PHP 8.5.0 (RC1) in unseren Repositories bereit. Da PHP 8.5 etwas mehr Änderungen mit sich bringt, sind leider noch nicht alle Extensions damit kompatibel - wir beobachten das und liefern diese bei Verfügbarkeit nach.
Viele Grüße
-Klaus Keppler
Offenbar wurde die Datei tls-lets-encrypt.json irgendwann mal gelöscht. Da das eine Config-Datei ist, wird diese bei einem Update nicht automatisch wiederhergestellt. Das lässt sich aber mit ein paar Tricks lösen:
Sollten bei einem der Schritte Fehler auftreten, bitte nicht weitermachen sondern erst den Fehler hier posten.
Äh - unabhängig davon: Filesystem-Quota würde verhindern, dass ein Server aufgrund eines Webspaces volläuft...
PHP-Anwendungen selbst können mit ini_set() die log_errors-Einstellung zur Laufzeit ändern. In diesem Fall müsste man ini_set in die disabled_functions mit aufnehmen (was möglicherweise andere Nebenwirkungen haben kann).
Oder ein hässlicher aber durchaus wirksamer Workaround: die php_errors.log schreibgeschützt anlegen (z.B. mit chattr +i ... oder chmod 0400 ...), dann kann diese auch nicht mehr wachsen.
Ab LiveConfig 3.0 ist das möglich: Verwaltung -> Einstellungen -> Tab Web-Oberfläche. Da gibt es folgende Box:
Die /etc/liveconfig/tls-lets-encrypt.json wird vom liveconfig3-Paket installiert, eigentlich kann diese nicht fehlen.
Ist vielleicht der Speicherplatz auf dem Server voll? Gab es irgendwelche anderen Fehlermeldungen während der Paketinstallation?
Probieren Sie ansonsten mal ein apt reinstall liveconfig3. Was wird da insgesamt ausgegeben?
ich habe soeben (Debian 12 & nginx/1.29.0) auf die Version 2.18.7 geupdatet und das Problem mit den fehlerhaften Konfigurationen besteht dort weiterhin.
Können Sie bitte eine solche fehlerhafte Konfiguration mal posten? (zumindest den fehlerhaften Abschnitt)
Mit dem Update dürften vHosts nur noch einmal ein http2 on; enthalten...
Die 3.0.4 und 2.18.7 werden voraussichtlich am Montag, 22.09. erscheinen - falls wir schneller fertig werden als geplant vielleicht auch schon am Freitag.
Ja, hier im Forum war's ziemlich genau 7 Werktage lang etwas ruhiger weil ich persönlich kurz im Urlaub war, meine Kollegen hier haben aber weiter Issues abgearbeitet.
Alle größeren Problem sollten soweit behoben sein. Die aktuell bearbeiteten Probleme - z.B. beim Verlängern von Let's-Encrypt-Zertifikaten - hängen mit "speziellen" Konstellationen zusammen die sehr aufwendig zu testen sind (in dem einen Fall z.B. dass es eine Hierarchie von Resellern und Endkunden mit jeweils eigenem Let's-Encrypt-Account gibt). Wir sind da aber dran.
Was uns in den letzten Tagen unglaublich viel Arbeit, Zeit und Nerven gekostet hatte war aber ein massiver DDoS-Angriff auf mehrere Webserver - in einer Dimension die ich so bislang noch nie erlebt habe. Wir reden hier von >10.000 Requests pro IP pro Minute, und das von >4.000 verschiedenen IPs.
Letztendlich profitiert LiveConfig aber auch davon, weil wir entsprechende Abwehrmechanismen da mit einbauen werden.
Bitte updaten Sie einfach auf die eben veröffentlichte Version 2.18.6 - damit sollte dieser Fehler behoben sein.
Zum Upgrade von LiveConfig 2.x auf 3.x wird es demnächst einen Beitrag in der Wissensdatenbank geben (bitte noch ein klein wenig Geduld...)
Viele Grüße
-Klaus Keppler
Hallo,
das ist bzw. war ein Fehler (normalerweise dürfen CNAME-Zielnamen keinen Underscore enthalten, einzige Ausnahme ist wenn der Hostname selbst ein Underscore enthalten darf - siehe [GH-56]).
Mit der aktuellen Preview-Version 3.0.3-4 (Build 16502) ist das bereits behoben.
Sie könnten z.B. das entsprechende Paket direkt per wget vom Repo-Server laden und mit dpkg installieren (liveconfig3_3.0.3-4.16502_amd64.deb).
Die automatische Verlängerung von Liveconfig hat nun bei den zu verlängernden Zertifikaten den Job doppelt angelegt.
Sind hier mehrere Let's-Encrypt-Accounts vorhanden? (z.B. einer beim "admin" und einer beim Kunden?)
Von 2.18.4 zu 2.18.5 gab es nur einen "regression bugfix" (falls Dovecot 2.4 verwendet wurde - also Debian 13 - wurde die dovecot.conf nicht automatisch während des Upgrades angepasst, das wird mit dem Update nachgeholt).
Zur o.g. Fehlermeldung mit Let's Encrypt: hier gab es einen Fehler bei der Registrierung von Let's Encrypt (staging). Das entsprechende Plugin ruft hierzu das ACME-Directory vom Server ab - wenn dieses nicht erreichbar ist (z.B. wegen Wartungsarbeiten) bricht das Programm derzeit ab. Das werden wir ändern (so dass das den Start von LiveConfig selbst künftig nicht mehr beeinträchtigt). Issue hierzu lege ich gleich an.
Im nächsten LC3-Update (3.0.4) wird die Staging-Umgebung von Let's Encrypt zudem nicht mehr automatisch aktiviert (das war jetzt für Tests ganz praktisch, in Produktivumgebungen braucht's das aber nicht mehr).
Mit der neuen DNSSEC-Konfiguration (dnssec-policy), dem LiveConfig-Update (ggf. auf V3) und Debian 13 (insbes. Dovecot 2.4) kommen leider gerade sehr viele Sachen auf einmal zusammen. 
Wir bereiten derzeit in der Wissensdatenbank die Anleitung für's Debian 13 Update vor, da nehmen wir die hier beschriebenen Erfahrungen als mögliche Stolpersteine mit auf.
weltmeister: PHP-Versionsumstellung per Klick steht bereits auf der Arbeitsliste (ist für uns mit LC3 auch wesentlich einfacher zu realisieren als mit der "alten" Version).
Für "das gleiche Problem" müsste man wissen, um welches Problem genau es sich handelt. 
Wie genau äußern sich die "nicht erreichbaren" Websites? Erscheint dort eine Fehlermeldung? Was wird bei Web-Zugriffen in den einschlägigen Logfiles (insbes. /var/log/apache2/errors.log) protokolliert? Welche LiveConfig-Version läuft? (2.18.5 oder 3.0.3?)
Sehr wahrscheinlich hat sich auch die PHP-Standardversion geändert (Debian 12 hatte 8.2.x, Debian 13 hat 8.4.x). Es könnte sein, dass die betroffenen Anwendungen/Websites damit vielleicht nicht zurecht kommen.
Bitte alles so anpassen / ermöglichen, das jeder Kunde weiterhin wie bisher seinen eigenen LE-Account ohne Fehlermeldungen nutzen kann.
Klar, wir sind da dran.
Eine kurze Rückfrage noch: wenn Sie (siehe Bild 3) ein solches Zertifikat löschen, dann gibt es die Fehlermeldung "The requested resource couldn't be found", aber das Zertifikat selbst (bzw. der offene Job) ist anschließend gelöscht - oder? (also aus der Liste der Zertifikate, ggf. Seite mal reloaden um ganz sicher zu gehen)
Das ist aber neu in LiveConfig3 (und so auch sinnvoll!), aber bisher in LiveConfig2 so nicht gewesen - oder hab ich die letzten 10 Jahre da was falsch benutzt?
In LiveConfig 2 konnten Endkunden ohne eigenen Let's-Encrypt-Account bislang keine Zertifikate für z.B. Subdomains selber anlegen.
Häufig war/ist einfach als "admin" ein LE-Account eingerichtet, und beim Anlegen neuer Domains konnte mit einer (sogar vorausgewählten) Checkbox automatisch ein Let's-Encrypt-Zertifikat dafür eingerichtet werden. Der Endkunde hat von dem Zertifikat selbst üblicherweise praktisch nichts mitbekommen (die technischen Details interessieren die meisten Anwender ja auch nicht).
mein Fehler er wird mit userdb_sieve=/var/mail/user/1/Maildir/dovecot.sieve erstellt.
Aber sicher nicht durch LiveConfig...
Die von LiveConfig erstellten Einträge in die /etc/dovecot/passwd enthalten definitiv kein .../Maildir/... in userdb_sieve (oder irgend einer anderen Einstellung).
