Merkwürdiges Verhalten nach Upgrade von Debian 11 zu Debian 12 mit KeyHelp Script [GELÖST]

[Toorms]

Guten Tag,

ich habe heute ein sehr komisches Verhalten festgestellt im Zusammenhang mit dem Update-Script von KeyHelp von Debian 11 zu Debian 12. Ich habe das ganze vor einigen Monaten schon einmal hier geschildert, aber noch nicht wirklich die Zeit gefunden es nachzustellen: viewtopic.php?p=44902#p44902

Fehler war damals sowie heute; dass E-Mails nicht reinkommen nach dem komplett "erfolgreichen" update von Debian 11 auf 12. Gemacht wurde alles so, wie es in dem News-Artikel beschrieben steht.

Ich habe es heute auch wieder gemacht und etwas genauer untersucht uns gesehen, dass nicht Python "wegrasiert" wurde sondert resolveconf sich aus dem Staub gemacht hat (oder gebeten wurde zu gehen) - ich kann mir vorstellen, dass im Upgrade-Script da etwas zu Radikal mit apt autoremove umgegangen wurde.

Fehler waren folgende - einmal gelistet:

mail.log - bei eingehender E-Mail:

Code: Select all

Feb 25 14:24:50 marge postfix/smtpd[29750]: connect from mail-xxxx.foobar.com[xxx.xxx.xxx.xxx]
Feb 25 14:24:50 marge postfix/smtpd[29750]: TLS SNI my.keyhelpserver.de from mail-xxxx.foobar.com[xxx.xxx.xxx.xxx] not matched, using default chain
Feb 25 14:24:50 marge postfix/smtpd[29750]: warning: missing attribute action in input from private/policy
Feb 25 14:24:50 marge postfix/spawn[29752]: warning: command /usr/bin/policyd-spf exit status 1
Feb 25 14:24:51 marge postfix/smtpd[29750]: warning: missing attribute action in input from private/policy
Feb 25 14:24:51 marge postfix/smtpd[29750]: warning: problem talking to server private/policy: Application error

Aus dem Log als auch aus der master.cf wissen wir, dass die neue Umgebung mit policyd-spf arbeitet, welche Python UND AUCH die /etc/resolv.conf braucht, was wir in der folgenden Meldung sehen, wenn wir /usr/bin/policyd-spf händisch ausführen - dann schäpperts nämlich wie folgt:

Code: Select all

root@marge:~# policyd-spf
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/spf.py", line 154, in <module>
    import dns
ModuleNotFoundError: No module named 'dns'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/policyd-spf", line 5, in <module>
    from spf_engine.policyd_spf import main
  File "/usr/lib/python3/dist-packages/spf_engine/__init__.py", line 53, in <module>
    import spf
  File "/usr/lib/python3/dist-packages/spf.py", line 165, in <module>
    import DNS    # https://launchpad.net/pydns
    ^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/DNS/__init__.py", line 37, in <module>
    Base._DiscoverNameServers()
  File "/usr/lib/python3/dist-packages/DNS/Base.py", line 85, in _DiscoverNameServers
    return ParseResolvConf()
           ^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/DNS/Base.py", line 53, in ParseResolvConf
    with open(resolv_path, 'r') as stream:
         ^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/etc/resolv.conf'

Ein Blick mit "file" auf die /etc/resolve.conf verrät das folgende

Code: Select all

root@marge:~# file /etc/resolv.conf
/etc/resolv.conf: broken symbolic link to /run/systemd/resolve/stub-resolv.conf

... und somit war es auch nicht mehr weit hergeholt, dass resolve.conf fehlt. Ich habe sodann folgende Schritte unternommen, um das System wieder lauffähig zu machen und final kamen auch wieder E-Mails rein und wieder raus.

Code: Select all

apt install --reinstall resolvconf
nano /etc/resolvconf/resolv.conf.d/tail
	nameserver 1.1.1.1
	nameserver 1.0.0.1
	nameserver 8.8.8.8

resolveconf -u
systemctl restart postfix

Meine Frage, die ich nun noch an die Entwickler habe sind die folgenden:

• 1. Sind meine Änderungen in Ordnung oder wie muss in dem Fall vorgegangen werden, sodass das System nach KeyHelp vorgaben korrekt läiuft?

• 2. Muss ggf. noch etwas beachtet werden?

Besten Dank, cheers
Toorms

[Toorms]

Hätte gerne das Template nachträglich genutzt bzw. mein OT angepasst, leider ist das nicht mehr möglich. Daher bitte um Verzeihung, dass ich nicht das Template genutzt habe.

[Florian]

Hallo,

das ist aber kein generelles Verhalten.

Ich habe grade nochmal durchlaufen lassen und da war auch nach dem Dist-Upgrade die resolv.conf noch entsprechend verlinkt

Vielleicht wurde hier mal bei Auflösungsproblemen die resolv.conf manuell geändert.

[Toorms]

Vielleicht wurde hier mal bei Auflösungsproblemen die resolv.conf manuell geändert.

Das glaube ich nicht, da im originalen (Snapshot wiederhergestellt) die resolve.conf noch vorhanden ist.

Code: Select all

nameserver 127.0.0.53
options edns0 trust-ad
search .

Es wäre noch zu erwähnen, dass nicht nur die .conf Datei wegrasiert wurde, sondern das gesamte Paket nicht mehr vorhanden war. Ein wenig komisch ist das schon - gäbge es hier ggf. noch mehr zu prüfen?

Meine Frage, kann ich meine Resolve.conf denn so nachträglich konfigurieren und lassen (wie im Original Post) harmoniert das nicht mit dem restlichen System von KeyHelp?

Nachdem ich die resolveconf so behandelt habe wir im OP, funktionierte postfix sowie Mail ein- und ausgang wieder.

[Toorms]

Was bei mir vielleicht zu dem Merkwürdigen Verhalten geführt haben kann ist, dass ich unter /index.php?page=admin_configuration&configure=dns_server 9 DNS Server konfiguriert habe und auch die folgende Datei schon etwas meckert:

Code: Select all

root@marge:~# cat /run/systemd/resolve/resolv.conf 
nameserver 46.38.225.230
nameserver 46.38.252.230
nameserver 1.1.1.1
[b]# Too many DNS servers configured, the following entries may be ignored.
[/b]nameserver 1.0.0.1
nameserver 2a03:4000:0:1::e1e6
nameserver 2a03:4000:8000::fce6
search .

Also im Testcenter, wenn man es mal nachspielen möchte bei KeyHelp mal 9 DNS Server eintragen und schauen ob das gleiche Ergebnis kommt, wie bei mir?

Ich werde am kommenden Wochenende nochmal ein Upgrade durchführen mit nur zwei DNS Servern in der KeyHelp Administration.

[Alexander]

KeyHelp schreibt weder Inhalte in die resolv.conf, noch benutzt es den direkten Inhalt der Datei in irgendeiner Weise (mal von einer generell funktionierenden Namensauflösung auf dem System abgesehen).

KeyHelp entfernt dieses Paket im Zuge eines Upgrades auch nicht. Es kann aber natürlich sein, dass die Debian Paketverwaltung der Ansicht ist, das Paket im Zuge eines Dist-Upgrades entfernen zu müssen. Das wäre aber out-of-scope von KeyHelp.

Lange Rede, kurzer Sinn: Was du in die resolv.conf einträgst ist komplett dir überlassen, wenn es der Funktionalität des Servers zuträglich ist, dann go for it. Es kollidiert nicht mit KeyHelp Einstellungen.

[Toorms]

Lange Rede, kurzer Sinn: Was du in die resolv.conf einträgst ist komplett dir überlassen, wenn es der Funktionalität des Servers zuträglich ist, dann go for it. Es kollidiert nicht mit KeyHelp Einstellungen.

Herzlichen Dank in die Runde für die Infos. Dann führe ich das Update erneut durch am Wochenende.