Beiträge von kk

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

Das Stichwort dürfte hier "output buffering" sein. Im PHP-Handbuch ist das etwas beschrieben:

https://www.php.net/manual/de/book.outcontrol.php

Ich wüsste auswendig gerade von keiner Einstellung, die LiveConfig in der php.ini setzt, welche hierauf einen Einfluss hat.

Wenn Sie ein Setup haben/hatten, unter dem Ihr Script die Daten ungepuffert ausgibt, würde ich dessen php.ini mal mit der von LiveConfig erzeugten php.ini vergleichen (z.B. mal eine "phpinfo()"-Datei anlegen, in beiden Umgebungen aufrufen und die Einstellungen vergleichen).

Zudem kann es einen Unterschied machen, wie PHP ausgeführt wird (FastCGI oder FPM, ggf. einmal im Vertrag mal testweise umstellen).

Viele Grüße

-Klaus Keppler

Die 2.18er-Preview ist seit Freitag (wieder) im Test-Repo verfügbar. Die Links im Debian-Repo waren leider teilweise defekt, weil es während des Deployments einen Fehler bei der GPG-Signatur gab.

Der Code zur Aktualisierung des Datenbank-Schemas ist in v2.x und v3.x exakt identisch.

In LiveConfig v3 haben wir diese Gruppierung (vorerst) komplett entfernt, da sich das derzeit nicht mit der Datenstruktur der Accounts/Reseller sinnvoll umsetzen lässt.

php.ini-Einstellungen können also serverweit über "Hosting" -> "PHP-Einstellungen" verwaltet werden, und pro Vertrag überschrieben werden (wahlweise durch den Admin oder auch den Endkunden - je nach Einstellung).

Wir haben soeben LiveConfig 3.0.0-rc5 sowie die Preview für 2.18 (2.18.0-dev20250506-1) im Test-Repository bereitgestellt.

Beide Versionen (3.0.0-rc5 und 2.18) sind zueinander Datenbank-kompatibel.

Während der Installation wird jeweils eine Migration der DNSSEC-Konfiguration durchgeführt (siehe Wissensdatenbank).

(wer DNSSEC nicht nutzt oder überhaupt keine eigenen DNS-Server betreibt, wird davon ohnehin nichts mitbekommen)

Version 3.0.0 ist aus unserer Sicht nun soweit stabil. Es fehlen noch ein paar kleinere Features (manuelle Verwaltung von TLS-Zertifikaten, Integration Website-Builder, einige Sprachen in den Übersetzungen), diese sind aber schon implementiert und werden in den nächsten Tagen abschließend getestet und integriert.

Ab sofort rollen wir v3.0.0-rc5 auf den ersten produktiven Servern einiger "early adaptor" aus und beobachten ob es Probleme gibt. Sobald sich alles soweit eingeschliffen hat, werden wir v3 dann auch offiziell für den Produktivbetrieb freigeben. Bis dahin wird es entsprechend eng getaktete Updates geben.

Die LiveConfig-Website wird derweil entsprechend überarbeitet, u.a. pflegen wir ab sofort ein detailliertes Changelog für v3 (bislang enthielt das eher stichpunktartig nur die wichtigsten Änderungen). Für Anpassungen der REST-API wird es ebenfalls ein eigenes Changelog geben.

Viele Grüße

-Klaus Keppler

Wie es der Zufall so will hat Sectigo gestern Abend bekannt gegeben, Zertifikate künftig auch voll automatisiert via ACME ausstellen zu können (aber natürlich nicht kostenfrei...). Die CAs bereiten sich also sukzessive auch auf entsprechende Automatisierungsprotokolle vor.

LiveConfig unterstützt mit ACME prinzipiell alle damit kompatiblen Anbieter, wobei wir das bislang im Detail immer nur mit Let's Encrypt getestet haben.

In LiveConfig3 sind aber auch die Einstellungen für Buypass und SSL.com hinterlegt (die können also relativ einfach aktiviert werden).

Zudem haben wir in LC3 bewusst eine offene API für TLS-Anbieter geschaffen (mit einem ACME-Modul als Referenzimplementierung). Darüber lassen sich auch weitere TLS-Anbieter in automatisierte Prozesse integrieren.

Auch die (sehr gute) API von PSW ließe sich somit also anbinden. Wenn jemand da ein Modul entwickeln möchte, unterstützen wir das sehr gerne.

LC3 kommuniziert mit den TLS-Plugins über schlichte Programmaufrufe und tauscht die Daten via STDIN/STDOUT im JSON-Format aus - man kann das also in jeder beliebigen Sprache programmieren und sehr einfach an LiveConfig anbinden.

Ja.

Und prinzipiell auch "rückwärts" (Datenbank aus LC3 mit LC2 verwenden). Da kann es nur sein, dass das zwischen unstabilen dev-Versionen nicht immer klappt, aber an sich soll man jederzeit hin- und herschalten können.

Wir sind am RC5 dran, DNSSEC-Migration. Aktuell wird das Deaktivieren von DNSSEC noch angepasst, sollte heute abgeschlossen sein.

Wenn alles klappt, werden die DNSSEC-Änderungen dann in LC3 übernommen (wurde bislang "nur" in LC2 implementiert).

(daneben gab es noch ein halbes Dutzend anderer Features und Verbesserungen, die sind bereits integriert)

Wir planen idealerweise noch am Mittwoch Abend den RC5 freigeben zu können (Donnerstag ist Feiertag, und Freitag wird hier gerne als Brückentag genutzt )

Da die DNSSEC-Migration (wie gestern ausführlich beschrieben) noch etwas Arbeit bedarf, haben wir eben LiveConfig 3.0.0-rc4 (noch ohne DNSSEC-Migration) veröffentlich. Die wichtigsten Neuigkeiten sind:

• Übersetzungen in Spanisch, Französisch und Niederländisch mit aufgenommen
• Bearbeiten von Kundendaten (Kundennummer, Stammdaten) nun auch via GUI möglich
• Löschen von Hosting-Templates nun auch via GUI möglich, auch Verschieben in ein anderes Template
• Bibliotheken aktualisiert (SQLite, libidn, Expat, cURL)
• neue "coming soon"-Platzhalterseite
• etliche Fehlerbehebungen und Verbesserungen in der neuen Oberfläche

Aktuell befinden wir uns im Endspurt mit der Extension-API (hierüber wird der Website-Builder Site.pro eingebunden), zudem laufen die Arbeiten an der DNSSEC-Umstellung (Migration auf dnssec-policy ist auch schon abgeschlossen, Deaktivieren von DNSSEC sowie Key-Verwaltung erfordert aber noch viele Anpassungen). Die Website wird nun sukzessive auf LC3 angepasst (u.a. LC3-Changelog in Kürze).

Die Online-Demo (admin/admin) wurde eben auch auf rc4 aktualisiert. Ich weise an dieser Stelle auch nochmal kurz auf den Issue-Tracker hin, der schon fleißig genutzt wurde.

Vielen Dank an dieser Stelle schonmal für das viele Feedback!

Viele Grüße

-Klaus Keppler

Wie sich herausgestellt hat, war auf dem Build-Server für Ubuntu 24 (AMD64) zu dem Zeitpunkt, als dort "php-8.[1-3]-opt-apcu" gebaut wurde, noch ein php-8.[1-3]-opt-dev-Paket installiert, welches die interne PCRE-Bibliothek von PHP genutzt hatte (daher das "php_" am Anfang des nicht gefundenen Symbolnamens).

Außerdem haben unsere Prüfungen ergeben, dass PHP 8.2 und 8.3 unter Debian 12 auch mit dem internen PCRE gebaut wurde (da waren die APCu-Pakete aber darauf abgestimmt).

Wir haben das nun korrigiert und die Pakete entsprechend aktualisiert. Für PHP 8.3 und 8.4 stehen heute ohnehin Updates an (8.3.20, 8.4.6).

Viele Grüße

-Klaus Keppler

Nach längerer Suche konnten wir das endlich reproduzieren... der Fehler wird nur dann angetriggert, wenn ein APCu-Iterator mit einem regulären Ausdruck genutzt wird (ironischerweise enthält die komplette APCu-Testsuite keinen einzigen solchen Test - sonst wäre das aufgefallen...)

Mit folgendem Befehl lässt sich das antriggern/testen:

/opt/php-8.3/bin/php -d apc.enable_cli=1 -d display_errors=1 -r '$it = new APCuIterator("/.*/", APC_ITER_VALUE);'

Update/Lösung ist in Arbeit, PHP-Updates (8.3.20/8.4.6) stehen ohnehin für morgen Vormittag an.

Hallo,

ursprünglich wollten wir gestern noch v3.0.0-rc4 freigeben, allerdings hat die DNSSEC-Migration wesentlich mehr Aufwand mit sich gebracht als vermutet.

Zur Erklärung hier ein paar technische Details:

Bislang nutzt LiveConfig für DNSSEC die BIND-Option "auto-dnssec: maintain". Diese ist inzwischen aber "deprecated" und wurde durch die Methode der "dnssec-policy" ersetzt. Spätestens ab BIND 9.20 wird "auto-dnssec" nicht mehr unterstützt - also ist die Umstellung obligatorisch.

Das neue Verfahren (dnssec-policy) ist mega mächtig, u.a. erlaubt das langfristig sogar ein automatisiertes Deployment der DS-Keys bei der Registry (RFC8078). LiveConfig nutzt die dnssec-policy nun u.a. um die Zone Signing Keys (ZSK) vollautomatisch alle 60 Tage zu rotieren.

Und da liegt schon die erste Herausforderung: die Schlüssel müssen nun zusätzliche Metadaten enthalten (u.a. Veröffentlichungsdatum im DNS), damit BIND anhand der verschiedenen TTLs berechnen kann, wann welche Events stattfinden müssen. Damit BIND die Schlüsselzustände verwalten und diese später auch rotieren kann, müssen diese von BIND beschreibbar sein. Auf /etc/bind/keys/ hat BIND mit AppArmor aber nur Lesezugriff, also migrieren wir diese nach /var/lib/bind/keys/.

Nächste Herausforderung: standardmäßig geht BIND bei der Signatur-Erneuerung davon aus, dass kein RR-TTL mit >24 Std vorliegt. Sollte das der Fall sein, muss das explizit konfiguriert werden, da sonst lange gecachte Signaturen ungültig werden können. Wir müssen also im Rahmen der Migration auch prüfen, welche TTLs in den Zonen vorhanden sind, und ggf. die dnssec-TTL-Option entsprechend anpassen.

Nach unseren ersten Tests hatte die Migration reibungslos geklappt, nur dass plötzlich keine dynamischen DNS-Updates mehr möglich waren. Hier stellte sich heraus, dass es einen bislang noch unbekannten/undokumentierten Bug im BIND gibt (Keys für dynamische Updates werden in manchen Fällen (nicht in allen!) im Verzeichnis /var/cache/bind/ gesucht, statt im konfigurierten key-directory (/var/lib/bind/keys/).

Da die DNSSEC-Migration von auto-dnssec zu dnssec-policy eine "Operation am offenen Herzen" ist, muss das äußerst sorgfältig erfolgen. Sollte es zu Problemen kommen, kann es mitunter sehr kompliziert werden, etwas zu korrigieren. Ein einfaches "neu signieren" geht oft nicht, weil ja alte Signaturen noch in anderen Resolvern gecached sein könnten.

Wir haben uns daher dazu entschlossen, die DNSSEC-Migration auch in LiveConfig 2 noch zu implementieren (Version 2.18), und auch dort noch in allen erdenkbaren Kombinationen durchzutesten. Nach dem aktuellen Stand der Dinge gehe ich davon aus, dass wir noch diese Woche hier die Preview fertig haben (aktuell glauben wir alle Probleme gelöst zu haben und sind "nur" noch in den Tests).

LC3 3.0.0-rv4 wird dann zeitgleich mit der LC2 2.18-Preview bereitgestellt, so dass sich beide Versionen analog verhalten. Zudem bereiten wir noch einen KB-Artikel zur DNSSEC-Migration vor.

Die restlichen für RC4 geplanten Punkte (u.a. Übersetzungen in ES/FR/NL, Löschen von Templates, etc.) sind erfolgreich abgeschlossen.

Viele Grüße

-Klaus Keppler

Dann wird diese Einstellung entweder im Vertrag überschrieben sein (die "log_errors"-Einstellung kann auch vom Kunden geändert werden: Hosting -> Webspace -> Box "Webspace-Eigenschaften", bei "PHP:" den "bearbeiten..."-Button klicken).

Oder die PHP-Anwendung selbst setzt das mit "ini_set()" selber. Ist technisch ja auch möglich.

Meines Wissens sollten die php_errors.log aber vom Logrotate auch regelmäßig aufgeräumt werden...

Soeben haben wir LiveConfig 3.0.0-rc3 im Test-Repository bereitgestellt.

Der letzte Showstopper ist nun noch die Migration bestehender DNSSEC-Konfigurationen im BIND. Sobald das abgeschlossen ist (ich hoffe in ca. 4-5 Arbeitstagen) werden die Übersetzungen integriert (die liegen uns bereits vor) und damit dann der RC4 veröffentlicht. Diesen werden wir dann ein paar Tage "in freier Wildbahn" beobachten - dann steht dem Produktiv-Release nichts mehr im Weg.

Viele Grüße

-Klaus Keppler

Zitat von kroerig

Lässt sich das auch per Default für alle externen Weiterleitungen aktivieren? Der gemeine Anwender kann mit dieser Funktion i.d.R. nichts anfangen. Er ist es aber gewohnt, dass Weiterleitungen bei den großen Anbietern einfach funktionieren und da muss nichts extra aktiviert werden. Die wenden einfach SRS an, der Nutzer bekommt davon ja nichts mit.

Wir wollten bewusst erst einmal mit einer "Opt-In"-Variante starten, um eventuelle Probleme frühzeitig zu erkennen.

Die Architektur von Postfix - so flexibel diese sein mag - ist gerade bei SRS leider eher etwas nachteilig, weil anzupassende E-Mails da sehr speziell nach dem Umschreiben erneut in die Queue gesteckt werden müssen. Hier möchten/müssen wir vermeiden, dass bei diesem erneuten Queueing auch wieder Spamfilter, DKIM usw. nochmal angewendet werden, SPF keinen Ärger macht, usw...

Wenn sich die SRS-Integration als soweit stabil "at scale" erweist, werden wir auch eine Möglichkeit bereitstellen, SRS als Default zu aktivieren und ggf. ein "SRS-Opt-Out" pro Postfach anzubieten.

Zitat von kroerig

Hab gerade auch mal in meine main.cf geschaut. Da stehen zwei Zeilen drin:

Code

smtpd_tls_dh1024_param_file = /etc/postfix/dh2048.pem
smtpd_tls_dh512_param_file = /etc/postfix/dh512.pem

Ab Postfix 3.6 wird die untere Zeile stillschweigend ignoriert. Sollte LC die dann nicht auch rausnehmen, wenn sie in Bestandsinstallationen noch vorhanden ist?

Danke, das werden wir prüfen! Die DH512-Parameter machen in dem Zusammenhang wirklich keinen Sinn mehr. Wird also voraussichtlich mit dem nächsten Update ebenfalls entfernt.

Hallo,

ab sofort stehen die gestern veröffentlichten PHP-Updates für die Versionen 8.1-8.4 sowie eine gepatchte Version 8.0 (backport) in unseren Repositories bereit (Debian 11/12, Ubuntu 20/22/24).

Es handelt sich um ein Sicherheits-Update, eine zeitnahe Aktualisierung wird also empfohlen.

Viele Grüße

-Klaus Keppler