wipe d'un disque syst

Le
Eric Belhomme
Bonjour,

J'ai besoin de "wiper" un disque système sur une machine distante sur
laquelle je n'ai qu'un accès via ssh.

Mon idée était d'utiliser l'outil "wipe" packagé par Debian de cette
manière :

# wipe -kq /dev/sda

Ainsi, le disque devrait prendre bien cher, et tant que le système ne
reboote pas, je ne devrais pas m'auto-kicker du système !

Qu'en pensez-vous ?

--
Rico
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #25998892
Eric Belhomme a écrit :

J'ai besoin de "wiper" un disque système sur une machine distante sur
laquelle je n'ai qu'un accès via ssh.

Mon idée était d'utiliser l'outil "wipe" packagé par Debian de cette
manière :

# wipe -kq /dev/sda

Ainsi, le disque devrait prendre bien cher, et tant que le système ne
reboote pas, je ne devrais pas m'auto-kicker du système !

Qu'en pensez-vous ?



J'en pense qu'il ne vaut mieux pas que le système cherche à lire un bloc
du disque qui a été effacé, sinon ça risque de faire du vilain.
Inversement, le système peut continuer à écrire des données dans des
blocs qui sont censés avoir déjà été effacés.
Mieux vaudrait démarrer un système entièrement en RAM ou sur le réseau
(initramfs, tmpfs, NFS...) qui ne monte pas de système de fichiers se
trouvant sur le disque à effacer.
Répondre en citant
Eric Belhomme
Le #25998962
Le Thu, 20 Feb 2014 10:09:33 +0100, Pascal Hambourg a écrit :

J'en pense qu'il ne vaut mieux pas que le système cherche à lire un bloc
du disque qui a été effacé, sinon ça risque de faire du vilain.
Inversement, le système peut continuer à écrire des données dans des
blocs qui sont censés avoir déjà été effacés.



J'ai fait un test sur une machine en configuration identique : le noyau a
détecté que des trucs pas clairs aient lieu sur le FS, et l'a remonté en
RO très vite.
Mon wipe tourne toujours, et je n'ai pas perdu ma connexion ssh. J'attends
la fin du wipe pour voir au reboot...

Mieux vaudrait démarrer un système entièrement en RAM ou sur le réseau
(initramfs, tmpfs, NFS...) qui ne monte pas de système de fichiers se
trouvant sur le disque à effacer.



Si je pouvais booter sur un système en RAM, je ne me poserais pas ces
questions !
Le but est de wiper un serveur loué dans un DC auquel je n'ai pas d'accès
physique.

--
Rico
Répondre en citant
Eric Belhomme
Le #25999772
Le Thu, 20 Feb 2014 20:30:38 +0100, Pascal Hambourg a écrit :


Si je pouvais booter sur un système en RAM, je ne me poserais pas ces
questions !



Qu'est-ce qui t'en empêche ?

Le but est de wiper un serveur loué dans un DC auquel je n'ai pas
d'accès physique.



Pas ça en tout cas.



Je n'ai pas d'accès KVM, ni IPMI, ou autre protocole de supervision. Donc
si par malheur je merde quelque part, je l'ai dans le c*l. D'où ma
préférence à wiper "online".

Et de toutes façons j'ai validé le concept sur un "geany pig" chez moi,
et ça fonctionne parfaitement. Faut juste surtout pas perdre la connexion
ssh à partir du moment où le wipe a commencé :)

--
Rico
Répondre en citant
Eric Belhomme
Le #26004642
Le Fri, 21 Feb 2014 09:10:09 +0100, Pascal Hambourg a écrit :

Je n'ai pas d'accès KVM, ni IPMI, ou autre protocole de supervision.



En quoi est-ce un empêchement ?

Donc si par malheur je merde quelque part, je l'ai dans le c*l. D'où ma
préférence à wiper "online".



Ce qui n'exclut pas de démarrer un système en RAM avec un sshd.



Ca implique un reboot, et à la moindre erreur, je n'aurais plus aucun
moyen d'accès à ce serveur !

--
Eric
Répondre en citant
Olivier B.
Le #26004732
On 24 Feb 2014 10:44:22 GMT, Eric Belhomme wrote:

Le Fri, 21 Feb 2014 09:10:09 +0100, Pascal Hambourg a écrit :

Je n'ai pas d'accès KVM, ni IPMI, ou autre protocole de supervision.



En quoi est-ce un empêchement ?

Donc si par malheur je merde quelque part, je l'ai dans le c*l. D'où ma
préférence à wiper "online".



Ce qui n'exclut pas de démarrer un système en RAM avec un sshd.



Ca implique un reboot, et à la moindre erreur, je n'aurais plus aucun
moyen d'accès à ce serveur !



Pourtant, vous devez bien avoir une procédure de récupération de la
machine en cas de probleme non ? sinon comment faites vous ?

(genre console de gestion avec possibilité de remasteriser la machine)


--
pas de turlututu. apres l'@robase
Répondre en citant
Eric Belhomme
Le #26004792
Le Mon, 24 Feb 2014 12:29:35 +0100, Olivier B. a écrit :

Pourtant, vous devez bien avoir une procédure de récupération de la
machine en cas de probleme non ? sinon comment faites vous ?

(genre console de gestion avec possibilité de remasteriser la machine)



C'est de la prestation hors-forfait chez Orange, et ils se contentent de
remasteriser le serveur. Donc retour à la case départ. Moi je veux
*wiper* le disque avant d'arrêter le contrat de location.

--
Rico
Répondre en citant
tt
Le #26005902
Le Mon, 24 Feb 2014 21:21:37 +0100, Pascal Hambourg

franck PISSOTTE a écrit :
Le 24/02/2014 13:46, Eric Belhomme a ecrit :
Le Mon, 24 Feb 2014 12:29:35 +0100, Olivier B. a écrit :

Pourtant, vous devez bien avoir une procédure de récupération de la
machine en cas de probleme non ? sinon comment faites vous ?

(genre console de gestion avec possibilité de remasteriser la mac hine)



C'est de la prestation hors-forfait chez Orange, et ils se contenten t
de
remasteriser le serveur.





Pas de possibilité de demander un simple reboot hard ?

Moi je veux *wiper* le disque avant d'arrêter le contrat de locati on.



oui mais il y a wiper et wiper.
est ce que ca veux dire effacer "sérieusement" le disque ie plusieu rs
passages.

sinon un simple programme qui ecrit des données aléatoires jusqu' a ce
que le disque soit plein,
devrait faire l'affaire.



Autant je peux douter de l'utilité de faire plusieurs passes (AMA un e
seule passe de zéros suffit largement), autant le remplissage du sys tème
de fichiers laissera forcément des petits bouts d'anciens fichiers e n
place, notamment dans les blocs réalloués à d'autres fichiers et non
remplis complètement, dans le journal si les données sont journali sées...



et avec dd ?
--
Thumain Thérèse
Répondre en citant
Pascal Hambourg
Le #26006652
tt a écrit :
Le Mon, 24 Feb 2014 21:21:37 +0100, Pascal Hambourg

Autant je peux douter de l'utilité de faire plusieurs passes (AMA une
seule passe de zéros suffit largement), autant le remplissage du système
de fichiers laissera forcément des petits bouts d'anciens fichiers en
place, notamment dans les blocs réalloués à d'autres fichiers et non
remplis complètement, dans le journal si les données sont journalisées...



et avec dd ?



C'est un moyen d'écrire une passe de zéros.
Répondre en citant
tt
Le #26006682
Le Tue, 25 Feb 2014 20:41:20 +0100, Pascal Hambourg

tt a écrit :
Le Mon, 24 Feb 2014 21:21:37 +0100, Pascal Hambourg

Autant je peux douter de l'utilité de faire plusieurs passes (AMA une
seule passe de zéros suffit largement), autant le remplissage du
système
de fichiers laissera forcément des petits bouts d'anciens fichiers en
place, notamment dans les blocs réalloués à d'autres fichiers et non
remplis complètement, dans le journal si les données sont
journalisées...



et avec dd ?



C'est un moyen d'écrire une passe de zéros.



Pas forcément des 0, suivant if=, me semble t-il me souvenir.

--
Thumain Thérèse
Répondre en citant
Pascal Hambourg
Le #26007092
tt a écrit :
Le Tue, 25 Feb 2014 20:41:20 +0100, Pascal Hambourg

tt a écrit :
Le Mon, 24 Feb 2014 21:21:37 +0100, Pascal Hambourg

Autant je peux douter de l'utilité de faire plusieurs passes (AMA une
seule passe de zéros suffit largement), autant le remplissage du
système
de fichiers laissera forcément des petits bouts d'anciens fichiers en
place, notamment dans les blocs réalloués à d'autres fichiers et non
remplis complètement, dans le journal si les données sont
journalisées...


et avec dd ?


C'est un moyen d'écrire une passe de zéros.



Pas forcément des 0, suivant if=, me semble t-il me souvenir.



Si tu veux, mais à mon avis cela n'apporte pas grand-chose de plus pour
l'effacement de disque.
Répondre en citant
Publicité
Poster une réponse
Anonyme