[résolu] Mail Delivery Subsystem : fatal errors après mise à jour

Aide
1

Bonjour !

Je suis l’heureux propriétaire d’un Raspberry PI 3 B+ dont je me sers de cloud et d’hébergement pour mon site web perso. Je n’y connaissais pas grand chose en Linux, mais votre site et les quelques autres que Google m’a monté, m’ont permis de mettre le tout sur pied, assez rapidement. Tout a fonctionné (et globalement, tout fonctionne toujours) de manière impeccable.

Mais voilà, vous l’avez deviné, si je fais ce sujet aujourd’hui, c’est bien parce que j’ai un problème pour lequel Google n’arrive pas à me pointer la solution… :frowning:

Je fais régulièrement les mises à jours de raspbian.J’ai même mis en place une routine cron qui me télécharge les mises à jours,et donc me préviens par mail du résultat de la requête. Cela a toujours fonctionné à merveille.

Mais là, depuis 3 jours (et donc les mises à jours que j’ai fait ce jour-là) les mails de rapport de tache cron que je reçois sont en erreur « 553 » « Domaine of sender root@raspberrypi not exist ».

J’ai bien un fichier /etc/mail/aliases dans lequel j’ai rentré l’adresse mail (à @free.fr) que j’utilise, et sur laquelle j’ai toujours reçu les mails. C’est d’ailleurs sur cette adresse que je reçois les mail de mailer-daemon@raspberrypi. Et bien entendu, ce fichier n’a pas été modifié par la mise à jour…

Bref, je suis bien incapable de trouver ce qui ne va pas, de trouver quel est ce module que j’ai mis à jour, et qui a provoqué cette erreur, et donc de régler ce problème.

Quelqu’un parmi vous aurait-il une idée sur la cause, ou une piste de rechercher pour solutionner ce problème ?

2

Bonjour,

Il faut identifier quel paquet est utilisé pour configurer les mail.
Vérifier si il a été mis à jour, et reprendre sa configuration.

Perso j’utilise ssmtp et donc le fichier /etc/ssmtp/ssmtp.conf. Si c’est le cas aussi vérifier le paramètre rewriteDomain dans ce fichier.

A+

3

Oui, saurais-tu comment identifier ce paquet ?

Je ne me souviens pas avoir installé de paquet pour les mails.
J’utilise SwiftMail sur mon site PHP (sous Symfony) et ça fonctionne comme il faut.
Le souci n’est visiblement que pour les mails générés par les tâches CRON.

Je n’ai pas le fichier /etc/ssmtp/ssmtp.conf, ni le dossier d’ailleurs.
Je ne dois donc pas utiliser ce paquet ssmtp.

D’ailleurs, au sujet de ma distribution, pour pouvoir installer PHP7, j’ai lu quelque part qu’il fallait passer sur le dépôt « buster »…
J’ai donc modifier un fichier de config pour chercher les mises à jour sur ce dépôt.

Ainsi, lsb_release -a donne :

linux raspberrypi 4.19.79-v7+ #1159 Sun 4 Nov 17:50:20 GMT 2018 armv71 GNU/Linux

et uname -a :

No LSB modules are available.
Distributor ID: Raspian
Description: Raspbian GNU/Linux buster/sid
Release: testing
Codename: buster

Bon, j’avoue, utiliser une distribution en test alors qu’on s’y connait pas trop en linux n’est probablement pas une bonne idée… Mais je reste persuadé que ce problème peut être réglée en 2 temps 3 mouvements.
Le tout est de savoir quel fichier rectifier… :roll_eyes:

4

C’est certainement le cas. Par contre je n’ai pas plus d’idées.
Je laisse la main à d’autre forumeurs…

Bon courage
A+

5

Ok, merci quand même Jelopo !
J’espère que d’autre forumeurs sauront me mettre sur la voie…

J’ai poursuivis mes investigations, et j’ai trouvé dans /log/apt/history la liste (109!) des paquets concernés par la mise à jour qui a provoquée ce bug.

A toutes fins utiles, je vous mets ici cette liste…
Desfois que quelqu’un identifierait un paquet qui s’occupe de ces fameux mail Cron, ou des DNS…

Start-Date: 2018-12-19 18:32:04
Commandline: apt upgrade
Requested-By: boss (1002)
Install: libpython3.7-minimal:armhf (3.7.2~rc1-1, automatic), python3.7:armhf (3.7.2~rc1-1, automatic), libpython3.7-stdlib:armhf (3.7.2~rc1-1, automatic), python3.7-minimal:armhf (3.7.2~rc1-1, automatic)
Upgrade: fdisk:armhf (2.32.1-0.1, 2.33-0.2), php7.3-xml:armhf (7.3.0~rc4-1+b2, 7.3.0-2), perl-base:armhf (5.28.1-1, 5.28.1-3), libpolkit-gobject-1-0:armhf (0.105-22, 0.105-23), php7.3-zip:armhf (7.3.0~rc4-1+b2, 7.3.0-2), libpython3.6-minimal:armhf (3.6.7-1, 3.6.8~rc1-1), libpangoft2-1.0-0:armhf (1.42.4-4, 1.42.4-5), libnghttp2-14:armhf (1.34.0-1, 1.35.1-1), libcups2:armhf (2.2.9-2, 2.2.10-3), libdbus-1-3:armhf (1.12.10-1, 1.12.12-1), libnih-dbus1:armhf (1.0.3-10+b9, 1.0.3-10+b11), sysvinit-utils:armhf (2.92~beta-2, 2.93-1), libfdisk1:armhf (2.32.1-0.1, 2.33-0.2), php7.3-mbstring:armhf (7.3.0~rc4-1+b2, 7.3.0-2), php7.3-readline:armhf (7.3.0~rc4-1+b2, 7.3.0-2), libc6-dbg:armhf (2.27-8+rpi1, 2.28-2), libc6-dev:armhf (2.27-8+rpi1, 2.28-2), libsystemd0:armhf (239-13+rpi1, 239-15+rpi1), dash:armhf (0.5.10.2-1, 0.5.10.2-2), cpp-8:armhf (8.2.0-9+rpi1, 8.2.0-12+rpi1), dbus:armhf (1.12.10-1, 1.12.12-1), mariadb-common:armhf (1:10.1.37-1, 1:10.1.37-3), libpixman-1-0:armhf (0.34.0-2, 0.36.0-1), libasound2-data:armhf (1.1.7-1, 1.1.7-2), libmount1:armhf (2.32.1-0.1, 2.33-0.2), gcc-8-base:armhf (8.2.0-9+rpi1, 8.2.0-12+rpi1), libsqlite3-0:armhf (3.25.3-2, 3.26.0-3), libpython3.6-stdlib:armhf (3.6.7-1, 3.6.8~rc1-1), binutils:armhf (2.31.1-10+rpi1, 2.31.1-11+rpi1), php7.3:armhf (7.3.0~rc4-1, 7.3.0-2), php7.3-json:armhf (7.3.0~rc4-1+b2, 7.3.0-2), perl-modules-5.28:armhf (5.28.1-1, 5.28.1-3), libbabeltrace1:armhf (1.5.6-1, 1.5.6-2), libc6:armhf (2.27-8+rpi1, 2.28-2), php7.3-mysql:armhf (7.3.0~rc4-1+b2, 7.3.0-2), util-linux:armhf (2.32.1-0.1, 2.33-0.2), mariadb-server-core-10.1:armhf (1:10.1.37-1, 1:10.1.37-3), libpython3.6:armhf (3.6.7-1, 3.6.8~rc1-1), python3.6:armhf (3.6.7-1, 3.6.8~rc1-1), php7.3-gd:armhf (7.3.0~rc4-1+b2, 7.3.0-2), python3:armhf (3.6.7-1, 3.7.1-2), libpolkit-agent-1-0:armhf (0.105-22, 0.105-23), php7.3-curl:armhf (7.3.0~rc4-1+b2, 7.3.0-2), udev:armhf (239-13+rpi1, 239-15+rpi1), locales:armhf (2.27-8+rpi1, 2.28-2), libxcb-shm0:armhf (1.13.1-1, 1.13.1-2), libasan5:armhf (8.2.0-9+rpi1, 8.2.0-12+rpi1), libxcb-render0:armhf (1.13.1-1, 1.13.1-2), isc-dhcp-common:armhf (4.3.5-4+rpi1, 4.4.1-2), binutils-arm-linux-gnueabihf:armhf (2.31.1-10+rpi1, 2.31.1-11+rpi1), libudev1:armhf (239-13+rpi1, 239-15+rpi1), rsyslog:armhf (8.38.0-1+b1, 8.40.0-1), mariadb-server-10.1:armhf (1:10.1.37-1, 1:10.1.37-3), php7.3-common:armhf (7.3.0~rc4-1+b2, 7.3.0-2), libgcc1:armhf (1:8.2.0-9+rpi1, 1:8.2.0-12+rpi1), mount:armhf (2.32.1-0.1, 2.33-0.2), libperl5.28:armhf (5.28.1-1, 5.28.1-3), python3.6-minimal:armhf (3.6.7-1, 3.6.8~rc1-1), libgcc-8-dev:armhf (8.2.0-9+rpi1, 8.2.0-12+rpi1), libblkid1:armhf (2.32.1-0.1, 2.33-0.2), libc-l10n:armhf (2.27-8+rpi1, 2.28-2), php7.3-opcache:armhf (7.3.0~rc4-1+b2, 7.3.0-2), python3-minimal:armhf (3.6.7-1, 3.7.1-2), libc-bin:armhf (2.27-8+rpi1, 2.28-2), libubsan1:armhf (8.2.0-9+rpi1, 8.2.0-12+rpi1), libpangocairo-1.0-0:armhf (1.42.4-4, 1.42.4-5), php7.3-bz2:armhf (7.3.0~rc4-1+b2, 7.3.0-2), g+±8:armhf (8.2.0-9+rpi1, 8.2.0-12+rpi1), libxcb1:armhf (1.13.1-1, 1.13.1-2), php7.3-cli:armhf (7.3.0~rc4-1+b2, 7.3.0-2), libnih1:armhf (1.0.3-10+b9, 1.0.3-10+b11), libpython3-stdlib:armhf (3.6.7-1, 3.7.1-2), systemd-sysv:armhf (239-13+rpi1, 239-15+rpi1), libuuid1:armhf (2.32.1-0.1, 2.33-0.2), gcc-8:armhf (8.2.0-9+rpi1, 8.2.0-12+rpi1), libpam-systemd:armhf (239-13+rpi1, 239-15+rpi1), systemd:armhf (239-13+rpi1, 239-15+rpi1), libgomp1:armhf (8.2.0-9+rpi1, 8.2.0-12+rpi1), libsmartcols1:armhf (2.32.1-0.1, 2.33-0.2), rfkill:armhf (2.32.1-0.1, 2.33-0.2), libpolkit-backend-1-0:armhf (0.105-22, 0.105-23), libhogweed4:armhf (3.4-1, 3.4.1~rc1-1), mariadb-client-10.1:armhf (1:10.1.37-1, 1:10.1.37-3), libnss-systemd:armhf (239-13+rpi1, 239-15+rpi1), bsdutils:armhf (1:2.32.1-0.1, 1:2.33-0.2), binutils-common:armhf (2.31.1-10+rpi1, 2.31.1-11+rpi1), libasound2:armhf (1.1.7-1, 1.1.7-2), mariadb-client-core-10.1:armhf (1:10.1.37-1, 1:10.1.37-3), libnettle6:armhf (3.4-1, 3.4.1~rc1-1), policykit-1:armhf (0.105-22, 0.105-23), libmariadbclient18:armhf (1:10.1.37-1, 1:10.1.37-3), libc-dev-bin:armhf (2.27-8+rpi1, 2.28-2), libbinutils:armhf (2.31.1-10+rpi1, 2.31.1-11+rpi1), multiarch-support:armhf (2.27-8+rpi1, 2.28-2), libnss3:armhf (2:3.40-1, 2:3.41-1), libedit2:armhf (3.1-20180525-1, 3.1-20181209-1), perl:armhf (5.28.1-1, 5.28.1-3), libcryptsetup12:armhf (2:2.0.5-2, 2:2.0.6-1), libatomic1:armhf (8.2.0-9+rpi1, 8.2.0-12+rpi1), libcc1-0:armhf (8.2.0-9+rpi1, 8.2.0-12+rpi1), libstdc++6:armhf (8.2.0-9+rpi1, 8.2.0-12+rpi1), libpango-1.0-0:armhf (1.42.4-4, 1.42.4-5), isc-dhcp-client:armhf (4.3.5-4+rpi1, 4.4.1-2), libapache2-mod-php7.3:armhf (7.3.0~rc4-1+b2, 7.3.0-2), libstdc+±8-dev:armhf (8.2.0-9+rpi1, 8.2.0-12+rpi1)
End-Date: 2018-12-19 18:41:01

Start-Date: 2018-12-19 19:01:51
Commandline: apt autoremove
Requested-By: boss (1002)
Remove: python3.6:armhf (3.6.8~rc1-1), python3.6-minimal:armhf (3.6.8~rc1-1)
End-Date: 2018-12-19 19:01:56

Edit: pour mémoire, l’erreur est :

The original message was received at Mon, 24 Dec 2018 06:05:02 +0100
from boss@raspberry

----- The following addresses had permanent fatal errors -----
dawn
(reason: 553 5.1.8 boss@raspberry… Domain of sender address boss@raspberry does not exist)
(expanded from: boss)

----- Transcript of session follows -----
… while talking to [127.0.0.1]:

DATA
<<< 553 5.1.8 boss@raspberry… Domain of sender address boss@raspberry does not exist
550 5.1.1 boss… User unknown
<<< 503 5.0.0 Need RCPT (recipient)

6

Bon, je reprend…

De ce que je vois, il n’y a aucun paquet relatif aux mails de mis à jour. C’est peut être une librairie qui à un impact ? Mais je n’y croit pas de trop.
Es-tu sûr de n’avoir rien modifié entre le moment où ça fonctionnait et pas ? Même un tout petit fichier coincé dans un coin ?

A l’installation de Raspbian, les mails utilisateurs (dont root) ne sont pas configurés, par conséquent, une configuration à été mise en place. Il faut reprendre la conf mail (hors PHP).

En désespoir de cause essayer d’ajouter une entrée pour boss dans /etc/aliases? Faire une recherche sur le net pour voir la syntaxe.

A+

7

Ce jour-là, la seule action concrête que j’ai faite est cette mise à jour, suivi de l’autoremove.
Ensuite, j’ai fait un backup de ma carte SD.
Puis j’ai ajouté un disque dur USB pour lequel je n’ai même pas modifié le fstab, je n’ai fait qu’un mount.

J’avais déjà configuré des aliases, et c’est d’ailleurs grâce à ça que ça fonctionnait. Car avant d’avoir créé ce fichier, je n’avais simplement aucun mail lié à mes tâches cron, ce qui est d’ailleurs normal, à quelle adresse me les aurait-il envoyé ?

La modification que j’avais faite de /etc/aliases était toute simple, sous la forme de « boss mail@domaine.com » (avec un simple espace entre les 2). Ce fichier ne faisait donc qu’une seule ligne, et ça fonctionnait.

Dans la mesure où je reçois les mails de Mailer Daemon sur cette même adresse, et que c’est le seul emplacement où je l’ai écrit, je pense que ce fichier est encore utilisé.

Ceci dit, j’ai fait effectivement des recherches sur l’utilisation et la syntaxe de ce fichier (en imaginant que la syntaxe n’est pas si simple), et je l’ai modifié récemment en y ajoutant 2 points après le pseudo (donc « boss: mail@domaine.com ») ainsi que tout un tas de pseudo comme postmaster, mailer-daemon, nobody, hostname, etc… qui eux, ne pointent pas vers un mail mais vers « boss ».
Et donc, la ligne de « boss » à la fin du fichier avec le mail pour tous.

Cette action n’a absolument rien changé… :frowning:

Et moi aussi, l’étude des paquet mit à jour ne m’a mené à rien… :frowning:

Bref, je crois bien qu’il ne me restera plus qu’a récupérer une ancienne backup de ma SD, et tenter de faire les mises à jour des paquet 1 à 1…
Je testerai probablement ça dans le courant du mois de janvier, à moins que d’ici-là quelqu’un ici puisse me donner une autre solution :slight_smile:

8

De mémoire, je crois me souvenir qu’un jour j’avais vu que ce fichier était lu à l’envers.
Essayer de mettre la dernière ligne en première position.

A+

9

J’ai essayé de mettre l’adresse mail en haut du fichier, hélas cela ne change rien…

Je n’ai pas encore testé de reprendre un backup, mais je sens qu’il va vraiment falloir.

Ceci dit, en regardant bien le message d’erreur « Domain of sender address boss@raspberry does not exist » c’est peut-être une modification dans la configuration des DNS, non ?

Je vais creuser un peu de ce côté…

et au passage : BONNE ANNÉE 2019 ! :tada:

10

Bon, alors j’ai essayé de reprendre une vieille backup de ma SD pour revenir avant cette mise à jour.
J’ai donc restauré une backup du 1er novembre (alors que la màj qui me pose problème date du 19 décembre…).
Tout démarre bien, forcement. Je me suis fait un petit crontab qui affiche un message toutes les 5min, pour vérifier le fameux bug : et je reçois bien ce message. Sachant que mon /etc/aliases est de la forme que j’ai défini de base, c’est à dire « nom mail » sur une seule ligne.

Ainsi, pour confirmer que le problème vient bien d’une mise à jour : j’ai lancé la fameuse requète « apt update » et me voilà avec 374 paquets à mettre à jour.
Je lance directement le « apt upgrade », persuadé qu’après cette commande, je ne recevoir plus que des mails de MailerDaemon toutes les 5 min…

Mais non !

Là, le apt upgrade se termine par une magistrale erreur :

dpkg: unrecoverable fatal error, aborting:
loading files list file for package ‹ fakeroot ›: cannot read /var/lib/dpkg/info/fakeroot.list (Erreur d’entrée/sortie)
E: Sub-process /usr/bin/dpkg returned an error code (2)
W: Problème de suppression du lien /var/cache/apt/pkgcache.bin - pkgDPkgPM::Go (30: Système de fichiers accessible en lecture seulement)

Suite à ce vilain message, je me retrouve avec la main, mais n’importe quelle commande (même LS) me donne le message « Bash: erreur d’entrée/sortie ».

Dégouté, je fais un hard reset, et mon petit Raspberry reboot tranquille.

Insistant, je relance un apt update et upgrade, et là : les 374 paquets se mettent bien à jour. :face_with_raised_eyebrow:
et Pire : je reçois toujours les mails de root@raspberry sans aucune erreur ! :astonished:

Moralité, le problème vient probablement d’un paquet que j’ai installé entre le 1 novembre, et le 19 décembre.

Donc, soit je vais poursuivre mon enquête, soit je vais repartir de ma backup du 1er novembre sur laquelle il faut que je refasse toutes les modifications que j’ai faites sur mon site… Je me tâte encore sur le chemin à prendre.

Mais, une chose est sûre : désormais je ferais des backup avant CHAQUE apt upgrade.
Lesson learned.

11

Bonjour,

Sage décision. Pour ma part, je ne suis pas fan des mises à jour systématiques et trop fréquentes.
De préférence utiliser la version stable à la testing ou unstable pour des Raspbian ou Linux Debian qui ne sont pas de machines développement.

A+

12

C’est justement une machine qui me sert à développer :wink:
Et j’aime bien garder tout à jour…

De plus, c’est confirmé, mon problème n’était visiblement pas lié à une mise à jour, puisqu’en reprenant une vieille backup, et en mettant à nouveau tout à jour : je n’ai plus ce problème.
Il y a peut-être eu un bug pendant l’update que je pensais responsable, ou ma mémoire me joue des tours et j’ai fait des actions problématique entre temps…

Quoi qu’il en soit, j’ai donc récupéré une sauvegarde, remis mes scripts et programmes à jour, puis tous les paquets (ce fut long et fastidieux) mais tout fonctionne à nouveau impeccablement.

Malgré que la solution de ce bug n’ait pas été découverte, je passe ce sujet en [Résolu]

Ceci dit, cette petite aventure m’a permis de constater un fait impressionnant :
Les cartes SDHC PNY 32Go sont plus grandes que les cartes SDHC Sandisk de 32Go !
J’utilisais depuis toujours une Sandisk, et j’ai acquis une PNY pour bidouiller ma vieille sauvegarde. Maintenant que tout fonctionne, je constate que je ne peux pas écrire un backup de la PNY sur la Sandisk à cause d’un manque de place…
Bon, c’est ballot mais pas bien grave. J’ai vu l’astuce de rpi.clone, je testerai un de ces 4.

Bref, merci Jelopo pour ton soutiens dans cette aventure :smiley: