Mail-Empfänger-Logfehler nach Letsencrypt-Update

Unterstützung
1

Fortsetzung der Diskussion aus Update für den selbst gehosteten Mail-Empfänger nach der Änderung des Root-Zertifikats von Let’s Encrypt:

Nach dem Update des Mail-Empfängers auf die neueste Version führt ./launcher logs mail-receiver nach folgendem Fehler aus:

postfix/postfix-script: warning: symlink leaves directory: /etc/postfix/./makedefs.out
<20>Oct  1 06:10:33 postfix/postfix-script[86]: warning: symlink leaves directory: /etc/postfix/./makedefs.outStarting Postfix

Es werden keine weiteren Ereignisse angezeigt (eingehende E-Mails, abgelehnte E-Mails, …).

Ich habe einige Probleme mit benutzerdefinierten Postfix-Einstellungen festgestellt (die vor dem kürzlichen Update einwandfrei funktionierten) und muss diese debuggen, was ohne Logs schwierig ist.

2

Hast du diese Schritte bereits ausprobiert?

1 „Gefällt mir“
3

Ich sehe ebenfalls die gleichen Fehler Warnungen, aber Postfix läuft zufriedenstellend weiter und nimmt Mails danach entgegen.

Manchmal scheinen die Logs nicht sofort zu flushten, sodass du möglicherweise etwas warten musst, bis du eine Ausgabe erhältst. Das hat jedoch nichts mit den Warnungen zu tun.

Stürzt es bei dir also tatsächlich ab?

4

Bei mir genauso, mit den Standard-Einstellungen. Allerdings musste ich eine zusätzliche Postfix-Regel vorübergehend deaktivieren:

  POSTCONF_smtpd_client_restrictions: 'regexp:/etc/postfix/shared/client_access_regex'

Diese hat vor dem Upgrade einwandfrei funktioniert (verwendet Regex-Regeln, um Spammer abzulehnen). Das eigentliche Problem ist, dass Postfix mit dieser Einstellung aktiv alle eingehenden E-Mails ablehnt, aber ich kann aus den Logs nicht erkennen, warum!

Eine Weile vielleicht, aber es sind schon Stunden vergangen und in den Logs steht immer noch nichts (weder angenommene noch abgelehnte E-Mails werden angezeigt, obwohl eingehender Datenverkehr vorhanden ist).

5

Du hattest recht, es gibt weitere Log-Einträge in der Ausgabe, aber die Ausgabe selbst ist durcheinandergeraten:

Die Ausgabe von ./launcher logs mail-receiver beginnt mit einem <HEAD>:

/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
Operating environment:
HOSTNAME=discourse-mail-receiver
LANGUAGE=en_US.UTF-8
MAIL_DOMAIN=...
...
...
Setting smtpd_tls_security_level to 'may'
postfix/postfix-script: warning: symlink leaves directory: /etc/postfix/./makedefs.out

gefolgt von einer einzigen Zeile mit Log-Einträgen und endet mit dem <HEAD>, der sechs weitere Male wiederholt wird:

<HEAD>
Single line of log entries without line breaks..............................................................................................................................................................................................
<HEAD>
<HEAD>
<HEAD>
<HEAD>
<HEAD>
<HEAD>

Ich habe bisher nur das Ende der Ausgabe betrachtet, und dort schien es immer nur den <HEAD> ohne weitere Einträge zu geben.

Definitiv liegt ein Fehler bei der Darstellung des Logs über ./launcher logs mail-receiver vor.

6

Ich glaube, ich habe das Problem gelöst: Im Dockerfile fehlt eine Zeile mit maillog_file. Als temporäre Lösung habe ich zu mail-receiver.yml hinzugefügt:

  POSTCONF_maillog_file: '/dev/stdout'

und neu erstellt. Dies sollte jedoch wahrscheinlich im Docker-Image selbst behoben werden:

RUN > /etc/postfix/main.cf \
+	&& postconf -e maillog_file=/dev/stdout \
	&& postconf -e smtputf8_enable=no \
...
7

Also, nachdem du das hinzugefügt hast, ist der Fehler verschwunden und die Protokolle funktionieren? Falls ja, hättest du nichts dagegen, einen PR einzureichen, um diese Änderung vorzunehmen?

8

https://github.com/discourse/mail-receiver/pull/11

1 „Gefällt mir“
9

https://github.com/discourse/mail-receiver/pull/12

10

Danke @md-misko – ich habe den PR zusammengeführt und den discourse/mail-reciever:release-Tag auf Dockerhub aktualisiert.

Ich bin sicher, dass Sie sich dessen bereits bewusst sind, aber falls jemand anderes auf dieses Thema stößt, können Sie Ihre Mail-Receiver-Version aktualisieren, indem Sie Folgendes ausführen:

docker pull discourse/mail-receiver:release
cd /var/discourse
./launcher rebuild mail-receiver
3 „Gefällt mir“
11

Haben Sie Ideen, wie man testen kann, ob das aktuell laufende Image die neueste Version ausführt?

12

Etwas umständlich … aber ich denke, das sollte funktionieren:

# Stellen Sie zunächst sicher, dass Sie das neueste Basis-Image lokal haben
docker pull discourse/mail-receiver:release

# Holen Sie sich die oberste Ebene des Basis-Images
BASE_IMAGE_HASH=$(docker history discourse/mail-receiver:release -q | head -n 1)

# Holen Sie sich die Ebenen der **laufenden** Version
RUNNING_IMAGE_HASH=$(docker container inspect mail-receiver -f "{{.Image}}")
RUNNING_IMAGE_LAYERS=$(docker history $RUNNING_IMAGE_HASH -q)

# Prüfen Sie, ob die Ebenen des laufenden Images das aktuelle Basis-Image enthalten:
[[ "$RUNNING_IMAGE_LAYERS" == *"$BASE_IMAGE_HASH"* ]] && echo "Up to date"

Das gibt “Up to date” aus, wenn Sie auf dem neuesten Stand sind. Andernfalls gibt die letzte Zeile nichts aus und wird mit einem Nicht-Null-Status beendet.

2 „Gefällt mir“
13

Oh. Das ist brillant. Und es sieht so aus, als wäre es eine allgemeine Lösung, für die ich bisher nur Einzellösungen gefunden habe. Es hätte eine Weile gedauert, bis ich das herausgefunden hätte. Die RUNNING_IMAGE_LAYERS ist das, wonach ich nicht gesucht habe.

Ich habe es auf einer Instanz getestet, die aktualisiert wurde, und auf einer, die nicht aktualisiert wurde, und es scheint sich wie erwartet zu verhalten.

Vielen Dank!

3 „Gefällt mir“
14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.