Beiträge von kk

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

Argh... danke! Eben behoben. Bitte LiveConfig neu starten (aktualisiert das Repo), alternativ 24 Std warten.

Oh je.

Also... der Support für Outlook 2010 wurde von Microsoft bereits am 13.10.2020 eingestellt. Die Verwendung von 1024bit-DH-Parametern gilt inzwischen nicht mehr als sicher (wenn man das als Provider dennoch anbietet, dann kann das ein Risiko darstellen - NIS2 etc lassen grüßen).

Ich sehe hier prinzipiell zwei Lösungsansätze:

1. über eine Konfigurations-Anpassung erlauben Sie serverseitig weiterhin 1024 Bit DH-Parameter (s.u.), oder
2. der Kunde richtet einen TLS-Tunnel ein (z.B. mit stunnel), der auf Kundenseite "schwache" Verschlüsselung erlaubt und seinerseits eine sichere Verbindung zum Mailserver aufbaut

Vorträge über die (Un)sicherheit solcher alter Software können wir uns ja vermutlich sparen...

Variante (1) ließe sich einrichten, indem Sie eine Datei namens /etc/liveconfig/lua.d/postfix.lua anlegen, mit folgendem Inhalt:

postfix.LOCALMASTER = {
  ["submission"] = {
    ["inet"] = { "n", "-", "n", "-", "-", "smtpd", {
                 "-o syslog_name=postfix/submission",
                 "-o smtpd_sasl_auth_enable=yes",
                 "-o smtpd_client_restrictions=permit_sasl_authenticated,reject",
                 "-o smtpd_helo_required=no",
                 "-o smtpd_helo_restrictions=",
                 "-o smtpd_tls_dh1024_param_file=/etc/postfix/dh1024.pem"
               } }
  }
}

Prüfen Sie ggf. ob in Ihrer /etc/postfix/master.cf noch andere Optionen für den "submission"-Service gesetzt sind und nehmen diese hier ggf. mit auf. Wichtig ist eben die Option smtpd_tls_dh1024_param_file, um die alten DH-Parameter auch zu unterstützen.

(eventuell muss noch die Option -o cleanup_service_name=cleanupfilter aufgenommen werden, wenn die IP-Adresse bei Submission aus den Received-Headern entfernt werden soll)

Anschließend LiveConfig neu starten und die Postfix-Konfiguration neu schreiben lassen.

Danke für den Hinweis!

Wir werden das Paket in Kürze aktualisieren und ein AppArmor-Profil mit aufnehmen, um Problemen vorzubeugen.

Die meisten Mail-Clients rendern spezielle Auszeichnungen von reinen Text-Mails wie folgt:

• Sternchen: Fett gedruckt. *hallo* -> hallo
• Unterstrich: Kursiv. _hallo_ -> hallo

Ich habe einen Feature Request angelegt, in LiveConfig 3 einen HTML-Editor für den Autoresponder zu integrieren.

Hallo,

ab sofort steht LiveConfig v2.17.0 zum Download bereit. Neben kleineren Bugfixes und Detailverbesserungen bringt diese Version nun Unterstützung von SRS (Sender Rewriting Scheme). Die detaillierte Liste aller Änderungen findet sich wie immer im Änderungsverlauf.

Für SRS muss die Software PostSRSD in der Version 2.x verwendet werden. Für Debian/Ubuntu stellen wir hierfür ein entsprechendes Paket bereit ("lc-postsrsd"), da die Distributionen derzeit noch Version 1.x mit ausliefern. LiveConfig ermöglicht dann ein "Opt-In" für SRS - das Verfahren kann einzeln pro Postfach aktiviert/deaktiviert werden.

Viele Grüße

-Klaus Keppler

Haben Sie im LiveConfig in den FTP-Server-Einstellungen die Option "SSL session reuse erforderlich" aktiviert?

Schalten Sie diese ggf. mal um und beobachten, ob der Fehler weiterhin auftritt.

LiveConfig kann da ansonsten ohnehin nicht viel machen, da der eigentliche Fehler ja ganz offensichtlich im ProFTPD steckt...

Identische Frage, identisches Thema:

Thema

ProFTPD Verbindungsabbrüche

Vermehrt melden sich Kunden, das die Verbindungen bei FTP-Übertragungen abbrechen. Folgendes steht in den Logs:

(Quelltext, 2 Zeilen)


Die Verwaltung von ProFTPD läuft komplett über LiveConfig. Muss hier etwas nachgebessert oder angepasst werden?

weltmeister

1. April 2022

Möglicherweise Bug https://github.com/proftpd/proftpd/issues/1706

Ohne Info zur ProFTPD- und Debian-Version kann ich nicht mehr sagen.

Aus dem KB-Artikel haben wir die Blocklist nun auch entfernt.

Die Ablehnung von Mails am Freitag Vormittag wird mancherorts nun als "temporärer Konfigurationsfehler" kommuniziert, seitens des ehemaligen Betreibers gab es leider keine Stellungnahme dazu (was ich in einem gewissem Umfang auch verstehen kann, da das ja nun nur noch Kosten verursacht und ohnehine ein "pro-bono"-Service war).

Nichts desto trotz sollte die Liste aus allen aktiven Konfigurationen entfernt werden. Wir prüfen auch, ob wir das evtl im Rahmen der anstehenden v2.17 zuverlässig automatisch machen können.

Guten Morgen,

die DNS-Blocklist ix.dnsbl.manitu.net wurde zum Anfang dieses Jahres leider eingestellt. So wie es aussieht, beantwortet diese Blocklist ab sofort alle Anfragen positiv, d.h. alle geprüften E-Mail-Adressen werden somit als Spam-Absender abgewiesen!

Falls Sie also diese DNS-Blocklist verwenden, entfernen Sie diese schnellstmöglich aus Ihrer Mailserver-Konfiguration!

(Serververwaltung -> E-Mail -> Postfix-Einstellungen)

Viele Grüße

-Klaus Keppler

Wir stecken derzeit unsere gesamten Ressourcen in die Fertigstellung von LiveConfig 3. Aktuell bearbeiten wir pro Woche bis zu 30 Issues (das sind alles Sachen, die man hier im Forum leider nicht sieht).

Eben haben wir den ersten "Release Candidate" (RC1) in das Test-Repository gestellt. Aktuell haben wir nur noch vier "Showstopper" offen, teilweise aber etwas kompliziert (u.a. Migration der DNSSEC-Konfiguration im BIND).

Anfang nächster Woche wird LiveConfig 2.17 freigegeben, und in dem Rahmen dann auch die Website bzgl LC3 aktualisiert.

Für LiveConfig 3 führen wir zusätzlich einen öffentlichen Issue-Tracker - damit es da eben mehr Transparenz gibt (und zwar objektiv/konkret, und nicht allgemein).

Viele Grüße

-Klaus Keppler

php-wpcli ist nach wie vor verfügbar: https://github.com/wp-cli/builds/tree/gh-pages/deb

Wir hatten das lediglich auch in die LiveConfig-Repositories kopiert, um es darüber bequemer installieren zu können.

Wir werden das gleich mal aktualisieren...