Beiträge von kk

Ab v2.14.3 (Preview, gestern aktualisiert) prüft LiveConfig ob die MySQL-Datenbank utf8mb4 mit "langen" Indizes unterstützt. Wenn das nicht der Fall ist, erfolgt die Migration und der Zugriff mit utf8.
Wir haben das erfolgreich mit MySQL 5.5 durchgespielt.

Man bekommt alte MySQL/MariaDB-Installationen übrigens durchaus dazu, auch lange Indizes zu unterstützen. Der "Trick" besteht darin, dass manche Einstellungen in der MySQL-Konfiguration auf "1" statt auf "ON" gesetzt werden müssen (ist ein Bug in älteren MySQL-Versionen).
In der Regel genügt es, eine Datei z.B. in /etc/mysql/conf.d/99-innodb.conf anzulegen und anschließend MySQL neu zu starten:

[mysqld]
innodb_file_format = Barracuda
innodb_large_prefix = 1
innodb_file_per_table = 1

MySQL <5.6 und MariaDB <10.2 brauchen die Option "innodb_file_per_table" (bei neueren Versionen klappt das auch ohne diese Einstellung, die dann aber auch eh standardmäßig aktiv ist).
Manchmal liest man auch was von der Einstellung "innodb_default_row_format". LiveConfig braucht diese nicht, neuere MySQL-Versionen unterstützen diese auch nicht mehr.

Öhem, sorry, ich war da gerade irgendwie auf MySQL fixiert (wir haben heute den ganzen Tag nur am MySQL-Support gearbeitet...)

Es kann durchaus sein, dass die SQLite-Datenbank an der Stelle irgendwo korrupt ist.
Am besten wäre es daher, die Datenbank mal zu dumpen und neu zu erzeugen:

systemctl stop liveconfig
cd /var/lib/liveconfig
mv liveconfig.db liveconfig.db.ORIG
sqlite3 liveconfig.db.ORIG .dump >liveconfig.sql
sqlite3 liveconfig.db <liveconfig.sql
rm liveconfig.sql
chown liveconfig:liveconfig liveconfig.db*

Mit folgendem SQL müssten Sie die Dupletten löschen können. Bitte an das Datenbank-Backup vorher denken.

DELETE r1 FROM RRD_TRAFFIC r1
JOIN RRD_TRAFFIC r2 ON (r1.RRD_ARCHIVEID = r2.RRD_ARCHIVEID AND r1.RRD_SLOTID=r2.RRD_SLOTID AND r1.RRD_TIMESTAMP < r2.RRD_TIMESTAMP);

Führen Sie bitte mal folgenden SQL-Befehl aus, um eventuelle Dupletten zu finden:

SELECT RRD_ARCHIVEID, RRD_SLOTID, COUNT(*)
FROM RRD_TRAFFIC
GROUP BY RRD_ARCHIVEID, RRD_SLOTID
HAVING COUNT(*) > 1

Doppelte Daten hätten da eigentlich auch früher (vor dem Update) gar nicht drin landen dürfen.
Wir prüfen derweil mal, ob LiveConfig eventuelle Dupletten automatisch löschen kann.

Oh, danke für den Hinweis. Wird gleich korrigiert.

Wir arbeiten aber bereits an einer komfortableren Lösung. Wenn LiveConfig erkennt, dass das Backend "zu alt" ist, soll es selbständig (ohne Anpassung in der liveconfig.conf) auf utf8 wechseln.

Viele Grüße

-Klaus Keppler

Dieser Fehler ist bereits in v2.14.3 (aktuelle Preview) behoben - der trat dann auf wenn SOAP-Funktionen mit Reseller-Verträgen ausgeführt wurden.

Der einfachste Weg wäre tatsächlich, mit der 2.14.3 und db_options = "charset=utf8,collation=utf8_unicode_ci" die Datenbank eben mit "nur" utf8 zu verwenden. Wenn später irgendwann mal auf MySQL >= 5.7 oder MariaDB >= 10.1 aktualisiert wird, lassen sich die Tabelleneinstellungen relativ einfach ändern (ALTER TABLE tablename CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;)

Eine Migration von MySQL auf SQLite haben wir bislang noch nicht geplant.

Da aber scheinbar noch viele "Antik-Systeme" im Einsatz sind prüfen wir heute, ob LC die Version der Backend-Datenbank erkennen kann und dann selbständig auf utf8 schaltet.

Zitat von dkrause

Es ist (leider) noch ein altes Debian 8.

Debian 8 LTS ist seit zwei Jahren "end-of-life" (30.06.2020).
Unser Fehler bestand darin, dass wir für die 2.14-Version keine entsprechende Paketabhängigkeit eingerichtet haben, damit kein (versehentliches) Upgrade möglich ist.

Zitat

Die MySQL-Option war/ist schon aktiv. leider legt das Update neue Tabellen mit der Kollation utf8mb4 an. Meiner Meinung nach wäre nur ein reines utf8 notwendig.

Nein, es gibt Unicode-Zeichenklassen die MySQL eben nur in utf8mb4 korrekt speichern kann (z.B. Emoticons, die auch in vielen IDN-Domainnamen erlaubt sind).

Zitat

utf8mb4 sprengt das Limit. Das hätte in den Release Note kommuniziert werden müssen. Erst ab MariaDB 10.2.2 dürften die Voraussetzungen für ein problemloses Update erfüllt sein.

Wir haben mit v2.14.3 nun die Optionen "charset" und "collation" für die Konfigurationsanweisung db_options eingeführt. Damit kann (falls zwingend erforderlich) von utf8mb4 auf utf8 umgeschaltet werden. Allerdings wird eine solche LiveConfig-Datenbank nicht mit komplexen UTF8-Zeichen umgehen können (man muss dann später die Datenbank manuell auf utf8mb4 konvertieren).

Die wirklich einfachste Lösung wäre, den Server zu aktualisieren (siehe Anleitung). Der Debian 9 LTS-Support läuft diese Woche auch aus, d.h. zum Ende diesen Jahres wird LiveConfig auch das nicht mehr unterstützen.

Welche Distribution genau setzen Sie denn ein? MySQL 5.5 ist schon extrem alt.

Eventuell kann die MySQL-Einstellung innodb_large_prefix helfen.

Argh!
Danke für den Hinweis.
Wäre ja auch zu schön, wenn sich die einzelnen echo-Implementierung gleich verhalten würden... :-/

Update ist bereits in Arbeit...

Wir haben eben die Version 2.14.1 bereitgestellt. Diese beseitigt folgende Probleme, die uns vereinzelt gemeldet wurden:

• Bei Dovecot >=2.3 wurde die "stats-writer"-Anweisung in die dovecot.conf aufgenommen. Je nach System/Shell war dieser Eintrag aber eventuell korrupt (falsche Zeilenumbrüche).
• die Migration der Tabelle MAILBOXES schlug fehl, wenn geparkte Postfächer (also Postfächer ohne Domain) vorhanden waren
• wenn manuell Daten aus den Tabellen IPS oder WEBSERVERS gelöscht worden sind, schlug die Migration fehl.

Bei wem das Update auf 2.14.0 reibungslos durchgelaufen ist, für den spielt dieses Update eigentlich keine Rolle.

Viele Grüße

-Klaus Keppler

Künftig sollen auch alphanumerische Kundennummern möglich sein (z.B. "K12345"), daher wurde die betroffene Datenbankspalte geändert.

Wir lassen uns etwas einfallen, wie wir numerische Kundennummern trotzdem korrekt sortieren können.

Danke für die Info! Wir haben die RPM-Pakete neu signiert und aktualisiert, sollte nun klappen.
(der GPG-Agent für die Signatur hatte ein Problem gemeldet, die Fehlermeldung dazu ging leider unter)

Viele Grüße

-Klaus Keppler

Genaue die selbe Meldung hatte wenige Stunden vorher auch ein anderer Kunde gemeldet. Auch hier waren "Datenleichen" die Ursache.

Wir werden das Upgrade an dieser Stelle anpassen, so dass LiveConfig nur gültige IPs übernimmt. Der o.g. SQL-Befehl ist praktisch perfekt.

Viele Grüße

-Klaus Keppler

Wie im Text weiter oben geschrieben und wie auch im Änderungsverlauf dokumentiert wurde die in LiveConfig genutzte Expat-Bibliothek mit v2.13.1 aktualisiert (30.01.2022).

Viele Grüße

-Klaus Keppler

Hallo,

wir freuen uns, die Verfügbarkeit von LiveConfig 2.14.0 bekanntgeben zu dürfen!

Die größte Änderung in dieser Version ist das komplett überarbeitete Datenbankschema, um später einen völlig reibungslosen Wechsel auf LiveConfig 3 zu ermöglichen.
Zudem gab es etliche Detailverbesserungen - alle Details stehen im Änderungsverlauf.

Viele Grüße

-Klaus Keppler

Siehe https://www.liveconfig.com/de/blog/2021/02/liveconfig-v2.11/ (gelbe Box ganz unten, sowie darin der letzte Absatz).

Viele Grüße

-Klaus Keppler

Hallo,

der Fehler tritt auf, wenn Einträge der Tabelle WEBSERVERIPS auf nicht mehr vorhandene Einträge in IPS verweisen.
Das sollte eigentlich nicht passieren. Wir werden das mit dem nächsten Update ändern (da werden ggf ungültige Einträge dann vorher gelöscht).
Sollte noch jemand an diesem Problem hängen bleiben: entweder den foreign key check vorübergehend deaktivieren, oder kurze Mail an support@liveconfig.com und wir helfen mit einem passenden SQL-Befehl aus.

Viele Grüße

-Klaus Keppler

Hallo zusammen,

wir haben den KB-Artikel zu LC3 eben aktualisiert. Der aktuelle Zeitplan sieht so aus:
- heute (01.06.) wurde die Online-Demo nochmal aktualisiert
- am 01.07. ist das nächste Update der Online-Demo geplant
- danach gibt's jeden Montag ein Update (mit Changelog) zum Entwicklungsfortschritt

Die Entwicklung kommt mit großen Schritten voran. Kleinere Verzögerungen gab es aufgrund unvorhersehbarer Probleme - eine kleine Auswahl:
- bestimmte HTTPS-Requests aus LiveConfig heraus klappten komischerweise nicht mehr (Fehler "Out of memory" von cURL). Stellte sich dann als Bug in cURL heraus.
- unsere Unit-Tests brachten irgendwann OpenSSL zum Absturz. Nach längerer Fehlersuche: Bug in OpenSSL gefunden und gemeldet.
- es stellte sich heraus, dass die von uns neu verwendete Lua-C++-Bibliothek ein schweres "Showstopper-Problem" hat, d.h. wir mussten diese komplett durch eine andere Bibliothek ersetzen
- für die systemd-Anbindung (s.u.) haben wir eine (kreative) Lösung entwickeln müssen, um Systeme von CentOS 7 bis Ubuntu 22 unterstützen zu können und auch nicht von künftigen Distributionen überrascht zu werden (ich sage nur: zstd-Kompression im neuen Kernel und systemd...)
Mit den "Low-Level"-Arbeiten sind wir inzwischen aber durch und rechnen daher nicht mehr mit größeren Überraschungen.

Aktuell liegt der Fokus also auf der REST-API und dem Frontend. Die REST-API-Doku wurde auch frisch aktualisiert, hier kommen derzeit pro Woche 2-3 neue Funktionen dazu. Daher rechnen wir damit, ab Juli im Wochentakt in den Endspurt zu gehen. Ein exaktes Fertigstellungsdatum wäre unseriös, wir versuchen den Fortschritt möglichst transparent zu machen.

Was inzwischen noch neu ist:
- LiveConfig prüft nun, ob alle für einen Dienst (z.B. "E-Mail") notwendigen Services (postfix, dovecot, ...) auch laufen. Hierbei verbindet sich LC3 direkt über den dBus mit systemd (ist somit extrem effizient und erfasst Änderungen in Echtzeit) (LC3-Demo: Serververwaltung -> Tab "E-Mail")
- Service-Probleme werden als "Popup-Benachrichtigungen" in der Oberfläche angezeigt falls man gerade angemeldet ist.
- die Graphen werden nun mit einer anderen, eleganteren Bibliothek erstellt (somit kann man u.a. auch die einzelnen Werte anzeigen lassen)
- das neue Backup-System unterstützt verschiedene Storage-Backends, u.a. Borg, Restic und das klassische Tar-Archiv. Ziele können wahlweise lokal (auf dem selben Server) oder remote (via SSH oder FTPS) sein. Borg und Restic sind die schnellsten und effizientesten Open-Source Backup-Tools - man will kein Backup mehr mit tar machen.

Am 20.06. planen wir LiveConfig 2.14 zu veröffentlichen. Wie schon angekündigt enthält das recht umfangreiche Änderungen an der Datenbank. Diese sind Voraussetzung für LiveConfig 3, d.h. danach wären auch Testinstallationen mit LC3 auf eigenen Servern möglich.

Vielen Dank schonmal für die vielen positiven Rückmeldungen!

Viele Grüße

-Klaus Keppler

Zitat von Systemhaus-EHST

Aber Serverseitige Einstellungen können nunmal nicht per IMAP Client weder auf dem Handy noch am PC vorgenommen werden.

Doch, dafür gibt's das "managesieve"-Protokoll (RFC5804).

Manuell kann man jetzt schon managesieve mit Dovecot einrichten. Wir möchten das seitens LiveConfig durchaus vereinfachen (insbesondere dass es keine Kollisionen mit dem LC-Autoresponder gibt). Steht aber erst nach v3.0 auf der ToDo-Liste.