Salut et bienvenue dans ce nouvel épisode du podcast.
Je suis Nicolas Bondin Bernhard, je suis fondateur de Code Garage.
Code Garage, qu'est-ce que c'est ? C'est une plateforme de formation pour tous et toutes
les devs qui veulent se former pour moins de 20 euros par mois sur énormément de sujets
et accessibles à tout le monde.
Aujourd'hui, c'est un petit podcast de rentrée et on va faire un format un petit peu différent
d'habitude.
J'ai fait des interviews sur le podcast, j'ai fait aussi un petit peu de la vulgarisation,
on va dire.
Et aujourd'hui, je vais vous raconter une histoire.
C'est pas une histoire qui m'est arrivée, c'est une histoire que j'ai trouvé sur
le net et que j'ai trouvé vraiment qui m'a vachement interpellée et que j'ai trouvé
super intéressante.
Je l'avais partagé sur le blog, ça vous avait beaucoup plu donc je vous la fais en
version audio.
Cette histoire, c'est tout simplement l'histoire d'un email plutôt de plusieurs emails qui
étaient limités à 800 kilomètres de distance.
Cette histoire, elle commence avec Tray Harris.
Tray Harris, il est tout simplement administrateur système et il s'occupe spécifiquement des
serveurs mails d'une université aux États-Unis.
Et donc, c'est une histoire qui lui est arrivée il y a quelques années, je ne sais pas exactement
l'année puisqu'il a publié ça en 2002 mais il y a quelques années auparavant.
Tout commence avec un coup de fil qui reçoit du président du département de statistiques
de l'université et qui lui dit « nous avons un problème pour envoyer des emails en dehors
du département de statistiques ». Tray il demande « quel est le problème exactement
» et le président lui dit « c'est simple, on ne peut pas envoyer d'email à plus de
500 miles ». 500 miles ça fait à peu près 800 kilomètres.
Et là, évidemment Tray Harris est plus ou moins étouffé avec son café et en fait
le président lui dit « c'est simple, on ne peut pas envoyer d'email à plus de 500
miles d'ici ». En réalité, on a calculé un petit peu et c'est 520 miles mais pas plus
loin.
Et là, évidemment, la première chose qui vient à l'esprit de Tray Harris est que
les emails ne fonctionnent pas comme ça et surtout il essaie de ne pas faire paniquer
le président du département parce que ça n'a aucun sens et en même temps s'il y a un problème,
il faut quand même le résoudre.
Donc, il lui demande « qu'est-ce qui vous fait penser qu'on ne peut pas envoyer d'email à
plus de 500 miles ». Et l'autre lui répond « en fait j'ai essayé il y a quelques jours,
quelques jours c'est déjà énorme sans pouvoir envoyer d'email où on veut ». Surtout pour
un président du département de l'université.
Et donc, en fait, il lui dit « j'ai essayé d'envoyer des emails à plusieurs personnes,
à plein de personnes différentes habitant dans des villes différentes, etc. et j'ai
récupéré des coordonnées GPS et j'ai fait des calculs de distance ». C'est logique,
c'est le président des statistiques après tout.
Donc, ils ont demandé à des géostatisticiens d'y jeter un œil et ils ont généré une
carte qui montre le rayon à l'intérieur duquel ils pouvaient envoyer les emails et
ils savairaient qu'effectivement ça faisait légèrement plus de 500 miles de rayons.
Et en fait, ils arrivaient à envoyer toutes les adresses à l'intérieur du rayon et
aucune à l'extérieur.
Et donc là, Tréarys, il se demande un petit peu ce qui a pu se passer entre le moment
où il y a plusieurs jours où c'était encore possible de le faire et ce moment-là.
Et donc, il réfléchit et il sait qu'il y a le consultant qui est venu qui a patché
le serveur de mail et qui l'a relancé.
Mais non, pas le serveur de mail, le serveur global plutôt, mais en appelant le consultant,
il découvre qu'a priori le consultant n'a pas changé au système, au serveur d'email
spécifiquement.
Donc, il dit au président « Bah écoutez, laissez-moi jeter un œil et je vous rappelle
plus tard ». C'est pas le 1er avril, mais il croit quand même un petit peu une blague
et c'est vrai que l'intitulé, on va dire, du problème fait croire à une blague.
Donc, il se connecte sur le serveur du département, il envoie quelques emails de test et en fait,
il arrive à s'envoyer un email à son compte perso et il a envoyé à Richmond, Atlanta,
Washington, etc.
Et même jusqu'à Princeton, Princeton qui a 400 miles de l'université de la Hulais.
Mais dès qu'il essaye effectivement d'envoyer un mail à un fils qui a 600 miles,
Saichou, Boston, Saichou, Détroit, Saichou.
Du coup, il sort son carnet d'adresse pour commencer un petit peu à trier les villes
et les gens qui connaissent.
New York, ça marche, ça fait 420 miles, Providence 580 miles, Saichou.
Donc là, il croit un peu devenir fou.
Il essaie d'envoyer un email à un ami qui vit en Caroline du Nord, mais dont le fournisseur
de d'email est à Seattle.
Et Saichou, donc ça continue de confirmer son truc parce que si le problème était lié
à la localisation géographique du destinataire et pas de son serveur d'email, il raconte
qu'il aurait vraiment fondu en larmes ce qu'il peut s'expliquer.
Donc, a priori, il a un bug qui est vrai répétable et donc il commence à les fouiner
tout simplement dans la configuration du serveur d'email.
Alors là, tout à l'heure plutôt normal, en fait tout à l'heure exactement comme d'habitude.
Quand il compare avec le fichier sendmail.sef de config de son répertoire local de test
et celui qui emprode, c'est exactement le même.
Il n'avait même pas été modifié.
Et il raconte même qu'il a bien vérifié qu'il n'y ait pas une configuration qui s'appelle
spécifiquement ne pas envoyer d'email à plus de 500 miles, c'est qu'il était effectivement
qui n'existait pas évidemment et qu'il n'avait pas activé.
Et donc, il se connecte tout simplement sur le serveur SMTP et là, il se rend compte
qu'il reçoit donc une bannière son OS à l'époque.
Et en fait, quand il voit la page d'accueil, il se rend compte que son à l'époque
déployait donc ce qui s'appelle leur serveur de mail s'appelait sendmail, il déployait
toujours sendmail 5 avec le système d'exploitation, même si à l'époque ils étaient déjà
à sendmail 8.
Et en fait, en tant qu'administrateur système, il avait fait la mise à jour de tous les
serveurs, il avait standardisé sendmail 8.
Et donc, il avait écrit un fichier de config qui utilisait des noms de variables longs
et intuitifs comme il dit disponibles dans sendmail 8 parce qu'apparemment les confirations
de sendmail 5 étaient vraiment assez cryptiques et pas évidentes.
Et donc, quand il a remarqué que le consultant qui avait patché le serveur avait rétrogradé
sans le faire exprès, évidemment, la version de sendmail puisque il avait mis à jour ce
noeud, ce qui était encore fourni avec la version 5 de l'outil.
Et donc, la mise à jour avait laissé le même fichier de config sendmail, mais il était
déjà en désormais chargé par la mauvaise version du logiciel en lui-même.
Et donc, il pouvait fonctionner avec un fichier de config, mais la plupart des règles en fait
étaient tout simplement traités comme des anomalies et ignorées.
Et donc, tout simplement, les configurations qui étaient ignorées étaient initialisées
à zéro et un des paramètres qui avaient été mis à zéro, c'était le temps d'attente
maximale pour se connecter au serveur SMTP distant.
Et après quelques expérimentations, il découvre qu'avec cette machine en particulier avec
sa charge normale, un temps d'attente à zéro, ça annuleraient la connexion au bout
de 3 millisecondes.
Et une particularité un peu étrange du réseau de son campus, il explique, c'était
qu'il fonctionnait à 100% sur des switches et qu'un paquet sortant, un paquet TCP sortant,
induirait un délai routeur qu'après avoir atteint le POP, le point de connexion, point
d'accès à internet, il touchait un routeur de l'autre côté.
Donc, le délai pour se connecter à un autre distant peu chargé sur un réseau proche
était, en gros, il dit globalement gouverné par la distance parcourue à la vitesse de
la lumière jusqu'à destination plutôt que par des délai routeurs parce qu'il n'y
avait pas de routeurs, c'était que des switches.
Et donc, il a commencé à faire son petit calcul où en fait, il a fait 3 millisecondes
à la vitesse de la lumière, il convertit ça en miles et ça donne tout simplement
558 miles, 94,719.
Donc 500 miles ou un petit peu plus.
Voilà, j'ai trouvé cette histoire assez simple et en même temps assez folle, c'est-à-dire
que je n'aurais vraiment pas aimé me retrouver dans la peau de très arrises qui a dû résoudre
ça.
Et voilà, je voulais vous la partager parce que ça raconte bien un petit peu ce qui
est notre quotidien en tant que développeur et développeuse ou administrateur système
DevOps, peu importe.
Mais l'outil informatique est censé répondre à nos besoins et répondre à exactement
ce qu'on lui demande de faire.
Mais en réalité, une petite configuration, une valeur par défaut, peu importe, ça peut
changer énormément de choses et surtout avoir des conséquences qu'on ne comprend absolument
pas.
Voilà, donc la morale de cette histoire, c'est ne vous énervez jamais contre un ordinateur,
relisez vos fichiers de config et regardez ce qui a changé depuis la dernière fois.
Merci d'avoir écouté cet épisode.
Il a été un petit peu différent d'habitude, j'espère qu'il vous a quand même plus.
Moi, je vous dis à la prochaine pour la semaine prochaine, même pour le prochain épisode.
Et n'hésitez pas à laisser cinq étoiles ou un commentaire ou peu importe sur la plateforme
vous écoutez ce podcast.
Et moi, je vous dis à la semaine prochaine.
Ciao !