Alles anzeigenHallo
mal die Domain bearbeitet und neuabgespeichert?
Sowie das Zertifikat einmal geöffnet und abgespeichert?
Mit freundlichen Grüßen
Martin Krüger
Schon zig-fach probiert. Ich werde wohl wieder auf Version2 zurücksetzen. Zu Viele Bugs.
Alles anzeigenHallo
in der aktuellen Version werden aktuell bei uns die Lets Encrypt Zertifikate neu sowie auch alt korrekt verlängert, was sagt das Log?
Mit freundlichen Grüßen
Martin Krüger
Kurioserweise nichts zu der betroffenen Domain. Das Zertifikat wird einfach nicht ausgestellt, vorher hagelt es Fehlermeldungen, die ich hier schon gemeldet habe: RE: SSL-Problem
Sämtliche SSL-Zertifikate werden nicht automatisch verlängert. Das ausstellen von neuen Zertifikaten ist weiterhin nicht möglich. Wann wird dieses gravierende Problem behoben?
Bisher wird das alles manuell erledigt, was jedesmal etliche Stunden kostet, wenn der Kunde z.B. 60 Mailkonten und 80 Subdomains + SSL angelegt hat. Der Kunde hat die Erwartung in solchen Fällen nicht selbst aktiv werden zu müssen. Zitat: "bei anderen Hostern muss ich auch nichts selbst kopieren, da geht das automatisch".
Das Thema hatte ich auch schon vor Jahren mehrfach vorgeschlagen. Es wird eine Möglichkeit gesucht, alle Einstellungen, Daten des Kunden... 1:1 auf einen anderen Server kopieren zu können. Dazu zählen: Mailkonten (mit Inhalt!), Weiterleitungen, Datenbanken, Spamfiltereinstellungen, FTP-Zugänge, Dateien auf dem Webspace... usw.
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.
Bitte alles so anpassen / ermöglichen, das jeder Kunde weiterhin wie bisher seinen eigenen LE-Account ohne Fehlermeldungen nutzen kann.
Bild 1: anlegen des Zertifikats
Bild 2: nichts passiert
Bild 3: wenn man das nicht angelegte Zertifikat löschen will, ebenso der Fehler
Ein Zertfikat wird nicht angelegt.
Im Log steht: [618190] [2025-08-25 21:18:50.563145] [INFO] TLS certificate 'xxxxx.de' (254) successfully added.
Bei der selben Eingabemaske. Hier hat jeder Kunde bisher seinen eigenen Let's Encrypt-Account.
Jetzt folgende Fehlermeldung: The requested resource couldn't be found.
Das Zertifikat wird nicht angelegt.
Das ganze sollte als normaler Endkunde (z.B. web6) angelegt werden. Anbei ein Bild.
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)
Alles anzeigenDas 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.
Dieses Problem besteht jedoch weiterhin. Wie kann man den Account restlos ohne Fehlermeldungen löschen?
Lizenzkey (/etc/liveconfig/liveconfig.key) löschen und neu aktivieren (liveconfig --activate)? Was sagt liveconfig --diag?
Das habe ich gerade erledigt, das problem ist gelöst.
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! 
Die Webseiten sind noch erreichbar.
Der LiveConfig-Dienst hatte sich soeben beendet und nein, die Lizenz ist auf keinem anderen Server aktiv!
[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.