Beiträge von kk

    Hallo,


    wir haben soeben LiveConfig 2.18.0 freigegeben.

    Alle Änderungen sind wie immer im Changelog zu finden. Auf zwei besonders wichtige Themen möchten wir hier aber noch mal ausdrücklich hinweisen:

    1. Wenn LiveConfig mit einem selbst-signierten TLS-Zertifikat mit einem 1024 Bit RSA-Schlüssel genutzt wurde, dann ersetzt LiveConfig 2.18 dieses beim ersten Start durch ein neues, ebenfalls selbst-signiertes Zertifikat mit 2048 Bit. Das hat den Hintergrund, dass manche Clients keine Zugriffe mehr auf Server mit 1024-Bit-Schlüsseln zulassen.
      Also nicht wundern, wenn es nach dem Update in diesen Fällen eine Warnung bezüglich eines unbekannten Zertifikats gibt.
    2. Wer LiveConfig zur DNS-Verwaltung nutzt und hierbei DNSSEC aktiviert hat: die BIND-Konfiguration wird während des Updates auf ein anderes Schema umgestellt (von "auto-dnssec" auf "dnssec-policy"). Alle Details hierzu sind ausführlich in der Wissensdatenbank beschrieben: DNSSEC-Migration
      Am besten prüfen Sie in diesem Fall nach der Migration, ob das Verzeichnis /etc/bind/keys/ leer ist bzw. nur noch veraltete/manuelle Schlüssel enthält.

    Sollten Fragen oder Probleme auftauchen, geben Sie uns bitte Bescheid.


    Die Version 2.18 ist übrigens Mindestvoraussetzung für ein künftiges Update auf LiveConfig 3.0. Ein Update von früheren Versionen auf 3.0 wird vom Paketmanager geprüft und ggf. abgebrochen.


    Viele Grüße


    -Klaus Keppler

    Die Version 2.18.0 wird auch morgen mit veröffentlicht (und ja, alle Änderungen darin sind in 3.0 auch schon enthalten).

    Die Versionen 2.18.0 und 3.0.0 sind "datenbank-kompatibel", d.h. zwischen diesen kann bei Bedarf jederzeit umgestellt werden.


    Alle Details dazu werden in einer entsprechenden Upgrade-Anleitung zusammengefasst.


    Die Versionen 2.18.x und 3.x werden noch eine Zeit lang (mindestens bis Ende 2025) parallel weiter gepflegt, um einen reibungslosen Umstieg ohne Zeitdruck zu ermöglichen.

    Oder vielleicht reicht es ja auch aus einen Business Server als C&C zu nutzen und dann wird die Funktion auf die Standard Server vererbt.
    So wie beim Let's Encrypt Feature.

    Let's Encrypt wird künftig in allen Lizenzen verfügbar sein.

    LAC benötigt auf jedem Server, auf dem es genutzt wird, eine Business-Lizenz.

    Aber: für Bestandskunden haben wir als Dankeschön für die Geduld und die Unterstützung ein spezielles "Weihnachtsgeschenk" - mehr dazu in Kürze. :)

    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.

    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. :D

    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. 8)

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

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

    Wurde eben atualisiert :D 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

    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. 8)


    Viele Grüße


    -Klaus Keppler