LiveConfig 3.2.0 und 2.19.0 veröffentlicht

1. offizieller Beitrag
    • Neu

    Vielen Dank!

    • phpMyAdmin single sign on
      - auf LC-Server: Communication with LiveConfig server failed: Failed to connect to ... port ... after 0 ms: Could not connect to server
      - auf LC-Client (Version 3.1.4 (17009)) funktioniert das

      Mit Klick auf den Schlüssel einloggen können war praktisch. Die Sub-Navigation mit nur einem Eintrag ist umständlich.
    • Berichte
      Standard ("Übersicht") zeigt keine Daten
      Kunden insgesamt (inklusive Resellerkunden):
      Eigene Wiederverkäufer:
      Eigene Endkunde:
    • SSHFP RR - Mehrere eingetragen, speichern, "An internal server error has occured. Please check the log file for more details."
      [1648976] [EMERG] Uncaught exception: PCRE error in '(?s)^([0-9a-fA-F][0-9a-fA-F]){0,2048}$' (pos. 0): regular expression is too large
      [1648976] [EMERG] METHOD: PATCH; URL: /liveconfig/api/v1/domains/domain.test [1648976] [EMERG] Got exception: std::runtime_error [ 0] 0x... /usr/lib/liveconfig/libk.so.0.9 [ 1] 0x... [ 2] 0x... [ 3] 0x... [ 4] 0x... [ 5] 0x... [ 6] 0x... [ 7] 0x... [ 8] 0x... [ 9] 0x... [10] 0x... [11] 0x... [12] 0x... [13] 0x... /usr/lib/liveconfig/libk.so.0.9 [14] 0x... /usr/lib/liveconfig/libk.so.0.9 [15] 0x... [16] 0x... /lib/x86_64-linux-gnu/libstdc++.so.6 [17] 0x... /lib/x86_64-linux-gnu/libc.so.6 [18] 0x... /lib/x86_64-linux-gnu/libc.so.
    • Neu
    • Offizieller Beitrag
    Zitat

    auf LC-Server: Communication with LiveConfig server failed: Failed to connect to ... port ... after 0 ms: Could not connect to server


    Wo genau tritt diese Meldung auf, und in welchem Kontext? Welcher Port?

    (die Fehlermeldung würde ja eigentlich sagen, wer sich hier wohin connecten möchte - diese Information ist durchaus relevant)


    Zitat

    Berichte - Standard ("Übersicht") zeigt keine Daten

    Tritt eventuell ein Timeout während der Abfrage auf? Wird ansonsten etwas im liveconfig.log protokolliert? Ansonsten: als welcher Benutzer sind Sie angemeldet - als "admin"? Falls nicht, in welchem Kontext?


    Zitat

    SSHFP RR - Mehrere eingetragen, speichern, "An internal server error has occured. Please check the log file for more details."

    Schauen wir uns auch gleich an - aber: die Adressen des Stracktrace sind durchaus wichtig (deshalb werden die ja mit ausgegeben). Ein Stacktrace ohne Adressen ist völlig wertlos. ;) Da stecken keinerlei "sensible" Informationen drin.

    • Neu
    • Offizieller Beitrag

    SSHFP: Fehler ist lokalisiert und behoben - das betraf nicht SSHFP, sondern TLSA-Records (in Ihrem Fall wird in der bearbeiteten Zone auch ein TLSA-Record existieren, hier wurde die Prüfung der Eingabe "verschärft" - nur konnte das leider zu einem zu komplexen PCRE-Ausdruck führen)

    Behoben mit 3.2.0-2 (Build 17399), geht im Laufe des Vormittags in die Repositories.

    • Neu

    Eben auf zwei Systemen auf 2.19.0 aktualisiert. Ausgangsversion war 2.18.10.


    Logfile von LiveConfig:


    Code
    [2026/04/15 11:56:24.527379] [3704227|3704228] LC.liveconfig.updateSysconfig() failed: /usr/lib/liveconfig/lua/liveconfig.lua:1217: attempt to call field '?' (a nil value)
stack traceback:
    /usr/lib/liveconfig/lua/liveconfig.lua:1217: in function </usr/lib/liveconfig/lua/liveconfig.lua:244>
    • Neu

    Dem schließe ich mich an dieser Stelle an - Update auf LiveConfig 2.19.0 durchgeführt, gleicher Fehler:

    Code
    [2026/04/14 13:50:25.527042] [1838137|1838140] LC.liveconfig.updateSysconfig() failed: /usr/lib/liveconfig/lua/liveconfig.lua:1217: attempt to call field '?' (a nil value)
stack traceback:
        /usr/lib/liveconfig/lua/liveconfig.lua:1217: in function </usr/lib/liveconfig/lua/liveconfig.lua:244>
    • Neu
    Zitat von kk

    Wo genau tritt diese Meldung auf, und in welchem Kontext? Welcher Port?

    (die Fehlermeldung würde ja eigentlich sagen, wer sich hier wohin connecten möchte - diese Information ist durchaus relevant)

    "an phpMyAdmin anmelden..." (wofür stehen dabei die "..."?) -> https://.../lc-sso.php

    Der Port ist ein privilegierter Port. Von außen (Client mit 3.14 funktioniert er Zugriff, von intern nicht). An Firewall liegt es wohl nicht. GUI ist über diesen Port erreichbar.

    Code
    "POST /liveconfig/api/v1/databases/GktlqA/sso?id=... HTTP/1.1" 200 641 189 "/liveconfig/databases?id=..."
"POST /liveconfig/app/db-sso HTTP/1.1" 200 781 31
    Zitat von kk

    als welcher Benutzer sind Sie angemeldet - als "admin"?

    Ja, als admin / root.


    SSHFP funktioniert

    Code
    # ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub # Ungeeigneter Befehl!
256 SHA256:foobar comment (ECDSA)

    ssh -o FingerprintHash=sha256 <server> liefert denselben Wert "foobar".

    GUI: "foobar" bei "Wert" eingetragen -> speichern -> "Invalid input"


    Lösung: RE: LiveConfig 3.2.0 und 2.19.0 veröffentlicht


    Zitat von kk

    [Berichte]

    Tritt eventuell ein Timeout während der Abfrage auf? Wird ansonsten etwas im liveconfig.log protokolliert?

    Seit dem Upgrade auf 17401 funktioniert Bericht "Übersicht". Es wurde davor kein Timeout eingeblendet. Log hatte ich nicht kontrolliert.



    Seit mehreren Versionen treten diese Upgrade-Fehler auf:


    Entpacken von liveconfig3 (3.2.0-2.17401) über (3.2.0-1.17390) ...

    liveconfig3 (3.2.0-2.17401) wird eingerichtet ...

    Removing incomplete database backup

    mysqldump process received signal 9 and exited

    Job for lclogsplit.service failed because a timeout was exceeded.

    See "systemctl status lclogsplit.service" and "journalctl -xeu lclogsplit.service" for details.

    invoke-rc.d: initscript lclogsplit, action "start" failed.

    ● lclogsplit.service - LiveConfig lclogsplit

    Loaded: loaded (/usr/lib/systemd/system/lclogsplit.service; enabled; preset: enabled)

    Active: activating (start) since Wed 2026-04-15 16:39:52 CEST; 283ms ago

    Job: 417199

    ...

    Tasks: 1 (limit: 38366)

    Memory: 252K (peak: 260K)

    CPU: 830us

    CGroup: /system.slice/lclogsplit.service

    └─2978594 /usr/lib/systemd/systemd-executor --deserialize 68 --log-level info --log-target journal-or-kmsg


    systemd[1]: lclogsplit.service: Scheduled restart job, restart counter is at 1.

    systemd[1]: Starting lclogsplit.service - LiveConfig lclogsplit...

    systemd[1]: lclogsplit.service: Can't open PID file '/run/liveconfig/lclogsplit.pid' (yet?) after start: No such file or directory

    en verarbeitet ...

    Trigger für man-db (2.13.1-1) werden verarbeitet ...

    Trigger für libc-bin (2.41-12+deb13u2) werden verarbeitet ...

    Zusammenfassung:

    Aktualisiere: 0, Installiere: 0, Entferne: 0, Aktualisiere nicht: 0


    Wird das Backup wegen Timeout abgebrochen?

    Kann es sein, dass die Tabellen RRD_WEBSPACE RRD_TRAFFIC und RRD_MAIL nicht bereinigt werden? Die ältesten Einträge gehen zurück bis 201X.

    (Die ersten beiden Tabellen sind dabei ca. 6x so groß wie RRD_MAIL.)



    Gehört "/api/v2.0/" zu LC? "GET /api/v2.0/me/GetClientAccessToken HTTP/1.1" 404 577 104 "-" "Outlook-iOS/2.0"

    • Neu

    Auch mit der aktuellsten Version ist liveconfig.log voller Versuche, Zertifikate für in LC längst gelöschte Domains zu erlangen. Teils wurden die Accounts (Verträge), insgesamt gelöscht.

    Zitat

    DNS check for 'foo.test' failed: DNS error: unknown/invalid IP(s) found in DNS: <IPv4>

    DNS check for 'bar.test' failed: DNS lookup failed: domain not found (NXDOMAIN)

    Die Zertifikate sind nicht in der Zertifikatsliste zu finden. Es sind also verwaiste Einträge. Das Log ist so umständlich zu nutzen und der Server wird unnötig beschäftigt.

    • Neu
    Zitat von Marco

    Eben auf zwei Systemen auf 2.19.0 aktualisiert. Ausgangsversion war 2.18.10.


    Logfile von LiveConfig:


    Code
    [2026/04/15 11:56:24.527379] [3704227|3704228] LC.liveconfig.updateSysconfig() failed: /usr/lib/liveconfig/lua/liveconfig.lua:1217: attempt to call field '?' (a nil value)
stack traceback:
    /usr/lib/liveconfig/lua/liveconfig.lua:1217: in function </usr/lib/liveconfig/lua/liveconfig.lua:244>

    Habe ebenso das Problem. User können mit Liveconfig keinen Webspace bzw. eine Subdomain mehr einrichten...

    • Neu
    • Offizieller Beitrag

    Wir haben eben die Version 2.19.1 bereitgestellt, in welcher dieser Fehler behoben ist.

    Ich bitte um Entschuldigung für die Unannehmlichkeiten :(


    Hintergrund ist, dass wir die "SFTP-Only"-Einschränkung überarbeitet hatten, und hierfür Änderungen an der sshd-Konfiguration vorgenommen werden mussten. Dabei griff LiveConfig 2.x auf eine Funktion zu, die aber erst in 3.x verfügbar ist. Wir haben unsere Tests angepasst, damit so etwas künftig (hoffentlich) nicht mehr passiert. Die SFTPOnly-Anpassung in LC 2.x wird auf ein späteres Update verschoben.


    Viele Grüße


    -Klaus Keppler

    • Neu
    • Offizieller Beitrag
    Zitat von lebenszeit

    "an phpMyAdmin anmelden..." (wofür stehen dabei die "..."?) -> https://.../lc-sso.php

    Der Port ist ein privilegierter Port. Von außen (Client mit 3.14 funktioniert er Zugriff, von intern nicht). An Firewall liegt es wohl nicht. GUI ist über diesen Port erreichbar.

    Auch damit kann ich leider überhaupt nichts anfangen. Die URLs zu phpMyAdmin (wo auch die lc-sso.php liegen muss) und zum LiveConfig sind zwei völlig verschiedene Baustellen. Schicken Sie uns ggf. die konketen URLs und exakten Fehlermeldungen (möglichst ungekürzt) an support@liveconfig.com.


    Zitat

    ssh -o FingerprintHash=sha256 <server> liefert denselben Wert "foobar".

    GUI: "foobar" bei "Wert" eingetragen -> speichern -> "Invalid input"


    "foobar" ist kein gültiger Hash. Der von o.g. Befehl erzeugte Fingerprint ist nicht im vom DNS erwarteten Format. Verwenden Sie bitte den Befehl ssh-keygen -r <Host> (oder ssh-keyscan -D <Host>)


    Zitat

    Removing incomplete database backup

    mysqldump process received signal 9 and exited
    Job for lclogsplit.service failed because a timeout was exceeded.


    Wie lange dauert bei Ihnen die Erstellung eines MySQL-Dumps der LiveConfig-Datenbank, und wie groß ist die resultierende Datei?

    time /usr/lib/liveconfig/lcdbbackup /root/test.dump

    • Neu
    • Offizieller Beitrag
    Zitat von lebenszeit

    Auch mit der aktuellsten Version ist liveconfig.log voller Versuche, Zertifikate für in LC längst gelöschte Domains zu erlangen. Teils wurden die Accounts (Verträge), insgesamt gelöscht.

    Die Zertifikate sind nicht in der Zertifikatsliste zu finden. Es sind also verwaiste Einträge. Das Log ist so umständlich zu nutzen und der Server wird unnötig beschäftigt.

    Ich gehe davon aus, dass es sich hier um "Altlasten" handelt (bei allen unserer Tests werden Domains und Zertifikate korrekt und vollständig gelöscht).

    Domains müssen gemäß Datenbank-Constraints immer einem Vertrag zugeordnet sein; wenn da also noch Domains im Log auftauchen, existieren die Verträge möglicherweise noch. Ohne einen konkreten Fall zu prüfen, macht das keinen Sinn. Bitte kurze Mail an support@liveconfig.com, dann gehen wir mal die erforderlichen Datenbankabfragen durch.

    • Neu
    Zitat von kk

    time /usr/lib/liveconfig/lcdbbackup /root/test.dump

    # time /usr/lib/liveconfig/lcdbbackup /root/test.dump

    Removing incomplete database backup

    mysqldump process received signal 9 and exited

    real    5m0,073s

    user    0m3,207s

    sys     0m0,800s


    # time /usr/lib/liveconfig/lcdbbackup /root/test.dump

    real    4m46,509s

    user    0m5,504s

    sys     0m1,006s


    339M test.dump_LIVECONFIG.sql

    • Neu
    Zitat von kk

    wenn da also noch Domains im Log auftauchen, existieren die Verträge möglicherweise noch

    Es existieren Zertifikate, ohne dass die zugehörige Domain existiert. (Domains ohne Vertrag sind nicht aufgefallen.)

    "Für diesen Kunden existieren noch keine Accounts.

    Dieser Kunde hat noch keine Accounts mit E-Mail oder Webspace."

    Bei Löschen von Domain oder Webspace blieben früher wohl die Zertifikate in SSLCERTS erhalten. Heute kann das Zertifikat mitgelöscht werden.

    -> Wie Zertifikate richtig bereinigen ist in neues Ticket ausgelagert.


    Erst bei Löschen des Kunden greift FOREIGN KEY (`SSL_OWNERID`) REFERENCES `CUSTOMERS` (`CUST_ID`) ON DELETE CASCADE

    FOREIGN KEY (`SSL_CUSTOMERID`) REFERENCES `CUSTOMERS` (`CUST_ID`) ON DELETE SET NUL

    Wofür ist die Differenzierung SSL_OWNERID / SSL_CUSTOMERID?


    Gibt es in den Relationen/Verknüpfungen einen Unterschied ob Zertifikate, über "Domains" mit der neuen Automatik oder über "SSL-Zertifikate"/"TLS-Zertifikate" erstellt wurden/werden? Gefunden habe ich keinen.

    • Neu
    Zitat von kk

    Verwenden Sie bitte den Befehl ssh-keygen -r <Host> (oder ssh-keyscan -D <Host>)

    Mein Fehler war, einen Teil aus der Ausgabe von ssh-keygen -lf zu verwenden weil durch abweichenden Port ssh-keyscan ins Leere lief. (Bei abweichendem Port: ssh-keyscan -p <Port> -D <Host>)

    SSHFP erwartet Hexdec.

    Auf Debian habe ich geschaut, welche Pubkeys vorhanden sind:

    ls -lah /etc/ssh/ssh_host*\.pub;

    um dann die Werte lokal auszulesen mit

    for file in /etc/ssh/ssh_host*\.pub; do ssh-keygen -lf $file; ssh-keygen -E md5 -lf $file; ssh-keygen -r example -f $file; echo; done


    Die SSHFP-Records sind in der Zone :) Vielen Dank für diese Erweiterung!


    Bequemer ist der von Ihnen genannte Befehl.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden