Fedora 25 - Btrfs, Encrypt - Anaconda Install

Sono ormai parecchi anni che, ciclicamente, mi lancio in prove e sperimentazioni con btrfs: non so poi per quale motivo, ma non ne sono mai uscito convinto a tal punto da decidere di utilizzarlo in ambiti di produzione (e per produzione intendo semplicemente il mio pc di lavoro).
Mi sono invece fatto irretire da zfs, ma, nei 4 mesi in cui l'ho utilizzato su di una partizione di un ssd per delle macchine virtuali, ho avuto un episodio di corruzione dati al mese. Questo mi mi ha costretto a rigenerare le macchine stesse e, alla fine, causa frustrazione, sono tornato a xfs.

In ogni caso, le ultime prove che ho fatto con Fedora 25, il suo installer anaconda e btrfs sono dal mio punto di vista estremamente promettenti.

Ambiente
Disco di prova da 40GiB

Idea per la sperimentazione
Boot da 1GiB ext4
Swap da 4GiB
Volume da 15Gib chiamato "system" non cifrato contenente i subvolume / /var e /usr
Volume da 20Gib chiamato "data" cifrato contenente /hiome /opt e /usr/local

Realizzazione
In anaconda scelgo "I will configure partitioning" e "Encrypt my data". Questo fa si che mi venga chiesta la passphrase che verrà poi utilizzata per sbloccare il contenitore LUKS.

Scelgo "New mount points will use the following partitioning scheme" - Btrfs e inizio a creare le partizioni come da schema iniziale in questo modo:

/boot -> ext4

/, /usr , /var -> Nel volume che ho chiamato "system", di tipo btrfs non cifrato

/home, /opt, /usr/local -> Nel volume che ho chiamato "data", di tipo btrfs cifrato

Risultato
Dopo aver fatto l'installazione di Fedora, qualche aggiornamento e qualche configurazione secondaria, riavvio il tutto partendo con una distro live di Ubuntu in modo da osservare "da fuori" ciò che l'installer di Fedora ha fatto:

Vedo 5 partizioni.
sda1 -> E' la boot in ext4
sda2 -> E' il volume "system" btrfs  che contiene i subvolume root usr e var
sda3 -> E' la partizione cifrata di swap
sda5 -> E' il volume cifrato "data" btrfs che contiene i subvolume home opt usr_local

Preparo 2 punti di montaggio per i volumi sotto /mnt

Osservo ora la cifratura del volume sda5

Mi sembra tutto "standard".
Vado ad aprirlo chiamandolo "volume_data" passandoglio la passphrase scelta in fase di installazione in anaconda:

Ora in /dev/mapper c'è  "volume_data" che contiene al suo interno il file system btrfs e i 3 subvolume.

C'è un solo devid perchè ho scelto un solo device fisico per creare il file system btrfs, niente raid.

Ora monto il subolume di default (quello con id 0) che altro non è che un contenitore di tutti e 3 i subvolume home, var, usr_local

-o subvolid=0 me lo potevo anche risparmiare ma l'ho scritto per essere chiaro nei miei intenti.

In /mnt/data mi troverò le 3 directory corrispondenti ai 3  subvolume di btrfs

ovvero questi

Ora voglio montare questi subvolume separatamente in 3 mount point che vado a creare.

Li posso referenziare sia per id che per nome, come preferisco.

Questo un df -h dopo i 3 montaggi appena effettuati più quello del subvolume 0 di default.

Dell'output di blkid vedo solamente la partizione sda5 cifrata e il volume "volume_data" contenente il file system btrfs con i 3 subvolume.

Sblocco in fase di boot
Ora non mi resta che cercare di capire come avviene lo sblocco in fase di boot: ok, mi chiede la password e la digito ma vorrei capire chi è il responsabile di questa procedura. Secondo me nell'initramfs un processo sblocca il disco e poi durante la fase di boot del sistema systemd rimonta tutte le partizioni senza richiedere nuovamente la passphrase.

L'fstab di Fedora dice

Questo file viene letto dal target local-fs.target per generare al volo le unità .mount che systemd usa per effettuare il montaggio.

C'è anche un crypttab

che immagino venga usato nel target cryptsetup.target per sbloccare (nel caso non sia già sbloccato) e montare le unità cifrate.

Initramfs
Anche nell'initramfs c'è crypttab, ma contiene solo la partizione swap. In effetti io non cifro la root (/) per cui è inutile sbloccare tutto nell'initramfs. In questo caso basta la swap e poi con la stessa passphrase viene sbloccato il volume "data" più tardi durante il boot.

Viene anche passato al kernel il parametro rd.luks.uuid con l'uuid dell'unica partizione da sbloccare in quella fase (quella dove il controllo è nell'initramfs).

in dmesg

Nel mio caso specifico, per prova, tolgo in grub il parametro
rd.luks.uuid=luks-ed8e43d8-c2ec-4a6a-a9dc-5a0c37c5ea4c
e tutto funziona ugualmente. Semplicemente la passphrase per sbloccare le 2 partizioni (1 partizione + 1 volume contenente i subvolume per essere precisi)mi viene richiesta più tardi nella fase di boot. Nel caso in cui avessi cifrato anche la root (/) ovviamente non avrebbe funzionato e sarebbe stato INDISPENSABILE sbloccarla dall'initramfs.

Qui un paio di link che ho consultato durante queste prove:
https://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html#
https://www.freedesktop.org/software/systemd/man/kernel-command-line.html

Mi sono poi "incartato" nel cercare di capire come l'initramfs abbia capito da solo che la swap era da sbloccare subito, mentre il resto si poteva delegare alla normale procedura di boot.
Dracut in questo fa un ottimo lavoro nel capire in autonomia cosa fare.

Se vado a togliere il file crypttab del mio Fedora e poi rigenero l'initramfs, dracut toglie sia il file crypttab sia il modulo crypt anche dall'initramfs.


Nota
1) Per capire cosa avviene durante la fase di boot meglio togliere "quiet" e "rhgb" (Red Hat Graphical Boot) dalla linea vmlinuz di grub.

2) Anche nell'initramfs c'è systemd, i vari target etc... (quindi, delirio anche qui).

3) Si può scompattare il contenuto dell'initramfs tramite il comando
lsinitrd --unpack (initramfs non è più un' archivio cpio)
Poi però non sono riuscito a capire se si possono modificare a mano i file scompattati e ricreare l'initramfs in base alle modifice effettuate. Credo che sia necessario usare dracut e i comandi annessi allo stesso (e funziona piuttosto bene nel capire automaticamente le cose).

 

Print Friendly, PDF & Email