Der aktuelle Stand der REST-API-Dokumentation ist ab sofort in der Wissensdatenbank online:
https://www.liveconfig.com/de/kb/lc3-api/
Dokumentiert sind da bislang nur die Funktionen, die (mehr oder weniger) "fertig" sind, kleinere Änderungen sind aber immer noch möglich.
Sobald die Online-Demo von LC3 bereit steht, werden wir die REST-API-Doku so anpassen, dass man die API damit direkt testen (herumspielen) kann.
Haben Sie mal (wie in der Fehlermeldung empfohlen) "liveconfig --help" ausgeführt? 
Der Parameter heißt nämlich eigentlich "--init" und nicht "--initpw". Ich schätze dass da ein Tippfehler in der Anleitung vorliegt, wir werden das morgen aktualisieren.
Viele Grüße
-Klaus Keppler
Sehr merkwürdig. Die letzte Änderung am Release-Repo ist einige Tage her. Wir werden mal die Logs prüfen, ob wir da auch nen 404 finden.
Das Meta-Paket hat NOCH NIE irgendetwas direkt enthalten, sondern hat nur Abhängigkeiten zu anderen Paketen.
Wie man an der Ausgabe unschwer erkennen kann, installiert das Paket "liveconfig-meta" per Abhängigkeit entweder awstats oder webalizer.
Webalizer gibt es z.B. unter Debian 11 nicht mehr.
Ein apt update für Debian Stretch liefert aktuell:
Fehl:3 http://repo.liveconfig.com/debian main Release
404 Not Found
Fehl:4 http://repo.liveconfig.com/debian stretch Release
404 Not Found
Können wir nicht nachvollziehen (eben auch nochmal mit Stretch getestet, sowohl "debian" als auch "debian-test"-Repo.
Nutzen Sie evtl. einen Proxy? Bzw. welche Architektur nutzen Sie?
deb http://repo.liveconfig.com/debian/ main maindeb http://repo.liveconfig.com/debian/ stretch phpapt show liveconfig-metaD.h. Sie arbeiten nach der Migration mit den SQL-eigenen Relationen (FOREIGN KEY ... REFERENCES)?
Ja, auch. (bislang hatten wir Relationen nur über die internen Objekte abgebildet, ab sofort aber eben auch im Datenbankschema verdrahtet)
Könnten Sie das genauer ausführen? Mangels API löschen wir aktuell Domains in der Datenbank direkt.
Die Domains (Tabelle DOMAINS) haben Abhängigkeiten in SUBDOMAINS, DOMAINDATA, DYNAMICDNS, MAILBOXES, MAILALIASES, MAILFORWARDS und vielleicht noch weiteren Tabellen.
Wenn ein Eintrag aus DOMAINS gelöscht wird, werden nun entweder abhängige Daten anderer Tabellen mit gelöscht, oder der Löschvorgang abgebrochen (z.B. wenn noch Postfächer mit dieser Domain existieren - diese müssen zuerst "korrekt" gelöscht werden, damit die aus der Postfix-Konfiguration entfernt werden).
Hallo Herr Keppler, bei dem Changelog "Zonendateien wurden manchmal beim Löschen einer Zone nicht entfernt" werden die Gelöschten Zonen nachträglich entfernt nach dem Update?
Es geht lediglich um die Dateien mit den Zonendaten (/var/lib/bind/...). Aus der BIND-Konfiguration (/etc/bind/zones.liveconfig) wurden Zonen immer korrekt gelöscht.
Ein nachträgliches selektives Löschen inaktiver Zonendateien ist nicht ganz einfach (LiveConfig kennt die gelöschten Zonen ja nicht mehr), auf den Betrieb des BIND hat das aber auch keinen Einfluss.
ZitatGilt das gleiche auch nachträglich für "gecachte DNS-Zonen-Datei beim Löschen einer Zone auch von Secondary-DNS löschen"
Ja, das hatte die selbe Ursache - bei Slaves liegen die gecachten Daten in /var/cache/bind/. Auch da "stören" inaktive Zonen nicht. Notfalls kann man da aber alle Daten aus /var/cache/bind/ löschen und BIND neu starten, dann müssen aber beim Start alle Zonen neu vom Primary abgerufen werden (kann etwas dauern).
Bezüglich
Codeneue DNS-Zonen erhalten notify no; (zur Reduktion von NOTIFY-Nachrichten)
kann man das auch wieder deaktivieren? Ich nutze ein Hidden Primary Setup ohne Liveconfig auf den eigentlichen Nameservern und ohne Notify würden da die Updates nicht mehr zeitnah passieren.
Das ist nur etwas unglücklich formuliert (werden wir ändern). Das "notify no;" wird nur bei Slave-Servern eingetragen. Der Master versendet selbstverständlich weiterhin ein Notify bei Änderungen.
[2022/02/13 16:00:01.559982] [702313|702318] Prepared statements invalidated - trying to recover...
[2022/02/13 16:00:13.572035] [702313|702318] (last message repeated 6 times)
[2022/02/13 16:00:13.572086] [702313|702318] Error while updating database: Re-preparation of MySQL statement failed (7 attempts, waited 63 seconds)
Diese Fehlermeldung bedeutet, dass LiveConfig bei der Ausführung eines SQL-Befehls den Fehlercode 1615 von MySQL/MariaDB erhalten hat. Normalerweise™ tritt dieser Fehler nur dann auf, wenn zwischenzeitlich die Verbindung zum MySQL-Server unterbrochen wurde und deshalb die Prepared Statements nicht mehr in dessen Cache sind. Allerdings kommen da zwei weitere Bugs ins Spiel (#41119, #42041), weshalb LiveConfig sicherheitshalber mehrfach versucht, die Statements neu anzulegen. Nach sieben erfolglosen Versuchen gibt LiveConfig (bzw. dessen Datenbanktreiber) dann auf.
Aus den Kommentaren zum MySQL-Bug #42041 kann man entnehmen, dass das wohl häufiger mal auftreten kann wenn der Server unter sehr hoher Last steht, oder die User-Tabellen gesperrt sind. Da eine "manuelle" Änderung über die MySQL-Konsole aber offenbar klappt, kann man das vermutlich ausschließen.
Laut einer Antwort bei StackOverflow könnte es helfen, den table_definition_cache zu vergrößern. Versuchen Sie das bitte einmal.
Viele Grüße
-Klaus Keppler
[Nachtrag]
Im selben StackOverflow-Beitrag findet sich weiter unten ein Hinweis, dass Prepared Statements mit Views Probleme machen könnten. Die neueren MySQL/MariaDB-Versionen setzen bei der Benutzerverwaltung nun auch auf View, da könnte es also einen Zusammenhang geben.
Wir werden mal prüfen, ob wir Passwortänderungen ohne Prepared Statement an die Datenbank übergeben können (wenngleich das ein Sicherheitsrisiko ist...).
Muss etwas beim Update mit eigener MySQL-Datenbank berücksichtigt werden oder passieren die Migrationen automatisch?
Das erfolgt selbstverständlich alles automatisch. Ein Kunde hat aber schon festgestellt, dass das Update einige Minuten dauern kann und somit der systemd ein Timeout auslöst. Wird mit dem kommenden Update (v2.14.0-dev20220215.x) behoben sein.
ZitatGibt es eine Übersicht der Änderungen? Wir greifen aus externen Tools mangels vernünftiger API direkt auf die Datenbank lesend zu. Müssen wir da irgendetwas wissen?
Bei Read-Only-Zugriffen ändert sich nichts. Es wurden teils einige ohnehin ungenutzte Spalten entfernt, somit sollte das keinen Einfluss haben. Bitte nach wie vor nicht schreibend direkt auf die Datenbank zugreifen. Ein falscher DELETE kann nun dazu führen, dass alle Daten gelöscht werden. 
Hallo,
ab sofort steht die erste Preview für LiveConfig 2.14.0 bereit.
Mit diesem Update gibt es umfangreiche Änderungen am LiveConfig-Datenbankschema. Unsere internen Tests zeigten bislang keine Probleme, wir empfehlen aber insbesondere bei MySQL-Datenbanken vor dem Upgrade ein Backup (mysqldump) zu erstellen.
Die Änderungen stellen u.a. auch die Grundlage für LiveConfig 3 dar - das Datenbankschema von v2.14.x und 3.x ist ab sofort bis auf weiteres identisch. Damit sind in Kürze dann auch Testinstallation mit LiveConfig 3 und bestehenden "eigenen" Datenbanken möglich.
Viele Grüße
-Klaus Keppler
Die Informationsseite zu LiveConfig 3 ist online.
Diese Seite wird regelmäßig aktualisiert, sobald es Updates gibt.
Unsere nächsten Schritte sind:
- Online-Demo bereitstellen
- Downloads der beta1 bereitstellen (zum Test auf eigenen Servern)
Habt bitte etwas Nachsicht beim Video - wir sind keine Youtuber, sondern Softwareentwickler.
Viele Grüße
-Klaus Keppler
Der Expat-Hotfix hat leider für etwas Verzögerung gesorgt. 
Der Tag ist aber noch jung. 
Hallo,
ab sofort steht LiveConfig 2.13.1 zum Download bereit.
Es handelt sich hierbei um ein Sicherheitsupdate - die XML-Parser-Bibliothek Expat wurde auf Version 2.4.4 aktualisiert.
Die Sicherheitslücke CVE-2022-23852 wird mit einem CVSS-Score von 9.8 als kritisch eingestuft (kann ohne Authentifizierung remote ausgenutzt werden). Eine Remote Code Execution ist prinzipiell möglich, allerdings ziemlich anspruchsvoll (LiveConfig hat Sicherheitsmechanismen wie ALSR, Stack Protection etc. aktiviert). Der Prozess, in dem LiveConfig die Expat-Bibliothek nutzt, läuft als Benutzer "liveconfig" (also nicht als root).
Wir empfehlen daher allen Anwendern das Update bei nächster Gelegenheit einzuspielen.
Viele Grüße
-Klaus Keppler
In der XML-Parser-Bibliothek "Expat" ist eine äußerst kritische Lücke bekannt geworden (CVE-2022-23852, CVSS-Score 9.8 von 10).
Derzeit steht noch kein Update von Expat zur Verfügung (daran wird mit Hochdruck gearbeitet). Auch LiveConfig setzt Expat ein, nach unserem aktuellen Kenntnisstand aber nicht in Prozessen die mit root-Rechten laufen.
Sobald Expat 2.4.4 verfügbar ist, werden wir sehr kurzfristig ein Sicherheitsupdate von LiveConfig (v2.13.1) bereitstellen.
Ein umfangreiches Update der Preview-Version (2.14) wird unabhängig davon erfolgen.
Viele Grüße
-Klaus Keppler
Hallo Herr Keppler, steht der 31.01.2022 für die erste Beta von Liveconfig 3 immer noch?!
Ja, ist nach wie vor für nächsten Montag geplant.
Aber: diese erste Beta-Version wird (ganz grob) nur ca. 10% des geplanten Funktionsumfang "fertig" haben - diese Version dient somit primär dazu, die neue Oberfläche, Architektur und vor allem die neue API kennenzulernen.
Details sowie (wenn alles klappt) ein kleines Video dazu dann ab Montag...
Wir können das leider nicht reproduzieren (Debian 11, MariaDB 10.5.12-MariaDB-0+deb11u1)
LiveConfig prüft bei der Passwortänderung lediglich, ob die MySQL/MariaDB-Version <= 5.7.6 ist.
Wenn nicht, dann wird zur Änderung der Befehl "SET PASSWORD FOR 'user'@'localhost' = PASSWORD('StReNgGeHeIm');" ausgeführt.
Die Versionsnummer wird wiederum aus dem Befehl "SHOW VARIABLES" ausgelesen (Variable "version"). Standardmäßig geht LiveConfig aber davon aus, dass MySQL/MariaDB > 5.7.6 läuft.
Die nächsten Schritte wären daher:
- führen Sie mal manuell (als root-Benutzer in MariaDB) den o.g. "SET PASSWORD FOR..."-Befehl aus
- haben Sie im LiveConfig externen Datenbankzugriff konfiguriert? (Serververwaltung -> Datenbanken) Wenn ja, dann prüfen Sie bitte mal ob auch folgender SQL ausgeführt werden kann: SELECT Password FROM user WHERE User='user' AND Host='localhost'
Starten Sie LiveConfig bitte mal neu. Melden Sie sich dann als "admin" an und gehen auf "Serververwaltung" -> "Datenbanken". Wird dort "Status: verbunden" angezeigt?
Ist evtl. beim Upgrade irgendwas schief gelaufen? Führen Sie ggf. mal das Programm "mysql_upgrade" aus (als root)
