Sondage Oui j’avoue, ma plus grosse boulette c’est d’avoir :

Posté par . Licence CC by-sa.
Tags : aucun
11
27
juin
2018
  • Tapé une fois cette commande :~# rm -rf / :
    312
    (16.8 %)
  • Redémarré un serveur en production par erreur :
    380
    (20.5 %)
  • Brutalement éteint un serveur en débranchant le mauvais câble :
    142
    (7.7 %)
  • Perdu le réseau en modifiant une règle de pare-feu :
    376
    (20.3 %)
  • Bien sauvegardé et vérifié tous les jours mais pas la bonne cible :
    44
    (2.4 %)
  • Éteint la clim de la salle serveurs :
    19
    (1.0 %)
  • Briqué un routeur avec un mauvais firmware :
    57
    (3.1 %)
  • Renversé mon café (sucré) sur le clavier d’un client :
    52
    (2.8 %)
  • Fait à peu près toutes celles-là ou bien d’autres données en commentaire :
    472
    (25.5 %)

Total : 1854 votes

La liste des options proposées est volontairement limitée : tout l'intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix. Les réponses multiples sont interdites pour les mêmes raisons. Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées, ou de l'impossibilité de choisir plusieurs réponses. 76,78% des sondés estiment que ces sondages sont ineptes.
  • # Proxmox

    Posté par . Évalué à 7.

    Oui éteindre le serveur hôte Proxmox plutôt que la machine virtuelle…
    C'est vite fait

    • [^] # Re: Proxmox

      Posté par (page perso) . Évalué à 4.

      J'ai fait la même connerie, et ça va vachement lent le redémarrage surtout avec 100 utilisateurs qui attendent lol

      • [^] # Re: Proxmox

        Posté par . Évalué à 3.

        Je confirme, surtout quand le check des disques se déclenche….

      • [^] # Re: Proxmox

        Posté par (page perso) . Évalué à 6. Dernière modification le 28/06/18 à 22:15.

        surtout avec 100 utilisateurs qui attendent

        En général ce n'est pas le mot qui correspond à l'attitude de certains d'entre eux :-)

  • # rm -rf /

    Posté par . Évalué à 6.

    J'ai fais rapidement un script BASH ou l'argumant de "rm -rf" était $toto/$titi, sauf que le $toto comprenait une coquille dans le nom de la variable et $titi valait "*" ou ".". Bref le résultat ne s'est pas fait attendre car sous BASH une variable inexistante ne provoque pas d'erreur…

    • [^] # Re: rm -rf /

      Posté par (page perso) . Évalué à 7.

      sous BASH une variable inexistante ne provoque pas d'erreur…

      set -u
      

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: rm -rf /

      Posté par . Évalué à 10.

      Tu es développeur pour Steam sous Linux ?

    • [^] # Re: rm -rf /

      Posté par (page perso) . Évalué à 5. Dernière modification le 28/06/18 à 11:46.

      Bref le résultat ne s'est pas fait attendre car sous BASH une variable inexistante ne provoque pas d'erreur…

      Sauf si tu demandes gentiment:

      echo ${toto:?}/${titi:?}
      

      ou bien le set -u de Xavier Claude.

      • [^] # Re: rm -rf /

        Posté par . Évalué à 2. Dernière modification le 28/06/18 à 13:35.

        Je connaissait pas.

      • [^] # Re: rm -rf /

        Posté par (page perso) . Évalué à 4.

        set -u

        Vérifiera si la variable est déclarée mais ne vérifiera pas si la valeur de la variable est non nulle.

        #!/bin/bash
        set -u
        tata=
        echo ${tata}

        Sur ce genre de cas, il est préférable de tester au moins la taille de la valeur de la variable et idéalement tester sa valeur lorsque celle-ci peut être déterminée à l'avance.

        #!/bin/bash
        set -u
        tata=                                                                                                                                                                                          
        [ ${#tata} -gt 0 ] &&  echo "${tata}" || echo "erreur"

        Bon, j'ai l'air de me la péter mais j'ai déjà "rm -Rf" des répertoires importants par erreur.
        En fait j'ai déjà fais toutes les erreurs proposées sauf renverser mon café, briquer un routeur et éteindre la clim de la salle serveurs mais c'est très probablement dû au fait que je n'ai pas accès à cette clim ni jamais eu à flasher un routeur !

  • # Bricker un téléphone ça va si vite

    Posté par (page perso) . Évalué à 2.

    Supprimer le bootloader et le firmware d'un téléphone quand j'étais dans ADB… Ca va vite je vous jure. Bon c'est vraiment ridicule, mais c'était sur un vieux Galaxy S1 i9000 (j'adorais ce téléphone) qui était bloqué sous Android 2.3.6 (soit-disant parce qu'il n'avait pas les capacités de passer sous 4.0 alors que bien sûr que si…)

    • [^] # Re: Bricker un téléphone ça va si vite

      Posté par (page perso) . Évalué à 3.

      Ce n'est pas vraiment une boulette. C'est surtout dû aux contorsions nécessaires pour sortir du carcan des fabricants.

      J'ai eu quelques sueurs froides en rootant un Samsung-S4 :)

  • # terraform destroy

    Posté par (page perso) . Évalué à 3.

    Ca compte pour quoi un "terraform destroy" ?

    • [^] # Re: terraform destroy

      Posté par . Évalué à 1.

      Un jour j'ai mis un serveur en prod en commentaire dans un fichier de description de Terraform, et ce pour que la commande tf apply soit plus rapide. Bien entendu, pas de sauvegardes…

  • # liste non exhaustive

    Posté par . Évalué à 10.

    On pourrait ajouter :
    * inverser source et destination avec rsync --delete ou dd
    * taper mkfs au lieu de fsck

    • [^] # Re: liste non exhaustive

      Posté par . Évalué à 8.

      Avant d'aller me coucher, rsync dans mauvais sens (depuis le snapshot vieux de 2 mois vers la prod):
      + le backup "normal" a tourné pendant la nuit !

      1) vieux code => disparition des features (le logiciel évoluait régulièrement)
      2) les documents restaurés à une version antérieure !

      Réveil très brutal avec incompréhension totale de la part du client sur ce qui se passait (et retours d'utilisateurs).

      Pour le 1), facile git,

      Pour le 2), l'énorme stress:
      A. Enlever la possibilité aux utilisateurs de retravailler leurs offres (elles se baseraient potentiellement sur une version plus ancienne).
      B. Faire un programme qui extrait la dernière version du document en comparant dans l'historique du versionning sous AWS S3.
      C. Rétablir l'accès

      Mon pire début de journée, c'était cette année :-)

  • # Mauvaise cible

    Posté par . Évalué à 3.

    Mauvaise cible + loi de murphy = le client vient de terminer 6 mois de tests et paramétrages sur le nouvel environnement, mis en place à l'arrache par un chef de projet bien intentionné.

    Bien sûr les sauvegardes portaient sur "l'ancien nouvel environnement"… Crash d'un SSD en LVM stripping. SSD cryptés, irrécupérables…

    Cool, c'est une bonne occasion de tester des composants rarement mis à l'épreuve : l'assurance RC Pro et les contrats clients… (au final ça s'est pas trop mal terminé, mais quand on découvre que la sauvegarde n'est pas la bonne, on se sent trèèèès seul).

  • # Écraser les données + la sauvegarde

    Posté par (page perso) . Évalué à 8.

    À mes débuts avec Mandriva, j'avais sauvegardé les données de /home sur un disque externe avant une installation.

    N'ayant pas fait gaffe à l'installation, j'ai installé Mandriva sur le disque de sauvegarde (toujours branché). Mais bootant sur l'ancien système, je pensais que cela avait échoué.

    J'ai donc réinstallé, cette fois sur le disque interne. Mais je n'avais pas regardé l'état de la sauvegarde… Du coup j'ai tout perdu.

  • # chmod ...

    Posté par . Évalué à 6.

    Pour ma part ce fut un chmod -R 777 directement sur /
    La Solaris a tenu longtemps avant de montrer des signes de grosse déconne.

    • [^] # Re: chmod ...

      Posté par . Évalué à 8.

      Une variante : chown user:groupe /mondossier/.* avec le gros ".*" à la fin parce que je voulais aussi changer les droits des fichiers cachés. J'ai juste oublié que le dossier parent est "..". Moi ça n'a pas mis très longtemps avant de montrer des signes inquiétants.

      • [^] # Re: chmod ...

        Posté par . Évalué à 6. Dernière modification le 27/06/18 à 22:53.

        Autre variante : taper chown -R XXX au lieu de chmod -R XXX quand il existe un user ayant comme uid XXX.

  • # coreboot

    Posté par . Évalué à 3.

    n°1 (pas /, mais assez identique) & n°4 (le script de purge en cas d'inactivité : oublié): done

    Autre : une énième compil de coreboot en oubliant de connecter le secteur sur un pc avec une batterie presque vide : extinction du pc en pleine injection. Bim.

  • # Effacer accidentellement toutes les données de prod...

    Posté par . Évalué à 2.

    … en pensant que j'étais sur le serveur de dev… Heureusement, j'ai pu récupérer des backups !

  • # Erase partitions

    Posté par . Évalué à 4. Dernière modification le 27/06/18 à 15:28.

    Il y a longtemps dans une galaxy lointaine sur mon ancien laptop, j'essayais en vain d'installer Gentoo dans coin un du disque dur.
    J'avais dû recommencer plusieurs fois car cela échouait lamentablement pendant la compilation.
    À un moment j'ai cliqué sur "Erase partitions".

    Il y a un "s" dans "Partitions".

  • # Backups de BDD

    Posté par . Évalué à 1.

    Fais par un DBA a qui nous, développeurs, avions écrit une marche à suivre.

    Nous avions écrit : Écraser la base de recette avec un backup de la base de production.

    Le DBA a compris l'inverse.

    Cette opération ayant eu lieu vers midi, toutes les opérations de la matinée ont été perdues, le backup datant de la nuit.

    Pour chaque personne qui me plussoie, je frappe un fan de Justin Bieber.

  • # Écrasage de bios à l’arrache

    Posté par (page perso) . Évalué à 3.

    Sur une machine que je voulais utiliser comme serveur avec virtualisation, j'avais des plantages au démarrage sous proxmox.
    Je me suis rendu compte qu'elle n'avait aucun microcode dans le bios pour le processeur, et que sans, il y avait des problèmes sur les instructions de virtualisation.
    J'ai donc entrepris d'en rajouter un à la main.
    Après avoir sauvegardé le bios avec flashrom, je l'ai modifié et tenté la réinjection toujours avec flashrom.
    Je ne sais plus si ça s'était bien passé ou non, dans tous les cas, le pc ne démarrait plus.
    J'ai du dessouder l'eeprom et la sauvegarder et la flasher avec un petit montage et la ressouder.
    Il a démarré et avait son microcode injecté, il marche parfaitement 24h/24 depuis 8 ans.

    Autrement, j'ai aussi utilisé une mauvaise règle de firewall sur un serveur dédié.

    S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

    • [^] # Re: Écrasage de bios à l’arrache

      Posté par (page perso) . Évalué à 8. Dernière modification le 28/06/18 à 10:33.

      Je me souviens de la règle du firewall sur le serveur dédié.

      Je commençais mes tests pour les règles du firewall en les tapant à la main dans une session ssh, avant de les scripter.

      Donc tout d'abord, on bloque tout le trafic entrant avec iptables.
      2e règle, on ouvre le port ssh… pourquoi je n'ai plus la main… Ahhhhhh le con !!!

      S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

      • [^] # Re: Écrasage de bios à l’arrache

        Posté par (page perso) . Évalué à 3.

        La parade : un « chien de garde » dans un autre shell

        DELAI=180; while true; do test=""; read  -t $DELAI -p "pare-feu OK ? " test; if [[ $? -ne 0 ]]; then {
            for param in --flush --zero --delete-chain; do /sbin/iptables $param; done
            for table in $(cat /proc/net/ip_tables_names); do
                /sbin/iptables -t $table --flush
                /sbin/iptables -t $table --zero
                /sbin/iptables -t $table --delete-chain
            done
            for chain in INPUT FORWARD OUTPUT; do
                /sbin/iptables -P $chain ACCEPT
            done
        
            for param in --flush --zero --delete-chain; do /sbin/ip6tables $param; done
            for table in $(cat /proc/net/ip6_tables_names); do
                /sbin/ip6tables -t $table --flush
                /sbin/ip6tables -t $table --zero
                /sbin/ip6tables -t $table --delete-chain
            done
            for chain in INPUT FORWARD OUTPUT; do
                /sbin/ip6tables -P $chain ACCEPT
            done
        }; fi; done
  • # Liste non exhaustive

    Posté par (page perso) . Évalué à 10.

    • débranché le clavier d'un serveur SUN pour le brancher sur un autre (ça freeze le système et passe la main au bios avec un prompt… qui nécessite un clavier donc)
    • déplacé /lib/libc.so vers /usr/lib parce qu'il y a plus de place. Mais comme je flairais le piège, j'avais fait un mv && ln -s (indice: ça ne marche pas)
    • oublié de rebrancher un ventilateur de processeur
    • confondu mkfs et fsck
    • fait un rm<espace>*<espace>.o
    • pensé que ça marche au premier essai
    • oublié le --dry-run ou équivalent
    • lancé des opérations sur la mauvaise plateforme
    • estimé que cette migration de distribution irait vite et qu'on pouvait la lancer vite fait maintenant …

    Bref c'est important de tester, c'est important d'être en forme (ni crevé ni stressé ni …) pour ne pas faire n'importe quoi, et encore plus pour réparer ensuite. Un adminsys est un animal hyper dangereux.

    • [^] # Re: Liste non exhaustive

      Posté par (page perso) . Évalué à 10. Dernière modification le 27/06/18 à 18:36.

      c'est important d'être en forme (ni crevé ni stressé ni …)
      pour ne pas faire n'importe quoi,
      et encore plus pour réparer ensuite.

      (je me permets d'insister, avec les années on porrait croire que ça rentre, mais ça m'arrive encore d'oublier de dormir)

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: Liste non exhaustive

        Posté par (page perso) . Évalué à 10.

        j'ai oublié une super opération sur la prod LinuxFr : en SQL, un UPDATE accounts SET password='untruc' pour je ne sais plus quelle raison (fusion de deux comptes j'imagine). Beh faut voir ça positivement comme un test des sauvegardes.

        • [^] # Re: Liste non exhaustive

          Posté par . Évalué à 5.

          Oh ça m'est arrivé aussi ça (en prod également). Je commence à écrire un UPDATE SET <un truc super compliqué>, une fois fini je le relis 1 fois, 2 fois, 3 fois : ouais c'est bien le calcul que je veux faire. Et je lance l'exécution.

          Ca tourne. C'est bien long cette histoire. MERDE J'AI OUBLIE LE WHERE !

          Vive les sauvegardes, même si en pleine journée sur une base utilisée ça induit forcément un temps d'indisponibilité non négligeable…

      • [^] # Re: Liste non exhaustive

        Posté par (page perso) . Évalué à 7.

        pour ne pas faire n'importe quoi,
        et encore plus pour réparer ensuite.

        L'adrénaline aide bien aussi pour réparer.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Liste non exhaustive

          Posté par . Évalué à 5.

          L'adrénaline aide bien aussi pour réparer.

          Oh grave, on dégrise très très vite, et les neurones turbinent à plein régime !

          Yth :)

  • # Le chocolat chaud sur le bureau...

    Posté par (page perso) . Évalué à 10.

    Un vendredi vers 17 heures, le chocolat chaud renversé sur le bureau (et sur mes papiers qu'il y avait dessus). Je me lève pour aller chercher de l'essuie main aux toilettes, et découvre que mon écran est tout noir. Un rapide coup d’œil sous le bureau m'a permis de voir que le chocolat chaud avait coulé du bureau dans le bloc multiprise en dessous, donc tout avait disjoncté. Je sors dans le couloir pour me diriger vers les toilettes, et voit que tous les collègues sortent de leurs bureaux en demandant "que s'est-il passé?". En fait, tout l'étage avait disjoncté… Évidement, tous les collègues de l'informatique qui ont aussi les clefs pour remettre le courant étaient déjà partis en WE, donc nous sommes aussi partis en WE.

    Six mois plus tard, en discutant par hasard avec un collègue en charge de serveurs de prod, il me dit que le plus bizarre qui lui soit arrivé, c'est quelques mois auparavant, lorsque tout l’institut s'était retrouvé sans courant pour une cause inexpliquée, sans que le système ne parvienne à remettre le courant de lui-même et que la salle des serveurs avait appelée à l'aide car les onduleurs arrivaient au bout de leur capacité. J'ai pu fièrement lui annoncer que je connaissais la cause…

    Mathias
    PS: et depuis, j'ai compris à quoi servent les couvercles avec un trou pour mettre sur le mug.

  • # no boullette

    Posté par . Évalué à 6. Dernière modification le 27/06/18 à 19:02.

    Je n'ai pas su quoi répondre … Illustration du principe qui dit qu'il n'y a que ceux qui ne font rien qui ne font pas d'erreur !

    Guillaume

  • # FS de production monté en préprod

    Posté par . Évalué à 2. Dernière modification le 27/06/18 à 19:41.

    Une partition servie par GlusterFS plein de fichiers potentiellement intéressants laborieusement récolté au fil de cinq années (jeu de données).

    Mais la partition de production, avait été monté en préproduction.

    Ce n'était pas clair du tout et pour faire de la place sur le service Gluster (qui agonisait), j'ai décidé de supprimer ces fichiers de préprod…

    Bien sur, à l'époque, pas de sauvegarde de ces données là, et on ne s'est rendu compte de la boulette que trois mois après ! (quand quelqu'un à décider d'utiliser les fichiers et n'en a trouvé que quelques uns…)

    Bizarrement ça a motivé l'équipe à revoir les sauvegardes au plus vite…

  • # Formater le mauvais disque dur

    Posté par . Évalué à 1. Dernière modification le 27/06/18 à 20:27.

    Dans mes débuts sous Linux, quand les disques faisaient bien moins de 1To. j'ai confondu le disque qui contenait mes données avec celui où je voulais installer le système. => Environ 350 Go de données non sauvegardées et définitivement perdues. :((
    Plus récemment, j'ai cloné un disque cible sur la source et soigneusement écrasé ma partition système => plus qu'à tout réinstaller :(

    • [^] # Re: Formater le mauvais disque dur

      Posté par (page perso) . Évalué à 8.

      j'ai confondu le disque qui contenait mes données avec celui où je voulais installer le système

      C'est comme ça que j'ai appris le fonctionnement de photorec.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Formater le mauvais disque dur

      Posté par (page perso) . Évalué à 3.

      "Dans mes débuts sous Linux, quand les disques faisaient bien moins de 1To."

      Haha, à mes débuts sous Linux, les disques faisaient 20 Mo :) !

      (Et coûtaient la 1/2 du PC)

      "There's no such thing as can't. You always have a choice." - Ken Gor

      • [^] # Re: Formater le mauvais disque dur

        Posté par . Évalué à 1.

        A mon début il n'y avait que des disquettes.

        5"1/4, 360 kO

      • [^] # Re: Formater le mauvais disque dur

        Posté par (page perso) . Évalué à 1.

        à mes débuts sous Linux, les disques faisaient 20 Mo

        Linux est apparu en 1991.
        En 1991 les disques-durs grand public commençaient à 40 Mo (j'en avais un) et allaient au moins jusqu'à 200 Mo.

        Si tu as commencé à jouer avec Linux en 1991 tu avais donc un disque-dur d'une année antérieure. Mais il y a très peu de gens qui ont bricolé avec le pré-OS de cette époque.

        • [^] # Re: Formater le mauvais disque dur

          Posté par . Évalué à 2.

          les disques de 40 Mo étaient hors de prix, tout comme la mémoire d'ailleurs en 1991, l'étudiant fauché moyen fonctionnait encore en disquettes seules ou avec des disque pré-ide

          mes premières SLS et slackware c'était sur du disque MFM de 20 Mo à partir de disquettes 5p1/4 360 avec un 386 et 1,5 Mo de ram (grand luxe) pour faire tourner un kernel 0.9

          perso ma boulette c'est d'avoir branché un as/400 natif 110Volts sur le 220V…
          à l'install, donc moindre mal car pas de données et l'erreur venant d'ibm ils avaient pris en charge la casse (ouf!)
          mais une bonne suée vu le coût du matériel flingué

          • [^] # Re: Formater le mauvais disque dur

            Posté par (page perso) . Évalué à 1.

            les disques de 40 Mo étaient hors de prix, tout comme la mémoire d'ailleurs en 1991, l'étudiant fauché moyen fonctionnait encore en disquettes seules ou avec des disque pré-ide

            En 1991 un disque-dur IDE de 40 Mo coûtait 3000 francs (je viens de vérifier sur d'anciennes publicités). Le SMIC était à 5000 francs, c'est donc plus ou moins équivalent à 900 € actuels. Donc bien cher.

            J'étais justement étudiant particulièrement fauché (pas d'aides sociales, pas d'aides parentales), donc je suppose que mes petits boulots me rapportaient plus que ce que j'ai en mémoire. Sinon je n'aurais jamais pu acheter un 386SX16 avec 1 Mo de mémoire vive et 43 Mo de disque-dur (autour de 13000 francs, l'équivalent de 4000 € actuels).

  • # Flashé la carte mère avec le mauvais bios

    Posté par (page perso) . Évalué à 6.

    Une fois j'ai flashé la carte mère du PC portable de ma mère avec un mauvais BIOS. En même temps ils avaient mis deux BIOS dans le zip sans trop indiquer lequel est compatible avec quel PC…

    Résultat, retour au SAV pour changement de carte mère… (300 €). Et comme c'était le SAV ACER, et bien ils ont perdu le PC.

    Je n'ai plus jamais reflashé de BIOS depuis. Traumatisé.

  • # Copié les données de preprod dans la prod

    Posté par . Évalué à 10.

    Sous WIndows 2000 server, il y presque 20 ans, une copie des fichiers source (VB pas NET) des dev en prod (en fait, du quasi-dev) directement d'un dossier à l'autre. Astuce: sous windows, déplacer des fichiers à la souris depuis une dossier à l'autre fait une copie si c'est pas les même partition / disque / montage, mais un déplacement dans le cas contraire, avec PLEIN de fichiers en plus… Prod foirée, préprod foirée, pas de sauvegarde… pas de versionning… à poil ! Et le tout à 18H00 avec un rendez-vous important juste après: ça m'a coûté mon poste, mais j'ai pu partir en formation… Tous les jours je béni cette énorme boulette ! (le boulot était vraiment merdique)

    Depuis, je ne travaille plus que sous linux…

  • # mauvais backup

    Posté par (page perso) . Évalué à 6.

    il y a longtemps, un collègue met en place des backups sur bande.

    Impeccable.

    3 mois plus tard, un utilisateur demande la restauration d'un fichier détruit par mégarde.

    Le collègue ne trouve pas ce fichier dans le backup de la veille.
    Ni sur les backups des jours précédents…

    En fait il backupait un disque, rembobinait la bande au début, backupait un deuxième disque, rembobinait…

    Oui, seul le dernier disque était sauvegardé…

    Moralité, toujours tester une restoration

    Sinon, sur un site financier, on savait qu'une machine serveur de flux récemment mise en prod n'avait jamais été backupée. Je demande à un nouveau récemment arrivé dans l'équipe (qui savait soi-disant tout faire) de redémarrer à 19 h cette machine en minimum, et la backuper.
    Un peu plus tard, il vient me voir, il essayait d'écraser le disque système avec la bande, mais sa syntaxe n'était pas correcte…

    Multitasking — The art of doing twice as much as you should half as well as you could.

    • [^] # Re: mauvais backup

      Posté par . Évalué à 4.

      C'est super depuis que le dernier technicien est venu la sauvegarde sur bande qui mettait 2h est instantanée.
      Quelques semaines plus tard : comment ça j'aurai du le signaler ?

  • # Top 3

    Posté par (page perso) . Évalué à 5.

    • Un # dd avec le mauvais disque (celui de sauvegarde) comme destination
    • Un DROP CASCADE sur la BDD Prod (à la place d'un TRUNCATE (problème de GUI)
    • Redresser un connecteur tordu, sous tension, avec un objet métallique (la machine ne s'en est pas remise)
  • # Un virus belge

    Posté par (page perso) . Évalué à 10.

    Pour le coup j'étais vraiment petit (j'étais collègien au tout début des années 2000), mais je me suis vraiment senti très très con.

    Le principe du virus belge, c'est que c'est un virus fait par gens qui ne savent pas programmer et qui utilisent donc l'interface chaise-clavier comme interpréteur de commande. Concrètement j'avais reçu un mail, disant quelque chose comme :

    ATTENTION !!! Un virus est en train de se propager sur Internet !!! Pour vérifier si tu es contaminé, va dans tel dossier et regarde si tel fichier existe. Si c'est le cas, supprime le vite !!! Envoie ce mail à tous tes contacts !!! URGENT !!!

    Évidemment le fichier à supprimer était un fichier système très important. C'était sur l'ordinateur de travail de mon père. Le lendemain au boulot il est vraiment passé pour un couillon a devoir expliquer ce que son crétin de fils avait bien pu faire…

    • [^] # Re: Un virus belge

      Posté par (page perso) . Évalué à 2. Dernière modification le 28/06/18 à 22:42.

      Le pire c'est lorsque l'éditeur du logiciel de gestion de ta boîte fait parvenir ce type de virus Belge à ta direction.
      Là tu te dis qu'ils sont encore plus crétins que tu l'imaginais, parce que forcément ils t'ont fait subir bien d'autres épreuves du même genre avant.

  • # Redémarrage d'un service que j'aurais du laisser tout seul...

    Posté par (page perso) . Évalué à 3.

    Développeur sur une plateforme financière, le support vient me dire qu'une donnée n'a pas été mise à jour. Je leur propose de relancer le service adéquat, me disant qu'en 30 secondes ça sera revenu, et que tous les postes clients ayant les infos en cache, ça ne se sentira même pas. On relance, et puis ça met un peu plus longtemps que prévu à charger les données depuis la base…

    Derrière moi, j'entends monter le grondement sourd de la salle de marché, les traders commencent à parler de plus en plus fort, on entend des cris de "pourquoi mes ordres ne passent pas???".

    Le support re-route rapidement les ordres vers l'ancienne plateforme, et tout s'est remis à marcher (nous étions en Beta, et nous avions donc des solutions de secours), donc pas de conséquences, mais je me suis senti très bête.

  • # Les deux trucs dont j'ai le plus honte...

    Posté par . Évalué à 3.

    Sur un système financier, j'ai créé une boucle infernale en livrant un bugfix, qui est monté en production. Il a fallu bosser 3 jours et 3 nuits avec les ops pour corriger toutes les données et éviter tout impact pour les clients.

    Sur un autre système financier, j'ai voulu livrer en environnement dev une mise à jour du paramétrage de contrôle de position titres que j'étais en train de modifier. Je l'ai livré en production. J'ai mis 15 minutes à m'en rendre compte ; le contrôle de position n'a pas été très efficace ce jour-là, puisqu'il a fallu réinitialiser tout et attendre le jour suivant pour retrouver des chiffres corrects.

    Tout ça, c'était y'a 15 ans. Maintenant on peut plus faire des livraisons en production à la sauvage, et c'est pas plus mal…

  • # Montage NFS sur /tmp

    Posté par (page perso) . Évalué à 10.

    Je ne sais plus qui m'avait raconté cette histoire :
    Ayant préparé un serveur de prod, il le monte en permanent par NFS sur son /tmp.
    Ayant basculé sur ce serveur et tout fonctionnant bien, il l'avait un peu oublié.

    Ayant besoin de redémarrer sa machine, il trouva que le boot était bien long… C'est alors qu'il blêmit et comprit que la lenteur était due à un rm -rf /tmp/* qui avait lieu à chaque démarrage !

  • # Le CP de la mort

    Posté par . Évalué à 3. Dernière modification le 28/06/18 à 08:27.

    Il y en a un que j'aime bien, et qui fout toujours dans la merde les personnes ne comprenant pas vraiment l'important du point dans les chemins de repertoires.

    cp -rf .* /tmp/grosbackupquandmême
    

    Pour info la solution

    cp -rf .[^.]*
    

    (but : copier les dossiers cachés)

    • [^] # Re: Le CP de la mort

      Posté par . Évalué à 1. Dernière modification le 28/06/18 à 15:36.

      Pour copier tout le contenu d'un répertoire il vaut mieux utiliser :
      cp -rf ./ /tmp/grobackupquandmeme
      L'avantage c'est que ton fichier "..fic3" sera pris en compte aussi dans cette commande et que tu n'as pas besoin de dissocier les fichiers cachés des autres.

      • [^] # Re: Le CP de la mort

        Posté par . Évalué à 0.

        je parlais d'une commande qui ne copiait QUE les fichiers cachés. aussi, avoir des fichiers qui commencent par ".." faut viter quand mëme…

  • # comme labgui

    Posté par (page perso) . Évalué à 4.

    N'étant qu'un admin occasionnel, je n'ai pas encore réussi à faire de grosses boulettes … mais j'essaye régulièrement. ;-)
    Il aurait fallu prévoir une entrée dans ce sens là, au sondage.

  • # Le truc le plus stupide et apprentissage par l'expérience

    Posté par . Évalué à 2. Dernière modification le 28/06/18 à 09:07.

    En installant un serveur je termine l'installation et je veux faire un peu de ménage et la je veux effacer le fichiers d'un répertoire en root et je tape rm -Rf / un espace malheureux et le nom de mon répertoire

    Et là je me suis insulté pendant 5 minutes.

    Plus récemment je travaillais sur une base mysql et au lieu de faire un
    drop database mabase j'ai fait un drop mysql heureusement ce fut sans conséquences pour d'autres personnes.

    bref toujours vérifier le commandes et le contexte et si t'es trop fatigué fait toi relayer ou demande un deuxième avis.

    C'est la maxime que j'applique.

    Et si ce n'est pas urgent, on attendra demain :D

    Et maintenant je ne travail en root que quand c'est nécessaire.

    :P

  • # Avoir confiance au fail-over forcément *dans les deux sens*

    Posté par . Évalué à 5.

    En bossant sur les LNS de FDN, où arrivent toutes les connexions ADSL, je testais le fail-over de L2TPNS avec mes modifications pour annoncer les LNS en BGP aux routeurs upstream. Bien sûr, je teste depuis une ligne ADSL de chez FDN. Les deux serveurs sont up, les connexions sont réparties sur les deux, je coupe le premier : victoire, celles sur le premier basculent sur le second, ça fonctionne bien ! C'est vraiment époustouflant comme mécanisme, c'est quasi-instantané (quelque secondes) et toutes les lignes (environ 250 à l'époque, je crois) migrent sans problème. Confiant dans le système, je redémarre ce premier serveur, et « pour la forme » teste en coupant le second : allo ? Ya quelqu'un ? Ah, le fail-over n'a pas l'air d'avoir marché dans l'autre sens… Toutes les lignes sont tombées, y compris la mienne, et ça n'a pas l'air de redémarrer.

    Bien sûr, on est dimanche soir minuit, et je n'ai donc plus d'accès au Net. Je ne suis pas à Paris ni Amiens, mais heureusement geb est dans le coin, lui pourra sûrement m'aider, je pars toquer à sa porte. En arrivant chez lui, il rigole bien, à priori la nouvelle s'est répandue assez vite sur IRC. C'est un autre Benjamin (bien nommé pour un dimanche) qui a vu la coupure et a redémarré les serveurs le temps que je fasse ma petite marche.

    J'ai aussi appris plus tard par Domi que j'aurais pu me logger sur les serveur avec un realm et un login propre à notre fournisseur le collecte, vu l'architecture assez « open » du DSL en France.

  • # Boulettes des autres

    Posté par . Évalué à 9.

    J'ai fait plein de boulettes comme tout le monde, mais les meilleures que j'ai vécues étaient du temps où je bossais pour le sous-traitant d'un gros opérateur email, et qu'on n'était pas raisonnables dans la gestion des droits :
    - le client qui met en place une régle qui rejette tous les emails qui ont dans leur sujet "cialis"… il a fallu qu'une chaîne info fasse un titre remontant que les socialistes étaient censurés pour qu'il se rende compte de sa boulette
    - le développeur qui découvrant qu'il pouvait accéder à la base de données de prod a cru pouvoir corriger discrètement un bug dans la signature d'une utilisatrice avec un petit update incognito… il a oublié le "where", des millions de boîtes se sont retrouvées avec en signature le nom et le numéro de téléphone de l'utilisatrice

    Membre de l'april, et vous ? http://www.april.org/adherer

    • [^] # Re: Boulettes des autres

      Posté par (page perso) . Évalué à 3. Dernière modification le 28/06/18 à 11:55.

      il a oublié le "where", des millions de boîtes se sont retrouvées avec en signature le nom et le numéro de téléphone de l'utilisatrice

      Ouh, ça j'aime. :)

      Je dois dire que lorsque je suis contraint de faire ce genre de choses je demande à un collègue – si possible, le chef – de confirmer la commande. Ça attrape pas mal de fautes!

      • [^] # Re: Boulettes des autres

        Posté par . Évalué à 1.

        Sous DBeaver ou HeidySQL, il t’alerte quand il n'y a pas de where sur un update ou delete. Mais c'est certain que la ligne de commande elle ne fais rien.

        • [^] # Re: Boulettes des autres

          Posté par (page perso) . Évalué à 4.

          Avec mysql, on peut rajouter le paramètre "safe-updates" qui prévient quand on fait un delete ou un update sans clause WHERE. Mais bon ça donne de mauvaises habitudes.

  • # Autres

    Posté par (page perso) . Évalué à 2.

    J'ai effacé le MBR avec la table des partitions (Style PC 1980) d'un ordinateur personnel. Le lendemain matin, TESTDISK m'a sauvé la vie!

  • # dd if=unedistrib.iso of=/dev/le-disque-dur-interne-au-lieu-de-la-cle

    Posté par . Évalué à 5.

    CTRL+C !! CTRL+C !!

    C'est fou le nombre d'octets qu'on peut écrire en deux secondes.*
    Bien sûr, le début de la partition contient l'information pour lister les fichiers et les dossiers.

    Bon, pas de panique, redémarrons !!!
    (indice : ne surtout pas redémarrer dans la précipitation dans ce cas. Le système a peut-être de quoi restaurer au moins une partie de cette information en mémoire. De toute façon, le système ne va pas démarrer, le programme de démarrage a été écrasé.)

    Heureusement, je n'ai perdu beaucoup plus que la demi journée pour réinstaller le système et restaurer les données. Les sauvegardes des fichiers importants étaient à jour.

    *Loi de Murphy: dd n'est jamais aussi rapide que quand la destination n'est pas la bonne. En particulier si la destination contient des données importantes non sauvegardées : plus la destination contient des données importantes non sauvegardées, plus dd est exponentiellement rapide, et plus votre moyen d'atteindre CTRL+C est lents.

  • # rm * : c'est arrivé à Pixar pour Toy Story 2

    Posté par . Évalué à 10.

    Je trouve cette histoire assez fascinante. Un rm * malencontreux a supprimé tout Toy Story 2 pendant sa production.
    Et les sauvegardes n'étaient pas bonnes, le disque de sauvegarde était plein et les logs qui auraient dû lancer l'alerte étaient censés être écrits… sur ce disque plein.

    Mais une des employées, alors enceinte, avait une copie estimée récente du film chez elle, qui a été comparée à une sauvegarde de deux mois, en partie à la main.

    Je vous invite à lire cet article : https://thenextweb.com/media/2012/05/21/how-pixars-toy-story-2-was-deleted-twice-once-by-technology-and-again-for-its-own-good/

    Des gens de Pixar ont participé à cette question sur Quora : https://www.quora.com/Did-Pixar-accidentally-delete-Toy-Story-2-during-production?share=1

    Si vous préférez une vidéo résumée de 2-3 minutes : https://www.youtube.com/watch?v=8dhp_20j0Ys

  • # Datacenter

    Posté par . Évalué à -2.

    J'ai fait tombé un des DC du ministère de la justice en début d'année .
    Je ne donnerais pas plus d'infos.

  • # Ordonnanceur

    Posté par . Évalué à 1.

    Le "rm -rf /", mais emballé dans un script, le tout cablé dans l'ordonnanceur.
    C'est industriel, propre, silencieux : ça régénère un NAS dans la nuit…
    Et le matin : mais qui, qui a encore fait la boulette ??

  • # mv **/*.raw dosier_photo/

    Posté par . Évalué à 5.

    J'ai voulu déplacer toutes mes photos dans un seul dossier parce que ça trainait partout.

    J'avais pas pensé qu'elles avaient en fait quasiment toutes le même nom… J'ai perdu énormément de mon travail, le deuil était pas facile.

    Depuis j'ai des sueurs quand je manipule des fichiers depuis un terminal d'ailleurs.

    • [^] # Re: mv **/*.raw dosier_photo/

      Posté par . Évalué à 1.

      Depuis j'ai des sueurs quand je manipule des fichiers depuis un terminal d'ailleurs.

      C'est pour cette raison, entre autres, que j'utilise toujours MC (formidable et indispensable outil GNU) pour manipuler les fichiers dans un terminal.

  • # Upgrade de libc ...

    Posté par (page perso) . Évalué à 10. Dernière modification le 29/06/18 à 00:28.

    Yaka désinstaller l'ancienne et réinstaller la nouvelle, non ?

    # dpkg --force-depends --remove libc6 
    # dpkg -i libc6*.deb 
    bash: /usr/bin/dpkg: No such file or directory
    # ls
    bash: /bin/ls: No such file or directory
    

    Argh !

  • # migration oracle

    Posté par . Évalué à 1.

    Sur un changement de version Oracle (ça devait être de 7 vers 8), une petite confusion dans un exp d'un serveur de test (au lieu de l'ancien prod évidemment) et imp sur le nouveau serveur de prod…

    Bon ça se corrige facilement, mais sur le coup c'est un moment de solitude…

    J'ai aussi : avoir installé un serveur oracle à la "va vite" parce que l'économiseur d'écran d'un NT4 rendait le serveur très très lent… que d'énergie alors qu'il suffisait de désactiver l'économiseur… Encore fallait-il le savoir!

  • # Une de mes meilleures bourdes était sous MS Windows

    Posté par (page perso) . Évalué à 5.

    Sous MS Windows il y a (ou il y avait) un mécanisme d'association de fichiers, qui permet d'associer l'extension d'un fichier (en gros le suffixe) à une application qui permet de “l'ouvrir”.

    J'avais installé une version gratuite de la suite de développement Borland sur ce système MS Windows (95 ou 97 je pense), et gentiment le debugger propose de s'associer avec les fichiers exe et com ce qui m'a permis de déboguer quelques binaires.

    Je vous laisse deviner ce qui s'est passé lorsque j'ai désinstallé le débogueur. ;)

  • # La plus tordue

    Posté par . Évalué à 6. Dernière modification le 03/07/18 à 15:54.

    Mettre par terre un backbone réseau après avoir rebooté un routeur Cisco alors qu'un commutateur Nortel était configuré en bridge-routeur sur ses interfaces avec le dit backbone.

    La fonction brouter sur les Nortels consistait à se comporter comme un routeur pour le trafic IP et en bridge pour le reste. Hors, les routeurs Cisco, héritage de leur histoire, avaient la délicate attention d'envoyer une trame de type Decnetau démarrage, comme un hommage à l'histoire des réseaux informatiques.

    Du coup, vous voyez le coup venir ou pas ? Nous on a eu du mal, il a fallu faire péter le tcpdump dans tout les coins pour voir que des trames decnet se baladaient partout façon broadcast storm. Ben oui, Decnet, c'est pas de l'ip alors le nortel, il broadcast la trame sans se poser plus de questions sur ses interfaces brouter et ainsi de suite jusqu'a explosion du réseau. Bon en même temps, des interfaces en bridge routing, fallait vraiment chercher les emmerdements pour utiliser ça.

    En fait c'est arrivé à des collègues en TP de nuit lors de la mise à jour des cisco. Quand on est arrivé le matin, ils tiraient un peu la tronche, avaient tout le management de la boite sur le dos et un datacenter par terre.

    Enfin, c'était le bon temps, où l'on voyait encore autre chose de que de l'ip. Mais bon, il parait qu'il y a un nouveau protocole qui doit sortir, ipv6 ça s'appelle. Enfin du changement !

    Faut pas gonfler Gérard Lambert quand il répare sa mobylette.

  • # La typo mortel et les erreurs d'inattention.

    Posté par . Évalué à 1. Dernière modification le 04/07/18 à 23:53.

    Ah au faite, tu peux rajouter une petite purge des fichiers à la fin du script Stp.
    C'était quelques choses comme ça,

    if [[ "${strPath}" ]] && [[ ${intRetention} ]]; then
        echo "Je commence"
        find ${srtPath}/ -type f -mtime +${intRetention} -exec rm -vf {} \+
        echo "J'ai terminé"
    else
        echo "Traitement des erreurs..."
    fi

    Malheureusement, le premier test à été fatal…

    Sinon pour aller plus vite, on à crée des Macro TMUX pour se connecter en TMUX synchro (set synchronize-panes) sur plusieurs serveurs. Bein des fois on lance la mauvaise macro et on se croit sur un environnement et en réalité on est sur un autre…
    En plus, dans ce cas, tu fais la connerie en synchro sur plusieurs serveurs, … le reboot ou se genre de chose

    Je confirme qu'il faut vraiment se forcer à bien dormir…

    Binou

  • # Silence

    Posté par . Évalué à 2.

    Couper un onduleur en pensant qu'il y a rien de brancher dessus comme il y avait aucune prise dessus.
    En faite il y avait un gros cable qui sortait par en dessous pour alimenter toute la salle (Que des équipements telco donc la charge était faible sur les indicateurs), c'était bien silencieux tout a coup…

Suivre le flux des commentaires

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