module

Beryl::CLI::Unlock

Sous-commande beryl unlock <host> (étape H4 du chiffrement) : importe et déchiffre les pools data chiffrés d'un host après un reboot.

Routage par mode (depuis T3 — 28 avril 2026) :

  • mode ssh_unlock (Option C, défaut historique) — la clé locale ~/.config/beryl/<société>/<domaine>/<host>.key voyage via stdin SSH jusqu'à zfs load-key. Aucune dépendance Tang.

  • mode tang (Option D) — délègue à crystal-clevis-zfs unlock sur le serveur. Le binaire interroge Tang en interne, dérive la clé, la pousse à zfs load-key. Pas de clé locale nécessaire.

Flow général :

  1. Pour chaque pool data déclaré chiffré : a. zpool import -N <pool> si pas déjà importé. b. Selon le mode :
    • ssh_unlock : zfs load-key <pool> avec clé locale via stdin.
    • tang : crystal-clevis-zfs unlock --no-mount --dataset <pool>. c. zfs mount -a -l (côté beryl, garde le contrôle du mount).
  2. Idempotent : si le pool est déjà importé et la clé chargée, log « déjà déverrouillé » et passe au suivant.

Voir zpool-encryption-architecture.adoc § « Le modèle SSH unlock » pour le contexte complet.

Constants

EXIT_KEY_MISSING = 4
EXIT_MISSING_CONFIG = 7
EXIT_NO_DATA_POOLS = 5
EXIT_OK = 0
EXIT_SSH_FAILED = 2
EXIT_TANG_BINARY_MISSING = 8
EXIT_UNEXPECTED = 3
EXIT_UNLOCK_FAILED = 6
EXIT_USAGE = 1
TANG_BINARY = "/usr/local/sbin/crystal-clevis-zfs"

Chemin attendu du binaire crystal-clevis-zfs côté serveur. Le README du shard documente cet emplacement comme cible d'installation. Si l'opérateur l'a mis ailleurs, la recette beryl crystal-clevis-zfs-install pourra l'override plus tard.

Class methods

run(config_root : String, args : Array(String)) : Int32
Source