Posts by kk

Was liefert der Befehl "dpkg -l | grep -i mariadb" ?

Hallo!

Ab sofort steht LiveConfig v2.16.1 zum Download bereit. Die wichtigsten Änderungen sind:

• Erkennung von MariaDB-Paketen wurde verbessert
• Erkennung des "postfix3"-Paketes (nicht-Standard!) unter CentOS
• unter Debian 12 kann nun auch das vollständig systemd-journald-basierte Log geparsed werden (damit zählt LiveConfig die ein- und ausgehenden E-Mails)

Außerdem wurden neben einigen kleineren Fehlern auch mögliche Problem beim Upgrade des Datenbank-Schemas von (sehr) alten LiveConfig-Installationen behoben.

Die vollständige Liste aller Änderungen findet sich wie immer im Changelog.

Die Änderungen am Schema der LiveConfig-Datenbank sind weitgehend abgeschlossen, so dass eine reibungslose Umstellung auf LiveConfig 3 (und auch zurück) möglich sein wird.

Das Update sollte - wie immer - reibungslos über den jeweiligen Paketmanager möglich sein.

Falls der Repository-Key abgelaufen ist, am besten das Paket liveconfig-keyring installieren (siehe Hinweise).

(ab März 2024 werden alle Pakete und Repositories mit dem neuen Key signiert, der in liveconfig-keyring bereits enthalten ist)

Viele Grüße

-Klaus Keppler

PHP 8.3.0 inklusive der üblichen Extensions (inkl. apcu/memcached/redis/igbinary/imagick) steht ab sofort in unseren Repositories zum Download bereit.

Hallo,

bei unseren automatisierten Tests kommt es mit PHP 8.1.25 und 8.2.12 immer wieder mal zu "Segmentation Faults", wenn der Ioncube Loader (13.0.2) und Opcache aktiv sind.

Reproduzieren lässt sich das z.B. mit folgendem Befehl:

echo '<?php echo php_ini_loaded_file(); ?>' | /opt/php-8.2/bin/php-cgi -q

Sollte es also zu Segmentation Faults bei PHP kommen, prüfen Sie ob Ioncube und Opcache aktiviert sind, und deaktivieren Sie ggf. eines der beiden Module.

Viele Grüße

-Klaus Keppler

Auf die Gefahr hin dass ich mich wiederhole: das ist kein Fehler in LiveConfig, sondern eine "Unschönheit" in MariaDB, dass /usr/bin/mysql inzwischen diese Warnmeldung ausgibt.

Wir testen LiveConfig ausschließlich mit den bei der jeweiligen unterstützten Distribution mitgelieferten Datenbanksystemen durch. Wer eine Software aus einer anderen Quelle installieren mag, muss das (schon immer) auf "eigenes Risiko" machen. Hier einen Workaround einzurichten (z.B. Anpassen des Dateinamens o.ä.) sollte einen Admin vor keine unlösbare Aufgabe stellen.

Wir werden die Prüfung auf /usr/bin/mariadb aber berücksichtigen, da früher oder später dieses Verhalten ja auch in die "normalen" Distributions-Versionen einfließen dürfte.

Hallo,

voraussichtlich am 23. November 2023 wird PHP 8.3 erscheinen.

Seit einiger Zeit stellen wir ja schon die Release-Candidate-Builds für PHP 8.3 bereit. Diese wurden nun nochmal aktualisiert (PHP 8.3 RC6 - der "finale" Release Candidate). Zudem werden aktuell auch die "üblichen" Extensions paketiert und bereitgestellt - allen voran ImageMagick (php-8.3-opt-imagick). Die restlichen Extensions (apcu, igbinary, memcached, redis) folgen noch diese Woche.

Viele Grüße

-Klaus Keppler

Mit Version 3.0 wird es da eine Änderung geben. Die "kleinste" Lizenz wird Let's Encrypt (bzw. alle ACME-kompatiblen Anbieter) unterstützen, aber muss leider auch ein klein wenig teurer werden. Die günstigste Lizenz macht nunmal den größten Supportaufwand.

Details folgen wenn's soweit ist.

Nein, da gab es keine Änderungen.

Sie meinen schon die unter "Verwaltung" -> "LiveConfig" -> "Eigene Links" verwalteten Seiten?

Auf der LiveConfig-Demo (admin/admin) ist eine Demo eingerichtet. Möglicherweise klappt etwas mit der Authentifizierung (seitens des aufgerufenen PHP-Scripts) nicht? Dieses muss ja eine Art "Callback" an LiveConfg machen, um zu prüfen, ob und welcher Benutzer angemeldet ist.

Ansonsten schicken Sie uns am besten mal (temporäre) Zugangsdaten an support@liveconfig.com, dann schauen wir das gerne mal kurz an.

Ich drücke mich mal vorsichtig aus: Händler sehen Paypal durchaus auch zwiegespalten.

(Sicherheitseinbehalt, Sperrungen, Erreichbarkeit, ...)

Wir planen das längerfristig wieder anzubieten, dazu müssen aber erst ein paar andere Rahmenbedingungen stimmen. Zusätzlich ist die Zahlung per Kreditkarte in Vorbereitung (nicht über Paypal).

Wenn Sie in der LC3-Demo als "admin" angemeldet sind, gehen Sie einfach auf "Verwaltung" -> "Kunden" und klicken in der Tabelle ganz recht auf das "..."-Icon. Dort dann den Punkt "als Benutzer [...] anmelden" anklicken. Und schon sind Sie als entsprechender Endnutzer angemeldet.

Es gbt unter "Serververwaltung" -> "E-Mail" jeweils bei den Postfix- und Dovecot-Einstellungen eine Checkbox "[X] nur verschlüsselte Benutzeranmeldung erlauben".

Damit können Sie optional auch unverschlüsselte Anmeldungen erlauben.

Ich gebe mal einen ganz kleinen Einblick in die Komplexität scheinbar trivialer Funktionen.

So sieht die Maske zur Bearbeitung der Domaineinstellungen künftig aus:

Herausziehen möchte ich hier mal nur den Punkt "TLS/SSL-Zertifikat".

• Wenn bereits ein oder mehrere passende Zertifikate im System vorhanden sind, die diesem Kunden oder dem bearbeitendem Admin gehören, dann würden diese hier mit zur Auswahl angezeigt. "Passend" heißt dabei, dass auch Wildcard-Zertifikate mit berücksichtigt werden, wobei darauf geachtet werden muss, ob die bearbeitete (Sub)-Domain durch Wildcards korrekt umfasst würde (z.B. gilt "*.example.org" nicht für die Domain "example.org").
• Die Option "neues Zertifikat" (wie im Screenshot zu sehen) taucht nur dann auf:
  • wenn mindestens ein Anbieter-Account für automatisierte, kostenfreie TLS-Zertifikate vorhanden ist (z.B. Let's Encrypt, können aber auch andere Anbieter sein). Dabei wird geprüft, ob für den aktuellen Kunden ein eigener Account hinterlegt ist, wenn nicht dann rekursiv aufsteigend für die Reseller nach oben.
  • und wenn kein Zertifikat vorhanden ist, das vom selben automatisierten Anbieter kommen würde (um Doppelbestellungen zu vermeiden) und automatisiert verlängert werden würde. Somit soll es möglich sein, ggf. auf einen anderen automatisierten Anbieter zu wechseln.
  • falls mehrere Anbieter verfügbar sind, gibt es hier eine Auswahl-Box. Der Default-Wert hierfür ist für den Admin einstellbar.
• Wird ein automatisiertes Zertifikat "weggewechselt" (also nicht mehr aktiv genutzt), dann bleibt dieses zwar noch im System vorhanden, wird aber nicht mehr verlängert (außer es wird wieder aktiviert). Abgelaufene Zertifikate (die also nicht verlängert wurden) und nicht mehr in Verwendung sind, werden automatisch gelöscht.
• Jetzt gibt's kostenfreie TLS-Produkte, die keine Wildcard-Zertifikate erlauben, die keine SAN-Zertifikate erlauben, und sogar welche, die nicht einmal die "www"-Subdomain als SAN erlauben. Wenn nun die Option mit "auch auf www-Subdomain anwenden" aktiviert ist, dann muss bei so einem TLS-Produkt ein komplett separater Bestellprozess losgetreten und verwaltet werden.
  Ohnehin fordert die "www-Subdomain"-Option eine ganze Menge Prüfungen (Was wenn nachträglich "www" deaktiviert wird? Oder auf eine andere IP-Adresse geändert wird? Oder umgekehrt: ein TLS-Zertifikat wurde bestellt, und später soll die www-Subdomain da mit dazu kommen...)
• Die Bestellung von TLS-Zertifikaten ist ein komplett asynchroner Prozess. In der Praxis läuft das zwar meistens binnen weniger Sekunden ab, aber wir hatten schon häufig den Fall, dass Bestellungen aufgrund verschiedenster Ursachen mal mehrere Stunden oder Tage brauchen.
  Die Herausforderung ist nun: wie visualisiert oder verwaltet man es, dass ein Kunde zwar ein (z.B.) Let's-Encrypt-Zertifikat bestellt hat, vielleicht aber noch ein anderes oder auch gar kein Zertifikat aktiv ist? Sobald das Zertifikat eintrifft soll es automatisch übernommen werden, bis dahin soll aber alles möglichst noch so wie bisher laufen.
• Ein Webhoster verdient an kostenfreien Zertifikaten nichts, daher darf es an dieser Stelle weder einen direkten Aufwand geben, noch darf es zu indirektem Aufwand aufgrund von Kundennachfragen kommen.
• Die Domainvalidierung (DV) muss schließlich auch zuverlässig durchgeführt und für eventuelle Fehlerfälle verständlich nachvollziehbar protokolliert werden (häufigste Ursache: Probleme bei authoritativen Nameservern, von Kunden übermütig gesetzte CAA-Records, etc. - also außerhalb des Einflußbereichs von LiveConfig).
• Last but not least muss ja noch irgendwo ausgewählt werden, was für Schlüssel für die Zertifikate verwendet werden sollen (RSA oder EC). Auch das kann je nach TLS-Produkt variieren (manche Anbieter erlauben z.B. keine EC-Schlüssel in deren kostenfreien Produkten). Der Endkunde soll damit nicht "belästigt" werden (daher gibt es hier keine Key-Auswahl).

Einige weitere Aspekte habe ich bestimmt noch vergessen - aber das zeigt hoffentlich schon, wie komplex die Logik hinter einer einzigen Checkbox sein kann. Und LiveConfig hat viele Checkboxen.

Je nach Patch-Stand in PHP lässt sich das sogar noch einfacher umgehen:

ini_set('open_basedir', '..');
chdir('..');chdir('..');chdir('..');chdir('..');chdir('..');chdir('..');
ini_set('open_basedir', '/');

Ganz unnützig ist open_basedir aber auch wieder nicht, weil es einen anderen (kritischen) Angriffsvektor gibt, der nach meinem Kenntnisstand nur damit umgangen werden kann.

Kleine Preview: so wird beispielsweise ein Backup-Ziel mit Borg konfiguriert:

Und so sehen Zeitpläne aus:

Und wie das aus Benutzersicht aussieht (Verwaltung der Backups, Restore-Jobs etc.) gibt's auch bald zu sehen...

Ich habe eine Hand voll vorheriger Beiträge eben weg-moderiert, da die mit dem Thema überhaupt nichts zu tun hatten.

Bitte immer schön sachlich bleiben. Stichwort "Netiquette" und so.

Zum Backup: das in LiveConfig 2.x enthaltene Backup-System ist eine Beta-Funktion. Diese wird auch nicht weiter unterstützt, sondern durch ein komplett anderes Backupsystem in LiveConfig 3.x ersetzt. Bei einer Multi-Server-Datensicherung gibt es eine ganze Menge Herausforderungen, die nicht ganz trivial sind - u.a.:

• Backup als "root"-Benutzer. Total einfach umzusetzen, aber eine ganz schlechte Idee (Dateien: Hardlink auf eine Datei die einem nicht gehört, und schon hat man die im Backup. Oder MySQL: schnell ein paar Trigger konstruiert, und schon kann man durch das Erstellen eines Backups beliebige SQL-Befehle in beliebigen Datenbanken ausführen).
  Damit LiveConfig all diese Angriffsvektoren eben nicht unterstützt, erstellen wir alle Backups ausschließlich mit den Berechtigungen des jeweiligen Benutzers. Bei Datei-Backups ist das vergleichsweise trivial, bei Datenbanken aber nicht: hier muss (nur) für das Backup temporär ein Benutzer mit den gewünschten Rechten angelegt und nach dem Backup wieder zuverlässig gelöscht werden.
• Multi-Server-Deployment: Webspace auf Server A, Datenbanken auf Server B und E-Mail auf Server C. LiveConfig ist das einzige Controlpanel, das solche Setups unterstützt, und wird gerade deshalb häufig genau in dieser Form genutzt. Die Datensicherung macht das freilich nicht einfacher, weil somit die einzelnen Backup-Jobs orchestriert werden müssen.

Das Alles war mit dem "alten" Backup-System nicht so realisierbar wie wir es ursprünglich geplant hatten. Das neue System macht das.

Zudem greifen wir beim neuen Backup auf vorhandene Tools wie Borg und Restic zurück und machen keine "dummen" FTP-Backups. (wer das zwingend braucht, kann aber auch das haben).

Sehr viele Dinge, die wir mit v3 auflösen, lassen sich in LiveConfig 2.x leider nicht einfach nachrüsten - sonst wäre das selbstverständlich der entspannteste Weg. Wir sind bei vielen Funktionen auf eine grundlegend andere Architektur angewiesen - diese ist wesentlich mächtiger und zukunftsfähiger, aber eben leider Gottes komplett neu.

Wir nähern uns immer mehr der Fertigstellung, aber auf neue (naturgemäß nicht belastbare) Terminankündigungen verzichte ich besser.

Derzeit arbeiten wir an der letzten großen Kernkomponente (der eigentlichen (Sub)Domain-Konfiguration mitsamt automatischem TLS. Ich weiß gar nicht was dabei komplexer ist: das Frontend (in dem wir versuchen, alle überflüssigen Optionen wegzulassen und möglichst viel "automatisch" zu erledigen), oder das Backend (in dem alle noch so undenkbaren Angriffs- und Fehlerfälle abgefangen werden müssen).

Also. Es geht voran. Und jetzt bitte beim Thema bleiben.

Hallo,

es handelt sich da um ein immerhin sehr seltenes Problem (nur bei Migrationen sehr "alter" MySQL-Datenbanken).

Mit der kommenden Version (2.16.1) aktualisieren wir nun das Datenbankformat so, dass die Meldung "Row size too large" da nicht mehr auftreten sollte.

Das Vorgehen wäre wie folgt:1.) folgenden SQL ausführen:

UPDATE LIVECONFIG SET LC_VALUE='0216004' WHERE LC_KEY='dbschema' AND LC_VALUE < '0216004'

(ausschließlich in diesem speziellen Einzelfall, weil die o.g. Schemaänderungen ja offenbar bereits durchgeführt wurden)

2.) aktuelle LiveConfig-Preview installieren:

cd /tmp
wget https://repo.liveconfig.com/debian-test/pool/main/l/liveconfig/liveconfig_2.16.1-dev20230711.1_amd64.deb
dpkg -i liveconfig_2.16.1-dev20230711.1_amd64.deb

Danach sollte LiveConfig die restlichen Schemaänderungen ausführen können und normal starten.

Quote from janwego

Ggf. hab ich aber PHP auch aus dem PHP Repository von ondrej installiert.

Vorab: Ondrej macht eine tolle Arbeit - insbesondere im Backporting der Patches neuerer Versionen!

Allerdings sind die mitgelieferten systemd-Unit-Files unserer Ansicht nach nicht für Shared Hosting ausgelegt/optimiert, sondern eher für den Fall, dass alles unter "www-data" läuft.

Um die Pakete von deb.sury.org nutzen zu können, muss man die gewünschten PHP-Binaries im LiveConfig registrieren - siehe Anleitung.

Der Codename "php8" ist in dem Fall in Ordnung - das heißt intern so viel wie "die 8er Standardversion von PHP".

Ich verstehe die Fragestellung noch nicht ganz. Geht es um ein Upgrade oder um eine Migration/Umzug?

Es ist immer wesentlich einfacher, einen Server zu aktualisieren, als alles manuell Dienst für Dienst neu aufzusetzen und die Inhalte umzuziehen.

Ubuntu 18 ist auch nicht sooo als dass man sich schämen müsste (bekommt ja auch noch LTS-Support). Ein Upgrade von 18.04 auf 20.04 und anschließend von 20.04 auf 22.04 sollte ziemlich reibungslos ablaufen.

Viele Grüße

-Klaus Keppler

Ja, der Fehler ist bekannt und bereits behoben, die Preview-Version wird heute mit einem entsprechenden Bugfix aktualisiert, in v2.17 ist das dann auch behoben.

Der Fehler tritt nur dann auf, wenn noch eine domain-spezifische manuelle Konfigurationsdatei (~/conf/<domain>.httpd.conf) existiert.

Da das bei Weiterleitungen i.d.R. keinen Sinn macht, dürfte der einfachste Workaround darin bestehen, diese .conf-Datei zu löschen.

Damit in diesem Thread nicht der Eindruck entsteht, dass wir uns in den letzten Wochen nur die Sonne auf den Pelz haben scheinen lassen und Däumchen drehen: dem ist nicht so. 😎

Es gibt täglich Commits im LiveConfig3, aber da diese Version ja noch nicht veröffentlicht ist, macht es auch keinen Sinn einen öffentlichen Changelog zu pflegen. Die REST-API-Doku spiegelt (wie schon mehrfach erklärt) den Stand der fertigen Funktionen wider, und erlaubt somit einen Rückschluss auf den Fortschritt. Aktuell arbeiten wir an der letzten großen Baustelle (Domainkonfiguration - von DNS und DNSSEC über Webspace bis TLS). Da das aber alles "work-in-progress" ist, ist die API dieser Funktionen derzeit noch häufig Änderungen unterworfen.

Würden wir nun z.B. die API-Doku für die Bearbeitung von Domains veröffentlichen und da alle paar Tage Änderungen vornehmen, würden uns die Entwickler an den Hals springen, die auf der Basis schon eigenen API-Code schreiben wollen.

Was genau für eine Kommunikation würden Sie denn erwarten - haben Sie konkrete Beispiele/Wünsche?

Sollen wir mal eine Woche lang protokollieren, was täglich entwickelt/geändert wurde?

Es freut mich sehr dass die neue Version sehnsüchtig erwartet wird - und ich garantiere, dass wir selber diese auch am liebsten schon gestern fertig hätten.