In der Adminoberfläche lässt sich der Punkt "Erste Schritte" nicht abarbeiten, der Punkt "Erste Schritte künftig nicht mehr anzeigen" ist ausgegraut (wurde glaube bereits schon einmal hier von einem Nutzer angeführt).
Die Checkbox "Erste Schritte künftig nicht mehr anzeigen" ist aktivierbar, sobald mindestens ein Dienst auf dem Server von LiveConfig verwaltet wird (völlig egal welcher).
bei einem Server mit Basic Lizenz ist aufgefallen das laut Erste Schritte eine Vorlage angelegt werden soll, wenn man dieser Aufforderung nachkommen möchte erhält man die Fehlermeldung/Hinweis: Angefragte Funktion ist nicht lizenziert.
Ist mit dem nächsten Update (3.0.2) behoben.
Wenn man unter dem Punkt "Kunden" nach einer Domain sucht, wird nichts gefunden. Das wäre noch eine große Hilfe, um den entsprechenden Account schnell finden zu können.
Sie meinen, wenn man in der Kunden-Tabelle nach einer Domain sucht? Bislang wird dort (bewusst) nur nach Kundendaten gesucht.
Nutzen Sie einfach das Schnellsuch-Feld (ganz oben) - ist auch per "#"-Taste erreichbar. Da werden alle Daten durchsucht.
Alles anzeigenDas hier steht im Log:
[2841599] [2025-08-08 12:50:23.164952] [INFO] Mailbox '39' successfully removed.
[2618575] [2025-08-08 12:50:23.169779] [INFO] LC.smtp.deleteMailbox(xxx.xxx@xxx-xxx.de) OK
[2618575] [2025-08-08 12:50:23.169830] [INFO] [LUA] Deleting mailbox xxx.xxx@xxx-xxx.de from dovecot config file: /etc/dovecot/passwd
[2618575] [2025-08-08 12:50:23.171692] [INFO] LC.popimap.deleteMailbox(xxx.xxx@xxx-xxx.de) OK
Aber das Postfach ist noch durchgestrichen zu sehen.
Wenn Sie die Seite aktualisieren (oder an/abmelden, oder Sortierung der E-Mail-Tabelle mal ändern) - steht das Postfach dann noch immer mit drin?
Das zählen von ein- und ausgehenden Mails scheint noch nicht zu funktionieren. Es steht überall noch nichts in der entsprechenden Spalte.
Sollte eigentlich funktionieren. Prüfen Sie bitte mal, ob der Dienst "lclogparse" läuft (der zählt die E-Mails).
Wenn nicht: welche LiveConfig-Version ist installiert?
Ubuntu 18.04 LTS ist seit Mai 2023 "end of life", Updates dafür gibt es nur noch via ESM.
Wir unterstützen mit Ubuntu 24.04, 22.04 und 20.04 die letzten drei "großen" Versionen.
Am besten wäre es, den Server von 18.04 auf (mindestens) 20.04 zu aktualisieren.
Frisch installiertes Debian 12.11 in einer KVM-VM. Außer der bekannten Meta-Package Abfrage und dem Lizenz-Code gab es während der Installation keine weiteren manuellen Eingriffe.
Während der Installation von liveconfig-meta wird (falls noch nicht vorhanden) auch apache2-suexec installiert. Dabei handelt es sich um ein Meta-Paket, welches von apache2-suexec-custom, apache2-suexec-pristine oder eben lac konkret bereitgestellt wird.
lac (LiveConfig Account Container) gehört wiederum zu LiveConfig 3. Ich vermute, dass der Paketmanager hier ausgerechnet dieses Paket genommen hat, und somit dann der Abhängigkeitspfad zu LiveConfig 3 geführt hat.
Wir werden das liveconfig-meta-Paket in Kürze komplett zurückziehen und durch ein Installationsscript (lc2.sh) ersetzen. Vorhandene Installationen werden davon nicht betroffen sein.
Danke für die Rückmeldungen! Wir werden die Punkte morgen alle mal durchgehen, eine ausführlichere Antwort folgt in Kürze.
Mails funktionieren jetzt wieder. Mir scheint als wurde der Installationsprozess hier nicht komplett zu Ende ausgeführt. Das Log gibt dazu leider nichts her.
Da sind wir ja auch noch eine Info schuldig: bei einem Upgrade von LC 2 auf 3 wird technisch betrachtet LiveConfig 2 entfernt (remove) und anschließend LiveConfig 3 installiert. Die Scripte, die hierbei in den einzelnen Schritten vom Paketmanager ausgeführt werden (u.a. postrm) werden zum Teil automatisch erzeugt (dpkg-helper). Und genau hier gab es einen fiesen Fehler: nach unseren Update-Tests gab es offenbar nochmal eine Änderung am postrm, welche bei der Deinstallation des Pakets liveconfig auch die Service-Unit-Files gelöscht hat (was hier eigentlich nur bei einem purge erfolgen soll). Das ist nun korrigiert, so dass Upgrades zwischen diesen Paketen nun eigentlich völlig reibungslos ablaufen sollten.
Ist das auch der Grund dafür, dass KSKs mit Algo 13/14 gar nicht erst gepublished werden?
Ja, für einen Algorithmus-Rollover genügt es nicht, einfach "nur" einen anderen Key zu erzeugen. Wir werden die DNSSEC-Maske in dieser Hinsicht noch etwas anpassen - künftig wird man wohl keinen konkreten Key erzeugen, sondern einen Algorithmus auswählen (um den Rest kümmern sich LC und BIND dann im Hintergrund). Zudem muss für einen Algorithmus-Rollover dann auch angezeigt werden, wann man die DS-Records der alten Keys bei der Registry entfernen kann.
Wir haben eben auch ein Upgrade von 2.8.2 auf 3.0.1 durchgeführt, die /etc/liveconfig/lclogparse.conf blieb dabei erhalten, ebenso waren alle Dienste korrekt "unmasked".
lcbackup ist in LiveConfig 3 ein vollständig neues System, der Dienst wird da erst aktiviert wenn man diesen unter Serververwaltung -> Datensicherung aktiviert und mindestens ein Storage-Ziel definiert. (Doku wird gerade entsprechend erweitert).
Hatten Sie während des Upgrades irgendwelche Fehler/Warnungen?
Mit 2.18.1 wurde der Fehler mit der DNSSEC-Migration von 4096-Bit RSA-Keys behoben (wer kein DNSSEC oder keine so großen Keys verwendet hat, den betrifft das also nicht).
Und in etwa einer Stunde werden wir 2.18.2 veröffentlichen, mit der das Upgrade auf LiveConfig 3 reibungsloser läuft (das betrifft die erwähnte Maskierung von Diensten während des Upgrades).
Manuelle Nacharbeiten sind eigentlich nicht erforderlich. Falls Dienste deaktiviert/maskiert wurden, korrigieren die Updates das automatisch.
Das Changelog wird im Laufe des Nachmittags auch entsprechend aktualisiert.
Zu Dovecot 2.4: die "breaking changes" sind uns bekannt, Debian 13 soll diesen Samstag (09.08.) erscheinen und wird mit Dovecot 2.4 ausgeliefert. Wir passen derzeit die entsprechenden Lua-Scripte an um das bereits zu berücksichtigen - hierfür wird es entsprechend noch mal ein LiveConfig-Update geben (sowohl für 2.18 als auch 3.0).
Das Problem mit den maskierten Services wird aktuell untersucht, wir haben bereits eine Vermutung.
Wir haben eben einen neuen Server installiert, wie gewohnt mit dem Installer-Script was wir eigentlich immer für LiveConfig 2 verwenden:
Codewget -O- https://install.liveconfig.com | shAuf dem Server befindet sich jetzt allerdings LiveConfig 3.
Dann muss da noch mal irgendetwas anderes passiert sein. LiveConfig 2.x und 3.x sind separate Pakete mit unterschiedlichen Namen; das o.g. Script kann nur LiveConfig 2.x installieren.
Auf welcher Distribution (&-Version) haben Sie das ausgeführt? Dann testen wir das gerne mal durch.
Durch die fehlerhafte dnssec-policy wurden offenbar neue KSKs erzeugt, was dazu führte, dass unsere Domain plötzlich nicht mehr auflösbar war – insbesondere bei deutschen DNS-Providern heute schon wieder, jetzt dauert es wieder mehrere Stunden bis die DNS Änderungen bei den Kunden ankommen, es ist zum Mäusemelken. Es tritt im übrigen nur bei .de domains bei mir auf die .at /.ch waren nicht betroffen das machte die Sache noch schwerer zu verstehen also musste es irgendwas mit der DENIC zu tun haben
Das tut mir sehr leid, ich verstehe Ihren Ärger. Mir einem Provider haben wir die Nacht durch durchgearbeitet, um die Ursache zu lokalisieren und zu beheben (der Chatverlauf zwischen einem Techniker dort und einem Entwickler von uns endete heute früh um 05:02).
Mit der TLD dürfte das aber nichts zu tun gehabt haben. Ich denke wir haben das inzwischen ganz gut nachvollzogen und werden eine ausführliche Beschreibung im Laufe des Tages veröffentlichen. Das Verhalten von BIND mit der dnssec-policy ist Fluch und Segen zugleich.
Aktuell entwickeln wir noch ein Tool, um die fälschlicherweise erzeugten KSKs, die in Form von DNSKEYs noch in manchen Zonen hängen, sauber zu entfernen. Die Domains sollten soweit operativ funktionieren, aber es gibt in manchen Fällen sehr viele Log-Meldungen bei BIND die nun behoben werden müssen.
Bei der DNSSEC-Migration gab es leider einen Fehler: bei DNS-Zonen, welche einen 4096-Bit RSA-Schlüssel als KSK haben, und bei denen wiederum der ZSK-Key-Tag einen kleineren Wert als der KSK-Key-Tag hat, bei denen wurde eine falsche DNSSEC-Policy in die Zonenliste geschrieben (für 2048-Bit statt 4096-Bit-KSKs). Das führte wiederum dazu, dass BIND die KSKs nicht übernommen sondern Neue erzeugt hat. :-/
(das ist leider eine seeehr hässliche Nebenwirkung der "wir-kümmern-uns-ab-sofort-um-alles"-Philosophie bei dnssec-policy.
Der Migrationsfehler wurde eben behoben, wir entwickeln eben noch ein Routine zur Korrektur aller betroffenen Domains (bei bereits migrierten Systemen), wird dann gleich in Form der v2.18.1 bereitstehen.
[EMERG] getaddrinfo() failed: Der Name oder der Dienst ist nicht bekannt
An dieser Stelle (also "so früh" beim Start) werden die lokalen Sockets für HTTP(S) und ggf. LCCP geöffnet.
Was genau steht in der /etc/liveconfig/liveconfig.conf bei http_socket, http_ssl_socket und lccp_socket?
(falls das sensible Daten sind, einfach an support@liveconfig.com schicken oder über's Kontaktformular mitteilen)
"liveconfig --diag" erkennt ja die IP, also kann es nicht an Rechten liegen. Habt ihr irgendwo einen Filter, der das ältere eth0 nicht mag und eno1 erwartet?
[...]
Im Dump der liveconfig.db ist der Bereich bei "INTERFACES" leer. Der Befehl "CREATE" existiert, aber kein nachfolgendes "INSERT".
Nein, der Name der Interfaces spielt keine Rolle. Wenn INTERFACES leer ist, dann ist das tatsächlich kein Frontend-Problem, sondern irgendetwas im Backend. Es handelt sich hier um eine Neu-Installation, oder? (also kein Upgrade einer bestehenden Installation)
Die Erkennung der IPs und Schnittstellen läuft exakt so wie in LiveConfig 2, und das was bei --diag ausgegeben wird sollte so eigentlich auch in der Datenbank landen.
Wenn es eine "leere" Installation ist, könnten wir uns das ggf mal direkt auf dem Server (via SSH) anschauen - wenn das für Sie ok ist, melden Sie sich bitte kurz unter support@liveconfig.com, damit wir das weitere Vorgehen besprechen. Parallel prüfen wir hier mal den Code, wie diese Tabelle normalerweise gefüttert wird.
Also mir hat's DNSSEC komplett zerlegt 🙃
Autsch.
Können Sie das etwas näher beschreiben? Wurden die Keys von /etc/bind/keys/ nach /var/lib/bind/keys/ verschoben?
Wurde während des Upgrades etwas in /var/log/liveconfig/liveconfig.log protokolliert?
Bei einem normalen (erfolgreichen) Update sollte das etwa so aussehen:
[<timestamp>] [<pid>|<tid>] Switching to dnssec-policy configuration on server 'xyz.example.org'
[<timestamp>] [<pid>|<tid>] dnssec-policy enabled on DNS server
[<timestamp>] [<pid>|<tid>] - updated ### zones on primary DNSAktuell ist LiveConfig 3 gar nicht nutzbar, da keine IP Adressen erkannt werden. Bei "Server - Web - konfigurieren" erscheint in der Auswahl nur 127.0.0.1. Aber selbst bei der Auswahl dieser IP meldet die Übersicht "Keine IP-Adressen ausgewählt."
Bitte prüfen Sie, ob in /var/log/liveconfig/liveconfig.log irgendetwas protokolliert wird, wenn Sie die Webserver-Konfiguration öffnen. Ich kann mir aktuell nur vorstellen, dass beim Abruf der IP-Adressen ein Fehler auftritt und deshalb die Liste in der GUI leer ist.
(das könnten fehlende oder falsche Berechtigungen sein, oder eine defekte Datenbankstruktur)