Howto déboguage Postfix Howto déboguage Postfix Ce document explique comment déboguer des éléments du système de messagerie Postfix lorsque le fonctionnement ne correspond pas à ce qui est attendu. Les méthodes varient de l'enregistrement volubile dans les journaux jusqu'à faire fonctionner un processus démon sous le contrôle d'un debugger ou d'un traceur d'appel.
On supposera ici que les fichiers de configuration de Postfix main.cf et master.cf sont stockés dans le répertoire /etc/postfix. Vous pouvez utiliser la commande "postconf config_directory" pour trouver l'emplacement actuel de ce répertoire sur votre machine.
Listées dans l'ordre de niveau d'investigation, les techniques de déboguage sont les suivantes :
Postfix enregistre tous les échec et succès de livraison dans un fichier journal. Ce fichier est généralement /var/log/maillog ou /var/log/mail ; le chemin exact est défini dans le fichier /etc/syslog.conf.
Lorsque Postfix ne reçoit ni n'envoie de message, la première chose à faire est de rechercher les erreurs qui indiquent un fonctionnement anormal de Postfix :
% egrep '(warning|error|fatal|panic):' /un/fichier/de/log | more
Note : les messages les plus importants apparaissent en DÉBUT de sortie. Les messages d'erreurs suivants sont moins intéressants.
La nature de chaque problème est indiquée comme suit :
"panic" indique un problème dans le logiciel lui-même que seul un programmeur peut régler. Postfix ne peut démarrer tant qu'il n'est pas fixé.
"fatal" résultat d'un fichier manquant, de permissions incorrectes, de pramètres incorrects dans les fichiers de configuration que vous pouvez résoudre. Postfix ne peut démarrer tant qu'il n'est pas fixé.
"error" rapporte une erreur fatale or non. Postfix ne peut démarrer tant qu'il n'est pas fixé.
"warning" indique une erreur non fatale. Ce sont des problèmes que vous pouvez ne pas être apte à régler (tels un serveur DNS fonctionnant mal quelque part sur le réseau) mais peut également indiquer une erreur de configuration locale qui peut devenir un problème ultérieurement.
Avec les version 2.1 et supérieures de Postfix, vous pouvez demander à Postfix de produire des rapports d'erreurs de livraison à des fins de déboguage. Ces rapports ne montrent pas seulement les adresses d'expédition/de destination après réécriture et substitutions d'alias ou transfert, ils montrent également des informations sur la livraison en boîte-aux-lettres à une commande non-Postfix, les réponses des serveurs SMTP distants, et ainsi de suite.
Postfix peut produire deux types de rapports de livraison à des fins de déboguage :
What-if: rapporte ce qui devrait arriver mais ne délivre pas le message. Ce mode opératoire est appelé avec :
$ /usr/sbin/sendmail -bv address... Le rapport sera envoyé à <votre nom de login>.
What happened: livre le message et rapporte les succès et/ou échecs y compris ceux des serveurs SMTP distants. Ce mode opératoire est appelé avec :
$ /usr/sbin/sendmail -v address... Le rapport sera envoyé à <votre nom de login>.
Ces rapports contiennent les informations générées par les agents de livraison de Postfix. Comme ces processus sont des démons et n'interagissent pas directement avec les utilisateurs, le résultat est envoyé par message à l'expéditeur du message de test. Le format de ces rapports est pratiquement identique à ceux des notifications ordinaires de non-livraison.
Un exemple détaillé de rapport de livraison est présenté au paragraphe debugging à la fin de la page ADDRESS_REWRITING_README.
Une faute courrante est d'activer la mise en cage chroot dans le fichier master.cf de Postfix sans suivre toutes les étapes de constitution de la cage chroot. Ceci entraîne un plantage des processus démons de Postfix du dans tous les cas à des fichiers manquants.
L'exemple ci-dessous montre un serveur SMTP configuré avec la mise en cage chroot désactivée :
/etc/postfix/master.cf:
# =============================================================
# service type private unpriv chroot wakeup maxproc command
# (yes) (yes) (yes) (never) (100)
# =============================================================
smtp inet n - n - - smtpd
Recherchez dans master.cf tous les processus qui n'ont pas la mise en cage chroot désactivée. Si vous en trouvez, faites une copie du fichier master.cf de Postfix et éditez l'entrée en question. Après avoir exécuté la commande "postfix reload", vérifiez si le problème a disparu.
Si c'est le cas, félicitations. Laisser Postfix tourner dans cette configuration est adéquate pour beaucoup de sites. Si vous préférez remettre le chroot, lisez la page BASIC_CONFIGURATION_README pour preparer la mise en cage chroot.
Dans /etc/postfix/main.cf, listez les noms de sites ou adresses dans le paramètre debug_peer_list. Par exemple, pour rendre le logiciel plus bavard pour les connexions sur la boucle locale :
/etc/postfix/main.cf:
debug_peer_list = 127.0.0.1
Vous pouvez indiquer plusieurs machines, domaines, adresses ou réseaux/masque. Pour rendre les changements effectifs immediatement, exécutez la commande "postfix reload".
Cet exemple utilise tcpdump. Pour enregistrer une conversation, vous devez indiquer un buffer assez grand avec l'option "-s" sinon, vous perdrez tout ou partie du contenu des paquets.
# tcpdump -w /nom/de/fichier -s 2000 host exemple.com and port 25
Lancez cette commande et tapez Ctrl-C pour arrêter. Pour voie les données, utilisez un visualisateur binaire, ethereal, or utilisez mon untilitaire tcpdumpx disponible à l'adresse ftp://ftp.porcupine.org/pub/debugging/.
Ajoutez une ou plusieurs options "-v" aux définitions des démons choisis dans /etc/postfix/master.cf et tapez "postfix reload". Ceci entraînera la journalisation de toute l'activité dans le démon syslog. Exemple :
/etc/postfix/master.cf:
smtp inet n - n - - smtpd -v
Rend le serveur SMTP de Postfix plus bavard. Pour diqgnostiquer les problèmes de réécriture d'adresses, on peut ajouter l'option "-v" au démon cleanup(8) et/ou trivial-rewrite(8), et pour les problèmes de livraison, on peut ajouter l'option "-v" au gestionnaire des files d'attente qmgr(8) ou oqmgr(8), ou aux agents de livraison lmtp(8), local(8), pipe(8), smtp(8), ou virtual(8).
Beaucoup de systèmes vous autorisent à inspecter manuellement un processus tournant avec un traceur d'appels système. Par exemple :
# trace -p process-id (SunOS 4) # strace -p process-id (Linux et beaucoup d'autres) # truss -p process-id (Solaris, FreeBSD) # ktrace -p process-id (generic 4.4BSD)
Encore plus d'informations peuvent être obtenues des appels de librairies. Exemples :
# ltrace -p process-id (Linux, également porté sur FreeBSD et BSD/OS) # sotruss -p process-id (Solaris)
Lisez la documentation de votre système pour plus de détails.
Tracer un processus tournant peut donner des informations sur ce qu'un processus tente de faire. Cette technique fournit le maximum d'informations que vous pouvez obtenir sans utiliser un programme debugger interactif comme décrit dans le dernier paragraphe.
Postfix peut attacher un traceur d'appels dès qu'un processus démon démarre. Les traceurs d'appel peuvent être utilisés dans plusieurs cas.
Traceurs d'appels système tels trace, truss, strace, ou ktrace. Ils montrent les communications entre les processus et le noyau.
Traceurs d'appels aux librairies tels sotruss et ltrace. Ils montrent les appels aux routines des librairies et donnent une meilleure idée de ce que fait un processus.
Ajoutez une option -D à la commande suspecte dans /etc/postfix/master.cf, Par exemple :
/etc/postfix/master.cf:
smtp inet n - n - - smtpd -D
Editez l'option debugger_command dans /etc/postfix/main.cf pour que Postfix invoque le traceur d'appel de votre choix, par exemple :
/etc/postfix/main.cf:
debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin;
(truss -p $process_id 2>&1 | logger -p mail.info) & sleep 5
Tapez "postfix reload" et observez les journaux.
Si vous avez un système X-Windows installé sur votre machine Postfix, alors un debugger interactif tel xxgdb peut être adapté.
Renseignez debugger_command dans /etc/postfix/main.cf pour qu'il invoque xxgdb :
/etc/postfix/main.cf:
debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
xxgdb $daemon_directory/$process_name $process_id & sleep 5
Assurez-vous que xxgdb est dans les chemins de recherche des commandes ($PATH), et exportez XAUTHORITY pour que le contrôle d'accès X fonctionne, Par exemple :
% setenv XAUTHORITY ~/.Xauthority (syntaxe csh) $ export XAUTHORITY=$HOME/.Xauthority (syntaxe sh)
Ajoutez une option -D à la définition du démon suspect dans /etc/postfix/master.cf, Par exemple :
/etc/postfix/master.cf:
smtp inet n - n - - smtpd -D
Arrêtez et redémarrez le système Postfix. Ceci est nécessaire pour que Postfix se lance avec les XAUTHORITY et DISPLAY appropriés.
Pendant que le démon suspect est démarré, une fenêtre du debugger apparaît et vous pouvez observer en détail ce qui se passe.
Si vous n'avez pas de X-Windows installed on the Postfix machine, ou si vous n'êtes pas familier avec les debuggers interactifs, vous pouvez essayer gdb en mode non interactif, et obtenir une trace de la pile d'appels lorsque le processus plante.
Renseignez debugger_command dans le fichier /etc/postfix/main.cf pour qu'il invoque le debugger gdb :
/etc/postfix/main.cf:
debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin; export PATH; (echo cont; echo
where; sleep 8640000) | gdb $daemon_directory/$process_name
$process_id 2>&1
>$config_directory/$process_name.$process_id.log & sleep 5
Ajoutez un option -D au démon suspect dans le fichier /etc/postfix/master.cf, par exemple :
/etc/postfix/master.cf:
smtp inet n - n - - smtpd -D
Tapez "postfix reload" pour activer les changement de configuration.
Pendant que le processus démon suspect est lancé, un fichier de sortie est créé nommé avec le nom du démon et son numéro de processus (par exemple, smtpd.12345.log). Lorsque le processus plante, une trace de la pile d'appel (avec sortie de la commande "where") est écrit dans ce fichier journal.
Parfois, le comportement apparent de Postfix ne semble pas correspondre au code source. Comment un programme peut-il dévier des instructions données par son auteur ? Il y a deux possibilités :
Le compilateur s'est trompé. Ceci arrive rarement.
La hardware s'est trompé. La machine a-t-elle assez de mémoire ECC ?
Dans les deux cas, le programme en fonctionnement n'est pas le programme supposé être exécuté donc tout peut arriver.
Il y a une troisième possibilité :
Des bugs dans le logiciel système (noyau ou librairies).
Les fuates relatives au Hardware ne se reproduisent pas exactement de la même manière après un redémarrage du système. Il y a peu que Postfix puisse faire sur un hardware défaillant. Assurez-vous d'utiliser du matériel qui peut détecter les erreurs de mémoire. Les systèmes critiques masquent le matériel réel.
Lorsqu'un compilateur fait une erreur, le problème peut être reproduit chaque fois que le programme résultat est lancé. Les erreurs du compilateur ont plus de chance d'arriver dans l'optimiseur de code. Si le problème est reproductible après les redémarrages, il peut être intéressant de recompiler Postfix en désactivant l'optimisation et d'observer la différence.
Pour recompiler Postfix en désactivant l'optimisation :
% make tidy % make makefiles OPT=
Ceci produit des Makefiles qui ne requierent pas l'optimisation.
Une fois les Makefiles créés, compilez le logiciel :
% make % su Password: # make install
Si le problème continue, il est tant de demander de l'aide à votre vendeur.
Les personnes inscrits sur la liste postfix-users@postfix.org sont d'une aide précieuse, en particulier si VOUS leur fournissez assez d'information. Souvenez-vous que ce sont des bénévoles et que leur temps est limité. Attention, il s'agit d'une liste de diffusion anglophone ! Si vous ne maîtrisez pas suffisament la langue de Shakespear, vous pouvez poser vos questions sur le groupe de news fr.comp.mail.serveur.
Lorsque vous rapportez un problème, assurez-vous d'inclure les informations suivantes.
Résumé du problème. S'il vous plait, n'envoyez pas seulement des logs sans explications ou ce que VOUS pensez disfonctionner.
Completez les messages d'erreur. Utilisez s'il vous plait le copier-coller ou utilisez une pièce jointe au lieu de réciter les informations de mémoire.
Journaux de Postfix logging. Lisez le texte du haut de la page DEBUG_README pour trouver les journaux. Ne frustrez pas les bénévoles en vous trompant de journaux.
Utilisez une adresse de test pour ne pas révéler votre véritable adresse mail ou des mots-de-passe.
Si vous ne pouvez pas utiliser une adresse de test, anonymisez les informations. Remplacez chaque lettre par un "A", chaque nombre par un "D" pour que les bénévoles puissent reconnaître les erreurs de syntaxe.
Sortie de "postconf -n". N'envoyez pas votre fichier main.cf ou plus de 400 lignes de sortie de postconf.
Utilisez plutôt la sortie de l'outil "postfinger".Il peut être trouvé sur http://ftp.wl0.org/SOURCES/postfinger.
Si le problème est relatif à SASL, incluez la sortie de l'outil saslfinger. Il est disponible sur http://postfix.state-of-mind.de/patrick.koetter/saslfinger/.
Si le problème concerne un encombrement des files d'attente, incluez la sortie de l'outil qshape, comme décrit à la page QSHAPE_README.
Si le problème est relatif au protocole (timeouts des connexions ou un serveur SMTP se plaignat des erreurs de syntaxe etc.), enregistrez une session avec tcpdump, comme décrit à la page DEBUG_README.
traduction par Xavier Guimard - Retour au menu