La plus grosse erreur de ligne de commande? [fermé]

Quel est le plus grand dommage (de quelque nature que ce soit) que vous ayez jamais causé avec une seule ligne de commande erronée / mal orthographiée / égarée? Par exemple, j’ai supprimé une base de données du système de production par erreur, mais j’ai eu de la chance (c’est-à-dire une sauvegarde) et il n’y a pas eu de perte permanente de données, d’argent perdu, de dégâts matériels, etc.

Plus important encore (pour les votes), que faites-vous pour que cela ne se reproduise plus jamais?

Dans un serveur SQL, sur un système de production:

update customer set password = '' <enter>

La sauvegarde la plus récente était vieille d'une semaine.

Pour atténuer cela, j'écris d' selectabord en général une déclaration pour m'assurer que la whereclause est correcte, puis revenez en arrière et modifiez-la pour insérer la setclause et remplacez la déclaration par update.

Plus grosse erreur? Je pensais avoir défini deux variables alors que je ne l’avais pas fait. Ainsi, rm -rf $ VARIABLE / $ VARIABLE2 est devenu rm -rf /. FreeBSD a récemment mis à jour son outil rm afin que rm -rf / ne soit plus possible précisément à cause de cette erreur!

shutdown -h now 

destiné au poste de travail local, mais saisi lors de la connexion via ssh sur le serveur de production. Depuis lors, j'ai toujours le nom d 'hôte dans mon $PS1.

Omettre le -r d'une commande d'arrêt. Sur un serveur distant. De l'autre côté du pays. Sans personnel informatique dans le bureau distant.

Nous l'avons tous fait, c'est presque un rite de passage à ce stade.

Sur un système VMS, j'utilisais la commande ASSIGN DCL pour attribuer des noms logiques et je voulais RAPPELER une ligne de commande ASSIGN antérieure. Désormais, dans VMS, vous n’avez saisi que le nombre de caractères d’une commande pour le rendre non ambigu. Donc j'avais l'intention de taper

REC ASS

mais j'ai tapé accidentellement

REQ ASS

au lieu. REQ était suffisamment clair pour la commande REQUEST, qui diffuse l'argument à tout le monde avec des privilèges d'opérateur (ce qui était tout le monde dans l'informatique). Donc tout le département a reçu mon message diffusé qui était simplement "ASS".

Sur un système Solaris: "killall dataLoader".

«DataLoader» était une application sur laquelle je travaillais. Sous Linux, killall fonctionne comme pkill. Il envoie un signal aux processus correspondant à une chaîne donnée en argument. Sous Solaris, killall essaie de tout tuer sur le système que l'utilisateur actuel peut tuer. J'étais root.

Une fois, il y a beaucoup de lunes, j'avais besoin de trouver un exécutable particulier, mais je ne me souvenais pas de son nom complet (mais je me souvenais de quelques lettres). J'ai donc pensé vérifier le répertoire / usr / bin avec quelque chose comme ceci

rm /usr/bin/i*g*

Étrange. Rien n'est revenu. Estimant que je venais de me tromperer sur la deuxième lettre, j’essayai de nouveau avec

rm /usr/bin/i*

Encore une fois, rien. Après avoir fait la même chose avec / usr / local / bin, / usr / sbin et tout ce que je pensais être dans, je me suis rendu compte que j'avais mal saisi la commande 'ls'.

Je ne sais pas très bien d'où vient le brainfart, mais ce n'est certainement pas une erreur que j'ai jamais commise.

setup.exe

C'était Windows Vista.

Essayer de changer la propriété de tout ce qui se trouve dans un répertoire, y compris les fichiers point, avec:

chown -R user * .*

Devinez ce que ça fait?

Destiné à détruire / dev / sdb, heureusement, j'avais une bonne sauvegarde à jour

dd if=/dev/urandom of=/dev/sda

select * from <File1> join <file2>

Sur une boîte de production. Notez l'absence de onclause. :-) Les deux tables étaient des tables de plusieurs millions de lignes, et c'était sur un AS / 400 au milieu des années 90 où, une fois le code SQL exécuté, vous ne pouviez pas le tuer.

Sur l’un de nos serveurs de production de données, l’une de mes racines a tapé:

chmod -R 777 /

Parce qu'il obtenait une erreur d'autorisation avec certains scripts ...

Peu de temps après, sa clé privée a été retirée de tous les serveurs et il s'est occupé de la restauration de 1 To de données sur le serveur de production de données ...

Mon préféré était quand j'étais à l'université. Je construisais une application (je ne me souviens plus de quoi) et comme je n'étais pas root, je l'avais construite avec

PREFIX=~username/usr/local

Je pourrais donc l'installer dans mon répertoire personnel. Malheureusement, il a installé dans

/home/username/src/app/~username/usr/local

au lieu. Naturellement pour le supprimer comme recommencer, j’ai exécuté

rm -rf ~username

Dans le répertoire source.

Je me demandais pourquoi cela prenait si longtemps ...

:-)

Cependant, mon pire problème était lorsque je travaillais avec une station de travail Solaris et, après avoir tout configuré, nous voulions effacer la configuration pour la configuration en direct. Alors j'ai exécuté

sys-unconfig

Accepté le message d'avertissement et au lieu de redémarrer l'ordinateur et de revenir aux "paramètres d'usine" La fenêtre xterm a simplement dit

connection closed by foreign host.

Morale de l'histoire Ne laissez jamais un shell racine ouvert sur un autre hôte! DÉJÀ!!

Il y a de nombreuses années, j'étais à la maison en train de coder certaines choses en php alors que je travaillais sur un projet avec un de mes amis qui en était le responsable. Nous nous imitions les uns les autres dans un effort de collaboration. On se moque toujours d'avant en arrière.

J'essayais de faire fonctionner ssh-agent correctement sur ma machine alors que nous avions une guerre religieuse entre Perl et PHP. Ensuite, j'ai mentionné quelque chose sur le fait que ssh-agent doit être évalué (je ne sais pas pourquoi j'ai dit cela). Alors, alors il m'a envoyé ce message dans un effort, alors j'ai pensé, pour m'aider à résoudre mon problème (gardez à l'esprit que j'étais su-racé):

\# eval $(echo ssh-agent | 
perl -pe 's/h-a/m -r/' | 
perl -pe 's/^ss/r/' | 
perl -pe 's/gent/f \//')

ATTENTION! NE COUREZ PAS CETTE COMMANDE !!!

SI vous supprimez eval et exécutez la commande interne elle-même, il s’agit:

rm -rf /

Il m'a fallu 4 secondes pour constater ce qui se passait, mais le mal était déjà fait. Je devais réinstaller mon système d'exploitation. Heureusement, rien de mon travail n’a été effacé, à l’exception de certains éléments de / etc iirc. Il a eu un rire ÉNORME lorsque je lui ai envoyé un message d'horreur lui demandant pourquoi il avait fait ça. Nous sommes tous deux ingénieurs systèmes à long terme. Il ne pensait pas que je le ferais et ferais plus attention à le vérifier avant de commencer à jouer. Je lui faisais confiance et je ne pensais même pas qu'il jouait. Inutile de dire que cette petite histoire revient tout le temps entre nous. Alors j'ai décidé de l'immortaliser.

Comment ai-je atténué le fait que cela se reproduise? Je ne fais confiance à personne!

Une autre histoire moins intéressante est celle d’il ya quelques années. Je travaillais sur une boîte essentielle à la mission. J'ai eu quelques termes ouverts à la machine différente. Je devais supprimer des éléments superflus dans un répertoire. Eh bien, je me suis perdu dans mes termes et accidentellement rm'ed . dans mon répertoire local mais sur le mauvais hôte (mauvais terme) !!. J'ai exécuté la commande dans / var / lib / mysql au lieu de / tmp sur le serveur d'applications (terme différent). Inutile de dire que j'ai effacé la base de données de production. Heureusement, nous avons eu une attente chaleureuse à laquelle nous avons basculé pendant que moi-même et un collègue reconstruisions le serveur principal à partir des sauvegardes et de la veille. Cela a pris environ 18 heures à faire.

Atténuation: plus de prudence dans les fenêtres dans lesquelles j'exécute des commandes avant de les exécuter.

la version courte

#/bin/bash
$0&
$0

Une fois, j'ai voulu supprimer un tas de fichiers dans un répertoire.

del *.*

L'ordinateur a ensuite dit "Êtes-vous sûr? [Y / N]" Je me suis dit: "Bien sûr, je n'aurais pas tapé la fichue commande autrement! Des ordinateurs stupides comme Sheesh grommellent ..."

Y <enter>

C:\Windows>_

Euh ... WTF? Est-ce que je viens d'effacer mon répertoire Windows? ....

undelete *.*

À cette époque de petits disques durs, je savais à quoi servait chaque fichier de c: \ windows et comment il s'appelait, mais même après la suppression de toute suppression, le système n'était jamais le même. J'ai acquis un peu de respect pour l'invite "Êtes-vous sûr". Juste un peu.

Je pense que la chose la plus stupide que j'ai jamais faite a été de supprimer la route par défaut sur un cluster de pare-feu faisant face à l'extérieur - alors que j'étais connecté à mon ordinateur à plus de cent kilomètres de distance.

Heureusement, il s’agissait d’une période désignée comme étant l’arrêt planifié (au cas où), mais cela ne m’a pas épargné le trajet aller-retour de 200 km pour reconfigurer le pare-feu sur place. Cela n'a pas non plus aidé que cela prenne nos systèmes de production exposés à Internet pendant la durée de mon voyage et la réparation ultérieure.

Nous connaissons tous la définition de la nano-seconde. Une ohno-seconde est encore plus petite et correspond au temps qui s’écoule entre le moment où vous appuyez sur «entrer» et la réalisation de votre erreur.

Premier de deux ...

Sur une machine Solaris, nous avions une sauvegarde tar d'une machine AIX.

Un des développeurs a tapé:

tax xvf AIX_Backup.tar

Bien sûr, les chemins dans la taxe étaient absolus et nous avons fini par créer une nouvelle distribution d’unix ... Solarix ... Le seul problème avec la distribution est qu’elle n’a pas démarré :(

Histoire m'a raconté:

Une autre succursale a appelé parce que son PBX local avait des problèmes. Après quelques recherches, nous avons appris qu'ils avaient mis à jour leur serveur, mais pas leur configuration Asterisk. L'administrateur a donc décidé de charger le responsable de la succursale de rétablir la configuration.

Admin: "Ok, maintenant, tapez rm -rf / etc / asterisk"

Guy: "Ok"

Admin: "Maintenant, tapez cp / var / ..."

Guy: "Attends, il fonctionne toujours ..."

Admin: ??? ... !!!

rm -rf / some/path 

au lieu de

rm -rf /some/path 

Heureusement, ça ne m'est pas arrivé ;-)

source ~/.bash_history

Mon intention était la source .bashrc, mais j'étais trop pressé avec l'onglet complet ...

Quelque chose dans le sens de ceci:

sudo dd if=/dev/zero of=/dev/sda

Je voulais dire sda4. J'ai effacé tout le disque, pas seulement la partition :-(

XCOPYest une puissante bête - impitoyable dans son exécution et retardée par le fait que ses arguments en ligne de commande sont inversés par rapport à ceux de Window COPYet d'UNIX cp.

Il y a quelques jours, j'ai accidentellement écrit:

xcopy src \path\to\a\new\nonexistent\directory

XCOPYa eu la gentillesse d'écraser mon srcrépertoire avec ... rien! Et cela n'a pas pris la peine de mettre les anciens fichiers dans la corbeille non plus.

Oh, et il s'avère qu'en XCOPYréalité, les mêmes secteurs du disque sont écrasés au lieu d'en allouer de nouveaux. J'ai essayé 3 programmes de récupération de disque, et le meilleur ne pouvait récupérer que 3 des 10 fichiers perdus. Bien sûr, ces 3 fichiers étaient seulement vshost.exeet ses copains. Se gonfler!

a eu des problèmes avec le réseau (sur une machine distante) et je voulais juste redémarrer l'interface

ifconfig eth0 down && ifconfig eth0 upp

De nos jours, je m'assure que quelqu'un est près de la machine avant d'essayer de telles choses (iptables est également un bon candidat). Et quand personne n’était là, j’ai dactylographié

sleep 600; reboot

dans un autre terminal (écran), afin qu'il redémarre si je ne peux pas ctrl + c la commande dans les 10 minutes.

J'ai aussi appris de cette erreur (ctrl + c, la veille va lancer le redémarrage) et maintenant je l'utilise

sleep 600 && reboot

ce qui me permettra de le faire ctrl + c.

ifconfig eth0 down

Oups, je suis du côté externe de eth0. Le serveur Web est à l'autre bout du monde, dans une pièce fermée à clé. Sans accès réseau pour vous connecter ou redémarrer. Merde.

Un cookie gratuit à quiconque peut me dire pourquoi je suis un idiot d’essayer de supprimer ainsi tous les fichiers et répertoires cachés:

rm -rf. *

Lors du nettoyage de mon dossier de départ sur un serveur Web de production, j'avais oublié que j'avais lié symboliquement la racine Web du serveur à un emplacement de mon dossier de départ. Ne pensant pas, j'ai lancé un rm -rf sur ce dossier et la prochaine chose que je sais, les gens disent que le site Web est en panne!

OOPS!

Une fois, j'ai comparé des données dans deux dossiers et ai exécuté rsync avec l'option -d (supprime les fichiers de destination qui ne figurent pas sur la source). Et puis j'ai changé de source et de destination quand j'ai exécuté rsync. Cela a supprimé tous les nouveaux fichiers, que je voulais sauvegarder. Maintenant, j'ai appris à utiliser rsync avec -n (exécution à sec).

rsync -trvd --stats --progress /destination /source

Je n'avais pas de sauvegarde.

Il était une fois (probablement System III, mais c'était il y a longtemps), il était possible de créer un fichier nommé *en utilisant le bon shell citant. Quand j’en ai trouvé un dans mon répertoire personnel, j’avais tapé rm *et mis la main sur la touche de retour quand quelque chose m’a fait hésiter et y penser ...

Créer un tel fichier pour d'autres utilisateurs était une farce courante.

Si le fichier se trouve dans un répertoire, il est difficile de le limiter. Le réflexe de simplement taper son nom exactement comme lsil est affiché est assez fort.

L'autre farce (moins dommageable) consistait à nommer les fichiers avec des espaces (ou uniquement des espaces), beaucoup plus difficiles à supprimer ...

En raison d'une mauvaise expérience de la scission générale de JBoss après un redémarrage, j'aime effacer les fichiers de travail de JBoss avant un redémarrage. Je ferais normalement:

# cd /var/cache/jboss
# rm -rf tmp/* work/*

Afin de me protéger de la saisie d'une des nombreuses erreurs possibles et désastreuses, telles que:

• / tmp / *
• tmp / *
• vous avez eu l'idée

Je fais la dernière commande:

# sudo -u jboss rm -rf tmp/* work/*

Étant donné que l'utilisateur de JBoss aurait des difficultés à supprimer les fichiers critiques qui ne lui appartiennent pas.

Je n'ai jamais réellement commis cette erreur, mais je suis en sécurité dans le cas que je fais.