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).
ja so sollte es nun sein, aber die neue "passwd" wurde mit userdb_sieve=/var/mail/user/1/dovecot.sieve erstellt bzw. nicht angepasst.
Dieser Pfad stimmt doch. Ich verstehe das Problem nicht.
Richtig ist userdb_sieve=/var/mail/user/1/dovecot.sieve - also ohne Maildir/.
Aktualisieren Sie bitte noch mal das liveconfig3-Paket (Build 16484) - dieser sollte kurz nach der Installation die /etc/liveconfig/sysconfig aktualisieren (so dass dort 61 steht), und damit auch die Maildir-Einstellungen korrigieren.
mail_driver=maildir ist korrekt und wird auch weiterhin so bleiben, vielmehr fehlte die Einstellung mail_path = ~ (sollte dieses Update korrigieren)
Bei den NGINX-vHosts wurde zwar http2 on; eingetragen, durch einen Fehler in der Versionsprüfung aber zusätzlich auch noch listen ssl http2; - das sollte nun auch korrigiert sein.
Leider können wir nicht alle denkbaren Einstellungskombinationen automatisiert durchtesten, es tut mir leid dass die Debian13-Konfiguration einiges an "Schluckauf" mit sich brachte.
Gibt es neben dem "Requested resource not found" auch eine Fehlermeldung im "Produkt:"-Dropdown?
Oder werden Sie nach dem Speichern auf eine Seite weitergeleitet, welche "Requested resource not found" anzeigt?
Was wird beim Anlegen/Speichern alles in /var/log/liveconfig/liveconfig.log protokolliert?
Hallo,
ab sofort stehen die LiveConfig-Versionen 2.18.4 und 3.0.3 in den Repositories zum Download bereit.
Es handelt sich hier um reine Bugfix-Updates - alle Details finden sich wie immer im Changelog.
Eine wichtige Änderung betrifft Debian 13 (bzw. Dovecot 2.4): dort wurden Postfächer vorübergehend fälschlicherweise in einem Maildir/-Unterverzeichnis (also z.B. /var/mail/web1/1/Maildir) angelegt. Dieses Update korrigiert das (weil sonst von Debian 12 auf 13 geupgradete Systeme nur leere Postfächer anzeigen würden), ggf. inzwischen vorhandenene Mails aus einem Maildir-Unterverzeichnis werden dabei eine Ebene "nach oben" kopiert und Dovecot zeigt nun per mail_path = ~ auf das "richtige" Verzeichnis zeigt.
Vielen Dank an dieser Stelle an die vielen Rückmeldungen, Bugreports und Unterstützung bei der Behebung von Fehlern!
-Klaus Keppler
Dann stimmt etwas nicht 
Was wird nach einem Neustart von LiveConfig in /var/log/liveconfig/liveconfig.log protokolliert?
Das sollte normalerweise etwa so aussehen:
[2025/08/25 09:04:40.982359] [402569|402573] [LUA] Detected 'Debian GNU/Linux 13.0 (Trixie)'
[2025/08/25 09:04:43.405040] [402569|402573] [LUA] Stopping Dovecot service
[2025/08/25 09:04:43.769133] [402569|402573] [LUA] Checking 'mail_path' setting in /etc/dovecot/dove
cot.conf
[2025/08/25 09:04:43.810158] [402569|402573] [LUA] Running '/usr/lib/liveconfig/lcservice.sh move-do
vecot-maildirs'
[2025/08/25 09:04:43.937066] [402569|402573] [LUA] Starting Dovecot serviceJetzt folgende Fehlermeldung: The requested resource couldn't be found.
Das Zertifikat wird nicht angelegt.
Bei der selben Eingabemaske wie oben? (#3)
Hat der betroffene Kunde einen eigenen Let's-Encrypt-Account?
Der Fehler bestand darin, dass bei in LiveConfig 2.x angelegten Let's-Encrypt-Accounts nicht alle Eigenschaften in LC3 importiert wurden um diese da nun auch verwenden zu können. Das Update (3.0.3 und 2.18.4) holt diese Änderungen nach - bei unseren Tests hier mit von 2.18.x geupgradeten Servern lief alles reibungslos durch... 
mit dem Update heute auf LiveConfig 3.0.3 (16481) wurde bislang nichts an der Dovecot Struktur unter /var/mail/ wieder zum Urzustand verändert.
Das dürfte nur dann der Fall sein, wenn Sie die Preview-Version vom Wochenende installiert hatten. Beim heutigen offiziellen Release (3.0.3-r16481) haben wir das "Aufräumen" der Maildir-Verzeichnisse erfolgreich getestet.
Im (nur!) diesem Fall ändern Sie in /etc/liveconfig/sysconfig den Wert für LC_CFGVERSION von 61 zurück auf 60 und starten LiveConfig noch mal neu.
Die Updates (2.18.4 und 3.0.3) wurden eben in den Repositories veröffentlich. Details dazu gleich in einem separaten Thread.
Allgemein zu Let's Encrypt: es ist nicht notwendig, dass sich Endkunden eigene Let's-Encrypt-Accounts anlegen. Im Idealfall sollte TLS inzwischen völlig transparent für Endkunden funktionieren: der Admin richtet einen "zentralen" Let's-Encrypt-Account ein, und Endkunden aktivieren beim Anlegen/Bearbeiten einer Subdomain lediglich die TLS-Checkbox. Den Rest macht LiveConfig automatisch.
Je weniger Optionen "normale" Endkunden an der Stelle haben, desto weniger Verwirrung und Rückfragen. Die Berechtigung "TLS/SSL-Verwaltung" ist eigentlich nur für die Fälle relevant, wenn Kunden "eigene" Zertifikate mitbringen und selber verwalten wollen (aus welchen Gründen auch immer, aber sicher eher die Aufnahme als die Regel).
Ok, der Fehler konnte lokalisiert werden - betroffen sind aus LiveConfig 2.x übernommene TLS-Accounts (Let's Encrypt). Neu angelegte TLS-Anbieter funktionieren.
Wir beheben das eben, Update kommt gleich...
Könnten Sie bitte noch kurz beschreiben, wo/wie Sie das TLS-Zertifikat anlegen wollen und Sie dann diesen Fehler erhalten? (sind Sie als Admin oder Endkunde angemeldet & in welcher Eingabemaske wollen Sie das Zertifikat anlegen)
Prinzipiell funktioniert das nämlich durchaus.