Quels sont vos moments Unix * douloureux * préférés

Que diriez-vous de partager vos moments favoris des leçons apprises ?

J'étais curieux de savoir si chmod 000 /cela fonctionnerait.

Eh bien, sans faille. Quelques minutes plus tard, je cherchais un CD de secours.

Lorsque j'ai commencé à travailler en tant que consultant utilisateur pour l'université que je fréquentais, on m'avait donné des sudodroits limités pour aider les étudiants qui avaient perdu / oublié leurs mots de passe. sudo passwd <username>était mon nouvel ami. Une heure après mon orientation, ma curiosité a eu sudo passwdraison de moi et j'ai saisi et regardé avec horreur l'invite d'un nouveau mot de passe. J'avais un peu peur de ^Csortir de là, pensant (par erreur, il se trouve) que je pouvais laisser le compte en question dans un état transitoire, alors j’ai entré un mot de passe et je me suis immédiatement dirigé vers le domaine sacré du 2e étage du campus SuperUser et lui a demandé s’il aimerait connaître le mot de passe root du système principal.

Surpris, personne d'autre n'a encore mentionné celui-ci:

rm -rf .*

(Lors de la tentative de suppression de tous les fichiers et sous-répertoires cachés, en oubliant complètement que cela se reproduira dans .et ..)

Makefile:

clean:
    @rm -f * .o

Ce qui, bien sûr, make cleanefface votre code source au lieu de simplement des fichiers objet.

Leçon: utiliser le contrôle de version.

Avait un ami couru :() { :|:&}; :sur un serveur distant auquel nous n’avions pas accès à la console. Impossible de redémarrer le serveur de production complètement gelé .

Décomposé (sur demande) pour le rendre un peu plus lisible.

:() # Define ':' as a function. Every time we say ':' execute the following code block
{ # Start of code block
    : # Call ':' again. 
    | # Pipe output to...
    : # Another ':' 
    & # Disown process. 
    # All on one line this would read :|:&, 
} # End of code block
; # End definition of ':' as a function
: # Call ':'

Il serait peut-être plus facile de regarder comme

bomb() { bomb|bomb& }; bomb

Je voulais bien dire, je l'ai vraiment fait. Essayer de chmodrécursivement un répertoire et a fini par échanger ./avec /.

En tant que racine, bien sûr, car seule cette racine permet d’atteindre la vraie douleur (et donc l’illumination).

J'ai essuyé la table de partition de mon lecteur principal par accident, pensant travailler sur un autre lecteur.

Avec le scrollback, l'utilisation prudente de df, la mémoire et la chance, j'ai pu le recréer exactement, le réécrire, le redémarrer et l'espoir ... Et ça a fonctionné.

Pas vraiment mon moment, mais quelqu'un d'autre.

À l'époque où je travaillais dans un centre de recherche en sciences nucléaires, nous utilisions un certain nombre d'ordinateurs SunOS, Ultrix et Linux et les chercheurs devaient partager le processeur sur ces machines. Lorsque des groupes de recherche individuels ont obtenu leurs propres subventions de recherche, ils ont acheté leurs propres ordinateurs, principalement SparcStations, et se sont chargés eux-mêmes de l'administration du système.

Auparavant, SunOS était livré avec le bureau OpenView et un bon gestionnaire de fichiers, voici à quoi il ressemblait:

La plupart de nos chercheurs travaillaient en tant que root et nous avons dû plus d'une fois réinstaller leurs systèmes d'exploitation car quelqu'un avait décidé de ranger le répertoire racine et avait déplacé / bin, / etc, / tmp et tout le reste qui encombrait la vue. la corbeille ou un sous-dossier.

D'autres utilisateurs ont choisi de ranger le répertoire / bin et de supprimer toute commande qu'ils ne connaissaient pas.

Les plus chanceux avaient des sauvegardes, la plupart avaient acheté un lecteur de bande, mais n'avaient pas l'habitude de faire des sauvegardes elles-mêmes.

Vers le milieu des années 90, un de mes amis et moi discutions de la folie de rm -rf *et à quel point une machine Linux irait mal. Nous sommes entrés dans des bibliothèques liées statiquement par opposition à des bibliothèques liées dynamiquement et j'ai postulé que le système pouvait très bien vivre sans /lib, puis je l'ai renommé sur mon poste de travail. De mauvaises choses se sont produites , mais nous nous sommes retrouvés avec plusieurs fenêtres de console ouvertes permettant d’essayer de réparer les dégâts (l’arrêt n’était plus une option). Aucun des éditeurs ne courrait. C'est incroyable les utilisations ésotériques que vous pouvez trouver pour la echocommande.

viet Caps-Lockcontre/etc/passwd

1. Connectez-vous à un ancien boîtier Solaris à l'aide d'un ancien terminal série qui n'actualise pas correctement l'écran.
2. su -
3. vi /etc/passwd. De toute façon, il n’existe pas de vipwsolution et "nous ne faisons que des modifications mineures".
4. Appuyez sur la Caps-Locktouche et ne remarquez pas.
5. Frapper jdeux fois pour faire défiler. Ignorez le fait que vous venez de taper J("Join"), ce qui combine cette ligne avec la ligne suivante. L'écran du terminal série ne s'actualisait pas correctement. Vous n'avez donc pas vu que vous aviez simplement combiné les 5 premières lignes en une seule ligne Loooooong, ce qui a corrompu les 5 premiers utilisateurs ('root', 'daemon', etc.).
6. Terminez votre AUTRE modification du fichier, tout en bas.
7. Enregistrer le fichier.
8. Connectez - Out.

Je l'ai fait une fois. Étonnamment, le système est resté fonctionnel pendant des mois. Cronjobs a fonctionné correctement, aucune erreur n’a été signalée dans les fichiers journaux.

Nous n'avions pas remarqué ce problème avant d'avoir redémarré le système des mois plus tard et nous ne pouvions pas nous connecter à la console. psa montré un tas d'emplois appartenant à UID '0' pas à l'utilisateur 'root'.

Vous ne pouviez pas vous connecter en tant que root, ni exécuter suou su -, et il n'y en avait pas sudosur cette boîte. Il n'y avait pas de lecteur de disquette, le CD-ROM était cassé et pas de ports USB (donc pas de CD-ROM externe). Le mode mono-utilisateur ne fonctionnait pas, car vous devez taper le mot de passe pour root, et cela vient de /etc/passwd.

rm -f * ~

et

rm -rf ${DIR}/

quand DIRn'a pas été réglé!

Je me souviens d'avoir essayé d'envoyer une SysRqséquence de touches à une machine distante ...

... mais il a été capturé par le local.

haltQuelques secondes plus tard, je reconnais simplement que je ne suis pas sur un shell local et que je n’ai plus la possibilité de rallumer le serveur de production.

Leçons apprises? L'invite de la machine ressemble maintenant à

[ --> root <-- @kompost:/home/echox] #

avec un joli balisage rouge ;-)

Mon moment préféré a été lorsqu'un collègue, qui utilise emacs, a voulu modifier un fichier important.

Parce que emacsc’est trop difficile à taper, il a configuré un alias pour emacs:

alias em=emacs

Sous l'influence de pas assez ou trop de café, il a bien mal tapé em...

Eh bien, c'est juste une autre raison d'utiliser vi...;)

Ou une autre expérience, comment se sentir vraiment stupide en quelques étapes faciles qui ne semblent pas si stupides individuellement.

Première étape: créez un compte pour l'enfant, s'il souhaite utiliser une machine Linux. Donnez-lui un mot de passe trivial, car après tout c'est un système domestique et n'est pas exposé au net.

Deuxième étape: prévoyez du temps pour ne pas vous souvenir de la première étape.

Troisième étape: ouvrez le port SSH du pare-feu (le NAT sur le routeur) pour entrer en ssh. Après tout, mes comptes ont de très bons mots de passe, et rien n’est vraiment précieux.

Quatrième étape: obtenez l’avis du FAI qu’une sorte d’activité DOS est dirigée vers un site suédois. Supposons qu'il s'agisse probablement des boîtes Windows, puis examinez-les et renforcez-les.

Cinquième étape: obtenez de l’avis du FAI que cela se poursuit. Demandez des détails, obtenez l'adresse IP du site suédois, lancez Wireshark, trouvez de quelle boîte provient l'attaque.

Sixième étape: nettoyer la machine Linux, se sentir stupide. Trouver le login vient d'une adresse roumaine. Supprimer des comptes sans bons mots de passe.

Quand j'étais au collège, dans les laboratoires informatiques, il y avait un économiseur d'écran qui simulait un tas de balles qui flotteraient. Ils ont tiré sur chacun avec une gravité simulée.

Une fois, alors que je m'amusais avec les paramètres, il s'est écrasé avec l'erreur Error: force on balls too great

Je développais une fois un pilote de périphérique pour Unix. Il y avait un problème de pointeur et au cours des tests, il commençait à écrire la fin d'un tableau dans la mémoire du noyau. J'étais lent à repérer cela et je n'ai pas appuyé sur le bouton de réinitialisation immédiatement. Le pilote avait gribouillé dans le cache du tampon de disque qui a ensuite été vidé sur le disque avant que je ne réinitialise. Un grand nombre de blocs étaient des inodes et des répertoires, et je me suis retrouvé avec un système de fichiers totalement détruit. Je pense que 6000 fichiers orphelins ont été mis en place lost+foundavant d'abandonner et réinstallés. Heureusement, ce n'était qu'un système de test, pas mon poste de travail avec tous mes fichiers dessus.

J'ai supprimé / etc et puis récupéré . Je ne pense pas avoir appris ma leçon ... J'ai aussi dû récupérer une suppression /bin. Cela semble arriver quand je travaille avec a chroot.

L'année dernière, un de mes collègues utilisait l'une de nos stations de travail Linux pour créer des copies de disques Flash à l'aide de la ddcommande. Il a accidentellement tapé quelque chose de semblable au suivant:

dd if=flash-image.img of=/dev/sda1

Au moment où il réalisa son erreur - écrasant le disque dur de la machine à la place du lecteur flash - la machine était déjà en panne. Nous avons dû reconstruire le boîtier, qui était d'ailleurs également la machine hébergeant toutes nos VM de développement à l'époque ...

Cela m'est arrivé l'année dernière. Je retirais certains fichiers du serveur à l'aide d'une variable temporaire:

rm -rf ${prefix}*

Devine quoi? La variable $prefixn'a pas été définie!
Vous pouvez imaginer le désastre ... des fichiers très critiques ont été supprimés.

J'ai failli le casser Control-Cet j'ai couru vers la CPU pour retirer le câble réseau !!

Hahaha je suis sûr que quelqu'un avait déjà fait ça ...

Au cours de ma deuxième année d’études en informatique, nous avons eu pour tâche de rédiger un programme en C qui générerait un certain nombre de sous-processus forket les ferait communiquer avec des tuyaux dans un "cercle" et déterminer lequel devrait être le "leader". ".

À l'époque, nous étions encore assez noobs et la plupart des peple ne disposaient pas de machines Linux. Nous avons donc travaillé sur nos comptes sur le serveur principal de notre faculté (qui hébergeait également le site officiel ainsi que les comptes et les sites du personnel). La plupart des gens ont écrit des forkbombs à un moment donné pour essayer de faire leurs devoirs. Plus de la moitié de mon groupe est parvenu au abusersdossier. C'était la charge la plus élevée sur ce serveur depuis très longtemps :)

Lorsque mon université a décidé de passer du réseau sans fil à l'utilisation de l'authentification propriétaire LEAP de Cisco ...

Commencé une très longue bataille qui s'est bien terminée. Rédaction de la documentation pour les autres utilisateurs souhaitant utiliser Linux et ayant accès à Internet. Six mois plus tard, ils ont également décidé d’ajouter le soutien PEAP. gifle

C'est mon préféré parce que j'ai gagné. Je l'ai fait au travail.

En tant que root sur Solaris,

$ kill -9 1

... et tout est tombé.

Mon ami s'est fait virer à cause de ça.

J'étais assistant de laboratoire pour une classe Linux. Une des étudiantes m'a appelée parce qu'elle ne pouvait plus su -parce qu'elle allait permission denied. OK, elle se souvient mal du mot de passe. Redémarrez en mode mono-utilisateur et réinitialisez. Quoi?! suSTILL ne fonctionne pas?! Il DOIT s'incliner devant ma volonté! Je redémarre donc en mode mono-utilisateur pour savoir ce qu’elle a fait. J'ai réalisé qu'elle couraitchmod -R 777 /var/www/html/drupal-6.19 /

Notez l'espace entre le nom du répertoire et la barre oblique finale.

Après quelques minutes de "Je ne veux vraiment pas la réinstaller, alors que faire et comment.", J'ai réussi à trouver que / bin / su avait maintenant les permissions de fichier de 777. Cela peut également être lu comme une autorisation de fichier 0777, ce qui supprime le bit setuid de /bin/su. Un rapide chmod u+s /bin/suet j'étais un héros.

Pas si pénible ... Mais un petit moment amusant:

Je me suis trompé en lstant que slet découvert que le sysadmin avait quelque chose installé pour un tel cas.

(déjà disponible dans les dépôts Debian , Ubuntu , Gentoo , ...)

git init
git clean -f

Cela ne supprime pas le référentiel. Cela supprime tout ce qui ne se trouve pas dans le référentiel.

Après avoir tenté de supprimer le référentiel existant, puis de relancer le contrôle de code source (sur la première version complétée d'un projet), ces deux commandes ont neutralisé tout mon code.

Une entreprise pour laquelle je travaillais auparavant avait son produit fonctionnant sous SCO. J'étais en train de déboguer sur le fait que les applications devenaient très lentes sur notre serveur de démonstration et, en même temps, un groupe de clients recevait une démonstration / conférence sur les nouvelles fonctionnalités à venir.

Donc, j'ai lancé l'application qui était bloquée, j'ai fait mon travail pour vérifier la cause du problème, mais comme elle était toujours "bloquée", j'ai essayé de la tuer:

pkill -9 mytestapplication

Ce que j’ai appris, c’est que pkill ne fait pas exactement la même chose sur SCO que sur linux =)

... il tue tout ce que l'utilisateur a accès, et avec root ... c'est tout =)

Mon passage de Debian à Ubuntu a commencé le jour où j’ai essayé de supprimer des fichiers et des répertoires, ce qui veut dire taper

rm -r /var/tmp/*

Malheureusement, j'ai inséré un espace entre "/ var / tmp /" et "*" et, pire encore, j'étais à la racine du système de fichiers.

root@workstation:/# rm -r /var/tmp/ *

S'il vous plaît, n'essayez pas ça à la maison!

Il y a une astuce intéressante pour faire l'équivalent de dirnameet basename, respectivement, dans Bash:

${path%/*}
${path##*/}

Pas si drôle quand $pathcontient un slash de fin ...

J'avais deux disques installés à un moment donné et le système de fichiers racine du deuxième disque était monté dans un répertoire /mnt. J'étais dans ce répertoire et j'ai essayé de supprimer varmais j'ai fini par taper à la rm -rf /varplace. Certains instincts semblaient entrer en jeu, ce qui var devait être précédé d'une barre oblique!

Quand j'ai réalisé ce que j'avais fait, j'ai immédiatement frappé Ctrl-Cmais c'était trop tard. Ma rpmbase de données avait depuis longtemps quitté le bâtiment. J'ai passé des siècles à tout ramener à la normale.

Maintenant pour la partie douloureuse.

Je retourne dans ce répertoire /mntpour reprendre ce que je faisais. Qu'est-ce que je tape? Eh bien, disons simplement que cet instinct a recommencé.

Au moins, j'ai pu restaurer le système beaucoup plus rapidement la deuxième fois;)