Le installazioni kickstart ci consentono di creare facilmente script e replicare installazioni automatiche o semiautomatiche di Fedora, Red Hat Enterprise Linux o CentOS. Le istruzioni necessarie per installare il sistema operativo sono specificate, con una sintassi dedicata, all'interno di un file Kickstart che viene passato all'installer di Anaconda. In questo tutorial vedremo come riutilizzare un LUKS già esistente (Linux Unified Keys Setup) durante l'esecuzione di un'installazione Kickstart:questo è qualcosa che non può essere ottenuto solo con le istruzioni di Kickstart e richiede alcuni passaggi aggiuntivi.
In questo tutorial imparerai:
- Come utilizzare un container LUKS esistente durante l'esecuzione di un'installazione Kickstart di Fedora, RHEL o CentOS
- Come creare e utilizzare un file update.img da utilizzare con il programma di installazione di Anaconda.
Come installare Fedora/RHEL/CentOS tramite kickstart su un dispositivo LUKS esistente Requisiti e convenzioni software utilizzati
| Categoria | Requisiti, convenzioni o versione del software utilizzata |
|---|---|
| Sistema | Fedora/Rhel/CentOS |
| Software | Non è necessario alcun software specifico per seguire questo tutorial. |
| Altro |
|
| Convenzioni | # – richiede che i comandi linux dati vengano eseguiti con i privilegi di root direttamente come utente root o usando sudo comando$ – richiede che i comandi linux dati vengano eseguiti come un normale utente non privilegiato |
Introduzione
Kickstart ci consente di replicare e personalizzare facilmente le installazioni del sistema operativo in modi semplicemente impossibili da ottenere dal programma di installazione grafico Anaconda. Possiamo, ad esempio, dichiarare quali pacchetti o gruppi di pacchetti dovrebbero essere installati sul sistema e quali invece dovrebbero essere esclusi.
Abbiamo anche la possibilità di eseguire comandi personalizzati prima o dopo l'installazione, specificandoli all'interno dell'apposito %pre e %posta rispettivamente le sezioni del file Kickstart. Sfrutteremo quest'ultima funzione menzionata per utilizzare un LUKS già esistente dispositivo durante il processo di installazione.
Crittografia con sintassi Kickstart nativa
La creazione di contenitori LUKS è abbastanza semplice e può essere eseguita semplicemente utilizzando le istruzioni kickstart native. Ecco un esempio:
part pv.01 --ondisk=sda --encrypted --luks-type=luks1 --cipher=aes-xts-plain64 --pbkdf-time=5000 --passphrase=secretpassphrase
Nell'esempio sopra, usando il part istruzione, creiamo un lvm crittografato volume fisico su /dev/sda disco. Specifichiamo il LUKS versione da usare (luks1 in questo caso – almeno nelle versioni recenti di Fedora luks2 è diventata l'impostazione predefinita), il cifrare e il tempo, espresso in millisecondi, da dedicare a PBKDF (Funzione di derivazione della chiave basata su password) elaborazione della passphrase (equivale a utilizzare il --iter-time opzione di cryptsetup ).
Anche se non è un'abitudine sicura, abbiamo utilizzato anche la --passphrase per fornire la passphrase di crittografia:senza questa opzione, il processo di installazione verrebbe interrotto e verrebbe richiesto di fornirne una in modo interattivo.
Possiamo vedere chiaramente come, utilizzando Kickstart, otteniamo molta più flessibilità rispetto a un'installazione tradizionale; perché dovremmo eseguire passaggi aggiuntivi, allora? Ci sono ancora alcune attività che non possiamo ottenere utilizzando solo la sintassi Kickstart standard. Tra le altre cose, non possiamo creare LUKS contenitori su dispositivi grezzi (solo su partizioni) o specificare l'algoritmo di hashing da utilizzare per LUKS impostazione della chiave, che per impostazione predefinita è sha256 (non c'è niente di male).
Per questi motivi potremmo voler creare la nostra configurazione della partizione prima di eseguire l'installazione, manualmente o utilizzando strumenti come parted all'interno di %pre sezione del file kickstart stesso. Potremmo anche avere solo un LUKS esistente configurazione che non vogliamo distruggere. In tutti questi casi dobbiamo eseguire i passaggi extra che vedremo tra poco.
La sezione %pre kickstart
Il %pre la sezione di un file kickstart è la prima ad essere analizzata quando il file viene recuperato. Viene utilizzato per eseguire comandi personalizzati prima dell'avvio dell'installazione e deve essere chiuso esplicitamente con %end istruzione.
In %pre , l'interprete della shell bash è usato per impostazione predefinita, ma altri possono essere specificati tramite --interpreter opzione (per usare python scriveremmo %pre --interpreter /usr/bin/python ). Possiamo usare questa sezione per eseguire i comandi richiesti per aprire il LUKS esistente contenitore. Ecco cosa possiamo scrivere:
%pre
iotty="$(tty)"
exec > "${iotty}" 2> "${iotty}"
while true; do
cryptsetup luksOpen /dev/sda1 cryptroot - && break
done
%end
Diamo un'occhiata al codice sopra. Prima di tutto, memorizziamo il risultato di tty comando, che stampa il nome del file del terminale collegato allo standard input, nel iotty variabile.
Con exec> "${iotty}" 2> "${iotty}" comando abbiamo reindirizzato l'output standard e l'errore standard allo stesso terminale:
in questo modo saremo in grado di inserire la password del contenitore quando crytpsetup luksOpen il comando verrà eseguito e il prompt verrà visualizzato sullo schermo. Il comando viene lanciato in un ciclo infinito che viene interrotto solo se il LUKS il contenitore è stato aperto correttamente.
Se vogliamo eseguire un'installazione completamente automatica, dobbiamo passare la passphrase direttamente a cryptsetup (di nuovo, questo non è raccomandato). Scriveremmo:
%pre echo -n "ourverysecretpassphrase" | cryptsetup luksOpen /dev/sda1 cryptroot - %end
Nell'esempio sopra abbiamo passato la passphrase allo standard input del comando cryptsetup tramite una pipe | :abbiamo usato echo comando con il -n opzione per evitare che un carattere di nuova riga venga aggiunto alla fine della passphrase.
Patch del programma di installazione di Fedora 31 anaconda
Se proviamo a utilizzare un contenitore LUKS sbloccato durante l'installazione di Fedora 31 tramite Kickstart, riceveremo il seguente
messaggio e il processo verrà interrotto:
Il dispositivo LUKS sbloccato esistente non può essere utilizzato per l'installazione senza una chiave di crittografia specificata per questo
dispositivo. Per favore, scansiona di nuovo lo spazio di archiviazione.
Ciò accade a causa di questo commit introdotto nella versione Fedora 31 del programma di installazione di Anaconda. Il codice fondamentalmente verifica che un dispositivo LUKS esistente abbia una chiave registrata, in caso contrario l'installazione viene interrotta. Il problema è che blivet , la libreria python utilizzata da Anaconda per gestire la partizione acquisisce la chiave solo se da essa viene aperto il container:questo può essere fatto dall'installer grafico ma non c'è, al momento della scrittura, un'istruzione Kickstart per sbloccare un
Creazione di un file update.img
Al momento l'unica soluzione (che io sappia) è quella di patchare il codice sorgente di Anaconda, commentando la riga che esegue il controllo introdotto con il commit di cui sopra. La buona notizia è che è molto semplice da usare.
Come prima cosa, dobbiamo clonare il repository git di Anaconda, in particolare il f31-release filiale:
$ git clone https://github.com/rhinstaller/anaconda -b f31-release
Una volta clonato il repository, inseriamo anaconda directory e modifica pyanaconda/storage/checker.py file:tutto ciò che dobbiamo fare è commentare la riga 619 :
def set_default_checks(self):
"""Set the default checks."""
self.checks = list()
self.add_check(verify_root)
self.add_check(verify_s390_constraints)
self.add_check(verify_partition_formatting)
self.add_check(verify_partition_sizes)
self.add_check(verify_partition_format_sizes)
self.add_check(verify_bootloader)
self.add_check(verify_gpt_biosboot)
self.add_check(verify_swap)
self.add_check(verify_swap_uuid)
self.add_check(verify_mountpoints_on_linuxfs)
self.add_check(verify_mountpoints_on_root)
#self.add_check(verify_unlocked_devices_have_key)
self.add_check(verify_luks_devices_have_key)
self.add_check(verify_luks2_memory_requirements)
self.add_check(verify_mounted_partitions)
Salviamo la modifica e, dalla radice del repository, lanciamo i makeupdates script che si trova negli script directory. Per eseguire lo script dobbiamo avere python2 installato:
$ ./scripts/makeupdates
Lo script genererà il updates.img file che conterrà le nostre modifiche. Per verificarne il contenuto possiamo utilizzare il lsinitrd comando:
$ lsinitrd updates.img Image: updates.img: 8.0K ======================================================================== Version: Arguments: dracut modules: ======================================================================== drwxr-xr-x 3 egdoc egdoc 0 Jan 30 09:29 . drwxr-xr-x 3 egdoc egdoc 0 Jan 30 09:29 run drwxr-xr-x 3 egdoc egdoc 0 Jan 30 09:29 run/install drwxr-xr-x 3 egdoc egdoc 0 Jan 30 09:29 run/install/updates drwxr-xr-x 3 egdoc egdoc 0 Jan 30 09:29 run/install/updates/pyanaconda drwxr-xr-x 2 egdoc egdoc 0 Jan 30 09:29 run/install/updates/pyanaconda/storage -rw-r--r-- 1 egdoc egdoc 25443 Jan 30 09:29 run/install/updates/pyanaconda/storage/checker.py ========================================================================
Useremo questo file per "rattoppare" l'installer di Fedora 31.
Applicazione della patch
Per applicare le modifiche contenute nel file che abbiamo appena generato, dobbiamo posizionarlo in un posto dove possiamo accedervi facilmente, magari tramite ftp o http, o anche su un dispositivo a blocchi locale, e utilizzare il inst.updates parametro per referenziarlo dall'immagine del programma di installazione Fedora. Dal menu di grub evidenziamo la voce di menu "Installa Fedora":
Menu di installazione di Fedora 31
Una volta selezionata la riga di menu, premiamo il tasto Tab:nella parte inferiore dello schermo viene visualizzata la riga di comando del kernel associata alla voce:
La riga di comando del kernel usata dalla voce "Installa Fedora" Tutto quello che dobbiamo fare ora è aggiungere il
inst.updates istruzione e fornire il percorso per updates.img file che abbiamo creato. Supponendo che sia il file Kickstart che il file update.img siano accessibili tramite http su un server locale con ip 192.168.0.37, scriviamo:vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-S-dvd-x86_31-31 quiet inst.updates=http://192.168.0.37/updates.img inst.ks=http://192.168.0.37/ks.cfg
A questo punto possiamo premere invio per avviare. Con la modifica di cui sopra l'installatore non si lamenterà più del
il LUKS sbloccato dispositivo e l'installazione procederà senza problemi.
Conclusioni
In questo articolo abbiamo visto come ottimizzare un'installazione kickstart per riutilizzare un LUKS già esistente dispositivo, sbloccandolo nel %pre sezione del file kickstart e come applicare una piccola soluzione al programma di installazione di Fedora 31 Anaconda che altrimenti fallirebbe quando si tenta questo tipo di installazione. Se sei curioso della sintassi di Kickstart, dai un'occhiata alla documentazione online.