Las instalaciones de Kickstart nos permiten crear secuencias de comandos y replicar fácilmente instalaciones desatendidas o semidesatendidas de Fedora, Red Hat Enterprise Linux o CentOS. Las instrucciones necesarias para instalar el sistema operativo se especifican, con una sintaxis dedicada, dentro de un archivo Kickstart que se pasa al instalador de Anaconda. En este tutorial veremos cómo reutilizar un LUKS ya existente (Configuración de claves unificadas de Linux) al realizar una instalación Kickstart:esto es algo que no se puede lograr solo con las instrucciones de Kickstart y requiere algunos pasos adicionales.
Cómo instalar Fedora/RHEL/CentOS mediante kickstart en un dispositivo LUKS existente
Requisitos de software y convenciones de la línea de comandos de Linux | Categoría | Requisitos, convenciones o versión de software utilizada |
|---|
| Sistema | Fedora/Rhel/CentOS |
| Software | No se necesita ningún software específico para seguir este tutorial. |
| Otro | - Conocimiento de la sintaxis Kickstart
- Conocimiento de LUKS (Linux Unified Key Setup) y el comando cryptsetup.
|
| Convenciones | # – requiere que los comandos de Linux dados se ejecuten con privilegios de root, ya sea directamente como usuario root o mediante el uso de sudo comando
$ – requiere que los comandos de Linux dados se ejecuten como un usuario normal sin privilegios |
Introducción
Kickstart nos permite replicar y personalizar fácilmente las instalaciones del sistema operativo de formas que son simplemente imposibles de lograr desde el instalador gráfico de Anaconda. Podemos, por ejemplo, declarar qué paquetes o grupos de paquetes deben instalarse en el sistema y cuáles deben excluirse en su lugar.
También tenemos la posibilidad de ejecutar comandos personalizados antes o después de que se realice la instalación, especificándolos dentro del %pre dedicado y %post secciones del archivo Kickstart respectivamente. Aprovecharemos esta última característica mencionada para usar un LUKS ya existente dispositivo durante el proceso de instalación.
Cifrado con sintaxis Kickstart nativa
Crear contenedores LUKS es bastante fácil y se puede hacer simplemente usando las instrucciones nativas de kickstart. Aquí hay un ejemplo:
part pv.01 --ondisk=sda --encrypted --luks-type=luks1 --cipher=aes-xts-plain64 --pbkdf-time=5000 --passphrase=secretpassphrase
En el ejemplo anterior, usando la part instrucción, creamos un lvm encriptado volumen físico en el /dev/sda disco. Especificamos el LUKS versión a utilizar (luks1 en este caso – al menos en versiones recientes de Fedora luks2 se ha convertido en la predeterminada), el cipher y el tiempo, expresado en milisegundos, para gastar en PBKDF (Función de derivación de clave basada en contraseña) procesamiento de frase de contraseña (es el equivalente a usar --iter-time opción de cryptsetup ).
Incluso si no es un hábito seguro, también usamos la --passphrase para proporcionar la frase de contraseña de cifrado:sin esta opción, el proceso de instalación se interrumpiría y se nos pediría que proporcionemos una de forma interactiva.
Podemos ver claramente cómo, usando Kickstart, obtenemos mucha más flexibilidad en comparación con una instalación tradicional; ¿Por qué tendríamos que realizar pasos adicionales, entonces? Todavía hay algunas tareas que no podemos lograr usando solo la sintaxis estándar de Kickstart. Entre otras cosas, no podemos crear LUKS contenedores en dispositivos sin procesar (solo en particiones) o especificar el algoritmo hash que se usará para el LUKS configuración de teclas, que por defecto está establecida en sha256 (no tiene nada de malo).
Por estas razones, es posible que deseemos crear nuestra configuración de partición antes de realizar la instalación, ya sea manualmente o utilizando herramientas como parted inside the %pre sección del propio archivo kickstart. También es posible que solo tengamos un LUKS existente configuración que no queremos destruir. En todos estos casos debemos realizar los pasos extra que veremos en un momento.
La sección kickstart %pre
El %pre La sección de un archivo kickstart es la primera que se analiza cuando se recupera el archivo. Se utiliza para ejecutar comandos personalizados antes de que comience la instalación y debe cerrarse explícitamente con %end instrucción.
En %pre , el intérprete de shell bash se usa de forma predeterminada, pero se pueden especificar otros a través del --interpreter opción (para usar python escribiríamos %pre --interpreter /usr/bin/python ). Podemos usar esta sección para ejecutar los comandos necesarios para abrir el LUKS existente envase. Esto es lo que podemos escribir:
%pre
iotty="$(tty)"
exec > "${iotty}" 2> "${iotty}"
while true; do
cryptsetup luksOpen /dev/sda1 cryptroot - && break
done
%end
Echemos un vistazo al código de arriba. En primer lugar, almacenamos el resultado del tty comando, que imprime el nombre de archivo del terminal conectado a la entrada estándar, en el iotty variables.
Con el exec> "${iotty}" 2> "${iotty}" redirijimos la salida estándar y el error estándar al mismo terminal:
de esta manera podremos ingresar la contraseña del contenedor cuando crytpsetup luksOpen se ejecutará el comando y se mostrará el aviso en la pantalla. El comando se inicia en un bucle infinito que se interrumpe solo si LUKS el contenedor se abrió con éxito.
Si queremos ejecutar una instalación completamente desatendida, debemos pasar la frase de contraseña directamente a cryptsetup (nuevamente, esto no se recomienda). Escribiríamos:
%pre
echo -n "ourverysecretpassphrase" | cryptsetup luksOpen /dev/sda1 cryptroot -
%end
En el ejemplo anterior, pasamos la frase de contraseña a la entrada estándar del comando cryptsetup a través de una tubería | :usamos el echo comando con -n opción para evitar que se agregue un carácter de nueva línea al final de la frase de contraseña.
Parcheando el instalador anaconda de Fedora 31
Si intentamos usar un contenedor LUKS desbloqueado al instalar Fedora 31 a través de Kickstart, recibiremos el siguiente
mensaje y el proceso se cancelará:
El dispositivo LUKS desbloqueado existente no se puede usar para la instalación sin una clave de cifrado especificada para este
dispositivo. Por favor, vuelva a escanear el almacenamiento.
Esto sucede debido a este compromiso introducido en la versión Fedora 31 del instalador de Anaconda. El código básicamente verifica que un dispositivo LUKS existente tenga una clave registrada, si no la tiene, la instalación se cancela. El problema es que blivet , la biblioteca de python utilizada por Anaconda para administrar la partición adquiere la clave solo si abre el contenedor:esto se puede hacer desde el instalador gráfico pero no hay, en el momento de escribir, una instrucción de Kickstart para desbloquear un LUCAS envase. Comenté personalmente el compromiso explicando la situación, y se ha abierto un error en red hat bugzilla.
Crear un archivo de actualizaciones.img
Por el momento, la única solución (que yo sepa) es parchear el código fuente de Anaconda, comentando la línea que ejecuta el control introducido con el compromiso que mencionamos anteriormente. La buena noticia es que es muy simple de operar.
Como primera cosa, necesitamos clonar el repositorio git de Anaconda, específicamente el f31-release rama:
$ git clone https://github.com/rhinstaller/anaconda -b f31-release
Una vez clonado el repositorio, ingresamos el anaconda directorio y modifique el pyanaconda/storage/checker.py archivo:todo lo que tenemos que hacer es comentar la línea 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)
Guardamos la modificación y, desde la raíz del repositorio, lanzamos el makeupdates script que se encuentra en los scripts directorio. Para que se ejecute el script debemos tener python2 instalado:
$ ./scripts/makeupdates
El script generará el updates.img archivo que contendrá nuestras modificaciones. Para comprobar su contenido podemos utilizar el 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
========================================================================
Usaremos este archivo para "parchar" el instalador de Fedora 31.
Aplicación del parche
Para aplicar las modificaciones contenidas en el archivo que acabamos de generar, debemos ubicarlo en algún lugar al que podamos acceder fácilmente, tal vez a través de ftp o http, o incluso en un dispositivo de bloqueo local, y usar inst.updates para referenciarlo desde la imagen del instalador de Fedora. Desde el menú de grub, destacamos la entrada de menú "Instalar Fedora":
Menú de instalación de Fedora 31
Una vez que se selecciona la línea de menú, presionamos la tecla Tab:la línea de comando del kernel asociada con la entrada se muestra en la parte inferior de la pantalla:
La línea de comando del kernel utilizada por la entrada "Instalar Fedora". Todo lo que tenemos que hacer ahora es agregar inst.updates instrucción y proporcione la ruta a updates.img archivo que creamos. Suponiendo que tanto el archivo Kickstart como el archivo upgrades.img sean accesibles a través de http en un servidor local con IP 192.168.0.37, escribiríamos: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
En este punto podemos presionar enter para iniciar. Con la modificación anterior, el instalador ya no se quejará de
el LUKS desbloqueado dispositivo, y la instalación continuará sin problemas.
Conclusiones
En este artículo vimos cómo ajustar una instalación kickstart para reutilizar un LUKS ya existente dispositivo, desbloqueándolo en el %pre sección del archivo kickstart, y cómo aplicar una pequeña solución al instalador de Fedora 31 Anaconda que, de lo contrario, fallaría cuando se intentara este tipo de instalación. Si tiene curiosidad acerca de la sintaxis de Kickstart, consulte la documentación en línea.
Cómo instalar Fedora/RHEL/CentOS mediante kickstart en un dispositivo LUKS existente