Journal Comment j'ai foutu en l'air une partie de notre prod (et comment on l'a remise sur pieds)

Posté par  . Licence CC By‑SA.
Étiquettes :
56
20
jan.
2023

Nal',

J'ai fait de la merde.

#rm -rf /etc /dev

Normalement la plupart d'entre vous a déjà compris ce que je viens de faire, se tire les cheveux et se demande comment j'ai pu faire ça. Je vais détailler…

1/ 16h42 - Jusqu'ici, tout va bien…

Je suis chargé, entre autres choses, d'aller nettoyer quelques répertoires SFTP chroot contenant des répertoires usr, lib, lib64, etc, dev.

Je me place dans mes répertoires SFTP chroot et je lance 

#rm -rf /etc /dev lib lib64 usr

A ce moment, je ne m'en suis pas encore rendu compte…

2/ 17h05 - Y a-t-il une intervention sur la machine ?

Je perds toutes mes sessions SSH. Je demande s'il y a une intervention sur la machine. On m'informe qu'elle semble être foutue en l'air. Ca lâche un "Qui a fait un rm -rf /* ?" pour plaisanter. Je rigole également et je ne percute toujours pas.

3/ 17h43 - Le coupable est démasqué

Un rapide check sur le bash history via iDRAC et le coupable est démasqué. Ca vient de ma session. Je ne comprends toujours pas. Puis on me montre la commande fatale… OK j'ai compris…

4/ 17h45 - Vive les backups

On a des backups quotidiens, heureusement. Seulement on ne peut pas monter /dev et /etc du backup parce qu'on boot sur une debian-free et on est sur une debian non-free… On les récupère en .tar.gz et on les redépose au bon endroit. On arrive à accéder en ssh à la machine, les voyants repassent au vert. Ouf…

5/ 19h25 - Plus de honte que de mal

Au final j'ai seulement perdu une petite partie de mon travail (quelques SFTP crées, des mises à jour sur l'expiration de quelques mots de passe), fait perdre du temps à quelques intervenants et surtout pris une grosse honte… On m'a rassuré sur le fait que "ça arrive". J'ai beaucoup apprécié l'attitude des supérieurs qui ont simplement cherché à comprendre comment c'est arrivé sans jamais me jeter la pierre. Je me la jette tout seul.

6/ Il fallait que ça arrive

Je suis toute la journée en root sur la prod… Oui vous avez bien lu. Pourquoi ? Parce que l'installation d'une grosse partie de notre production est installée et fonctionnelle en root… J'ai alerté dès le premier jour de ma prise de fonctions sur ce problème et qu'un jour, quelqu'un fera de la merde.

Ce jour est arrivé et c'est moi qui ai fait de la merde.

Je suis encore mort de honte.

Des dispositions seront sans doute prises prochainement pour que cela ne puisse plus se produire. Un mal pour un bien ? Sans doute… Finalement, le plus grave, c'est mon sentiment de honte. Maintenant je vais me mettre en boule dans me lit pour le reste du week-end.

  • # Savoir écrire

    Posté par  . Évalué à 5. 

    #rm -rf /etc /dec lib lib64 usr

    Devrait être :

    #rm -rf /etc /dev lib lib64 usr

    Je perds toutes mes session SSH

    Je perds toutes mes sessions SSH

    un debian-free

    une debian-free

    La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.

  • # blameless postmortem

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 20 janvier 2023 à 22:54.

    Je suggère de documenter.

    https://sre.google/sre-book/postmortem-culture/
    https://sre.google/workbook/postmortem-culture/
    https://sre.google/sre-book/example-postmortem/

    Après l'astuce c'est de refaire la même « erreur » toutes les semaines jusqu'à ce que le problème soit corrigé. Au niveau suivant tu déclenche tous les problèmes possibles et imaginables jusqu'à ce que le processus d'analyse d'incident soit bien huilé.

    De mon expérience les meilleurs sysadmins sont ceux qui cassent plein de trucs et analysent comment c'est arrivé.

    #hugops

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # il y a un proverbe qui dit grosso modo

    Posté par  . Évalué à 10. Dernière modification le 21 janvier 2023 à 00:00.

    Il existe 2 sortes d'admin : ceux qui ont fait une connerie en root, et ceux qui vont en faire une.

    On m'a rassuré sur le fait que "ça arrive". J'ai beaucoup apprécié l'attitude des supérieurs qui ont simplement cherché à comprendre comment c'est arrivé sans jamais me jeter la pierre. Je me la jette tout seul.

    Bah oui, le pire dans ce cas la c'est de blamer les gens, qui chercheront à cacher la prochaine fois qu'ils feront une erreur. Puis les sauvegardes, ça sert aussi à ça: a ratrapper ses conneries … Enfin, le plus important ce n'est pas de faire ou de ne pas faire d'erreur, mais c'est l'attitude que l'on a ensuite : soit on sait réparer et on répare, soit on ne sait pas réparer mais on ne reste pas passif, au moins on cherche à aider pour réparer (ou on suit pour pouvoir réparer soi-même la prochaine fois).

    Une de mes premieres conneries a été de faire en root un cp /dev/null en pensant que ma commande allait mettre mon fichier à la poubelle. Aujourd'hui j'en ris …. mais a l'époque, j'ai eu le même sentiment de honte. On aurait pu s'en rendre compte longtemps après, lorsque les redirections vers /dev/null auraient rempli le filesystem / de la machine sur laquelle on a fait ça, mais par chance, on avait un script d'alerting qui faisait un cat /dev/null et qui ne marchait plus comme prévu et générait des faux positifs. Quand l'admin qui a détecté et corrigé le problème a communiqué son constat, et a cherché à comprendre pourquoi, j'ai tilté et dit tout de suite que c'était moi (il a ralé un peu mais sans plus). Si on avait pas détecté le problème rapidement, je pense que jamais je n'aurais su que c'était moi qui avait fait de la merde, et j'aurait peut-être refait plusieurs fois l'erreur avant de la comprendre.

    • [^] # Re: il y a un proverbe qui dit grosso modo

      Posté par  . Évalué à 4.

      Si on avait pas détecté le problème rapidement, je pense que jamais je n'aurais su que c'était moi qui avait fait de la merde, et j'aurait peut-être refait plusieurs fois l'erreur avant de la comprendre.

      Si tu la faisais suffisamment régulièrement, il n'y aurait pas de problème d'espace disque

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: il y a un proverbe qui dit grosso modo

      Posté par  . Évalué à 5.

      [mode béotien ON]

      Une de mes premieres conneries a été de faire en root un cp /dev/null en pensant que ma commande allait mettre mon fichier à la poubelle.

      Comprends pas : ça ne déclenche pas une erreur de syntaxe ? Il n'y a pas de destination pour la copie de /dev/null et je n'ai pas vu dans la doc de cp qu'il y a une valeur par défaut.

      [mode béotien OFF]

      • [^] # Re: il y a un proverbe qui dit grosso modo

        Posté par  . Évalué à 10. Dernière modification le 21 janvier 2023 à 12:07.

        Il dit cp /dev/null mais je pense que totof2000 a lancé une commande de la forme

        cp fichier /dev/null

        Et du coup, ça remplace /dev/null par une copie du fichier donné en premier paramètre de cp. Et du coup /dev/null devient un fichier normal comme les autre, au lieu du fichier périphérique spécial "trou noir" qu'on connait.

        Il n'y a pas d'erreur de syntaxe, parce que /dev/null est un nom de fichier tout à fait valide.

  • # Pas le seul à rester en boule ce week-end

    Posté par  . Évalué à 10. Dernière modification le 21 janvier 2023 à 00:23.

    Aujourd'hui, j'ai envoyé à plein de personnes un courriel avec un fichier en pièce jointe. Sauf que je n'ai pas envoyé le bon fichier mais un autre fichier qui était dans le même dossier : un fichier déchiffré qui contenait tous les identifiants et mots de passe des serveurs web. Heureusement, j'ai relu le courriel envoyé et je m'en suis aperçu. Il a fallu changer les mots de passe des utilisateurs et des bases de données. La honte totale.

    • [^] # Re: Pas le seul à rester en boule ce week-end

      Posté par  (site web personnel) . Évalué à 10.

      J'espère que le postmortem contient un plan pour se débarrasser de l'utilisation de mots de passes partagés. C'est le système qui est pourri, pas l'opérateur.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # c'est pour ca que

    Posté par  . Évalué à 8.

    • on backup
    • on réplique
    • on redonde
    • on monitore

    et on teste les backup

    • backup qu'on réplique
    • qu'on redonde
    • qu'on monitore

    ceph + borg

    • [^] # Re: c'est pour ca que

      Posté par  (site web personnel) . Évalué à 7.

      Et dont on teste la restauration avant d'en avoir besoin.

      Adhérer à l'April, ça vous tente ?

    • [^] # Re: c'est pour ca que

      Posté par  (Mastodon) . Évalué à 6.

      Et on s'assure d'avoir les credentials et la doc dans un endroit safe (et si possible en lecture seule et/ou air-gaped) pour pouvoir s'y apouyer s'il faut remonter un système de backup de zero pour pouvoir restaurer les données hébergées sur un autre site.

      • [^] # Re: c'est pour ca que

        Posté par  . Évalué à 3. Dernière modification le 22 janvier 2023 à 12:19.

        Ah oui, j'étais content le 14 juillet, serveur de documentation en carafe, personne à la hotline… Depuis j'en fais régulièrement un export HTML en local…

      • [^] # Re: c'est pour ca que

        Posté par  (site web personnel) . Évalué à 10.

        La procédure de démarrage des serveurs … sur papier dans la salle serveur

        Parce que la doc de démarrage des serveurs en PDF dans le serveur de fichiers … c'est pas utile si l'infra est éteinte :)

  • # Expérience et postmortem

    Posté par  (site web personnel) . Évalué à 10.

    L'important est l'expérience retirée et l'amélioration va le post mortel.

    Un jour j'ai fait un UPDATE users SET password sur la base de prod de linuxfr.org et j'ai oublié le WHERE user_id.

    Un jour j'ai déplacé /usr/lib dans un autre système de fichiers plus grand.

    Un jour j'ai validé une merge request de supervision, qui était en alerte par défaut pour cause de mauvais seuil, et le collègue l'a déployé séquentiellement sur 5 plateformes sans sourciller, 5 alertes en parallèle, 2 prod touchées.

    Un jour j'ai déployé sur la mauvaise plate-forme.

    Un jour on a oublié de renouveler le certificat de LinuxFr.org

    …

    Ça fait partie du taf quand tu gères des machines, il y aura des erreurs… l'expérience et les postmortems définissent les seuils des différents cas : celles qui sont empêchées, celles qui arrivent c'est chiant mais on s'en sort, et celles qui sont fatales ("oh le datacenter brûle et je n'ai rien ailleurs").

    • [^] # Re: Expérience et postmortem

      Posté par  . Évalué à 10.

      Un jour, un script qui faisait :

      BASE_PATH=$1

find ${BASE_PATH}/ -mtime 7 -delete

      Je me souviens plus de la syntaxe de mtime, mais le but était de supprimer les fichiers de plus 7 jours. Et bien sûr, un jour, on l'a lancé sans argument. En root. Ça a supprimé '/'.

      Solution : set -u en début de script qui traite les variables non existantes comme des erreurs.

      En tout cas, on a un tableau de « Succès » qui recense toutes ses boulettes. Ça fait partie du travail :)

      • [^] # Re: Expérience et postmortem

        Posté par  (site web personnel) . Évalué à 4.

        Pas mal
        J'avais connu un script qui archivais des fichiers dans un répertoire 'arch'
        qui créait le répertoire arch au cas ou il n'existait … que du classique pour un shell script

        par contre ce script fonctionnait sur le répertoire courant, et un type du support a eu l'idée de le lancer depuis la racine '/' car il ne savait pas ce que faisait ce script, et en étant 'root'

        => une restauration a tout corrigé, avec AIX (Unix d'IBM) pas mal de choses sont prévues pour ce genre de problème.

        Morale :
        ne pas lancer des scripts sans les regarder, encore moins quand on est root
        quand on ne sait pas, on ne touche pas … surtout sur une machine de PROD en exploitation

    • [^] # Re: Expérience et postmortem

      Posté par  . Évalué à 10.

      Un jour j'ai fait un UPDATE users SET password sur la base de prod de linuxfr.org et j'ai oublié le WHERE user_id.

      Un jour, j'ai fait quasiment la même chose dans une CMDB qui servait de source à un DNS. J'ai attribué la même IP à des milliers de noms de serveurs.

      La requête contenait un where 2012 (ce qui donne un Vrai) au lieu de where id_serveur=2012.

      Ma procédure, écrite 15 jours avant l'opération de maintenance, et testée sur une base de test, a été revue par mes collègues, et par un comité de contrôle (revue de changement). Personne n'a détecté le problème avant que je voie mysql répondre qu'il avait modifié plusieurs milliers de lignes au lieu d'une seule. Bien sûr, je n'avais pas fait de transaction. On a rollback avant que le cron d'update du DNS de prod ne passe, mais j'ai mis des heures à m'en remettre.

      Bref, ça arrive, c'est très désagréable, mais ça fait clairement partie du métier.

      Les seuls qui ne font pas de conneries sont ceux qui ne font rien !

    • [^] # Re: Expérience et postmortem

      Posté par  (Mastodon) . Évalué à 4.

      Un jour j'ai fait un UPDATE users SET password sur la base de prod de linuxfr.org et j'ai oublié le WHERE user_id.

      Vu dans la vie réelle, joué il y a longtemps par un chef-de-projet qui voulait se la péter w4rl0rd sans passer par l'interface web ad-hoc :

      UPDATE yusers SET phonenumber = '06XXXXXXXX';

      plus de 90.000 utilisateurs avec le même numéro de téléphone, bonjour la panique :)

    • [^] # Re: Expérience et postmortem

      Posté par  . Évalué à 6.

      L'important est l'expérience retirée et l'amélioration va le post mortel.

      Je ne te donnerais jamais mon adresse.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # J'ai fait mieux ...

    Posté par  . Évalué à 3. Dernière modification le 21 janvier 2023 à 17:20.

    Sur mon PC personnel, je me croyais dans un répertoire dont je devais supprimer le contenu, mais en fait j'étais sous /.

    Je tape :
    # rm -rf *

    L'avantage, c'est que l'on s'aperçoit immédiatement que l'on vient de faire une immense connerie.

    Heureusement, je ne suis pas tombé de la dernière pluie et j'avais des sauvegardes de moins de 24 h.

    Mais j'ai tout de même dû faire une nouvelle installation et reprendre mes données à partir de la sauvegarde.

    Bref, une demi-journée de perdue.

    Depuis, je mets l'utilisateur, le nom de l'hôte, le numéro de console et le chemin d'accès dans l'invite de la ligne de commande :
    ab@BA1.P4-/u/voyages$
    cela minimise fortement le risque d'une catastrophe.

    • [^] # Re: J'ai fait mieux ...

      Posté par  . Évalué à 2. Dernière modification le 21 janvier 2023 à 18:24.

      Les couleurs ça aide aussi.

      Moi la dernière connerie du genre que j'ai fais était un peu original (sur machine perso). Je pensais être dans un chroot et :

      chown -R "${id qui n existe pas}:${id qui n existe pas}" /

      …

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # 1er erreur

    Posté par  . Évalué à 10.

    Je ne connais pas tes horaires, mais pour moi la première erreur fut de faire ce type d'opération un vendredi à 16h42.

  • # Quel rapport free/non-free

    Posté par  (site web personnel) . Évalué à 6.

    Yep, ça arrive.

    Juste un truc qui me perplexifie dans cette histoire:

    On a des backups quotidiens, heureusement. Seulement on ne peut pas monter /dev et /etc du backup parce qu'on boot sur une debian-free et on est sur une debian non-free…
    On les récupère en .tar.gz et on les redépose au bon endroit. On arrive à accéder en ssh à la machine, les voyants repassent au vert. Ouf…

    Quel rapport entre les backups et debian-free/non-free qui sont des packets supplémentaires / firmware additionnels ?
    Le backup n'est pas accessible car la carte réseau utilise un firmware closed ? si c'est ça votre "rescue" devrait être ajusté pour inclure cette contrainte…

    Also "/dev/" est soit un dossier virtuel généré par udev, il suffit généralement de retrigger udev pour qu'il soit refresh:

    udevadm control --reload-rules
    udevadm trigger
    Mais apparement vous avez rebooter donc …

    Et si c'est un /dev statique il y a la commande MAKEDEV normalement, quoi qu'elle est généralement dans /dev ce qui pourrait poser un problème…

    • [^] # Re: Quel rapport free/non-free

      Posté par  . Évalué à 5.

      Ben tu le dis : driver réseau non libre (coucou bnx2) -> pas de réseau -> pas de restore.

      À mon travail les images de rescue PXE ont tous les drivers non-free inclus, comme ça on se pose pas trop la question.

      Tu as aussi le cas des serveurs en LACP/bonding, qui pose problème lors d'un boot de secours en PXE. Il faut alors recâbler ou supprimer temporairement l'agrégat sur le switch (existe aussi saveur tag de VLAN).

  • # Pareil pour moi y'a plus de 15 ans

    Posté par  (site web personnel) . Évalué à 5.

    Je venais d'arriver dans mon nouveau boulot, on me confie le role de copier le répertoire /etc de l'ancien serveur méga critique vers le nouveau. Je tente une première copie en locale mais y'a un problème (je ne sais plus quoi). Au lieu de faire rm -rf etc (ou ./etc) je fais rm -rf /etc. Contrairement à toi je m'en rends compte tout de suite, donc Ctrl-C immédiat. Mais le mal est déjà fait: une partie des fichiers est perdue.

    Contrairement à toi, pas de backup. On a passé plusieurs jours à tenter de récupérer des confs manquantes et à analyser ce qui était cassé.

    À ce moment là, grosse honte pour moi. Avec le recul, confier ça au petit nouveau, lui faire faire direct sur la machine sans préparation sur une machine de test, ne pas avoir de backups, … C'était pas moi qui avait le plus à me reprocher !

    • [^] # Re: Pareil pour moi y'a plus de 15 ans

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      Y a nouveau et nouveau :D J'ai déjà débarqué sur des missions où vous êtes carrément là en mode GIGN/pompiers/whatever donc pas vraiment des nouveaux mais les experts venus nettoyer et sauver la mise. Je sais, c'est tordu ; et même quand on y arrive en général on brûle des cierges parce-que tout s'est bien passé (et j'aime faire un post-vivantem pour tenter de trouver tout ce qui aurait pu foirer et qu'on n'a pas vu sur le coup et comment s'en prémunir les fois d'après.)

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # Dans le même genre

    Posté par  (site web personnel) . Évalué à 5.

    Dans ma boîte, un jour quelqu'un a lancé un chmod -x /usr/bin/* /usr/sbin/* sur tous les PC Linux de tous les utilisateurs via le logiciel de gestion de parc…

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.