Mes meilleures anecdotes WTF de sysadmin Fraîchement sorti de l’école, j’ai commencé mon premier emploi en tant que prestataire dans un grand groupe Français. J’ai vu un certain nombre de trucs assez dingues lors de cette première expérience, et je pense que ça peut être intéressant de partager cela et d’essayer de comprendre comment on en est arrivé là. Préambule On a tous fait des erreurs à un moment ou un autre de notre carrière (et on continuera d’en faire), livré des produits avec des bugs, déployé des trucs à l’arrache en prod… Peut être parce qu’on a manqué de temps, mal compris le problème, ou bien qu’on ne maîtrisait pas assez les technologies employées. Et c’est pas grave. Avec le temps on monte en compétence, on se rend compte que ce qu’on a fait c’était finalement pas si bien que ça, on se remet en question et on travaille à l’amélioration du produit. Et ça ne sert à rien de ressasser ad vitam aeternam ces erreurs, ou de "troller" sur un blog ceux qui en font. Mais parfois, les mauvaises pratiques combinées à une inertie énorme, un non-soutien de la hiérarchie, la non prise au sérieux de cette derniere des personnes "sur le terrain", la politique… font que des entreprises peuvent se retrouver dans des situations ubuesques. Et faire comme si de rien n’était n’est pas non plus une solution. Cet article (qui est assez long) décrit les anecdotes techniques les plus hallucinantes que j’ai rencontré quand j’ai commencé à travailler. Tout se passe dans une seule entreprise. Je porte un toast virtuel à mes anciens collègues qui essayaient de lutter au quotidien pour améliorer les choses, et à mon premier chef qui a tout fait (dans la limite de ses moyens) pour améliorer la situation. On était peut être tous en bas de l’échelle hiérarchique, prestataires, sans aucun pouvoir de décision, mais grâce à beaucoup d’ingéniosité et une grosse capacité d’adaptation on arrivait quand même à faire tourner les trucs en prod, et assez miraculeusement ça continue de tourner aujourd’hui. Allez, c’est parti ! Mettre à jour Apache Comme dit précédemment, je sortais de l’école, motivé à bloc, je connais déjà pas mal la philosophie Devops, l’automatisation, des outils comme Ansible etc… Je me retrouve dans une petite équipe avec des collègues et un chef super, ladite équipe faisant partie d’un projet gigantesque (des centaines de personnes, que du prestataire venant de sociétés de services, turn over important, les rares "internes", non prestataires, sont les chefs. Vous voyez le genre). Dans cette équipe, on gère un système avec quelques applications Java, quelques services distribuées, le tout tournant sur des machines virtuelles (on y reviendra). La plupart des trucs sont déployés avec Ansible. Une de mes premières tâches est de mettre à jour Apache sur les machines, Mettre à jour Apache ? J’étais un peu comme ça à mon bureau, pensant que j’allais torcher ça vite fait bien fait quand on m’a demandé ça: Sauf que là on m’envoie de la documentation, et ça se passe pas comme prévu. Je reçois un pdf de 50 pages avec des instructions. Je dois télécharger un .tar.gz depuis un serveur FTP (wtf ?), je décompresse le machin et je vois plus de 10 000 lignes de script ksh (oui, 10 000, j’en rajoute pas. Vous savez, les scripts où en header il y a l’historique de qui a écrit quoi dedans), la doc disant que l’installation se fait en lançant les scripts dans un certain ordre. C’est là que je vois sur les serveurs des arborescences bizarres, comme /appli/projects, /logiciels, /var/projects, /log… Tout ça n’avait aucun sens. C’était mon premier contact avec ce qu’on appelait les souches. Des espèces de "packages" faits par une équipe dédiée à ça (qu’on avait interdiction de contacter d’ailleurs, pour des raisons obscures), validés par la sécurité. Obligé de passer par ça pour installer Apache. Toutes les applis des souches s’installaient dans l’arborescence louche décrite précédemment. Les scripts d’installation (qui étaient à moitié bugué) détruisaient votre machine en faisant des tonnes de trucs plus ou moins prévisibles (création de dossiers, changement de permissions, création d’utilisateurs et groupes, modification du sudoer…), c’était impossible à maintenir/automatiser… En conclusion, je n’ai jamais réussi à monter Apache de version. La tâche a été reprise par un collègue sénior quelques mois plus tard, qui a finalement réussi après d’énormes galères. De la même manière, Tomcat était packagé dans une iso (wtf ?), qu’il fallait monter sur la machine, puis modifier la configuration yum pour aller chercher un package dans cet iso, ledit package contenant "seulement" 5000 lignes de ksh. Bref, c’était un énorme problème au quotidien, et c’est dur de retranscrire à l’écrit l’horreur qu’était ces trucs et l’état des serveurs après l’installation. Les machines virtuelles et gestion de projets D’ailleurs, parlons en des machines virtuelles, gérées par de multiples équipes dans un autre bâtiment. Sans parler du fait que les performances étaient horribles (surallocation à fond, une fois un type voulait même couper notre prod car nos machines bossaient et donc consommaient du CPU), je peux vous dire que la machine virtuelle était une denrée rare. En début de projet (ou en cours de projet si il fallait plus de machines), toute une procédure devait être réalisée pour avoir du matériel. Il fallait en gros: Compléter un énorme jeux de slides (des dizaines) avec des informations sur le projet, le besoin, l’architecture technique, et pleins d’autres questions plus ou moins utiles. Prendre rendez-vous pour réunir un comité de "décideurs" (qui était ces gens n’a jamais été clair pour moi), mais définitivement pas des gens techniques. Organiser cette réunion était toute une histoire, cela se comptait en mois (donc pendant cette période, pas de machines). Présenter les slides devant ces gens. Attention, c’était des personnes très particulières qui étaient "habilités" à faire cette présentation, des "urbanistes" comme on disait. Bien que de bonnes volontés, ce n’était pas non plus des profils techniques, donc il fallait leur faire "réviser" les slides. On avait donc une réunion où une personne présentait quelque chose qu’elle ne comprenait pas à des gens qui ne comprenaient pas non plus le sujet. A la fin une décision était prise. Du genre "Non, on refuse de vous donner des machines virtuelles, bye" ou bien "OK vous pouvez y aller". Le résultat était complètement aléatoire, personne ne savait ce qui pouvait se passer même si certains disaient que certains mots clés sur certaines slides augmentaient les chances (écrire les slides pour maximiser ses chances était devenu une science). En cas de réponse positive, c’était la fête sur le projet. On savait qu’on allait pouvoir avoir des machines dans les mois à venir (oui, car ça mettait des mois à se faire "livrer"). En cas de réponse négative, il était possible de retenter sa chance au bout de quelques temps, et ça pouvait passer (mais en gros ça rajoutait un délai de fou, voir ça stoppait le projet). En conclusion: il fallait des mois et des mois pour avoir une machine virtuelle. Bien sûr, cela posait problème en cas de besoin urgent (besoin de rajouter un noeud sur un cluster). Des projets s’échangeaient parfois des machines virtuelles par exemple, pour dépanner. On a d’ailleurs un coup de chaud une fois où plusieurs de nos machines de prod qu’on nous avait "prêté" ont failli se faire décommissionner par des types de l’infra. Les machines virtuelles vivaient ensuite des années, il fallait pas espérer pouvoir les détruire ou reconstruire si besoin. Bizarrement, on avait des bécanes sous les bureaux plus puissantes que les serveurs de prod (du genre 12 à 24 CPU, 32 à 64 GB de ram), je vous laisse imaginer ce que des petits malins branchaient sur la prod quand il y avait des problèmes de perf. Rien de mieux pour faire disparaître du lag Kafka ! Déployer en prod C’est bien beau d’avoir des machines, encore faut-il pouvoir déployer dessus. La grande majorité des projets n’avaient pas d’accès (que ce soit SSH ou autre) à leurs propres serveurs, car c’était en théorie une autre équipe en dehors du projet qui devait déployer de cette manière: L’équipe projet envoie la procédure de déploiement à l’équipe qui a les accès (genre un pdf de 50 pages devant respecter certaines règles). L’équipe qui a les accès applique la procédure en copiant/collant les commandes. Heureusement, nous on avait le privilège d’être autorisé à faire du Ansible (lancé via Jenkins). Privilège qui était très rare. Sauf qu’on devait notamment déployer dans une zone où on avait accès à rien depuis les machines virtuelles, pour "raison de sécurité". Rien comme: Pas d’accès à des repository yum. Pas d’accès aux serveurs contenant les artefacts de build (Maven, Artifactory). Même pas un petit accès à un serveur HTTP où l’on aurait pû mettre des trucs. Et donc on, comme d’autres projets, devait déployer là dedans. Tout un système à base de tunnels SSH entre la machine cible et la machine Jenkins, qui elle même faisait tourner un proxy qui renvoyait vers les serveurs yum etc… avait été mis en place pour palier à cette limitation. Tout se lançait avant/durant le déploiement, ça a clairement sauvé pas mal de projets, qui n’auraient jamais pû être déployés sans cela. Debug la prod Et donc parfois il y avait des problèmes en prod. En théorie fallait aussi appeler une autre équipe externe au projet et leur dire quoi regarder/taper comme commandes etc… (comme vous pouvez l’imaginer, c’était pas les personnes les plus compétentes du monde). Bref, c’était impossible de travailler comme ça, il fallait des jours pour résoudre le moindre problème, et souvent ces équipes faisaient n’importe quoi. Toute une série de hacks "connus" pour accéder en douce à la prod, ou pour passer root sur les serveurs (exemple plus loin) se passaient de génération en génération sur les projets. On avait même des types qui débuggaient la prod en lançant des jobs Jenkins (qui lui avait le droit de se connecter aux serveurs via SSH) qui contenaient les commandes à exécuter sur les serveurs ! On avait parfois l’impression d’être les MacGyver de l’I.T. Il y avait comme une DSI parallèle qui s’était formée côté projet (car fallait bien avancer, jamais les projets n’auraient pû tenir les deadlines ou ne serait-ce que travailler). Migration RHEL 7 Une fois on demande à migrer nos machines virtuelles de RHEL 6 à RHEL 7. On était pas très exigeant, c’était OK pour détruire les anciennes machines et en redéployer des nouvelles. Cela a mis un an: Déjà fallait "valider" que RHEL 7 était "aux normes" de l’entreprise (pourquoi payer Red Hat dans ce cas ?), ce qui mettait déjà des mois voir années. Ensuite, une équipe devait créer la machine. Puis une équipe devait installer , genre un random outil "enterprise". Puis une autre équipe devait installer , genre outil de monitoring (je me rappelle plus du nom du truc, à côté Nagios c’était moderne, je crois que la boîte qui était derrière l’outil avait fermé il y a des années). Sauf que manque de bol, cet outil ne marche pas sur RHEL 7. Faut requalifier la distribution. Puis une autre équipe… Vous avez compris. Ouverture de ports A chaque nouvelle machine, à chaque nouvelle application déployée, il fallait envoyer un email à une équipe disant "stp ouvre la connexion entre les machines X et Y sur le port Z". Il fallait joindre au mail un document Excel incompréhensible indiquant quoi ouvrir. Cela mettait généralement plusieurs jours, et 50 % du temps le port n’était pas ouvert correctement (pourtant on nous disait "si si c’est ouvert" pendant quelques temps, avant qu’ils se rendent compte de l’erreur). Une fois, l’équipe réseau a sans raison apparente refusé des ouvertures de port. Ca a dû mettre deux mois avant d’être reglé, et il a fallu escalader le problème très très haut pour débloquer la situation. C’était aussi tout un cirque pour les load balancers (F5). A chaque fois qu’on ajoutait un noeud, il fallait aussi envoyer un formulaire Excel par mail, et la modification était faite "un jour". On a quand même réussi à tout remplacer par nos propres HAProxy au bout d’un moment, hourra. Certificats TLS Quand vous vouliez faire du TLS entre vos applications, il fallait des certificats qui devaient être générés par une équipe dédiée à ça. Il fallait là aussi envoyer un mail avec en pièce jointe un document Excel qui s’auto générait en plusieurs étapes. Attention, il fallait envoyer 1 mail par certificat, je me rappelle encore la rage de mon chef quand il a envoyé un mail pour 100 certificats et qu’on lui a répondu qu’il fallait faire 100 mails :D Sécurité Evidemment, tout cela était fait pour "la sécurité". Les souches, tous les trucs wtf, tout était "validé" par la sécurité et on ne pouvait rien y dire. Par exemple, les souches (dont Apache) créaient un utilisateur bien spécifique (pour lancer le process). Les script d’installation de la souche posaient aussi un script en "lecture+écriture+exécution". Chose intéressante, la souche modifiait aussi le fichiers sudoers pour permettre à ce script de se lancer en tant que root. Donc une des astuces pour passer root sur les machines quand on y était pas autorisé, mais qu’on avait accès à l’user Apache, était d’ajouter "bash" en début de script et de lancer "sudo