Beiträge von Systemhaus-EHST

  • Fehlerbericht LiveConfig 3.3.0 – SRS wird auch auf interne E-Mail-Weiterleitungen angewendet

    Sehr geehrter Herr Kepler,

    bei der Überprüfung unserer Postfix-Konfiguration in Verbindung mit PostSRSd ist uns ein Problem bei der Verarbeitung von E-Mail-Weiterleitungen mit aktiviertem Sender Rewriting Scheme (SRS) aufgefallen.


    Problem: LiveConfig versieht bei aktivierter SRS-Option sämtliche Weiterleitungsziele eines E-Mail-Kontos mit dem Präfix     srs= – unabhängig davon, ob es sich um interne oder externe Empfänger handelt.


    Dadurch können auch lokale Weiterleitungen unnötig über den für SRS vorgesehenen SMTP-Transport verarbeitet werden.

    1. Verwendete Umgebung

    • Betriebssystem: Debian 13 (Trixie)
    • LiveConfig-Version: 3.3.0
    • Mailserver: Postfix mit Dovecot
    • SRS-Implementierung: PostSRSd
    • Verwaltung virtueller Maildomains und Postfächer über LiveConfig
    • Separater Postfix-SRS-Transport über Port 10027

    Die SRS-Funktion wird über folgende Option aktiviert:

    „SRS (Sender Rewriting Scheme) zur Weiterleitung von E-Mails anwenden“

    2. Fehlerbeschreibung anhand eines anonymisierten Beispiels

    Angenommen, folgende E-Mail-Adresse wird über LiveConfig verwaltet:

    info@beispiel-domain.de

    Für dieses Konto sind drei Weiterleitungen eingerichtet:

    • intern1@beispiel-domain.de – lokales Postfach
    • extern@example.com – externer Empfänger
    • intern2@beispiel-domain.de – lokales Postfach

    Die Domain beispiel-domain.de sowie beide internen Empfänger werden auf demselben Postfix-Server verwaltet.

    Ohne aktivierte SRS-Option erzeugt LiveConfig folgende Alias-Konfiguration:

    Code
    info@beispiel-domain.de    intern1@beispiel-domain.de, extern@example.com, intern2@beispiel-domain.de

    Wird die SRS-Option aktiviert, ergibt sich aufgrund der aktuellen Implementierung folgende Konfiguration:

    Code
    info@beispiel-domain.de    srs=intern1@beispiel-domain.de, srs=extern@example.com, srs=intern2@beispiel-domain.de

    Damit werden auch die beiden internen Empfänger als SRS-Weiterleitungsziele behandelt.

    3. Ursache im LiveConfig-Quellcode

    In der Datei

    /usr/lib/liveconfig/lua/postfix.lua

    befindet sich innerhalb der Funktion addMailbox() folgender Abschnitt:

    Code
    -- write forwards (if defined)
if type(data.forwards) == "table" then  fhw:write(name, "@", data.domain, "\t")  if (data.mailbox == true or data.autoresponder == true) and name ~= '' then    -- save copy to local mailbox (or deliver to Dovecot Sieve for autoresponder)    fhw:write(name, "@", data.domain, ", ")  end  for i, s in ipairs(data.forwards) do    if i > 1 then fhw:write(", ") end    if data.srs and not string.match(s, "^srs=") then fhw:write("srs=") end    fhw:write(s)  end  fhw:write("\n")
end

    Die entscheidende Anweisung lautet:

    Code
    if data.srs and not string.match(s, "^srs=") then fhw:write("srs=") end

    Hier wird lediglich geprüft, ob SRS für das Konto aktiviert wurde und ob die Weiterleitungsadresse bereits das Präfix srs= besitzt.

    Eine Unterscheidung zwischen lokal verwalteten und externen Maildomains erfolgt nicht.

    4. Technische Auswirkungen

    In unserer Postfix-Konfiguration werden SRS-markierte Empfänger über folgende Transportregel verarbeitet:

    Datei: /etc/postfix/transport_srs.regex

    Code
    /^srs=.*@.*$/      smtp:127.0.0.1:10027

    Der separate SMTP-Dienst übernimmt die Nachricht und übergibt sie an einen speziellen Cleanup-Dienst zur SRS-Verarbeitung.

    Durch die Kennzeichnung interner Weiterleitungsziele können folgende unerwünschte Effekte entstehen:

    • Unnötige erneute SMTP-Einlieferung über Port 10027
    • Zusätzliche Verarbeitung durch Postfix
    • Mögliche Veränderung des Envelope-Absenders auch bei lokaler Zustellung
    • Erhöhte Komplexität bei der Fehleranalyse
    • Unnötige zusätzliche Verarbeitungsschritte bei Weiterleitungsketten

    Die tatsächlichen Auswirkungen hängen von der jeweiligen Postfix-Konfiguration ab.

    5. Erwartetes Verhalten

    Aus unserer Sicht sollte LiveConfig bei aktivierter SRS-Option zwischen internen und externen Weiterleitungszielen unterscheiden.

    Die gewünschte Alias-Konfiguration wäre:

    Code
    info@beispiel-domain.de    intern1@beispiel-domain.de, srs=extern@example.com, intern2@beispiel-domain.de

    Damit würden lokale Empfänger weiterhin regulär zugestellt, während nur externe Weiterleitungen über den SRS-Transport laufen.

    Eine mögliche Lösung wäre die Prüfung, ob die Domain des Weiterleitungsziels in den lokal verwalteten virtuellen Maildomains enthalten ist.

    Für Umgebungen mit mehreren eigenen Mailservern wäre zusätzlich eine konfigurierbare Ausnahmeliste für interne Maildomains sinnvoll.

    6. Abgrenzung: Lokales Postfach mit externer Weiterleitung

    Bei einem Konto mit lokalem Postfach und zusätzlicher externer Weiterleitung funktioniert die Alias-Erzeugung bereits wie gewünscht.

    Beispiel:

    Code
    kontakt@beispiel-domain.de    kontakt@beispiel-domain.de, srs=extern@example.com

    Die lokale Postfachkopie wird ohne SRS-Präfix erzeugt.

    Das Problem betrifft insbesondere Konfigurationen, bei denen mehrere Weiterleitungsadressen innerhalb von data.forwards hinterlegt sind und diese sowohl interne als auch externe Empfänger enthalten.

    7. Fragen an das LiveConfig-Team

    Wir würden uns über eine Rückmeldung zu folgenden Punkten freuen:

    1. Ist dieses Verhalten bekannt beziehungsweise beabsichtigt?
    2. Wäre es möglich, bei aktivierter SRS-Option lokal verwaltete Maildomains automatisch auszunehmen?
    3. Könnte zusätzlich eine konfigurierbare Liste interner Domains berücksichtigt werden, beispielsweise für Umgebungen mit mehreren Mailservern?
    4. Gibt es bereits einen offiziell unterstützten Erweiterungspunkt über /usr/lib/liveconfig/lua/custom.lua, um die Alias-Erzeugung entsprechend anzupassen?
    5. Ist gegebenenfalls eine Anpassung in einer zukünftigen LiveConfig-Version vorgesehen?

    Wir möchten direkte Änderungen an der Originaldatei postfix.lua vermeiden, da diese bei zukünftigen LiveConfig-Updates überschrieben werden könnten.


    Eine updatefeste Lösung innerhalb von LiveConfig wäre daher wünschenswert.


    Vielen Dank für Ihre Unterstützung und die Prüfung des Sachverhalts.


    Mit freundlichen Grüßen

    Martin Krüger

  • Preview: LiveConfig 3.3.0

    Hallo


    das System ist nicht frisch auf Debian 13 aufgesetzt sondern besteht schon gut 2-3 Jahre, und seit LiveConfig 2 jedes Update erhalten.

    Das Update lief mit der letzten Preview und wurde auf die aktelle Preview geupdatet.

    Mit freundlichen Grüßen

    Martin Krüger

  • Preview: LiveConfig 3.3.0

    Hallo


    Fehler bei Upgrade auf Version 3.3.0 (build 18139)


    Server OS: Debian 13.7

    Okt 05 20:53:30 testsystem systemd[1]: Starting liveconfig.service - LiveConfig Control Panel...

    Okt 05 20:53:30 testsystem liveconfig[1309399]: [1309399] [2026-10-05 20:53:30.459844] [INFO] LiveConfig 3.3.0 (build 18139) starting...

    Okt 05 20:53:30 testsystem liveconfig[1309399]: [1309399] [2026-10-05 20:53:30.466526] [INFO] Database driver loaded: MariaDB Connector/C (3.4.9)

    Okt 05 20:53:30 testsystem liveconfig[1309399]: [1309399] [2026-10-05 20:53:30.467945] [INFO] Upgrading database schema (r219032 -> 2.19.3-3)

    Okt 05 20:53:30 testsystem liveconfig[1309399]: [1309399] [2026-10-05 20:53:30.469013] [EMERG] Column 'P_ID' cannot be null

    Danach startet LiveConfig nicht mehr.

    Ein:


    Code
    mariadb LIVECONFIG -e "
ALTER TABLE PERMISSIONS
  ADD PRIMARY KEY (P_ID),
  MODIFY P_ID INTEGER NOT NULL AUTO_INCREMENT;
"


    behebt das Problem.

    Mit freundlichen Grüßen

    Martin Krüger

  • E-Mail-Weiterleitung an fremde Provider nur mit aktiven Spamfilter

    Hallo


    wir haben 24 Postfix Servern und 9 Exchange Servern die Ihre E-Mails eingehend und ausgehend über 2 MX (Proxmox Mailgateways) bekommen.

    Man hat dann ein Zentrales Mail Log für alle Server und Mail Queue falls ein Server mal ausfällt.

    Es werden nur E-Mails von tatsächlich angelegten E-Mails angenommen und versendet, bei CatchAll wird dann alles angenommen.

    Der Austausch der der E-Mail Adresse erfolgt direkt nach dem anlegen automatisch.

    Läuft seit mehreren Jahren wunderbar, sehr wartungsarm.


    Mit freundlichen Grüßen

    Martin Krüger

  • Ein APT-3.0.3-Bug bzw. eine False-Positive-Warnung bei Update aus Debian-Test Repository

    Hallo

    Es wurde gerade Debian 13.7 veröffentlicht, in der neuen APT-3.0.3 Version eine False Positiv Meldung:


    Aktualisierung für 2 Pakete verfügbar. Führen Sie »apt list --upgradable« aus, um sie anzuzeigen.
    Hinweis: Fehlendes Signed-By im Eintrag sources.list(5) für »http://repo.liveconfig.com/debian-test«


    obwohl Signed-By: /usr/share/keyrings/liveconfig-keyring.gpg gesetzt ist und sqv erfolgreich mit GOODSIG AFC55937C236EB95 verifiziert.

    Desweiteren werden nun auch Ubuntu statt Debian PHP Pakete angeboten:

    Was mittels:

    Code
    cat >/etc/apt/preferences.d/00-liveconfig-php.pref <<'EOF'
Package: php-8.4-opt
Pin: version 8.4.25-1+ubuntu26
Pin-Priority: -1

Package: php-8.5-opt
Pin: version 8.5.10-1+ubuntu26
Pin-Priority: -1
EOF


    korrigiert wurde, danach wurde wieder Debian13 Pakate angeboten.


    Vieleicht hilft es dem ein oder anderen.

    Mit freundlichen Grüßen
    Martin Krüger

  • WordPress erkennt aktiven OPCache nicht

    Hallo


    Das ist sehr wahrscheinlich kein Fehler deiner OPcache-Konfiguration, sondern eine Fehlerkennung in WordPress 7.0/7.0.1.


    WordPress prüft nicht nur, ob opcache.enable eingeschaltet und die Funktion vorhanden ist. Der Website-Zustand führt intern sinngemäß Folgendes aus:

    Code
    $status = opcache_get_status(false);

if ($status && true === $status['opcache_enabled']) {
    // OPcache erkannt
}


    Gibt opcache_get_status() also false zurück oder enthält das Ergebnis opcache_enabled => false, meldet WordPress „Der Opcode-Cache ist nicht aktiviert“ – selbst wenn OPcache tatsächlich arbeitet.


    Code
    opcache.file_cache_only

    Steht dieser Wert auf:

    Code
    opcache.file_cache_only = 1

    ist die Ursache gefunden. opcache_get_status() liefert nur Informationen über den Shared-Memory-Cache, nicht über den OPcache-Datei-Cache. WordPress interpretiert das derzeit fälschlicherweise als deaktivierten OPcache. Genau dafür existiert bereits ein bestätigter WordPress-Bug, dessen Korrektur aktuell für WordPress 7.0.2 vorgesehen ist.


    Die PHP-Dokumentation bestätigt ausdrücklich, dass opcache_get_status() keine Informationen zum Datei-Cache zurückgibt.

    Mit freundlichen Grüßen

    Martin Krüger