De nature rigoureuse, je fais toujours très attention à l'utilisation de la
commande 'rm'. De plus, j'utilise généralement le shell zsh qui nous protège
du fameux 'rm -rf /'.
Mais là, je n'avais pas imaginé le cas qui vient de m'arriver.
Le contexte : pour un petit projet personnel, je faisais des tests avec
chroot. Pour les besoins de ce projet, j'ai créé le compte suivant :
pwet:x:1137:0::/:/usr/local/bin/chrootsh
Mes différents tests étant finis, je n'ai plus besoin de ce compte et je
m'en vais alors pour le supprimer du système.
Je ne prête guère trop d'attention au dernier message, l'habitude d'ajouter
temporairement des comptes sans créer de répertoire home et de supprimer ces
comptes peu de temps après.
Je nettoye mon exécutable de test :
pegase ~ # rm -r /usr/local/bin/chrootsh
-bash: rm: command not found
Gni ?! Et là je comprends très vite... Satanée et fâcheuse habitude
d'utiliser l'option '-r' avec 'userdel' ! J'ai fait, indirectement,
l'équivalent du 'rm -rf /'...
pegase ~ # ls -la /
-bash: /usr/bin/ls: No such file or directory
Oh joie ! Il semblerait que la commande 'userdel' se soit arrêtée ou plantée
juste après l'effacement du premier répertoire de la racine, soit le
répertoire '/bin' (je n'ai pas encore cherché à comprendre pourquoi
d'ailleurs).
Bon, il ne me reste plus qu'à restaurer le répertoire '/bin' à partir de la
sauvegarde complète hebdomadaire et des sauvegardes incrémentielles de la
semaine (bien tombé, j'ai fait des mises à jours importantes sur cette
machine ces tous derniers jours).
pegase ~ # tar
-bash: tar: command not found
Bon, essayons la commande 'star', d'ailleurs ce n'est pas de 'tar' dont j'ai
besoin :
pegase ~ # star
star: Missing command, must specify -x -c -u -r -t -copy -n or -diff.
Usage: star cmd [options] file1 ... filen
Use star -help
and star -xhelp
to get a list of valid cmds and options.
Use star H=help
to get a list of valid archive header formats.
Use star diffopts=help
to get a list of valid diff options.
C'est bon signe.
pegase ~ # star -t -z -f /data/backup/archives/root-full-week-38.tar.gz
star: No such file or directory. Compress: exec of 'gzip' failed
star: Hard EOF on input, first EOF block is missing.
star: 0 blocks + 0 bytes (total of 0 bytes = 0.00k).
Grrr ! La commande 'gzip' n'est plus présente sur le système ! Bon, on
récupère un 'gzip' sur une autre machine :
pegase ~ # star -x -z -f /data/backup/archives/root-full-week-38.tar.gz
'bin' -C /
star: 'bin' did not match
star: 5342 blocks + 0 bytes (total of 54702080 bytes = 53420.00k).
et les archives incrémentielles jusqu'à la dernière de ce matin :
pegase ~ # for ((i=1;i<=`date +%w`;i++));do echo star -x -z -f
/data/backup/archives/root-inc-day-$i.tar.gz 'bin' -C /;done
[...]
Et là on respire...
À priori, après vérification, seul le répertoire '/bin' a souffert.
Maintenant, je serais moins laxiste et flémard avec 'userdel', je
l'utiliserai sans options et j'effacerai manuellement le répertoire home
quand il se doit !
Voilà, j'ai frôlé la catastrophe par manque de vigilance, mais la prévoyance
m'a sauvé. Tout ça pour dire : « FAITES DES SAUVEGARDES ! »
Personnellement, j'ai pris l'habitude de ne plus créer d'utilisateur ayant / comme répertoire HOME. J'ai déjà vu des serveurs de productions complètement purgés suite à des commandes malheureuses mais qui n'auraient pas eu de conséquences aussi facheuses si le HOME de l'utilisateur n'était le répertoire /. -- Bruno http://errance.lirano.net (photographies)
Personnellement, j'ai pris l'habitude de ne plus créer d'utilisateur
ayant / comme répertoire HOME.
J'ai déjà vu des serveurs de productions complètement purgés suite à des
commandes malheureuses mais qui n'auraient pas eu de conséquences aussi
facheuses si le HOME de l'utilisateur n'était le répertoire /.
--
Bruno
http://errance.lirano.net (photographies)
Personnellement, j'ai pris l'habitude de ne plus créer d'utilisateur ayant / comme répertoire HOME. J'ai déjà vu des serveurs de productions complètement purgés suite à des commandes malheureuses mais qui n'auraient pas eu de conséquences aussi facheuses si le HOME de l'utilisateur n'était le répertoire /. -- Bruno http://errance.lirano.net (photographies)
Oh joie ! Il semblerait que la commande 'userdel' se soit arrêtée ou plantée juste après l'effacement du premier répertoire de la racine, soit le répertoire '/bin' (je n'ai pas encore cherché à comprendre pourquoi d'ailleurs).
J'imagine que userdel a tenté d'appeler un exécutable dans /bin, ne l'a pas trouvé, et s'est arrêtée avec un message laconique...
Grrr ! La commande 'gzip' n'est plus présente sur le système ! Bon, on récupère un 'gzip' sur une autre machine :
N'était-ce pas plus simple de réparer à partir d'un CD de boot, façon RiP ? (Bon, évidemment, c'est uniquement dans le cas où tu as accès physique à la machine.)
Oh joie ! Il semblerait que la commande 'userdel' se soit arrêtée ou plantée
juste après l'effacement du premier répertoire de la racine, soit le
répertoire '/bin' (je n'ai pas encore cherché à comprendre pourquoi
d'ailleurs).
J'imagine que userdel a tenté d'appeler un exécutable dans /bin, ne
l'a pas trouvé, et s'est arrêtée avec un message laconique...
Grrr ! La commande 'gzip' n'est plus présente sur le système ! Bon, on
récupère un 'gzip' sur une autre machine :
N'était-ce pas plus simple de réparer à partir d'un CD de boot, façon
RiP ?
(Bon, évidemment, c'est uniquement dans le cas où tu as accès physique
à la machine.)
Oh joie ! Il semblerait que la commande 'userdel' se soit arrêtée ou plantée juste après l'effacement du premier répertoire de la racine, soit le répertoire '/bin' (je n'ai pas encore cherché à comprendre pourquoi d'ailleurs).
J'imagine que userdel a tenté d'appeler un exécutable dans /bin, ne l'a pas trouvé, et s'est arrêtée avec un message laconique...
Grrr ! La commande 'gzip' n'est plus présente sur le système ! Bon, on récupère un 'gzip' sur une autre machine :
N'était-ce pas plus simple de réparer à partir d'un CD de boot, façon RiP ? (Bon, évidemment, c'est uniquement dans le cas où tu as accès physique à la machine.)
Rakotomandimby (R12y)
Voilà, j'ai frôlé la catastrophe par manque de vigilance, mais la prévoyance m'a sauvé. Tout ça pour dire : « FAITES DES SAUVEGARDES ! »
Comment faire réduire le temps d'archivage et/ou compression?
Voilà, j'ai frôlé la catastrophe par manque de vigilance, mais la prévoyance
m'a sauvé. Tout ça pour dire : « FAITES DES SAUVEGARDES ! »
Comment faire réduire le temps d'archivage et/ou compression?
Dans le message <news:, *Rakotomandimby (R12y)* tapota sur f.c.o.unix :
Comment faire réduire le temps d'archivage et/ou compression?
En faisant des sauvegardes incrémentielles ? Pas sûr d'avoir bien compris ta question.
-- Sébastien Monbrun aka TiChou
Sébastien Monbrun aka TiChou
Dans le message <news:, *Fabien LE LEZ* tapota sur f.c.o.unix :
Grrr ! La commande 'gzip' n'est plus présente sur le système ! Bon, on récupère un 'gzip' sur une autre machine :
N'était-ce pas plus simple de réparer à partir d'un CD de boot, façon RiP ?
La machine héberge un tas de services et de comptes. L'arrêter est généralement assez problématique et il suffit des fois de 1 minute d'interruption pour avoir quelques utilisateurs venir râler.
(Bon, évidemment, c'est uniquement dans le cas où tu as accès physique à la machine.)
La machine est difficilement accessible (faut que je sorte d'ici pour y aller en plus) et elle n'a ni d'écran ni de clavier raccordés. Dans l'urgence, il m'était alors plus facile de réparer en ssh le système tant qu'il tournait encore et que j'avais la possibilité d'y lancer quelques commandes.
-- Sébastien Monbrun aka TiChou
Dans le message <news:2v68h2p26ev1558fn5vek5ng24n9rgcehu@4ax.com>,
*Fabien LE LEZ* tapota sur f.c.o.unix :
Grrr ! La commande 'gzip' n'est plus présente sur le système ! Bon, on
récupère un 'gzip' sur une autre machine :
N'était-ce pas plus simple de réparer à partir d'un CD de boot, façon
RiP ?
La machine héberge un tas de services et de comptes. L'arrêter est
généralement assez problématique et il suffit des fois de 1 minute
d'interruption pour avoir quelques utilisateurs venir râler.
(Bon, évidemment, c'est uniquement dans le cas où tu as accès physique
à la machine.)
La machine est difficilement accessible (faut que je sorte d'ici pour y
aller en plus) et elle n'a ni d'écran ni de clavier raccordés. Dans
l'urgence, il m'était alors plus facile de réparer en ssh le système tant
qu'il tournait encore et que j'avais la possibilité d'y lancer quelques
commandes.
Dans le message <news:, *Fabien LE LEZ* tapota sur f.c.o.unix :
Grrr ! La commande 'gzip' n'est plus présente sur le système ! Bon, on récupère un 'gzip' sur une autre machine :
N'était-ce pas plus simple de réparer à partir d'un CD de boot, façon RiP ?
La machine héberge un tas de services et de comptes. L'arrêter est généralement assez problématique et il suffit des fois de 1 minute d'interruption pour avoir quelques utilisateurs venir râler.
(Bon, évidemment, c'est uniquement dans le cas où tu as accès physique à la machine.)
La machine est difficilement accessible (faut que je sorte d'ici pour y aller en plus) et elle n'a ni d'écran ni de clavier raccordés. Dans l'urgence, il m'était alors plus facile de réparer en ssh le système tant qu'il tournait encore et que j'avais la possibilité d'y lancer quelques commandes.
-- Sébastien Monbrun aka TiChou
Sébastien Monbrun aka TiChou
Dans le message <news:, *Fabien LE LEZ* tapota sur f.c.o.unix :
Il semblerait que la commande 'userdel' se soit arrêtée ou plantée juste après l'effacement du premier répertoire de la racine, soit le répertoire '/bin' (je n'ai pas encore cherché à comprendre pourquoi d'ailleurs).
J'imagine que userdel a tenté d'appeler un exécutable dans /bin, ne l'a pas trouvé, et s'est arrêtée avec un message laconique...
La commande 'userdel' du paquet shadow (système Linux) n'appelle aucune commande externe pour l'effacement du répertoire (vérifié dans les sources). Je penche plutôt pour un bug dans la routine d'effacement récursive de la commande userdel.
-- Sébastien Monbrun aka TiChou
Dans le message <news:2v68h2p26ev1558fn5vek5ng24n9rgcehu@4ax.com>,
*Fabien LE LEZ* tapota sur f.c.o.unix :
Il semblerait que la commande 'userdel' se soit arrêtée ou plantée
juste après l'effacement du premier répertoire de la racine, soit
le répertoire '/bin' (je n'ai pas encore cherché à comprendre pourquoi
d'ailleurs).
J'imagine que userdel a tenté d'appeler un exécutable dans /bin, ne
l'a pas trouvé, et s'est arrêtée avec un message laconique...
La commande 'userdel' du paquet shadow (système Linux) n'appelle aucune
commande externe pour l'effacement du répertoire (vérifié dans les sources).
Je penche plutôt pour un bug dans la routine d'effacement récursive de la
commande userdel.
Dans le message <news:, *Fabien LE LEZ* tapota sur f.c.o.unix :
Il semblerait que la commande 'userdel' se soit arrêtée ou plantée juste après l'effacement du premier répertoire de la racine, soit le répertoire '/bin' (je n'ai pas encore cherché à comprendre pourquoi d'ailleurs).
J'imagine que userdel a tenté d'appeler un exécutable dans /bin, ne l'a pas trouvé, et s'est arrêtée avec un message laconique...
La commande 'userdel' du paquet shadow (système Linux) n'appelle aucune commande externe pour l'effacement du répertoire (vérifié dans les sources). Je penche plutôt pour un bug dans la routine d'effacement récursive de la commande userdel.
-- Sébastien Monbrun aka TiChou
Mehdi BENKIR
Rakotomandimby (R12y) wrote:
Voilà, j'ai frôlé la catastrophe par manque de vigilance, mais la prévoyance m'a sauvé. Tout ça pour dire : « FAITES DES SAUVEGARDES ! »
Comment faire réduire le temps d'archivage et/ou compression?
à l'époque où j'utilisais amanda dans fioritures particulières, j'arrivais à faire tenir des sauvegardes journalières d'un total de 90-130 GOs de données sur une bande de 2 GOs/jour, avec une ou deux bandes toutes les dix bandes pour gérer l'imprévisible.
Rakotomandimby (R12y) wrote:
Voilà, j'ai frôlé la catastrophe par manque de vigilance, mais la prévoyance
m'a sauvé. Tout ça pour dire : « FAITES DES SAUVEGARDES ! »
Comment faire réduire le temps d'archivage et/ou compression?
à l'époque où j'utilisais amanda dans fioritures particulières,
j'arrivais à faire tenir des sauvegardes journalières d'un total de
90-130 GOs de données sur une bande de 2 GOs/jour, avec une ou deux
bandes toutes les dix bandes pour gérer l'imprévisible.
Voilà, j'ai frôlé la catastrophe par manque de vigilance, mais la prévoyance m'a sauvé. Tout ça pour dire : « FAITES DES SAUVEGARDES ! »
Comment faire réduire le temps d'archivage et/ou compression?
à l'époque où j'utilisais amanda dans fioritures particulières, j'arrivais à faire tenir des sauvegardes journalières d'un total de 90-130 GOs de données sur une bande de 2 GOs/jour, avec une ou deux bandes toutes les dix bandes pour gérer l'imprévisible.
Chris
Bonjour la communauté,
Il fallait bien que cela arrive un jour.
Salut,
Je ne sais plus qui a dit ça mais c'est dans le ton :
Sous Unix il y a 2 catégories d'admin :
- Ceux qui ont fait une connerie sous root - Ceux qui vont faire une connerie sous root
A+ chris
Bonjour la communauté,
Il fallait bien que cela arrive un jour.
Salut,
Je ne sais plus qui a dit ça mais c'est dans le ton :
Sous Unix il y a 2 catégories d'admin :
- Ceux qui ont fait une connerie sous root
- Ceux qui vont faire une connerie sous root
