Beiträge von kk

Zitat von Mogwais

Wird die Rest Api in absehbarer Zeit in der Lage sein sämtliche Funktionen der Weboberfläche zu bedienen?

Und wird v3 alle Funktionen von v2 haben?

Ja und ja.
Die Architektur von LC3 ist komplett "API first", d.h. die Oberfläche ist praktisch nur noch ein Frondend für die REST-API. In der LC3 REST API Doku sieht man das z.B. bereits in den Funktionen für /servers/.
Das finale Release von LC3 wird erst dann erfolgen, wenn der Funktionsumfang von bisherigen LC2 übernommen ist.

Kein Problem, Infos kommen morgen (inkl. Update der API-Doku).

Die Fehlermeldung dürfte von der Anmeldung mittels FIDO U2F kommen, mit der Datenbank hat das also nichts zu tun.

Es handelt sich da also um irgendein Frontend-Problem, auf das wir keinen direkten Einfluss haben.
Hat sich evtl die URL vom LiveConfig geändert? (auch eine Änderung der Port-Nummer genügt schon)
Ggf müsste man U2F vorübergehend mal deaktivieren (einfach das admin-Passwort mittels "liveconfig --init" zurücksetzen).

Viele Grüße

-Klaus Keppler

PS: auch wenn das mit diesem Problem nichts zu tun hat - Debian 9 ist End-of-Life, bitte auf Debian 10 aktualisieren.

Zitat von ap24

In jedem Server Control Panel besteht auch die Möglichkeit den entsprechenden Server mit einem Mausklick zu kündigen...

Das wage ich zu bezweifeln - das dürfte vielmehr die Vertragsverwaltung der jeweiligen Anbieter sein. Ein Server Control Panel "weiß" überhaupt nichts von den Vertragskonditionen (Kündigungstermin etc.).

Zitat

Aber klar man kann auch für alles jeweils einen eigenen Kundenbereich bereitstellen (Hosting/Verträge/Ticketsystem etc.), wäre ja auch wirklich zu einfach alles nur über einen Zugang zu ermöglichen...

Man kann LiveConfig problemlos in eine beliebige Auftragsverwaltung integrieren, mit nur "einem Zugang" (Zauberwort Single Sign-On).

Zitat

Ich suche einfach nur eine Möglichkeit für unsere Reseller einen entsprechenden Kündigungsbutton für deren Endkunden in LiveConfig bereitzustellen, es muss auch keine automatische Löschung etc. erfolgen, es reicht wenn nur eine einfache Email mit der Kundennummer/Vertragsnummer/Kündigungstermin an den Reseller verschickt wird.

Ich gehe mal davon aus, dass die Reseller irgendwo eine Bestellmöglichkeit haben? Was spricht dann dagegen, genau dort auch den "Kündigungsbutton" (mit o.g. Minimal-Umfang) einzubauen?

Hallo,

ab sofort steht LiveConfig v2.14.3 bereit. Wie dem Änderungsverlauf zu entnehmen ist, handelt es sich dabei primär um Bugfixes die im Zusammenhang mit den vielen internen Änderungen zur 2.14 stehen.

Die wichtigsten Änderungen sind:

• LiveConfig-Installationen (<2.14.0) mit einer sehr alten MySQL/MariaDB-Datenbank als Backend werden nun automatisch im "utf8"-Zeichensatz (statt utf8mb4) migriert, wenn utf8mb4 nicht uneingeschränkt verfügbar ist (LiveConfig erkennt das automatisch)
• Ein SQL-Fehler im Zusammenhang mit der SOAP-API & Resellern wurde behoben

Viele Grüße

-Klaus Keppler

Zitat von weltmeister

Seit dem Update funktioniert das sortieren nach Kundennummern nicht mehr, aktuell geht das nur wie folgt:

1
10
11
...
19
2
20
21
...
29
3
30
...

Kann dies bitte wieder angepasst werden? Viele Reseller sind irritiert und haben sich bereits gemeldet.

Alles anzeigen

Sollte mit v2.14.3 (ab sofort verfügbar) wieder wie gewohnt funktionieren.

Nein, das wird leider nicht klappen (LiveConfig ist ja nur eine rein technische Serververwaltung, eine Kündigung müsste ja ans Bestell-/Auftrags-/CRM-System des jeweiligen Webhosters gelangen.

Über die IFRAME-API ist es aber möglich, eigene Seiten einzubinden.

Ja, das wird derzeit in die Website integriert (kommt auf die Shop-Seite sowie zur Kontakt-Seite).

Wie bisher geht das aber auch unkompliziert per formloser E-Mail oder das Kontaktformular.

Danke für den Hinweis, der Fehler ist mit v2.14.3 behoben (bereits als Preview verfügbar).

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