Beiträge von kk

Dann vermute ich mal, dass das in den php.ini-Einstellungen so eingetragen ist:

Das Problem ist: wenn "Änderbar" auf "Account" steht, dann wird die Einstellung bei PHP-FPM mit php_admin_value erzeugt - und die kann dann nicht durch's Script (Roundcube) geändert werden. Stellen Sie das auf "Benutzer" um, dann kann sowohl der Benutzer in seinen php.ini-Einstellungen das ändern, als auch das Script.

Von LiveConfig kommt diese Einstellung übrigens nicht, zudem ist die schon stark beschränkend (PEAR-Erweiterungen etc. werden da nicht gefunden).

Prüfen Sie bitte mal, ob in der /etc/php/8.3/fpm/pool.d/<Vertrag>.conf (bzw. /etc/php-fpm/php83-fpm.d/<Vertrag>.conf) eine include_path-Anweisung steckt.

(LiveConfig trägt standardmäßig keine ein, könnte aber evtl. in der php.ini-Verwaltung hinzugefügt worden sein)

Roundcube 1.6.7 sollte übrigens aktualisiert werden, da gibt es kritische Bugfixes.

Dieses Verhalten habe ich bislang noch nirgendwo erlebt oder davon gehört.

Wenn auf FastCGI zurückgestellt wird, tritt das nicht mehr auf?

Welche Versionen von PHP und RoundCube kommen zum Einsatz?

Exakt das ist mir in dem Vergleich auch aufgefallen: bei Litespeed ist ausdrücklich vom LSCache die Rede, bei Apache/NGINX wird aber kein Cache erwähnt.

Wenn ich die Zeit finde machen wir hier mal einen eigenen, transparenten Vergleich.

Zitat von pkambach

Guten Morgen,

gibt's für's Changelog (https://www.liveconfig.com/de/changelog/) noch irgendwas interessantes?

VG

Patrick

Alles anzeigen

Ups... da hatte ein rsync gefehlt. :-/ Wurde eben aktualisiert.

Bei der Gelegenheit: morgen im Laufe des Tages wird's ein Zwischenupdate mit kleineren Bugfixes geben.

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?