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.
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.
ZitatDie 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).
Zitatutf8mb4 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 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
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.
Welche Linux-Distribution & -Version genau, sowie welche MySQL- oder Maria-DB-Version genau wird verwendet?
Da ich nur "Bahnhof" verstehe, frage ich an, wie lässt sich der Kunde spurlos vom Server entfernen?
Zuerst einmal muss die Datenbank repariert werden - das ist nämlich der Grund warum es kracht ("Database exception: database disk image is malformed"). Wir haben hierfür einen Artikel in der Wissensdatenbank bereitgestellt:
https://www.liveconfig.com/de/kb/sqlite-reparieren/
Wenn die LiveConfig-Datenbank erfolgreich repariert wurde, setzen Sie noch einmal das Feld "HC_DELETED" auf "0" und löschen den Kunden dann erneut. Danach sollte das eigentlich klappen.
So wie es aussieht ist entweder noch eine PHP-Version für eine Subdomain ausgewählt, die zwischenzeitlich vom Server entfernt wurde, oder es gibt keine PHP-Standardversion für die ausgewählte Ausführungsart (CGI/FPM) auf dem Server.
Prüfen Sie daher bitte mal, ob die Pakete "php-cgi" bzw. "php-fpm" installiert sind.
Viele Grüße
-Klaus Keppler
Wie lautet die exakte Fehlermeldung in /var/log/liveconfig/liveconfig.log, die während der Aktualisierung geschrieben wird?
