Beiträge von weltmeister

    Problem: bei Debian-Updates bleiben die Werte der bisherigen PHP-Versionen (eigenstellt durch Kunden) in der Datenbank erhalten. Das muss jedesmal manuell durch "Bastelarbeiten" nach dem Debian-Update korrigiert werden, indem man diese Werte manuell entfernt. Andernfalls sind die Webseiten nicht zu erreichen oder Apache startet nicht.


    Schön wäre, wenn man das in Zukunft über die Oberfläche mit einem Klick regeln könnte. Es wäre zudem eine große Zeitersparnis. Aber das Thema "Massen-PHP-Änderung" wurde schon ja schon oft angesprochen.

    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 löschen des nicht ausgestellten Zertifikates (Bild 3) klappt dann erst nach dem 2. Versuch. Es erscheint die Meldung "The requested resource couldn't be found", erst nach dem 2 Klick auf löschen funktioniert es dann.

    Die Idee mit einem "globalen" Let's-Encrypt-Account ist ansonsten nicht verkehrt, da es in der Tat weniger Aufwand bedeuten würde.

    Nach dem Update auf Version 3 lassen sich keine neuen SSL-Zertfikate anlegen. Folgende Fehlermeldung:


    Unbekanntes TLS-Produkt oder nicht berechtigt

    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.

    Kein Problem, da es nichts geheimes ist, gern hier die Ausgabe:


    liveconfig --db-check delete CUSTOMERS CUST_CID 37

    - checking CUST_ID

    - checking CUST_ID

    Table 'HOSTINGCONTRACTS' blocks deletion with:

    HC_CUSTOMERID = 38 (PK: HC_ID = 37)

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

    Gerade das aktuelle Update eingespielt. Jetzt steht da: Demo-Modus, keine Lizenz. (Eine gültige Lizenz war seit 2013 aktiv)

    Auch ist die Übersicht unter Accounts leer. Diese sind verschwunden! =O Die Webseiten sind noch erreichbar.

    Der LiveConfig-Dienst hatte sich soeben beendet und nein, die Lizenz ist auf keinem anderen Server aktiv!

    Code
    [1622] [2025-08-13 14:10:10.035962] [INFO] License expired. Trying to renew...
    [1622] [2025-08-13 14:10:10.096307] [ERR] license renewal failed - license is active at another host
    [57348] [2025-08-13 14:10:10.096414] [INFO] Got INT signal, shutting down gracefully
    [1624] [2025-08-13 14:10:10.096419] [INFO] Got INT signal, shutting down gracefully
    [1622] [2025-08-13 14:10:10.202765] [INFO] LiveConfig stopping...

    Es existieren noch Objekte in der Datenbank, die mit diesem Kunden verknüpft sind und nicht automatisch mit gelöscht werden können.

    Ich vermute, dass es hierbei um End-Verträge eines Resellers geht, und der Reseller selbst gelöscht wurde.

    Sie könnten mal liveconfig --db-check ausführen und uns das Ergebnis an support@liveconfig.com schicken - dieser neue Kommandozeilenbefehl prüft die Datenbank auf mögliche Fehler.

    Ich muss leider noch einmal nachfragen: wie kann ich den Account komplett und restlos löschen?

    für PHP 5.6 unter Debian 13 sollte man übrigens Schmerzensgeld verlangen

    So sehe ich das auch, aber Sie glauben gar nicht, wie viele Kunden das noch immer nutzen. Eine "zwangsabschaltung" würde mit Kommentaren wie folgt enden: "dann suchen wir uns eben einen anderen Hoster, der das unterstützt." Oder Bewertungen bei Google: "Der Hoster hat meine Webseite geschrottet"... Das ist wie in den Flugzeugen mit den Disketten oder den Faxgeräten in den Behörden - mit den ewig gestrigen braucht man da nicht zu diskutieren.

    Nein, die Dauer war hier wohl eher zufällig. Mit einem Reload der Seite oder der Tabelle wäre das wohl sofort weg gewesen.

    Zum Hintergrund: wenn Sie auf den "löschen"-Button klicken, wird der Lösch-Befehl an den Server gesendet und anschließend wieder die Postfach-Tabelle angezeigt. Da sich das Postfach in Löschung befindet, ist es ausgegraut dargestellt. Wenn dann - irgendwann später - das Postfach tatsächlich gelöscht wurde, dann bekommt das der Browser hier offenbar noch nicht mit und ändert den Status deshalb nicht. Wir haben zwar einen Mechanismus dafür (Websockets + Messagebus), aber es kann sein dass das bisweilen noch nicht ganz rund läuft (z.B. wenn die Events eintreffen bevor die entsprechende Tabelle geladen wurde). Wir haben das bereits auf dem Radar.


    Zu Wildcard-Zertifikaten: wie sähe der Anwendungsfall hierfür aus? Es "kostet" ja nichts, jeweils einzelne Zertifikate auszustellen.

    Prinzipiell wären Wildcard-Zertifikate mit LC3 realisierbar, vorausgesetzt die betroffene Domain wird auch von LiveConfig im DNS verwaltet.

    Besten Dank erst einmal das Sie sich um das Problem kümmern.

    zu Punkt 2: was die Kunden konkret vorhaben, kann ich nicht exakt sagen, auch wird das bei Anfragen nicht weiter hinterfragt. Den Tipp mit den Einzelzertifikaten habe ich gegeben, der Kunde war nicht gerade begeistet und hat einen Providerwechsel angekündigt. Warscheinlich gibt es da eine Registrierungsfunktion wo zufällige Subdomains angelegt / erstellt werden. Diese sollten über SSL aufrufbar sein. So verstehe ich das. Bei WP-Multisites ist das ganze auch nicht ganz unwichtig. Auch da kamen schon zig Anfragen nach Wildcard-Zertifikaten.

    Es existieren noch Objekte in der Datenbank, die mit diesem Kunden verknüpft sind und nicht automatisch mit gelöscht werden können.

    Ich vermute, dass es hierbei um End-Verträge eines Resellers geht, und der Reseller selbst gelöscht wurde.

    Sie könnten mal liveconfig --db-check ausführen und uns das Ergebnis an support@liveconfig.com schicken - dieser neue Kommandozeilenbefehl prüft die Datenbank auf mögliche Fehler.

    Es handelt sich um keinen Reseller-Zugang. Es war ein ganz normal angelegter Endkunden-Account angelegt durch den Haupt-Benutzer. Da die Ausgabe unspektakulär ist direkt hier:

    # liveconfig --db-check

    Checking database integrity...

    - checking nested set of customers

    -> checked 43 customers

    - checking for orphaned customers

    - checking nested set of accounts

    -> checked 0 accounts with reseller resources

    - checking for accounts with invalid mail server

    - checking age of RRD data

    - RRD_TRAFFIC: 133712 records, oldest: 2013-12-04T00:00:00Z

    - RRD_WEBSPACE: 128834 records, oldest: 2013-12-04T00:00:00Z

    - RRD_NET: 11942 records, oldest: 2014-06-11T12:00:00Z

    - RRD_MEM: 12321 records, oldest: 2013-12-04T00:00:00Z

    - RRD_CPU: 12321 records, oldest: 2013-12-04T00:00:00Z

    - RRD_MAIL: 14866 records, oldest: 2017-02-23T08:15:00Z

    - checking table sizes, top 10 tables (KB):

    11429888 RRD_TRAFFIC

    10217472 RRD_WEBSPACE

    3278848 DNSSEC

    1716224 LOG

    1200128 RRD_MAIL

    1169408 RRD_MEM

    1123328 RRD_CPU

    953344 RRD_NET

    731136 SUBDOMAINS

    515072 SSLCERTS

    All checks passed.

    Das löschen von Accounts funktioniert auch nicht:


    [2853086] [2025-08-08 13:59:19.818784] [INFO] LiveConfig starting...

    [2853086] [2025-08-08 13:59:19.821898] [INFO] Database driver loaded: SQLite (3.50.3)

    [2853090] [2025-08-08 13:59:19.840787] [INFO] Database driver loaded: SQLite (3.50.3)

    [2853092] [2025-08-08 13:59:19.844870] [INFO] Connected to dBus!

    [2853092] [2025-08-08 13:59:20.063246] [INFO] [LUA] Loading custom Lua settings from '/usr/lib/liveconfig/lua/custom.lua'

    [2853092] [2025-08-08 13:59:20.071917] [INFO] [LUA] Detected 'Debian GNU/Linux 12 (bookworm)'

    [2853092] [2025-08-08 13:59:20.427383] [INFO] [LUA] Loading custom Lua settings from '/usr/lib/liveconfig/lua/custom.lua'

    [2853092] [2025-08-08 13:59:20.427657] [INFO] [LUA] Loading custom Lua settings from '/usr/lib/liveconfig/lua/custom.lua'

    [2853092] [2025-08-08 13:59:20.427782] [INFO] [LUA] Loading custom Lua settings from '/usr/lib/liveconfig/lua/custom.lua'

    [2853091] [2025-08-08 13:59:20.447988] [EMERG] Exception while processing sysinfo: Object not found or not authorised for it

    [2853091] [2025-08-08 13:59:27.477830] [INFO] Account 'web37' successfully removed.

    [2853092] [2025-08-08 13:59:27.481725] [INFO] LC.smtp.deleteMailbox(xxxx.xxxx@xxxx-xxxx.de) OK

    [2853092] [2025-08-08 13:59:27.481759] [INFO] [LUA] Deleting mailbox xxxx.xxxx@xxxx-xxxx.de from dovecot config file: /etc/dovecot/passwd

    [2853092] [2025-08-08 13:59:27.482022] [INFO] LC.popimap.deleteMailbox(xxxx.xxxx@xxxx-xxx.de) OK

    [2853091] [2025-08-08 14:00:02.057711] [EMERG] Database exception: FOREIGN KEY constraint failed

    [2853091] [2025-08-08 14:00:02.057729] [EMERG] SQL: DELETE FROM CUSTOMERS WHERE CUST_ID = ?1


    Der Trick in der Datenbank mit dem setzen von einer 0 bei Hostingcontracts funktioniert auch nicht mehr.

    Jetzt ist es nach langem warten wie von selbst verschwunden. Ist das normal, das es so lange dauert? Ca. 30 min. war es so zu sehen, das könnte für den Endkunden verwirrend sein.


    Noch eine Frage, die gerade und auch schon mehrfach von Kunden reinkam: ist künftig eine Wildcard-SSL-Unterstützung mit Let's Encrypt-Zertifikaten geplant?

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