Boulette avec rm sous debian squeeze

Système d'exploitation Linux
1

Bonsoir !

Bon, belle boulette qui j’imagine est arrivé à d’autres (j’espère histoire d’avoir l’air moins ridicule…)

Depuis la racine, voulant effacer le contenu d’un répertoire, j’ai taper comme un idiot la commande :

rm * /monDir

bien sur, avec “*” en 1er au lieu de le foutre après le répertoire pour en désigner son contenu…

bref, erreur sur la suppression des répertoires (encore heureux que j’ai pas fait un rm -R, bien que je ne suis pas sur que ça soit récupérable)

j’ai une bécane quasi identique à coté, quand je regarde le contenu de la racine, je n’ai que des répertoires, et 3 liens symboliques, aucun fichiers. Donc j’imagine que ma commande précédente n’a supprimé que les liens symboliques (init.img, lib64 et vmlinuz) mais ça doit suffire pour empêcher tout reboot j’imagine…

Je ne peux plus ouvrir d’autre console ssh, mon serveur ne tient donc plus que par un fil ^^

par contre toute commande lancer dans la console ssh se solde par un [quote=""]
-bash: /bin/ls: Aucun fichier ou dossier de ce type
[/quote]

Même en tapant directement “/bin/ls” j’obtiens la même erreur, pourtant j’imagine que le contenu de /bin est toujours présent…

1ère question, si seuls ces 3 liens ont étés supprimés, les recréer permettrait-il de récupérer cette énorme erreur ?
2ème question, comment faire pour exécuter quoique ce soit si les commandes ne me renvoient que des erreurs ?

Au moins celle là je m’en souviendrai…

Merci pour ceux qui sauront m’aider, ainsi qu’à ceux qui sauront être compatissant ^^

2

la commande “cd” marche encore, je peux au moins naviguer dans les répertoires ! mais bon je ne suis pas sorti d’affaire…

pour info, qu’est-ce que mon “rm” a pu supprimer pour que je perde l’accès aux commandes ?

Bizarrement si je tape “ls” depuis la racine il sait que ls se situe dans /bin/ mais il indique ne pas le trouver alors qu’il y ai bien…
Edité le 29/05/2013 à 21:44

3 
. /bin/ls

c’est grave docteur ?
Edité le 29/05/2013 à 21:54

4

“cd” est une commande du shell, ce n’est pas un binaire donc c’est normal que ça fonctionne encore.

Est-ce que tu peux taper les commandes suivantes :
alias
(permet de vérifier s’il y a un alias sur “rm” qui aurait fait plus que ce que tu crois, par exemple un alias rm=‘rm -r’…)

history
(ne copie ici que ce qui est utile c’est à dire les commandes à partir des éventuels “cd” avant le fameux rm), permettra de vérifier depuis quel endroit exactement tu as lancé ton “rm” et donc ce que tu as pu perdre)
Edité le 30/05/2013 à 09:00

5

Je viens de tilter

Si tu as en effet supprimé les liens, le problème doit venir de celui-là.
Donne-nous le retour de la commande “env”, si /lib64 est utilisé quelque part. Regarde également sur ton autre debian vers quel répertoire pointe ce lien (sans doute /lib mais je n’ai pas de debian pour confirmer)

Si c’est ça, ça va être assez simple à régler :wink:
Edité le 30/05/2013 à 10:13

6

Bonjour,

ma session ssh est fermée, plus d’accès à distance possible, la connexion s?interrompt juste après le login…

Est-ce qu’en bootant la machine physique sur un live cd je peux recréer les lien symboliques manquant et rebooter normalement ?

Pour l’alias du rm, non il n’y en a pas, je n’en ai pas mis en place et rm sans l’option -r ne fonctionnait pas sur les répertoires.

Je tente le boot sur un livecd pour refaire ces 3 liens, l’autre machine étant identique d’un point de vue OS je connais au moins les liens symbolique à refaire…

au passage sur l’autre machine, le “env” renvoi :

TERM=xterm
SHELL=/bin/bash
SSH_CLIENT=192.168.xx.xx 51403 22
SSH_TTY=/dev/pts/0
USER=root
MAIL=/var/mail/root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/root
LANG=fr_FR.UTF-8
SHLVL=1
HOME=/root
LOGNAME=root
SSH_CONNECTION=192.168.xx.xx 51403 192.168.yy.yy 22
_=/usr/bin/env

/lib64 pointe effectivement sur /lib
Edité le 30/05/2013 à 10:29

7

Oui avec un livecd tu pourras recréer les liens et surtout vérifier que rien d’autre ne manque :wink: (normalement il n’y a aucun fichier directement dans / donc ça devrait aller)
Edité le 30/05/2013 à 10:30

8

C’est bon, j’ai créé le lien lib64 et au reboot j’ai repris la main normalement…

Merci ^^

Y a t il moyen avec un alias de lancer un script avec une vérification du rm ?

9

La première chose à faire à mon avis c’est de mettre un alias rm=“rm -i”. Ça te demandera confirmation à chaque fichier. Par contre c’est un peu lourd pour la suppression de beaucoup de fichiers, mais ça peut être outrepassé à la demande par l’option “-f”.

Après tu peux mettre en place quelque chose de plus complexe, comme ça :
www.blaess.fr…

En gros ça ne supprime pas directement, ça permet de gérer une espèce de “corbeille”, qui peut être vidée soit avec le paramètre “–emptytrash” soit automatiquement avec un crontab (dans l’exemple, programmé à 4h du matin).
(attention à la mise en place de l’alias, il parle de mettre l’alias dans /etc/profile, il faut vérifier que ce fichier est bien chargé par défaut pour chaque utilisateur, ce n’est pas le cas dans toutes les distributions)

Un script plus simple qui détaille les paramètres et demande confirmation, c’est faisable aussi, je ne sais pas si on peut en trouver des tout faits mais au pire ce n’est pas très compliqué à écrire.

Un dernier conseil, plus général : ne se connecter en root que lorsque c’est réellement nécessaire ! La commande que tu as tapée, si cela avait été avec un utilisateur normal, n’aurait rien supprimé du tout :wink:
Edité le 30/05/2013 à 15:39

10

Je ne connaissais pas ce genre de choses pour gérer une “corbeille”. Ca peut être très utile, merci. :slight_smile:

C’est clair. :jap:

C’est le conseil numéro 1 selon moi. :jap:

11

pour le root, s’agissant d’un serveur, il n’y a pas de “vrai” utilisateur, et c’est bien en root que j’ai à faire des manipulations…

Là pour le coup je cherchait à supprimer un répertoire à la racine pour monter une nouvelle partition à sa place, root obligatoire…

Par contre le prochain coup je me mettrais dans un répertoire genre tmp et je lancerai le rm en absolu pour éviter ce genre de bêtise…

Par contre, concernant la “corbeille”, si on déplace comme moi le répertoire lib, on perd tout de même tout les commandes qui permettrait un retour en arrière non ?
Edité le 30/05/2013 à 22:55

12

Dans ton cas en effet ça t’aurait bloqué de la même manière, mais au moins tu aurais été rassuré sur le fait de ne rien avoir perdu.

C’est pour ça que je suggérais aussi un script plus simple qui ne fait qu’afficher les paramètres (le * étant automatiquement remplacé par l’ensemble des éléments concernés) et demander confirmation. C’est très simple à faire, si tu fais déjà un peu de scripts.

(sinon sur nos serveurs on a des utilisateurs dédiés aux applis serveur, ce qui nous permet de n’utiliser root que dans des cas exceptionnels… en production, quasiment jamais en fait, à part pour rebooter le serveur)
Edité le 31/05/2013 à 07:08

13

chaque service à son user effectivement, mais là pour le coup, s’agissant de toucher aux montages des volume LVM, de gérer leur taille, je ne suis pas sur qu’on puisse le faire autrement qu’en root, et si c’était le cas, cet user aurait des droits suffisant pour faire les mêmes dégâts à mon avis…

14

Je viens de tester un truc vite fait :

#!/bin/bash

echo "Your command is: rm $*"
read -p "Are you sure? " -r
if [[ $REPLY =~ ^[Yy]$ ]]
then
    /bin/rm $*
fi

Tu mets ça dans un script /usr/local/bin/rm_secure.sh, tu lui donnes les droits d’exécution (chmod a+x /usr/local/bin/rm_secure.sh)
Et tu fais un alias rm="/usr/local/bin/rm_secure.sh" que tu mets dans tes profils utilisateurs (et surtout dans celui de root).

Voilà le test que j’ai fait :

$ vi /tmp/rm_secure.sh
$ sudo cp /tmp/rm_secure.sh /usr/local/bin/
[sudo] password for myuser:
$ sudo chmod 755 /usr/local/bin/rm_secure.sh
$ alias rm="/usr/local/bin/rm_secure.sh"
$ touch test1 test2 test3 dont_remove
$ ls
dont_remove  test1  test2  test3
$ rm *
Your command is: rm dont_remove test1 test2 test3
Are you sure? n
$ ls
dont_remove  test1  test2  test3
$ rm test*
Your command is: rm test1 test2 test3
Are you sure? y
$ ls
dont_remove
$

Edité le 31/05/2013 à 10:08