Beiträge von lebenszeit

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.

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.

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

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.

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.

"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

# 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"

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.

Könnte der (Datenbank-)Server busy sein wenn das auftritt? Soweit ich weiß ist GUI-Timeout für API-Antwort 10 Sekunden.

Einerseits wird Timeout-Fehler eingeblendet, andererseits wird der Befehl aber ausgeführt. Das ist ein sehr unwillkommenes "Feature".

Bei Apache Proxy bestimmt wohl "Timeout" aus "/etc/apache2/apache2.conf" wie häufig GUI mit "Verbindung zum Server verloren" überblendet wird.

Ich bin dagegen, solche Subdomains als Default zu haben.

Die Funkion lässt sich leicht mit LC-API realisieren.

Für volle Funktionalität der Subdomain (E-Mail, Autodiscover) verbunden mit DNSSEC wird die Konfiguration lustig.

Ist RE: roundcube Passwort ändern Plugin? beachtet?

Siehe auch Roundcube Passwort Plugin nicht für LC3?

Der Fehler ist hier auch aufgefallen.

Die gewünschten Anwendungen sind auf 0. Es ist wahrscheinlich ein Bug in GUI. Ich vermute, GUI erwartet exakt ID 1-15 / Positionen 0-14.

Die Tabelle hat übrigens Fremdschlüssel. Nicht daran basteln.

"Behoben mit v3.2.0"

Bis dahin müssen zwei Anwendungen aus WordPress, phpMyAdmin, RoundCube AR_DISABLED=0 sein.

Ab 3.2.0 werden wohl einige Apps gestrichen.

Hier sind seit LC3 gar keine Apps mehr wählbar/installierbar. Es wird nichts angezeigt

Wie ist dein Eindruck wenn du Changelog liest?

Welche neuen Funktionen sind euch wichtig?

Stunden nach der Installation, installiert sind

php-8.5-opt 8.5.0-1+deb13u1 amd64 at /opt/php-8.5/

php-8.5-opt-imagick 1:3.8.1-1+deb13u1 amd64

PHP Startup: Unable to load dynamic library 'imagick.so' (tried: /opt/php-8.5/lib/extensions/no-debug-non-zts-20250925/imagick.so (/opt/php-8.5/lib/extensions/no-debug-non-zts-20250925/imagick.so

: cannot open shared object file: No such file or directory), /opt/php-8.5/lib/extensions/no-debug-non-zts-20250925/imagick.so.so (/opt/php-8.5/lib/extensions/no-debug-non-zts-20250925/imagick.so.so: cannot open shared object file: No s

uch file or directory)) in Unknown on line 0

Zitat von hchristo

Ungetestet (!!!) Aber hier wäre ein von ChatGPT vorgeschlagenes Script

Bis Zeile 8 scheint in Ordnung, danach sieht es für mich gruselig aus.

Ich würde empfehlen, mit dem Wechsel auf LC3 zurückhaltend zu sein. Eines der nächsten Releases soll einige Bugs beheben die zur Zeit viel Supportaufwand und Arbeit verursachen.

Geändert 5.11.:

Einige Bugs wurden mit 3.1.0 behoben

Aus Erfahrung empfehle ich eine Sicherung ALLER Datenbanken vor dem Upgrade von LC2 auf LC3! Nolz schreibt auf Github

Zitat

During the app migration from LC 2 to 3 there was a bug which resulted in all apps (PHPMyAdmin, Roundcube) being in state error and deleted databases.

Ich würde empfehlen, mit dem Wechsel auf LC3 noch etwas zu warten. Eines der nächsten Releases soll einige Bugs beheben die zur Zeit viel Supportaufwand und Arbeit verursachen.

Falls ihr DNSSEC und BIND in LC verwendet könnte es besser sein, bei Debian 12 und LC2 zu bleiben oder umfangreich zu testen, ob es nach dem Upgrade wirklich funktioniert.

Domains, die mit DNSSEC und LC3 API auf Debian 12 angelegt wurden machen (spätestens) nach Upgrade auf Debian 13 Schwierigkeiten. Vielleicht ist es nur davor nicht aufgefallen.

Debian 13.1 / BIND 9.20.11 / LiveConfig 3.0.8

Bei einigen Domains ist DNSSEC in LC aktiviert. Dynamische Updates werden protokolliert (https://www.liveconfig.com/de/kb/bind-logging/ )

Die Zonen hängen faktisch, da

"could not get zone keys for secure dynamic update"

"RSIG/NSEC/NSEC3 update failed: not found".

Zwischendurch Zone neu Schreiben (Umstellen auf extern - eigene Domain) ändert nichts.

Die Meldungen bleiben selbst beim Deaktivieren von DNSSEC für die betreffende Domain.

Mit KSK löschen, DNSSEC deaktivieren, Zone extern, intern, BIND restart bekommt man es irgendwie in den Griff.

Key rollover, also auch Wechsel des Algo, sei ein offenes Thema.

Zitat von KK, per Ticket

pro Zone darf bis auf Weiteres nur ein KSK aktiv sein. Das Problem ist, dass ein KSK-Rollover mit dnssec-policy relativ kompliziert ist (vor allem wenn sich der Algorithmus ändert).

[...] Bis das umgesetzt ist wurde daher das KSK-Limit auf "1" gesetzt.

Domains mit DNSSEC in LC3 löschen hinterlässt Dateien /var/lib/bind/keys/K<domain>... mit Schlüsseln. Diese zieht BIND9 heran wenn die Domain mit DNSSEC neu angelegt wird. LC3 hat davon keine Kenntnis mehr und zeigt Daten eines KSK an, der teilweise gar nicht verwendet wird. Hinterlegt man diese Daten beim NIC stimmen DS-Record dort mit der Zone nicht überein und die Domain sollte unerreichbar werden weil DNSSEC fehlschlägt.

BIND ist nicht exotisch konfiguriert.

Nomflow: Proxy: Mit Apache geht es. Mit nginx noch nicht.

Debian 12

/var/log/liveconfig/liveconfig.log

dnssec-policy enabled on DNS server
- updated 47 zones on primary DNS
Error while deleting/updating NSEC3PARAM (host '', zone 'example.com'): DNS update failed

Letzte Zeile 26x

Load nach Update deutlich erhöht.

In /var/log/named/messages Endlosschleife mit

zone example.com/IN: reconfiguring zone keys
zone example.com/IN: Updating DNSKEY TTL from 86400 to 3600
dns_dnssec_keylistfromrdataset: error reading /var/lib/bind/keys/Kexample.com.+007+99999.private: file not found
zone example.com/IN: zone_rekey:zone_verifykeys failed: some key files are missing

In /etc/bind/keys/ blieen nur zwei Dateien übrig:

Kexample.com.+007+99999.private und deren .key

Bei dieser Domain wurde vor Monaten mittels GUI neuer Schlüssel erstellt (und der alte nach Änderung beim NIC gelöscht.)

DNSviz zeigt für diese Domain keine Fehler, außer den veralteten Algo.

Nach service bind9 restart keine Einträge mehr, Load normalisiert.