Ausblick auf das nächste große Release

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

    Danke! Ein einfaches "up" oder "liveconfig_build_info{version=3.0.0-rc10} 1" wäre ja für den Anfang ausreichend ;)

    • Offizieller Beitrag

    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

    • Offizieller Beitrag

    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.

    • Offizieller Beitrag

    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

  • Hallo,


    super, ich bin gespannt, wie sich das ganze auf meinen Produktiv Server auswirkt.

    Die dreier Version hatte ich mal kurz im Test, das sah schon sehr gut aus. Wie auch mit dem Kollegen von Ihnen geschrieben, der die Barrierefreiheit managet, unter Windows ohne Probleme, unter iOS kann man sich noch nicht abmelden, er hat das wohl am Schirm.


    VG

    Armin Moradi

  • Hallo Zusammen,


    ich habe festgestellt, dass es über das Terminal möglich ist aus dem User-Verzeichnis heraus zu wechseln und sich (sehr begrenzt) in anderen Verzeichnissen umzusehen. So konnte ich z.b. von /var/backups eine Datei nach ~/priv kopieren und lesen. Da steht zwar nichts wirklich kritisches drin, aber irgend ein Kunde wird mir das als Sicherheitsrisiko verkaufen wollen. Meistens ist es sehr zeitaufwendig, so jemanden zu erklären, warum das nicht so ist.

    Ist hier geplant, den Terminalzugriff hinter einer Jail zu verstecken?

    Das gleiche gilt natürlich auch für den SSH-Zugriff.


    Gruss


    MK

  • Ist hier geplant, den Terminalzugriff hinter einer Jail zu verstecken?

    Das gleiche gilt natürlich auch für den SSH-Zugriff.


    Rein das Terminal ist sinnfrei, wenn SSH dann nicht eingesperrt wäre.

    Jails sind schwierig und nur bedingt sinnvoll. Es müssten dann alle benötigten Programme (rsync, PHP, ...) mit allen Libraries mit in alle Jails kopiert werden. Das ist ein großer Wartungsaufwand und äußerst fehleranfällig.


    Die von dir angesprochenen Backups in /var/backups wären bei uns dpkg und alternatives. Die sind unkritisch. Gefunden habe ich noch "shadow.bak", die allerdings auch auf Grund fehlender Berechtigungen nicht kopiert werden kann - passt.


    Letztendlich müsste, neben SSH, dann auch ein Jail für PHP selbst verwendet werden. Sonst bin ich über "system('ls /var/backups');" auch wieder "draußen".


    Persönliche Meinung: es ist sinnvoller, die Server allgemein zu härten. Leserechte entziehen, wenn nötig - und ja, manche Daten scheinen auf den ersten Blick ein Problem zu sein, sind aber schlichtweg für den Betrieb für alle lesbar nötig (Beispiel: /etc/passwd, damit die Directory Listings auch richtig angezeigt werden können).

    Wir setzen bei uns noch "/var/www" auf 0751. Damit ist ein Directory Listing ("ls -la /var/www") nicht mehr möglich. Lässt sich aber durch die passwd auch umgehen, wenn es jemand drauf anlegt.

    • Offizieller Beitrag

    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

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


    Wie ist das denn nutzbar? Ich habe einen Management-Server, der eine Business-Lizenz hat und drei Server für Web, Mail und Datenbank, die jeweils mit einer Standart-Lizenz ausgestattet sind. gibt es da durch Erweiterung der Lizenzen eine Möglichkeit LAC zu aktivieren?


    Viele Grüße


    MK

  • In diesem Setup wäre LAC eigentlich nur für den Web Server Relevant.
    Ein Ausbruch aus einem Skript bzw. ein Shell Zugriff auf den DB oder Mail-Server macht keinen Sinn, oder?
    Und eigentlich war ja der Plan von LC, dass man keinen expliziten C&C Server benötigt, sondern man einen ganz normal genutzten Server dafür nimmt. Somit könnte man den Webserver mit der Business ausstatten und den dann mit LAC.

    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. Das muss aber KK beantworten.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!