Vous n'êtes pas identifié(e).
Exim me signale aussi dans les mails que je récupère un plantage :
Que l'on retrouve dans le log d'exim4 :
Je suis en Stable/backports pour l'essentiel, avec une version de libc6 intermédiaire entre stable et testing (j'en ai eu besoin pour faire passer xfce4 à gtk3, sinon Libreoffice merdait). Il n'y a pas eu de MAJ d'exim hier, seulement de ces paquets :
Le seul paquet qui évoque exim4, evolution-data... n'est pas lié à lui :
apt-listbugs ne remonte pas de bug en ce moment sur exim...
Une idée ? Voici ce que le bug laissait comme trace dans /var/log/boot (je n'utilise pas systemd, suis toujours avec le vieil init.d):
Var/log/boot en ce moment
Pour info,
auth.log, au moment du plantage :
auth.log en ce moment, sans plantage
Je précise qu'un disque crypté annoncé dans fstab se monte au démarrage avec une demande d'entrée de MdP (toujours sans libpam-systemd, donc)
Dernière modification par anonyme-15 (17-07-2020 14:01:17)
Il vaut mieux montrer que raconter.
Hors ligne
Cela ressemble simplement à l'envoi interactif d'un courriel au destinataire "Lille" avec la commande "mail" ou équivalent.
A la ligne "Subject:" tu tapes l'objet du mail puis entrée.
Ensuite tu tapes le corps du message, terminé par une ligne contenant seulement un point ".".
Puis divers champs comme "Cc:" (copie à).
De quel logiciel est-ce la syntaxe ? Exim, mutt ?
Il faut trouver quel script de démarrage exécute cette commande.
Je n'ai créé ou modifié manuellement aucun script cette semaine. Une autre question serait de savoir pourquoi un tel script se serait déclenché.
J'utilise fetchmail et mutt avec un autre utilisateur, pour lequel l'adresse LIlle est en clair dans les fichiers de config avec un mot de passe périmé, mais c'est aussi la seule a être désactivée alors que d'autres adresses actives et correctement renseignées s'y trouvent. Ce genre de point de départ hypothétique nécessiterait aussi l'acquisition de droits au démarrage qui ne sont normalement pas ouverts, et je ne crois pas au vu des logs que ça ait été le cas.
Je vais regarder de plus près les scripts dans /etc/init.d
De quel logiciel est-ce la syntaxe ? Exim, mutt ?
Plutôt un MUA comme mutt ou équivalent (mailx), je dirais. Exim ou un de ses alias comme sendmail n'affiche pas de prompt "subject:".
Si c'est la commande "mail" qui est exécutée, c'est un lien symbolique et tu peux voir quel est le vrai programme avec
Je n'ai créé ou modifié manuellement aucun script cette semaine. Une autre question serait de savoir pourquoi un tel script se serait déclenché.
Peut-être cet envoi de mail est conditionnel, et cette condition s'est réalisée.
'utilise fetchmail et mutt avec un autre utilisateur
Je ne pense pas que ce soit pertinent puisque la commande est exécutée par root en mode single.
Il vaut mieux montrer que raconter.
Hors ligne
Je vais regarder de plus près les scripts dans /etc/init.d
Dans /etc/init.d, pas de modification via les dates, les droits des fichiers qui concernent exim n'ont pas été modifiés.
Dans les dossiers de /etc/... muttrc et exim, pas de modification.
Dans les fichiers hors dossiers de /etc, resolv.conf a été modifié, mais ne comprend que les adresses des serveurs DNS de numéricable, ld.so.cache modifé également.
Dernière modification par raleur (18-07-2020 10:59:17)
Il vaut mieux montrer que raconter.
Hors ligne
Autant de lignes que de connections à des points wifi différents d'une fac où je devais rentrer cette adresse pour me connecter, adresse qui a changé depuis (de lille3 à lille tout court). Je n'ai rien reçu de louche, spam ou autre sur cette boîte cette semaine non plus.
Avec "Lille", rien à part des commentaires faits par moi dans un script qui me sert à bloquer ou débloquer des ip pour avoir éventuellement la paix avec des mails.
Ce qui est curieux, c'est que l'adresse vers laquelle le mail local était dirigée comporte une majuscule à Lille, que l'adresse "réelle" ne comprend pas (xxx@y-lille3). L'adresse avec une majuscule n'apparaît dans /etc que dans ce commentaire de script (script où l'adresse mail complète n'apparaît pas mais seulement l'IP du serveur de mail). L'adresse locale qui a planté selon le panic.log d'Exim est :
Le seul script où apparaît Lille3 avec une majuscule a les bons droits, et le contenu partiel suivant :
Rien d'étrange à mes yeux avec une recherche de "mail"
Dernière modification par anonyme-15 (18-07-2020 11:44:14)
J'ai vérifié le fetchmail.rc appartenant à un autre compte utilisateur qui comprend les adresses mails et les mots de passe, situé dans un autre dossier, "Lille3" ou "lille3" n'y figure pas, seulement "lille".
Ca serait donc bien au niveau du fichier /etc/init.d/connex_net que ça se passe.
Il vaut mieux montrer que raconter.
Hors ligne
PS : pour /etc/aliases, je viens de me renseigner un peu, je suppose que la dernière ligne correspond à ce qui permet l'envoi des infos sur les mises à jour faites par cron-apt à une adresse locale au nom de stef alors que les adresses d'envoyeur et de récepteur de ces mails sont root@estivale.home. J'ai dû faire ce réglage là via la config d'exim4 sans savoir que ça modifiait /etc/aliases.
Dernière modification par anonyme-15 (19-07-2020 10:38:04)
L'adresse dans le mail est Lille3@estivale.home.
Pourtant l'adresse mentionnée dans le mail d'erreur que tu cites dans ton message #1 est Lille@estivale.home.
C'est après le changement de mac que le bug se produisait, avec le curseur.
Se produisait ? Il ne se produit plus ? As-tu changé quelque chose ?
Enfin, ce script en cas de démarrage single user se déclenche juste après la demande de mot de passe root ou ctrl+D.
Après la saisie du mot de passe root ?
C'est pour ça que l'hypothèse la plus probante pour l'instant est un parcours foireux du fichier /etc/init.d/connex_net.
J'ai du mal à y croire car je ne vois pas comment une ligne commençant par # pourrait être interprétée autrement que comme un commentaire. J'allais ajouter que "Mail" n'est pas "mail" mais en vérifiant je découvre que la commande "Mail" existe aussi ! Mais si le problème se produit toujours, il suffit de modifier ce commentaire pour en avoir le coeur net.
PS : la première ligne du script (#!) ne devrait contenir qu'un seul #.
Il vaut mieux montrer que raconter.
Hors ligne
Le "plantage" au démarrage a eu lieu le 17 juillet matin, toujours à la suite du déclenchement journalier des tâches de cron.
J'avais écarté evolution-data-server-common du problème parce qu'il n'était pas lié à exim et que je ne ai pas, actuellement, evolution d'installé.
Mais j'ai eu evolution d'installé, non seulement par défaut sur ma machine avec xfce4 avant de le virer, mais aussi à mes débuts sous Debian il y a une dizaine d'années où j'utilisais Gnome2. J'utilisais certes Thunderbird, pas Evolution, mais tout était lié par Gnome. Il n'est pas à exclure que j'ai alors validé une option d'import alors que l'adresse Lille3 était à cette époque valide. Un fichier de config lié à Evolution comprenant l'adresse pourrait toujours traîner dans mon home depuis.
Or la faille de sécu de evolution-data-server-common est la suivante d'après le change.log :
La fonction du paquet est la suivante :
Question : la correction de la faille n'aurait-elle pas entraînée le comportement étrange au démarrage et la resortie de cette vieille adresse ?
Je cherche dans les fichiers d'evolution ou dans les adressbook, mais je ne trouve rien, et surtout rien dans le /home.
ne renvoie qu'à des fichiers dans usr/share.
et
ne renvoie à aucun fichier de config dans home.
Dernière modification par anonyme-15 (19-07-2020 11:24:00)
Pourtant l'adresse mentionnée dans le mail d'erreur que tu cites dans ton message #1 est Lille@estivale.home.
C'est bien Lille3@estivale.home, j'ai dû vouloir modifier l'adresse pour ne pas la mettre sur le forum, ce qui n'était pas une bonne idée au vu de la suite...
Se produisait ? Il ne se produit plus ? As-tu changé quelque chose ?
Ne se produit plus depuis que j'ai récupéré les mails qui étaient dans la file d'attente d'exim.
Après la saisie du mot de passe root ?
Soit après un ctrl+D, soit après la saisie du mot de passe root si je modifie ce fichier au démarrage, ce que je fais assez souvent (journellement).
J'ai du mal à y croire car je ne vois pas comment une ligne commençant par # pourrait être interprétée autrement que comme un commentaire.
Oui, je ne vois pas comment le parcours du fichier par un humain ou une machine pourrait faire une telle erreur.
Je viens de voir ton post #4 d'hier qui m'avais échappé. La commande pour identifier le programme de mail renvoie :
Que penses-tu de l'autre possibilité, plus probable bien qu'elle aussi incomplète, liée à evolution-data-server (post #12) ?
Dernière modification par anonyme-15 (19-07-2020 11:39:18)
Soit après un ctrl+D
Donc dans la suite de l'initialisation du système.
soit après la saisie du mot de passe root
Donc lors du lancement du shell de secours, ce qui semble contradictoire avec ce qui précède.
si je modifie ce fichier au démarrage, ce que je fais assez souvent (journellement).
Quel fichier ?
Que penses-tu de l'autre possibilité, plus probable bien qu'elle aussi incomplète, liée à evolution-data-server (post #12) ?
Je ne connais pas evolution. Mais tu peux au moins exécuter
pour vérifier que ce qui se passe correspond à ce que tu as observé.
Il vaut mieux montrer que raconter.
Hors ligne
Anonyme-15 a écrit :
Soit après un ctrl+D
Donc dans la suite de l'initialisation du système.
Anonyme-15 a écrit :
soit après la saisie du mot de passe root
Donc lors du lancement du shell de secours, ce qui semble contradictoire avec ce qui précède.
En effet, le ctrl+D est toujours nécessaire, qu'il y eut intervention avec le compte root ou pas.
Anonyme-15 a écrit :
si je modifie ce fichier au démarrage, ce que je fais assez souvent (journellement).
Quel fichier ?
/etc/init.d/connex_net, le script qui comprend la ligne #Mail Lille3
Anonyme-15 a écrit :
Que penses-tu de l'autre possibilité, plus probable bien qu'elle aussi incomplète, liée à evolution-data-server (post #12) ?
Je ne connais pas evolution
Moi non plus, je ne m'en suis jamais servi, et si je l'ai ouvert pour voir, c'était il y a des années. Evolution-data-server se trouve sur mon système à cause d'abiword, et je n'en ai pas d'autre paquet. C'est à cause de la MAJ de sécu et de mon problème que je m'y suis intéressé.
Mais tu peux au moins exécuter mail Lille3
pour vérifier que ce qui se passe correspond à ce que tu as observé.
Ca correspond au niveau de l'invite de rédaction, pas forcément au niveau des moyens d'en sortir. ctrl+c deux fois suffit, ce qui n'était pas le cas avec le "bug" (ou alors c'était plus lent à la détente). J'ai essayé avec le compte user et le compte root, il n'y a aucun mail en attente dans /var/mail/stef. Peut-être étais-je allé sans le savoir jusqu'au bout de la rédaction et de l'envoi lors du bug, sans le savoir, mais ça m'étonnerait.
raleur a écrit :
Mais tu peux au moins exécuter mail Lille3
pour vérifier que ce qui se passe correspond à ce que tu as observé.
Ca correspond au niveau de l'invite de rédaction, pas forcément au niveau des moyens d'en sortir. ctrl+c deux fois suffit, ce qui n'était pas le cas avec le "bug" (ou alors c'était plus lent à la détente). J'ai essayé avec le compte user et le compte root, il n'y a aucun mail en attente dans /var/mail/stef. Peut-être étais-je allé sans le savoir jusqu'au bout de la rédaction et de l'envoi lors du bug, sans le savoir, mais ça m'étonnerait.
Deux fichiers dead.letter sont apparus dans le dossier /home/user et /root, dont le contenu correspond à ce que j'avais tapé.
Dans le cas du bug, ce que je tapais était transféré vers le service de mail local.