Beiträge von kk

Genau dieses "Problem" wird mit den LiveConfig Account Containern (LAC) gelöst.

Um Zugriff auf Verzeichnisse "außerhalb" des eigenen Home-Directories auf ein wirklich absolutes Minimum zu begrenzen gibt es verschiedene technische Ansätze. Der Bekannteste dürfte die "chroot"-Umgebung (chroot-Jail) sein. Die hat aber etliche Nachteile (vor allem einen gewaltigen Pflegeaufwand) und kann auch immer wieder mal umgangen werden (mal nach "chroot breakout" googeln).

Dann gibt es spezielle Patch-Sammlungen und Produkte (u.a. das "CageFS" von CloudLinux), welche i.d.R. über Kernel-Hooks für eine Isolation sorgen.

Die LiveConfig Account Container (LAC) arbeiten mit Kernelfunktionen, die inzwischen standardmäßig verfügbar sind und auch in der Container-Welt (Docker etc.) genutzt werden - also entsprechend ausgereift und sicher sind.

Da aber eine Menge Entwicklungsarbeit in LAC drin steckt und wir das auch noch weiter ausbauen (u.a. PHP-FPM-Unterstützung, für welche wir PHP patchen müssen), steht diese Funktion nur mit der Business-Lizenz zur Verfügung. Neben der Filesystem-Isolation wird übrigens auch das gesamte Netzwerk virtualisiert, so dass z.B. jeder Kunde sein "eigenes" Loopback-Interface (127.0.0.1) hat.

Viele Grüße

-Klaus Keppler

Soeben haben wir LiveConfig 3.0.0-rc12 in den Test-Repositories bereitgestellt.

Es handelt sich dabei um den letzten Release Candidate, in zwei Wochen (01.08.2025) soll dann das "Stable Release" von LiveConfig v3 erfolgen.

In den nächsten zwei Wochen liegt unser Fokus vor allem auf Upgrade-Tests und der Bereitstellung/Aktualisierung der Dokumentation.

Viele Grüße

-Klaus Keppler

Der Vollständigkeit halber: die Ursache liegt bei Ubuntu...

"Unsere" PHP-Pakete nutzen die von der Distribution bereitgestellte gd-Library (libgd3). Die libgd3 für Debian 12 hat avif-Support, die für Ubuntu 24 leider nicht (siehe Bug Report 2031934, speziell Kommentar #5).

Die Option mit --with-avif gilt nur für die mit dem PHP-Source mitgelieferte gd-Bibliothek. Im Allgemeinen versuchen wir aber immer die Distributions-Bibliotheken zu nutzen (um deren Aktualisierung müssen wir uns nicht kümmern, deren Aktualität kann einfacher geprüft werden, usw.). Zudem erhöht sich die Build-Komplexität nochmal erheblich, wenn die Bundled-gd-Version genommen werden soll (dann brauch'ts nämlich noch die dev-Bibliotheken für jpeg, png, xpm, webp und Freetype).

Bei den PHP-Paketen von sury.org wird das libgd3-Paket komplett ersetzt, deshalb klappt das dort. Wenn AVIF für php-gd zwingend benötigt wird, könnte daher eventuell eine Lösung sein, das libgd3-Paket von Sury zu installieren.

Viele Grüße

-Klaus Keppler

Meine persönliche Meinung (als Techniker und Nicht-Jurist) ist, dass E-Mail kein verlässlicher zweiter Faktor ist.

Der Grund ist banal: wenn das Passwort für LC via E-Mail zurückgesetzt werden kann, und Mail auch als 2FA genutzt wird, dann ist das eben nur ein Faktor.

Wir planen einen "NIS2-Enforcement-Modus", und der umfasst noch ein wenig mehr - u.a. dass Logging via Syslog (an einen Remote-Host) erfolgt.

Was DNS-Änderungen betrifft kann ich mir ein "Opt-In" vorstellen, so dass Privatpersonen die das nicht betrifft, ihre paar DNS-Einstellungen oder Dynamic DNS auch weiterhin ohne 2FA nutzen können (wenngleich 2FA grundsätzlich sinnvoll und empfehlenswert ist).

Hierfür wird das Paket "lc-ext-sitepro" benötigt, welches aktuell noch nicht im Repository bereitsteht (das Löschen von verwaisten Sites wird aktuell noch überarbeitet). Spätestens zur RC12 soll das aber auch veröffentlicht werden (wenn nichts dazwischen kommt: nächsten Dienstag, 15.07.).

Die Bugfixes aus PHP 8.1.33 wurden inzwischen auch für 8.0 und 7.4 backported, entsprechend haben wir auch diese PHP-Pakete aktualisiert.

Zitat von pkambach

Okay, dann habe ich mich unter Verwaltung -> Einstellungen -> Version mit [3.0.0-rc8] verwirren lassen, sorry...

Wurde eben atualisiert Beim Release Candidate müssen wir die Versionsinfos derzeit noch manuell pflegen (da die Releases nicht automatisiert sind). Auch die "Release Notes" (Dashboard) passen wir gleich noch an. Das "rc"-Suffix wird ab dem Release rausfliegen, dann werden die Versionsnummern "normal" hochgezählt, was es dann wieder übersichtlicher machen dürfte.

Bislang (LC 2.x) konnte man durch einen Klick ganz unten rechts auf den "Powered by ..."-Link im Popup die Versionsnummer einsehen. Das gibt's prinzipiell weiterhin, aber die Version wird nur noch Admins angezeigt.

Das geht aktuell nur durch den Kunden selbst (für die entsprechend freigegebenen Einstellungen):

Hosting -> Webspace -> Tab "PHP"

Das Bearbeiten durch den Admin/Reseller wird aktuell noch fertiggestellt, siehe Issue GH-32 (ist im nächsten RC dann auch erledigt).

Hallo,

wir haben die PHP-Pakete für Debian/Ubuntu eben auf die Versionen 8.1.33, 8.2.29, 8.3.23 und 8.4.10 aktualisiert.

Möglicherweise werden einzelne Patches auch für noch ältere Versionen "backported", es kann also gut sein dass da auch noch Updates kommen.

Viele Grüße

-Klaus Keppler

Öh, die Demo wurde bereits wenige Minuten nach Release aktualisiert...?

https://demo-v3.liveconfig.com:8443 (admin/admin)

Soeben haben wir LiveConfig 3 nochmal aktualisiert (Release Candidate 11 - also 3.0.0-rc11). Die Änderungen sind im Changelog (Tab "Version 3.x") aufgeführt. Letztendlich werden mit diesem Update einige Fehler und Probleme behoben, die im ersten Produktivbetrieb zu Tage gekommen sind.

Wir planen in etwa zwei Wochen dann den letzten Release Candidate (rc12) zu veröffentlichen, und weitere zwei Wochen später das "stable"-Release.

Viele Grüße

-Klaus Keppler

Mir würde da nur der logrotate einfallen.

LiveConfig hat von sich aus keinen Grund, Apache regelmäßig neu zu starten.

Danke, war bereits in Bearbeitung (ein anderes Ticket kam kurz vorher schon herein).

Es gab eine eigentlich(tm) minimale Änderung am Lizenzserver, um in einem bestimmten Fall eine aussagekräftigere Fehlermeldung bei der Lizenzverlängerung (LiveConfig 3.x) zu bekommen. Blöderweise hat LiveConfig 2.x bei der Verlängerung aber hier einen Fehler ausgelöst.

Nun sollte wieder alles korrekt laufen - sorry für die Unannehmlichkeiten.

Zitat von TCRserver

Bottleneck dürfte auch eher PHP sein als der eigentliche http-Server.

Das ist genau das Thema. Die größten Performance-Vorteile kommen durch's Caching zustande. Was "normale" Web-Zugriffe auf statische Inhalte betrifft, nehmen sich alle Server im Normalbetrieb kaum etwas.

Wir haben inzwischen sehr gute Erfahrungen mit NGINX-Caching gesammelt (und auch einige Stolperfallen kennengelernt) und bereiten die Integration in LC bereits vor (Stichwort "FastCGI Cache"). Zudem testen wir bei einem Projekt einen serverweiten Brute-Force-Schutz für Wordpress (das ist ein immer häufigerer Grund für lang dauernde und teils extrem hohe Serverlasten).

Zum FastCGI-Cache ggf. kurz an support@liveconfig.com wenden, dann können wir die aktuell getesteten NGINX-Einstellungen vorab teilen.

Auch OpenSSL 3 steht aktuell etwas in der Kritik, weil die TLS-Performance da in manchen Konstellationen leidet (das ist aber ein extrem komplexes Thema).

Aber erstmal eins nach dem anderen...

Nein, Litespeed wird nicht unterstützt (sonst würde der bei den Unterstützten Diensten aufgeführt sein). Vorerst ist auch keine Entwicklung in dieser Richtung geplant:

- die Nachfrage ist äußerst gering (max. 1-2 pro Jahr?)

- wir sehen keine nennenswerten technischen Vorteile

Da Litespeed angeblich weitgehend Apache-kompatibel sein soll, kann man ggf. versuchen den Apache einfach zu ersetzen (wir können hierbei aber keinerlei Support geben).

Ohne Litespeed schlecht reden zu wollen: welche Vorteile erwarten Sie sich damit genau?

Gibt's irgendwelche Meldungen in /var/log/liveconfig/liveconfig.log ?

Ein Server-Neustart behebt das Problem, ein LiveConfig-Neustart aber nicht?

Prometheus-Metriken sind an sich schon vorbereitet, für den Anfang aber noch eher rudimentär (der Appetit kommt beim Essen, es wird sich zeigen welche Daten sinnvoll sind). Weitere Details in Kürze (aktuell sind noch andere Themen etwas wichtiger)

Eben haben wir v3.0.0-rc10 bereitgestellt, mit der noch mal eine Hand voll Fehler behoben und Details verbessert wurden.

Aktuell gibt's noch ein Problem bei der Verlängerung von "alten" Let's-Encrypt-Zertifikaten (aus LC2), sollte aber bis morgen auch erledigt sein.

Die letzte Baustelle - die Extension-API für u.a. den Website-Builder (Site.pro) - ist technisch betrachtet auch abgeschlossen und wird im Laufe der nächsten Tage fertig integriert und getestet (insbes. reibungslose Migration von Site.pro-Accounts aus LiveConfig 2).

Last but not least werden die Github-Issues abgearbeitet.

Viele Grüße

-Klaus Keppler

Zitat von kk

Morgen im Laufe des Tages wird es ein umfangreiches Update zu LC3 geben. Aktuell laufen mehrere produktive Rollouts auf Multi-Server-Systemen, die wir sehr engmaschig begleiten und beobachten.

(nebenbei wurden alleine gestern u.a. PHP 8.3, PHP 8.4, Ioncube-Loader, 2.18.0-preview und 3.0.0-rc8 aktualisiert...)

Leider etwas später als geplant, aber hier der aktuelle Zwischenstand:

LiveConfig v3 läuft seit Ende Mai auf den ersten Servern im Produktivbetrieb. Vor etwa einer Woche erfolgte ein großes Roll-Out auf einem Multi-Server-System mit ein paar tausend Domains, da sind noch mal ein paar Problemchen aufgetaucht (fehlende Funktionen, kleinere Anzeigefehler, teils recht verzögerte Bearbeitung von TLS-Aufträgen). Wirklich kritische Sachen waren da zum Glück aber nicht dabei.

Wir lassen derzeit 1-2x täglich eine aktualisierte Version heraus und updaten die betroffenen Systeme entsprechend, sind somit also hauptsächlich mit Korrekturen und Updates beschäftigt. Alle erfolgreich getesteten Fixes werden dann für den nächsten Release Candidate freigegeben, das nächste Update (rc10) soll noch diese Woche erfolgen.

Ich kann unmöglich in alle technischen Details gehen, aber manche Sachen fallen leider erst im "echten" Betrieb auf. So gab es z.B. einen Fehler bei DynDNS-Updates (da war der neue Update-Hook unter einer anderen URL als bisher erreichbar), bei Let's Encrypt wurden bestehende Accounts nicht in das neue Format migriert (da gab's eine Fehlermeldung bei der Verlängerung), und in der GUI gab's kleinere Darstellungsfehler bzw. auch fehlende Informationen (z.B. DS-Digest für DNSSEC). Zudem ist jedes Update eines Servers von LC2 auf LC3 eine spannende Sache, weil wir den Vorgang ja absolut reibungslos gestalten möchten (daher gibt es da aktuell immer wieder Anpassungen an den Paketmanager-Scripts für .deb/.rpm).

Parallel bereiten wir die Website für v3 vor. Das Changelog für v3 ist bereits integriert (separate Tabs für v2 und v3), eine Liste mit Hinweisen zur Umstellung wird derzeit erstellt.

Unser Fokus liegt auf Stabilität und Sicherheit, daher wollen und werden wir die v3 erst dann vollständig freigeben, wenn wir das guten Gewissens können.

Wir befinden uns nun aber im Endspurt, die Ziellinie ist schon in Sicht.

Zitat von taenzerme

Hallo kk,

die Demo ist nicht erreichbar.

Die Demo läuft seit heute wieder.

LC2 hat extra einen Endpoint für automatisierte Checks (/liveconfig/nagios-check), den gibt's in LC3 leider noch nicht (steht aber schon auf der ToDo-Liste).

Morgen im Laufe des Tages wird es ein umfangreiches Update zu LC3 geben. Aktuell laufen mehrere produktive Rollouts auf Multi-Server-Systemen, die wir sehr engmaschig begleiten und beobachten.

(nebenbei wurden alleine gestern u.a. PHP 8.3, PHP 8.4, Ioncube-Loader, 2.18.0-preview und 3.0.0-rc8 aktualisiert...)