Beiträge von kk

  • PHP 8.2 Release Candidates

    Hallo,


    ab sofort stehen in unseren PHP-Repositories für Debian/Ubuntu die Release-Candidate-Pakete (RC) für PHP 8.2 zum Download bereit (php-8.2-opt).


    PHP 8.2 soll voraussichtlich am 24.11.2022 erscheinen, bis dahin erscheint etwa alle 14 Tage ein neuer Release Candidate. Mit den RC-Paketen können Anwendungen bereits vorab auf Kompatibilität mit PHP 8.2 getestet werden.


    Viele Grüße


    -Klaus Keppler

  • php-session-lifetime Permission denied seit Update

    Ja, dann prüfen Sie mal in welches der Verzeichnisse genau der web1 keinen Zugriff hat.
    Er braucht selbstverständlich Lesezugriff auf die php.ini, sonst kann PHP auch nicht sauber ausgeführt werden.
    Evtl. ist /var/www/web1/conf zu restriktiv eingestellt? (sollte www-data:<Vertrag> gehören und Mode 0750 haben)

  • php-session-lifetime Permission denied seit Update

    Das Programm php-session-lifetime wechselt zur Sicherheit jeweils in den betroffenen User, bevor die php.ini verarbeitet wird.
    In diesem Fall wird also der User "web1" keine Leseberechtigung für die betroffene php.ini-Datei haben.


    Sie können z.B. mal als root mit "su -s /bin/bash web1" eine Shell mit dem Benutzer web1 starten und dann schauen, ob er in das betroffene Verzeichnis kommt.


    Viele Grüße


    -Klaus Keppler

  • php-session-lifetime Permission denied seit Update

    Welche LiveConfig-Version lief denn vor dem Update?
    Ich bin mir aber ziemlich sicher, dass das Problem nicht mit dem LiveConfig-Update zusammenhängt. Die Scripte zum Löschen alter PHP-Session-Files sind schon ziemlich lange nicht mehr geändert worden.


    Der Aufruf des Scripts erfolgt durch /usr/lib/liveconfig/cron.php.sh - da gibt's auch nicht viel was schief gehen könnte.


    Am meisten wundert mich die Meldung "Permission denied". Wenn das Script als root ausgeführt wird, dann deutet das darauf hin dass vielleicht SELinux oder AppArmor aktiviert wurden und nicht passend konfiguriert sind.


    Viele Grüße


    -Klaus Keppler

  • Mehrere 2FA Methoden erlauben

    Ja, im LiveConfig 3 gibt's eine neue Anmeldemaske, welche separat nach FIDO oder OTP-Code fragt.
    Wenn man den FIDO-Token nicht dabei hat, kann man den OTP-Code einfach ans Passwort anfügen (also z.B. "SeCrEt123456" eingeben).

  • Ausblick auf das nächste große Release

    Zitat von kroerig

    was mir gerade fehlt, ist die Möglichkeit pro Kunde/Vertrag/Domain einstellen zu können, dass Mails nur mit TLS angenommen werden.


    Kommt da was in V3? Inzwischen sind sich die Juristen wohl einig, dass man zur Einhaltung der DSGVO "force/mandatory TLS" einstellen muss.


    Schwierig. Ein öffentlicher SMTP-Server muss gemäß RFC3207 auch unverschlüsselte Verbindungen erlauben. Prinzipiell ist es aber möglich, Postfix so zu konfigurieren dass bei bestimmten Empfängerdomains nur verschüsselte eingehende Verbindungen erlaubt sind (reject_plaintext_session). Wer sowas mal (manuell) machen möchte, bitte kurze Mail an support@liveconfig.com damit wir die notwendigen Einstellungen abklären können (geht über ein paar Lua-Einstellungen).
    Ob "normale" Benutzer so eine Funktion aktivieren dürfen müsste man sicherlich diskutieren - das dürfte in der Praxis häufig Probleme machen.
    Ich habe das dennoch mal als Feature Request angelegt, da wir aktuell ohnehin einige Themen bzgl. E-Mail-Sicherheit in der Pipeline haben.

  • Ausblick auf das nächste große Release

    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.

  • Unexpected server answer

    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.

  • Kündigungsbutton

    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?

  • LiveConfig 2.14.3

    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

  • LiveConfig 2.14.0


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

  • Kündigungsbutton

    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.

  • Kündigungsbutton

    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.

  • DB-Schemaupgrade bei Upgrade von 2.13.1 auf 2.14.2 schlägt fehl

    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:

    Code
    [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.

  • DB-Schemaupgrade bei Upgrade von 2.13.1 auf 2.14.2 schlägt fehl - SQLite

    Ö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:


    Code
    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*

  • DB-Schemaupgrade bei Upgrade von 2.13.1 auf 2.14.2 schlägt fehl - SQLite

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


    SQL
    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.