Beiträge von kk

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.

Zitat von weltmeister

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)

Zitat von antondollmaier

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).

Zitat von Systemhaus-EHST

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).

Zitat von Systemhaus-EHST

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 service

Zitat von weltmeister

Jetzt 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...

Zitat von Systemhaus-EHST

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.

Die Builds laufen aktuell, sobald die fertig sind landen 3.0.3 und 2.18.4 noch heute am (späteren) Abend im Test-Repository.

Wenn damit dann alles passt, wird das am Montag in die Stable-Repositories veröffentlicht.

Viele Grüße

-Klaus Keppler

Ja, LC3 ist zu LC2-Clients "abwärtskompatibel". Allerdings stehen manche Funktionen wie z.B. Web-Terminal mit LC2-Clients nicht zur Verfügung.

Diese Kombination (LC3-Server + LC2-Client) wird von uns auch ausdrücklick supported, sollte es zu Problemen kommen bitte einfach melden (wir können da leider technisch bedingt nicht mehr alle denkbaren Kombinationen durchtesten).

LC3 unterstützt kein CentOS7/8 mehr, dafür die 9er (Rocky 9 etc.).

ACHTUNG!

IMAP-Postfächer sind nach einem Upgrade auf Dovecot 2.4.1 derzeit "leer", weil Dovecot ärgerlicherweise einen Standardwert ohne Hinweis in der Dokumentation geändert hat. Alle Details sind im Issue GH-42 zu finden.

"Frische" Installationen sind von diesem Symptom nicht betroffen (auch wenn die Mails nun alle im "falschen" Ordner liegen)

Wir werden das mit dem kommenden Update 2.18.4/3.0.3 korrigieren und inzwischen neu angelegte Postfächer dann automatisch in den "richtigen" Ordner verschieben. Das Update ist für morgen Nachmittag oder spätestens Vormittag geplant.

Die waren lediglich noch nicht in der aktualisierten Build-Pipeline vorhanden.

Die Pakete sind ab sofort in den Repositories enthalten.

Hmm, ich hatte gedacht dass die Paketscripte das wieder glattziehen - aber das tun sie scheinbar nicht.

Ich schaue mir das an und gebe dazu nochmal Rückmeldung!