module

Beryl::CLI::Wipe

Sous-commande beryl wipe <host> --disk PATH : efface un disque sur un hôte actuellement en rescue Linux. Commande destructrice, exige une confirmation explicite (OUI ou YES) sauf --force.

Constants

DETACH_CHECK_TICKS = 5
DETACH_LOG = "/tmp/beryl-wipe.log"
DETACH_RC = "/tmp/beryl-wipe.rc"
DETACH_SH = "/tmp/beryl-wipe.sh"
DETACH_TICK = 1.second
EXIT_CANCELLED = 2
EXIT_NOT_IN_RESCUE = 5
EXIT_OK = 0
EXIT_SSH_FAILED = 4
EXIT_UNEXPECTED = 3
EXIT_USAGE = 1

Class methods

detach_disk_log(disk : String) : String

Log dédié d'un disque en mode parallèle : /tmp/beryl-wipe-<dev>.log (ex. /tmp/beryl-wipe-nvme0n1.log). Isole chaque shred -v pour un tail -f lisible, sans entrelacement.

Source
detach_launch_cmd

Commande qui lance le script wipe en session DÉTACHÉE (setsid) : le travail survit à une coupure SSH (un shred de plusieurs To dépasse largement la durée de vie d'une session). Sortie redirigée dans un log, code de sortie écrit dans un fichier .rc à la fin. Tous les fds sont détachés du canal SSH (</dev/null >/dev/null) pour que l'appel rende la main immédiatement.

Source
detach_rc_cmd

Commande de complétion : renvoie le contenu du .rc (vide tant que le wipe tourne). ; true FINAL crucial : sinon le code de sortie est celui de cat #{DETACH_RC}, qui ÉCHOUE (exit 1) tant que le .rc n'existe pas (= wipe en cours) — beryl le prendrait à tort pour une coupure SSH. Avec ; true, seul un vrai échec de transport (ssh 255) rend un exit ≠ 0. La complétion se lit dans le CONTENU du .rc, pas dans le code de sortie.

Source
detached_exec(conn : SSH::Connection, script : String) : Bool

Lance script sur le rescue en DÉTACHÉ puis affiche un battement : [HH:MM:SS].........10.........20.........30.........40.........50 1mn une ligne par minute (heure au début, total en fin de ligne). Les points sont pilotés par une horloge LOCALE ; toutes les DETACH_CHECK_TICKS secondes beryl interroge le rescue pour la complétion. Un appel SSH qui échoue n'interrompt rien : le wipe est détaché, les points continuent, et la vérif reprend au tick suivant. Renvoie true si le script a fini en 0.

Source
erase_plan(disk : String, passes : Int32, hardware : Bool, secure : Bool = false) : String

Résumé lisible de la stratégie d'effacement d'un disque (pour le dry-run). En mode matériel sur un support non-NVMe, le choix exact (blkdiscard vs shred) se fait à l'exécution selon rotational, donc on annonce les deux issues.

Source
heartbeat_glyph(secs : Int32) : String

Ligne de battement : un point par seconde, le repère des dizaines (10, 20, 30, 40, 50) aux secondes rondes. secs va de 1 à 59 (0/60 = saut de ligne, géré par l'appelant). Exposé pour test.

Source
run(config_root : String, args : Array(String), confirm_io : IO = STDIN) : Int32
Source
verify_fn

Fonction shell de vérification (définie une fois en préambule quand --verify) : lit 7 sondages répartis sur le disque et confirme qu'ils sont à ZÉRO. Valide le « Deterministic Zeroes After Trim » d'un SSD / le zéro après nvme format. Écrit « VERIFY FAIL … » sur toute divergence et renvoie non-zéro.

Source
wipe_script(disk : String, passes : Int32 = 0, hardware : Bool = false) : String
Source
wipe_script_multi(disks : Array(String), passes : Int32 = 0, hardware : Bool = false, parallel : Bool = false, secure : Bool = false, verify : Bool = false) : String

Script shell qui détruit les pools ZFS importables (une seule fois, avant les boucles disque) puis efface chaque disque passé en argument. Le zpool destroy/export se fait globalement parce qu'un même pool peut couvrir plusieurs disques : essayer de l'attaquer disque par disque rate ou duplique les opérations.

Trois niveaux d'effacement (du plus rapide au plus sûr) :

  • défaut (passes 0, hardware false) : métadonnées seules (labels ZFS + GPT + 10 Mo de tête). Rapide, données récupérables.
  • passes >= 1 : réécrit l'intégralité du disque N fois via shred (fallback dd if=/dev/urandom). Lent (taille × passes).
  • hardware true : effacement matériel adapté au support détecté sur le rescue — nvme format (NVMe), blkdiscard TRIM (SSD), et repli shred (HDD rotatif, sans support matériel). Quasi instantané sur SSD/NVMe. passes sert alors de nombre de passes du repli HDD (défaut 1).

parallel : avec plusieurs disques, lance un sous-shell par disque (devices indépendants → gain de temps réel, surtout pour les HDD en shred). La destruction des pools ZFS reste AVANT et séquentielle (un pool peut couvrir plusieurs disques). On attend tous les sous-shells et on propage un échec si l'un d'eux a échoué.

Source