Erreurs de journal Mail-receiver après la mise à jour de letsencrypt

Soutien
1

Suite à la discussion de Mise à jour du récepteur de courrier auto-hébergé suite au changement de certificat racine de Let’s Encrypt :

Après avoir mis à jour le récepteur de courrier vers la dernière version, ./launcher logs mail-receiver affiche une erreur après :

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.outDémarrage de Postfix

Aucun autre événement n’est affiché (courriels entrants, courriels rejetés, etc.).

J’ai rencontré des problèmes avec des paramètres Postfix personnalisés (qui fonctionnaient parfaitement avant la récente mise à jour) et j’ai besoin de déboguer, ce qui est difficile sans les journaux.

2

avez-vous essayé ces étapes

1 « J'aime »
3

Je vois bien les mêmes erreurs avertissements, mais Postfix tourne tranquillement et accepte les courriels après cela.

Parfois, les journaux ne semblent pas être vidés immédiatement, il peut donc falloir attendre un peu avant d’obtenir une sortie. Cela n’a toutefois aucun lien avec les avertissements.

Alors, est-ce que cela plante réellement chez vous ?

4

Même chose avec les paramètres par défaut. Mais j’ai dû désactiver temporairement une règle Postfix supplémentaire :

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

qui fonctionnait parfaitement avant la mise à niveau (elle utilise des règles regex pour rejeter les spammers). Le vrai problème est que, lorsque ce paramètre est activé, Postfix rejette tous les courriels entrants, mais je ne vois pas pourquoi dans les journaux !

Peut-être un moment, mais cela fait des heures et il n’y a toujours rien dans les journaux (aucun courriel accepté ou rejeté n’est affiché, et il y a bien du trafic entrant).

5

Vous aviez raison, il y a d’autres entrées de journal dans la sortie, mais la sortie elle-même est illisible :

La sortie de ./launcher logs mail-receiver commence par un <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

suivie d’une seule ligne d’entrées de journal, et se termine par le <HEAD> répété six fois de plus :

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

Je ne regardais que la fin de la sortie, et il semblait toujours n’y avoir que le <HEAD> sans aucune autre entrée.

Il y a certainement un problème avec le rendu du journal via ./launcher logs mail-receiver.

6

Je pense avoir résolu ce problème : il manque une ligne maillog_file dans le Dockerfile. Solution temporaire : j’ai ajouté

  POSTCONF_maillog_file: '/dev/stdout'

dans mail-receiver.yml et reconstruit l’image, mais cela devrait probablement être corrigé directement dans l’image Docker

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

Ainsi, après avoir ajouté cela, l’erreur a disparu et les journaux fonctionnent ? Si c’est le cas, seriez-vous d’accord pour soumettre une PR afin d’apporter cette modification ?

8

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

1 « J'aime »
9

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

10

Merci @md-misko - j’ai fusionné la PR et mis à jour l’étiquette discourse/mail-reciever:release sur Dockerhub.

Je suis sûr que vous êtes déjà au courant, mais au cas où quelqu’un d’autre tomberait sur ce sujet, vous pouvez mettre à jour votre version du récepteur de courrier en exécutant :

docker pull discourse/mail-receiver:release
cd /var/discourse
./launcher rebuild mail-receiver
3 « J'aime »
11

Avez-vous des idées sur la façon de tester que l’image en cours d’exécution est la dernière version ?

12

Un peu alambiqué… mais je pense que cela devrait fonctionner :

# Tout d'abord, assurez-vous d'avoir la dernière image de base localement
docker pull discourse/mail-receiver:release

# Obtenez la couche supérieure de l'image de base
BASE_IMAGE_HASH=$(docker history discourse/mail-receiver:release -q | head -n 1)

# Obtenez les couches de la version **en cours d'exécution**
RUNNING_IMAGE_HASH=$(docker container inspect mail-receiver -f "{{.Image}}")
RUNNING_IMAGE_LAYERS=$(docker history $RUNNING_IMAGE_HASH -q)

# Vérifiez si les couches de l'image en cours d'exécution incluent l'image de base actuelle :
[[ "$RUNNING_IMAGE_LAYERS" == *"$BASE_IMAGE_HASH"* ]] && echo "À jour"

Cela affichera “À jour” si vous êtes à jour. Sinon, la dernière ligne n’affichera rien et se terminera avec un statut non nul.

2 « J'aime »
13

Oh. C’est génial. Et il semble que ce soit une solution générale pour laquelle je n’avais trouvé que des solutions ponctuelles auparavant. Il m’aurait fallu un certain temps pour comprendre cela. Le RUNNING_IMAGE_LAYERS est ce que je ne savais pas chercher.

Je l’ai testé sur une instance qui avait été mise à niveau et une autre qui ne l’avait pas été, et il semble que le comportement soit celui attendu.

Merci beaucoup !

3 « J'aime »
14

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