OpenDKIM-Milter wird nicht auf dem richtigen Server-Socket gestartet

OpenDKIM-Milter wird nicht auf dem richtigen Server-Socket gestartet

Der folgende Fehler verhinderte den Neustart von opendkim

× opendkim.service - OpenDKIM Milter
     Loaded: loaded (/lib/systemd/system/opendkim.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Sat 2023-04-22 08:00:27 UTC; 2s ago
[...]    Process: 2295 ExecStart=/usr/sbin/opendkim (code=exited, status=78)
opendkim.service: Control process exited, code=exited, status=78/CONFIG

Der Versuch, die (unverschlüsselt, und möglicherweise nicht aktualisiert) Dokumentation wurde nichts zu gefunden status=78.
Aber offensichtlich sind die Milter-Konfigurationen irgendwie falsch. /etc/postfix/main.cf definiert:

# Milter configuration
milter_default_action = accept
milter_protocol = 6
smtpd_milters = local:opendkim/opendkim.sock
non_smtpd_milters = $smtpd_milters

in /etc/opendkim.confder Erwägung, dass

Syslog                  yes
SyslogSuccess           yes
LogWhy                  yes

Canonicalization        relaxed/simple
Mode                    sv
SubDomains              no
OversignHeaders         From

UserID                  opendkim
UMask                   007

Socket                  local:/var/spool/postfix/opendkim/opendkim.sock

#Nameservers            127.0.0.1
AutoRestart                     yes
AutoRestartRate                 10/1M
Background                      yes
DNSTimeout                      5
SignatureAlgorithm              rsa-sha256

ExternalIgnoreList      refile:/etc/opendkim/trusted.hosts
InternalHosts           refile:/etc/opendkim/trusted.hosts
KeyTable                refile:/etc/opendkim/key.table
SigningTable            refile:/etc/opendkim/signing.table

PidFile                 /var/run/opendkim/opendkim.pid
# UserID                  opendkim:opendkim

Mir ist Folgendes aufgefallen:
• Die OpenDKIM-Konfiguration wurde ursprünglich referenziert, ExternalIgnoreList refile:/etc/opendkim/TrustedHostswährend die vorhandene Datei lautet /etc/opendkim/trusted.hosts. Dies wiederholt sich für den gesamten Block. Der gesamte Block wurde in die durch Punkte getrennten Dateinamen in Kleinbuchstaben geändert und der Dienst wird dann neu gestartet.

Allerdings werden E-Mails beim Senden von Postfix mit folgendem protokolliert: warning: connect to Milter service local:opendkim/opendkim.sock: No such file or directory

cd /var/spool/postfix/opendkim
-bash: cd: /var/spool/postfix/opendkim: No such file or directory

Ich sehe auch keine PID-Datei in/var/run/opendkim/

Hier sind wahrscheinlich einige Dinge zwischen der Postfix- smtpd_milters = local:opendkim/opendkim.sockKonfiguration und der OpenDKIM- SocketDefinition falsch. Was muss geändert werden?

Aktualisieren
warning: connect to Milter service local:opendkim/opendkim.sock: Permission deniedbefindet sich immer noch in den Mail-Protokollen, daher ist dieses Konfigurationselement falsch.

Ändern der Einstellung postfix/main.cfin

smtpd_milters = local:/var/spool/postfix/opendkim/opendkim.sock

ergibt: warning: connect to Milter service local:/var/spool/postfix/opendkim/opendkim.sock: No such file or directory. Die Existenz von /var/spool/postfix/opendkim/opendkim.sockist nachgewiesen.

Antwort1

Dies ist zwar der Pfad, unter dem sich der Socket im System befindet, es ist jedoch nicht der Pfad, unter dem ihn chroot-SMTP-Instanzen sehen:

smtpd_milters = local:/var/spool/postfix/opendkim/opendkim.sock

Postfix smtpd möchte einen Pfadrelativzum Chroot-Verzeichnis, der /var/spool/postfix/Pfad ist ihm nach dem Start nicht bekannt.

smtpd_milters = unix:opendkim/opendkim.sock

Die Einzelheiten finden Sie in /usr/share/doc/postfix/MILTER_READMEund man 5 master. Ich zitiere hier nur die wichtigsten Informationen, Hervorhebung von mir:

Wenn der smtpd(8)- oder cleanup(8)-Prozess chroot läuft, wird ein absoluter Pfadname interpretiertrelativ zum Postfix-Warteschlangenverzeichnis. Auf vielen Systemen ist „local“ ein Synonym für „unix“

Antwort2

Teillösung

sudo chown opendkim:postfix /var/spool/postfix/opendkim war erforderlich, um Postfix die Berechtigung zum Erstellen zu erteilenopendkim.sock

und obwohl opendkim.service: Can't open PID file /run/opendkim/opendkim.pid (yet?) after start: Operation not permittedes passierte, war es nur vorübergehend

Started OpenDKIM Milter.folgte kurz darauf und /run/opendkim/opendkim.pidwurde effektiv opendkim.pidvon root erstellt und ihm gehört.

verwandte Informationen