Mail-Empfänger-Logfehler nach Letsencrypt-Update

Unterstützung
1

Continuing the discussion from Self-hosted mail-receiver update following Let's Encrypt root certificate change:

After updating mail-receiver to latest ./launcher logs mail-receiver errors out after

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

and doesn’t show any other events (incoming emails, rejected emails, …).

I’ve encountered some issues with custom postfix settings (which worked flawlessly prior to recent update) and need to debug, which is difficult without logs.

2

have you tried these steps

1 „Gefällt mir“
3

I do see the same errors warnings but Postfix is happily running and accepting mails after that.

Sometimes the logs don’t seem to flush immediately so you might need to wait for a while before you get some output. But that’s unrelated to the warnings.

So is it actually crashing for you?

4

Ditto, with vanilla settings. But I had to temporarily disable additional postfix rule

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

which worked perfectly before the upgrade (uses regex rules to reject spammers). The real issue is that with this setting enabled, postfix starts rejecting all incoming email, but I can’t see why from the logs!

A while maybe, but it’s been hours and still nothing in logs (neither accepted nor rejected emails are shown, and there is inbound traffic).

5

You were right, there are other log entries in the output, but the output itself is garbled:

./launcher logs mail-receiver output begins with a <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

followed by a single line of log entries, and ending with the <HEAD> repeated six more times:

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

I was only looking at the end of the output, and there was always seemingly just the <HEAD> without any other entries.

Definitely something wrong with the rendering of the log via ./launcher logs mail-receiver.

6

I believe I figured this one out, there is a maillog_file line missing in the Dockerfile. Temp fix: added

  POSTCONF_maillog_file: '/dev/stdout'

to mail-receiver.yml and rebuilt, but this should probably be fixed in the docker image

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

So after adding this, the error is gone, and the logs are working? If so, would you mind submitting a PR to make that change?

8
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.