Un développeur tape par erreur « s tty erase ^? », avec un espace entre "s" et "tty". Il se rend rapidement compte qu'il y a sur la machine un script "s", qui arrête toutes les bases de données Oracle du réseau.
Il va donc voir l'administrateur SGBD, et lui dit que ce n'est peut-être pas une bonne idée d'appeler son script "s", ni de le mettre accessible à tous.
Celui-ci a réagi ainsi :
$ cd /opt/oracle/(...)/bin
$ rm s*
Oui, "s*", et non pas "s" tout court. Comme "sqlplus", "srvctl", "sqlldr", etc.
Tout cassé Oracle. PEBKAC.
Un administrateur de bases de données Oracle certifié, a un jour écrit à notre administrateur SGBD auto-formé :
« Salut mec ! Sur la machine "srv-ora1", il y a des fichiers .DBF de près de 2 Go dans "C:Oracleoradata". À quoi servent-ils, et puis-je les supprimer ? ».
Notre admin a eu beaucoup de mal à ne pas lui proposer d'effacer directement le dossier "C:Oracle". PEBKAC.
Pendant mes études (années 90), nous avions régulièrement besoin de relancer des tâches système, corriger des droits foireux, etc. ("ipcrm" en particulier). Au début, on demandait aux professeurs. Puis on a réussi à "pirater" les serveurs, et nous avions mis un « /usr/bin/sp » qui permettait de passer root discrètement. L'outil étant dans une zone système, ressemblant aux centaines d'utilitaires Unix aux noms abscons. Tous les étudiants l'utilisaient régulièrement sans abus.
Puis un jour, le prof' a rencontré à un problème : un étudiant avait été saboter le travail d'un autre. Ne trouvant rien, le prof' est venu m'extraire d'un examen, m'a posé devant un terminal dans le répertoire d'un étudiant, et m'a dit : « Trouve-moi s'il a un truc pour pirater le serveur ! ».
Sachant où était le hack (/usr/bin), j'ai fait, en confiance, un "find" dans le répertoire de l'étudiant pour des programmes set-uid root.
Et paf... Cet imbécile avait copié l'outil partagé dans son répertoire à lui. PEBKAC.
Je réalise que tous les messages envoyés @<mon_FAI>.fr échouent. J'appelle le support, qui insiste pour vérifier la configuration de mon client de messagerie. Je lui propose de s'envoyer un e-mail à lui-même depuis Gmail, Hotmail, ou autre webmail. Il me confirme qu'il n'a pas d'erreur. Je demande au support :
- Vous avez essayé depuis Gmail ?
- Non, depuis « support@<mon_FAI>.fr ».
- Donc s'il y a une erreur, vous espérer la recevoir... sur <mon_FAI>.fr, qui est lui-même en erreur ? De mon côté, j'envoie depuis mon boulot et j'ai « User unknown » sur l'adresse « support@<mon_FAI>.fr ».
J'entends des bruits d'engrenages... puis le support reprend :
- Ah... Mais c'est peut-être l'e-mail de votre entreprise qui fonctionne mal !
- Je travaille chez Cisco... Et je n'ai de problèmes qu'avec les adresses @<mon_FAI>.fr.
- Ah bon, je me renseigne...
Évidemment, c'était leur serveur qui était en panne. Pour le mec du support qui n'est même pas au courant que son serveur mail est down (contrairement à ses collègues) : PEBKAC.
page 1/1