Siehe https://www.liveconfig.com/de/blog/2025/12/update-lizenzschlüssel/
Schicken Sie bitte einfach eine kurze Mail an support@liveconfig.com, dann senden wir Ihnen den erforderlichen Patch.
Grundsätzlich empfehlen wir natürlich, Server immer möglichst aktuell zu halten.
Ist aktuell in Arbeit (wir haben auch noch Tickets dazu offen) - sollte bis morgen soweit fertig sein.
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.
"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.
Zitatssh -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>)
ZitatRemoving 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
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
Ich verstehe nicht, was die automatische Erhöhung der Kundennummer (beim Anlegen neuer Kunden/Accounts) mit der Domainauswahl bei neuen TLS-Zertifikaten zu tun haben soll...
Die Fehlermeldung im Screenshot lautet "Nicht berechtigt für diesen Vorgang", daher vermute ich einen anderen Zusammenhang. Waren möglicherweise noch keine Domains für den Vertrag angelegt?
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.
Zum SSHFP: was genau haben Sie denn hinterlegt, wodurch der Fehler aufgetreten ist? Bei unseren Tests funktioniert alles. Die relevanten Records können Sie z.B. mit dem Befehl ssh-keygen -D <hostname> erzeugen.
Zitatauf 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)
ZitatBerichte - 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?
ZitatSSHFP 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.
Hallo,
ab sofort steht LiveConfig in den Versionen 3.2.0 und 2.19.0 zum Download bereit.
Alle Änderungen sind - wie immer - im Changelog dokumentiert. Was die Version 3.2 betrifft sind diese recht umfangreich...
Viele Grüße
-Klaus Keppler
Wir haben eben die Version 3.2.0 "stable" freigegeben, da wurde u.a. auch ein Fehler behoben der zu Timeouts geführt haben kann (konkret oft nach dem Zugriff auf den Log-Viewer oder File-Browser).
Sollte das Timeout-Problem weiterhin auftreten, geben Sie bitte nochmal Bescheid.
Das mit den Nummern schauen wir uns an, danke für den Hinweis!
Ich habe da offenbar etwas durcheinander gebracht. LC2 unterstützt Rocky8 ja bereits, eine Rocky9-Testumgebung bereiten wir vor. Ob Rocky10 auch von LC2 noch unterstützt werden wird, kann ich an dieser Stelle aber nicht versprechen.
LC3 wird definitiv nicht unter Rocky8 laufen (wie bereits erwähnt bauen und testen wir das ab Rocky9).
Dass bei RHEL/CentOS/Rocky keine "Dist-Upgrades" vorgesehen sind, ist durchaus ärgerlich/lästig. Wir bieten aber an, die Migrationsanleitung entsprechend zu erweitern, um einen reibungslosen Umzug zu ermöglichen.
Der Migrationspfad würde dann also so aussehen:
- den Server mit LC2 von Rocky 8 auf Rocky 9 aktualisieren (sobald wir LC 2.19 für Rocky 9 freigegeben haben)
- anschließend (wenn alles passt) von LC 2.x auf 3.x aktualisieren
Viele Grüße
-Klaus Keppler
Die Previews wurden eben aktualisiert: LiveConfig 3.2.0 / 2.19.0
Roadmap (ganz grob): Backup/Restore weiter ausbauen (als Nächstes auch Einstellungen exportieren/importieren), Fehlersuche vereinfachen (z.B. Overprovisioning bei Verträgen, inkonsistente Datenbank, ...), Spam-Filter verbessern (konkret: rspamd), einfachen Bot-Schutz für Webserver.
Wir arbeiten durchgehend daran, können aber keine fixen Termine für die Fertigstellung nennen.
Viele Grüße
-Klaus Keppler
Hallo,
wir haben eben die Preview für LiveConfig 3.2.0 und 2.19.0 aktualisiert. Derzeit rollen wir diese Versionen auf einigen Servern produktiv aus - sofern nicht Kritisches auftaucht ist das Release für kommenden Montag (13.04.2026) geplant.
Die Änderungen finden sich wie immer im Changelog (nun auch für die 3er Version auf der Preview-Seite enthalten). Es gab sehr umfangreiche Änderungen und Erweiterungen - neben "alten" Funktionen (Berichte, Rundmail) wurden auch etliche Fehler behoben und Details verbessert.
Viele Grüße
-Klaus Keppler
LiveConfig 2.x wird noch mindestens bis Ende 2026 aktiv weitergepflegt. Da der technische Unterbau zur Konfigurationserzeugung (die Lua-Scripte) identisch mit denen von LiveConfig 3 sind, werden auch neuere Distributionen prinzipiell mit unterstützt.
Wir bereiten eine Rocky8-Testumgebung für LC2 vor, ich gebe hier dann in Kürze zum Status Bescheid.
Nein, mit der 3.2.x hat das nichts zu tun, die Diagnosefunktionen sind in der 3.1.4 und zum Teil in 2.18.10 auch schon enthalten.
Jedes mal wenn die Meldung "An internal server error has occured" auftaucht, wird eine Meldung im liveconfig.log protokolliert - die wäre in dem Zusammenhang wichtig.
Dem Gesamtbild nach gibt es aber vermutlich ein Problem in der Kunden- oder Accountstruktur. Wenn Sie nochmal auf 3.x aktualisieren, führen Sie danach in der Shell bitte mal den Befehl liveconfig --db-check aus. Den Output schicken Sie uns gerne mal an support@liveconfig.com. Mit liveconfig --db-repair können die Daten größtenteils korrigert/repariert werden (aber am besten erst nach Rücksprache mit uns).
LiveConfig 3 ist wesentlich sensibler was die Datenstruktur betrifft (dafür werden die Berechtigungen über alle Reseller-Ebenen hinweg nun korrekter durchgeprüft). Häufig haben sich durch Datenbankeingriffe mal leicht defekte Strukturen gebildet, die LiveConfig 2.x praktisch ignoriert, 3.x aber nicht.
Öhm - die Gründe (also die einzelnen Punktzahlen) stehen doch ausführlich dabei, ich verstehe das Problem nicht...?
Lässt sich scheinbar über /etc/spamassassin/local.cf anpassen:
https://serverfault.com/a/849013
Im LiveConfig selbst kann man in den Postfix-Einstellungen die Checkbox "IP-Adresse des SMTP-Absenders unterdrücken" setzen (ist auch aus Datenschutz-Gründen zu empfehlen).
Ihre IP Ihres Providers X.X.X.X steht auf folgender DNS-Spam-Blacklist: xxxxxx
Wenn Sie Fragen zu einem Blacklisting Ihrer IP-Adresse oder nicht zustellbaren E-Mails haben, wenden Sie sich bitte ausschließlich unter Angabe dieser Fehlermeldung an Ihren eigenen E-Mail-Anbieter, nicht an XXX oder gar an den Webhosting-Kunden, den Sie versuchen zu erreichen!
Ja, verstehe ich - aber das wird nicht möglich sein. SpamAssassin meldet nur "XXX Punkte erreicht" zurück (siehe meine Beschreibung vorher!). Eine "Spam-Blacklist" auf die man sich beziehen könnte gibt's eh nicht. Es muss an dieser Stelle also bei einer eher allgemeinen Fehlermeldung bleiben. Ich könnte mir aber vorstellen, dass man da eine URL reinpackt, unter welcher dann weitere Details zu finden sind.
Beispiel:
554 5.7.1 Your message was rejected because it appears to be spam. For more information, please visit https://example.org/rejected-spam
Auf der angegebenen URL könnte man dann die üblichen Gründe für eine Ablehnung nennen.
Konkret zu sagen, welche SpamAssassin-Tests angeschlagen haben, wäre übrigens eine ganz schlechte Idee, weil Spammer somit trainieren könnten wie ihre Mails besser durchkommen.
Diese Meldung 554 5.7.1 Your message was rejected because it appears to be spam wird von lcsam (dem LiveConfig SpamAssassin Milter) erzeugt. Das passiert dann, wenn die von SpamAssassin vergebene Punktzahl über dem Schwellwert für Ablehnungen liegt.
SpamAssassin hat ja keinen "einzelnen" Grund, eine Mail abzulehnen, sondern am Ende vieler Tests (u.a. Blacklists, Inhalt, ...) gibt's eine Gesamtpunktzahl. Daher ist diese Fehlermeldung auch bewusst allgemein gehalten.
Über LiveConfig konfigurierte DNS-Blocklists werden übrigens vor SpamAssassin geprüft und dann mit einer entsprechend konkreten Fehlermeldung ausgewiesen.
Was für eine Fehlermeldung würde Ihnen denn vorschweben? Aktuell ist die Meldung im lcsam hartcodiert, prinzipiell spricht aber nichts dagegen dass wir das konfigurierbar machen.
