Beiträge von kk

    Dann stimmt etwas nicht :) Was wird nach einem Neustart von LiveConfig in /var/log/liveconfig/liveconfig.log protokolliert?


    Das sollte normalerweise etwa so aussehen:

    Code
    [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

    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... :/

    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.

    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!

    Mit den eben veröffentlichten Versionen 2.18.3 und 3.0.2 unterstützt LiveConfig nun auch Dovecot 2.4 und somit Debian 13.

    Hallo,


    ab sofort stehen die Versionen 2.18.3 und 3.0.2 in den Repositories zum Download bereit.


    Mit diesen Updates wird nun auch Dovecot 2.4 und somit Debian 13 ("Trixie") unterstützt.

    Die Version 3.0.2 enthält zudem noch einige kleinere Bugfixes (alle Details wie immer im Changelog) - unter anderem gab es einen Fehler beim Bearbeiten von Reseller-Accounts.


    Außerdem kann LiveConfig v3 nun automatisch die Konfigurationsdateien von verwalteten Diensten aktualisieren, wenn sich deren Versionsnummer ändert. Bislang war es vor allem bei "dist-upgrades" immer notwendig, nach dem Update bei einigen Diensten die Konfiguration neu schreiben zu lassen (Serververwaltung -> (Dienst) -> bearbeiten ...). Das erfolgt nun automatisch und vereinfacht Upgrades somit.


    Viele Grüße


    -Klaus Keppler

    Dieses Problem besteht jedoch weiterhin. Wie kann man den Account restlos ohne Fehlermeldungen löschen?

    Mit v3.0.2 haben wir hierfür eine Diagnose-Möglichkeit eingebaut um herausfinden zu können, welche Daten das Löschen blockieren.

    Führen Sie bitte folgenden Befehl aus:

    liveconfig --db-check delete CUSTOMERS CUST_CID 1234

    (statt "1234" bitte die von Ihnen vergebene Kundennummer des zu löschenden Kunden eingeben)

    Der Output wäre dann interessant - bitte entweder hier posten oder an support@liveconfig.com schicken.

    Ja, die Dovecot-Anpassung wird noch bearbeitet (da sind wir mittendrin - das Problem ist weniger die Änderung bei der Config-Erstellung, sondern vielmehr die Anpassung unserer CI-Tests)


    PHP 8.2, 8.3 und 8.4 sind nun auch für Debian Trixie verfügbar (jeweils AMD64/ARM64).

    Alles in einem sind das 268 neue Pakete. :)

    Wir empfehlen auch die Checkbox "Darf nicht für neue Konfigurationen verwendet werden" (Serververwaltung -> Web -> Box "PHP-Versionen") zu nutzen.


    Bis auf weiteres sehen wir uns (leider) gezwungen, diese alten Versionen mitzuschleppen, weil ansonsten manche Admins ihre Server überhaupt nicht aktualisieren ("wenn es auf Debian 13 kein PHP 5.6 mehr gibt, dann kann ich nicht upgraden").

    Aber der Aufwand, das zum Laufen zu bekommen, ist erheblich - und es wird immer mehr. Jetzt kommt bald PHP 8.5 heraus, somit haben wir 12 (ZWÖLF!) PHP-Versionen auf sechs Distributionen und z.T. zwei Hardwareplattformen - das sind 108 (!) Kombinationen. Und Extensions sind da noch gar nicht berücksichtigt.

    Übrigens alles im Preis enthalten - wir berechnen das nicht extra.


    Was ich hier eigentlich eben schreiben wollte: PHP 7.4/8.0/8.1 (inkl. Extensions) stehen für Debian Trixien nun auch bereit. Der Rest folgt voraussichtlich morgen.

    Nein, Debian 13 (Trixie) wird aktuell noch nicht unterstützt (siehe Unterstützte Betriebssysteme).


    Für Dovecot 2.4 müssen wir noch Anpassungen vornehmen (ist bereits in Arbeit), außerdem haben wir noch nicht alle PHP-Versionen portiert.

    PHP 5.6/7.0/7.1/7.2/7.3 inkl. APCu, ImageMagick, Redit, igbinary, memcached etc. sind aber schon fertig (für PHP 5.6 unter Debian 13 sollte man übrigens Schmerzensgeld verlangen). Wenn nichts dazwischen kommt, könnte das bis Ende der Woche abgeschlossen sein.

    Kann ich nicht bestätigen - ich habe jeden Menge Dienste über LC verwaltet (Ubuntu 24) und das wird nicht erkannt - Diag sagt auch: [...]

    Argh... ja, wir haben da einen Fehler gefunden und eben behoben (ist dann auch in 3.0.2 beseitigt). In der Testumgebung waren alle Dienst installiert (aber nicht aktiviert). Wenn ein Dienst nicht installiert war, dann konnte es zu diesem Verhalten kommen. Sorry... :-/