Tout Et Rien

De trey@sage.org Ven 29 Nov 2002 18:00:49 
Date : Dim 24 Nov 2002 21:03:02 -0500 (EST)
De : Trey Harris <trey@sage.org>
À : sage-members@sage.org
Objet : L’affaire des emails de 500 miles (était RE : [SAGE] Votre tâche impossible préférée ?)

Voici un problème qui *semblait* impossible… Je regrette presque de diffuser
cette histoire au grand public, car c’est une super histoire à raconter
autour d’un verre en conférence. :-) L’histoire est légèrement modifiée pour
protéger les coupables, éviter les détails non pertinents et ennuyeux, et
globalement rendre toute l’histoire plus distrayante.

Il y a quelques années, j’étais en charge du système d’emails du campus
quand le directeur du département de statistiques m’a appelé.

« Nous avons un problème quand nous essayons d’envoyer des mails hors du
département.

– Quel est le problème ? ai-je demandé.

– Nous ne pouvons pas envoyer d’emails à plus de 500 miles », a expliqué le
directeur.
Je me suis étouffé avec mon latte. « Pardon ?

– Nous ne pouvons pas envoyer d’email à plus de 500 miles d’ici, a-t-il répété.
Un peu plus, en fait. À peu près 520 miles. Mais pas plus loin.

– Euh… Les emails ne fonctionne vraiment pas comme ça, en général »,dis-je, en
essayant de contrôler la panique dans ma voie. On n’exprime pas de panique
quand on parle à un président de département, même d’un département
relativement défavorisé comme les statistiques. « Qu’est-ce qui vous fait penser
que vous ne pouvez pas envoyer d’emails à plus de 500 miles ?

– Ce n’est pas ce que je pense, a répondu le président avec irritation. Vous
voyez, quand nous avons remarqué ceci, il y a quelques jours -

– Vous avez attendu quelques JOURS ? l’ai-je interrompu, avec un tremblement
dans la voix. Vous n’avez pas pu envoyer d’emails tout ce temps ?

– Nous pouvions envoyer des mails. Juste pas à plus de -

– 500 miles, oui, ai-je fini à sa place. J’ai compris. Mais pourquoi vous n’avez
pas appelé plus tôt ?

– Eh bien, nous n’avions pas collecté assez de données pour être sûrs de ce qui
se passait jusqu’à maintenant. » C’est vrai. C’est le président du département
de statistiques. « En tout cas, j’ai demandé à une des géostatisticiennes de se
pencher sur la question...

– Géostatisticiennes…

– Oui, et elle a réalisé une carte qui montrait que la zone à l’intérieur de
laquelle nous pouvons envoyer des mails avait un rayon d’un peu plus de 500
miles. Il y a un certain nombre de destinations à l’intérieur de ce rayon que
nous ne pouvons pas joindre non plus, ou alors de façon sporadique, mais nous ne
pouvons pas envoyer de mails plus loin que ce rayon.

– Je vois », ai-je dit en prenant ma tête dans mes mains. « Ça a commencé
quand ? Vous m’avez dit il y a quelques jours, mais est-ce que quelque chose
dans votre système a changé à ce moment ?

– Eh bien, le consultant est venu, a patché notre serveur et l’a redémarré. Mais
je l’ai appelé, et il a dit qu’il n’avait pas touché au système de mails.

– Ok, je vais jeter un coup d’oeil et je vous rappelle », ai-je dit, en ayant du
mal à croire que je rentrais dans son jeu. On n’était pas le premier avril. J’ai
essayé de me souvenir si quelqu’un voulait se venger de moi avec ce genre de
blague.

Je me suis connecté au serveur de leur département et ai envoyé quelques mails
de test. C’était dans le Research Triangle de Caroline du Nord, et un mail de
test à mon propre compte a été délivré sans souci. Pareil pour un mail envoyé à
Richmond, et Atlanta, et Washington. Un autre à Princeton (400 miles)
fonctionnait.

Et puis j’ai essayé d’envoyer un mail à Memphis (600 miles). L’envoi a échoué.
Boston, échec. Detroit, échec. J’ai sorti mon carnet d’adresses et ai commencé à
essayer de préciser tout ça. New York (420 miles) fonctionnait, mais Providence
(580 miles) échouait.

Je commençais à me demander si j’avais perdu la tête. J’ai essayé d’envoyer un
mail à un ami qui vivait en Caroline du Nord, mais dont le FAI était à Seattle.
Heureusement, il a échoué. Si le problème était relatif à la position
géographique du destinataire humain et pas à son serveur mail, je pense que
j’aurais fondu en larmes.

Ayant établi que, de façon--incroyable--, le problème tel que décrit était réel,
et reproductible, j’ai ouvert le fichier sendmail.cf. Il avait l’air plutôt
normal. En fait, il me disait quelque chose.

Je l’ai comparé au sendmail.cf de mon répertoire home. Il n’avait pas été
modifié : c’était un sendmail.cf que j’avais écrit. Et j’étais à peu près sûr de
ne pas avoir activé l’option « FAIL_MAIL_OVER_500_MILES ». En dernier recours,
je me suis connecté en Telnet sur le port SMTP. Le serveur m’a gaiement répondu
avec une bannière de sendmail SunOS.

Attends… une bannière de sendmail SunOS ? À l’époque, Sun intégrait toujours
Sendmail 5 dans son système d’exploitation, même si Sendmail 8 était plutôt
mature. En bon administrateur système, j’utilisais Sendmail 8 en standard. Et
toujours en bon administrateur système, j’avais écrit un sendmail.cf qui
utilisait les jolies options et noms de variables longs et auto-documentés de
Sendmail 8 plutôt que les codes cryptiques en signes de ponctuation qui étaient
utilisés dans Sendmail 5.

Les pièces se sont mises en place d’un coup et je me suis à nouveau étouffé avec
le fond de mon latte maintenant froid. Quand le consultant avait « patché le
serveur », il avait apparemment upgradé la version de SunOS, et ce faisant avait
downgradé Sendmail. L’upgrade avait heureusement laissé tranquille le
sendmail.cf, même si c’était maintenant la mauvaise version.

Il s’avère que Sendmail 5, ou du moins la version livrée par Sun, qui avait
quelques modifications, pouvait gérer le sendmail.cf de Sendmail 8, vu que la
plupart des règles étaient restées telles quelles. Mais les nouvelles longues
options de configuration, il les avait vues comme inutiles et les avait
ignorées. Et le binaire sendmail n’avait pas d’options par défaut compilées pour
la plupart de ces options, donc, ne trouvant aucun paramètre adéquat dans le
fichier sendmail.cf, ils avaient été réglés à 0.

L’un des réglages qui avait été mis à zéro était le délai d’expiration pour se
connecter au serveur SMTP distant. Un peu d’expérimentation a permis d’établir
que sur cette machine en particulier avec sa charge habituelle, une expiration
de zéro mettrait fin à une tentative de connexion en un peu plus de trois
millisecondes.

Une particularité du réseau de notre campus à l’époque était qu’il était
intégralement commuté. Un paquet sortant ne rencontrerait aucun délai de routage
avant de tomber sur le POP et d’atteindre un routeur de l’autre côté. Donc le
temps de connexion à un hôte distant peu chargé sur un réseau proche serait en
réalité plus déterminé par la distance vers la destination parcourue à la
vitesse de la lumière que par des délais de routage.

Légèrement grisé, j’ai tapé dans ma console :

$ units
1311 units, 63 prefixes

You have: 3 millilightseconds
You want: miles
        * 558.84719
        / 0.0017893979

« 500 miles, ou un peu plus. »

Trey Harris
--
Je cherche du travail. Si vous avez besoin d’un SAGE de niveau IV avec 10 ans
d’expérience en Perl, développement d’outils, formation, et architecture,
écrivez-moi à trey@sage.org. Je suis prêt à me déplacer pour une opportunité
intéressante.