Como instalar o Fedora/Rhel/CentOS via Kickstart em um dispositivo Luks existente

Como instalar o Fedora/Rhel/CentOS via Kickstart em um dispositivo Luks existente

Instalações do Kickstart Vamos script e replicar facilmente instalações sem acompanhamento ou semi-uniformes do Fedora, Red Hat Enterprise Linux ou CentOS. As instruções necessárias para instalar o sistema operacional são especificadas, com uma sintaxe dedicada, dentro de um arquivo Kickstart que é passado para o instalador da Anaconda. Neste tutorial, veremos como reutilizar um já existente Luks (Linux Unified Keys Setup) Contêiner ao executar uma instalação do Kickstart: Isso é algo que não pode ser alcançado apenas com instruções do Kickstart e requer algumas etapas extras.

Neste tutorial, você aprenderá:

  • Como usar um contêiner Luks existente ao executar uma instalação de Kickstart de Fedora, Rhel ou CentOS
  • Como criar e usar uma atualização.arquivo IMG para ser usado com o instalador da Anaconda.
Como instalar o Fedora/Rhel/CentOS via Kickstart em um dispositivo Luks existente

Requisitos de software e convenções usadas

Requisitos de software e convenções de linha de comando Linux
Categoria Requisitos, convenções ou versão de software usada
Sistema Fedora/Rhel/Centos
Programas Nenhum software específico é necessário para seguir este tutorial.
Outro
  • Conhecimento da sintaxe Kickstart
  • Conhecimento de Luks (Configuração da chave unificada do Linux) e o comando CryptSetup.
Convenções # - requer que os comandos Linux sejam executados com privilégios root diretamente como usuário root ou por uso de sudo comando
$ - Requer que os comandos do Linux sejam executados como um usuário não privilegiado regular

Introdução

Kickstart Vamos replicar e personalizar facilmente as instalações do sistema operacional de maneiras que são simplesmente impossíveis de alcançar do instalador gráfico da Anaconda. Podemos, por exemplo, declarar quais pacotes ou grupos de pacotes devem ser instalados no sistema e o que deve ser excluído.

Também temos a chance de executar comandos personalizados antes ou depois que a instalação for executada, especificando -os dentro do dedicado %pré e %publicar seções do arquivo Kickstart, respectivamente. Vamos aproveitar esse último recurso mencionado para usar um já existente Luks dispositivo durante o processo de instalação.

Criptografia com sintaxe de kickstart nativo

Criar contêineres Luks é bastante fácil e pode ser feito apenas usando instruções de kickstart nativas. Aqui está um exemplo:



Parte PV.01 --ondisk = sda --ncrypted--luks-type = luks1-cipher = aes-xts-plain64-pbkdf-time = 5000-passphrase = secretPasshrase

No exemplo acima, usando o papel Instrução, criamos um criptografado lvm volume físico no /Dev/SDA disco. Nós especificamos o Luks versão a ser usada (LUKS1 neste caso - pelo menos nas versões recentes do Fedora Luks2 se tornou o padrão), o cifra, e o tempo, expresso em milissegundos, para gastar por Pbkdf (Função de derivação de chave baseada em senha) Processamento da frase de senha (é o equivalente a usar o --ITER-TIME opção de Cryptsetup).

Mesmo que não seja um hábito seguro, também usamos o --senha Para fornecer a senha de criptografia: sem esta opção, o processo de instalação seria interrompido e seríamos solicitados a fornecer um interativamente.

Podemos ver claramente como, usando o Kickstart, temos muito mais flexibilidade em comparação com uma instalação tradicional; Por que precisamos executar etapas extras, então? Ainda existem algumas tarefas que não podemos alcançar usando apenas a sintaxe do kickstart padrão. Entre outras coisas, não podemos criar Luks contêineres em dispositivos brutos (apenas em partições) ou especifique o algoritmo de hash para usar para o Luks A configuração de chaves, que por padrão está definida como SHA256 (nada de errado com isso).

Por esses motivos, podemos querer criar nossa configuração de partição antes de executar a instalação, manualmente ou usando ferramentas como separadas dentro do %pré Seção do próprio arquivo Kickstart. Também podemos apenas ter um Luks configuração não queremos destruir. Em todos esses casos, devemos executar as etapas extras que veremos em um momento.

O Kickstart %pré se seção

O %pré A seção de um arquivo Kickstart é a primeira a ser analisada quando o arquivo é recuperado. É usado para executar comandos personalizados antes do início da instalação e deve ser fechado explicitamente com o %fim instrução.

Em %pré, O intérprete de shell bash é usado por padrão, mas outros podem ser especificados através do --intérprete opção (para usar python, escrevíamos %pré -interpretador/usr/bin/python). Podemos usar esta seção para executar os comandos necessários para abrir o existente Luks recipiente. Aqui está o que podemos escrever:

%pre IOTty = "$ (tty)" Exec> "$ iotty" 2> "$ iotty" while true; Do CryptSetSetup Luksopen /dev /sda1 Cryptroot - && quebrar
cópia de

Vamos dar uma olhada no código acima. Primeiro de tudo, armazenamos o resultado do tty comando, que imprime o nome do arquivo do terminal conectado à entrada padrão, no iotty variável.

Com o Exec> "$ Iotty" 2> "$ iotty" Comando, redirecionamos a saída padrão e o erro padrão para o mesmo terminal:
Dessa forma, poderemos entrar na senha do contêiner quando o Crytpsetup Luksopen O comando será executado e o prompt será exibido na tela. O comando é lançado em um loop infinito que é interrompido apenas se o Luks O contêiner é aberto com sucesso.

Se queremos precisar executar uma instalação completamente desacompanhada, devemos passar na senha diretamente para o CryptSetup (novamente, isso não é recomendado). Nós escrevíamos:

%pré -echo -N "OurverySecretPassphrase" | Cryptsetup Luksopen /dev /sda1 Cryptroot - %final

No exemplo acima, passamos a senha para a entrada padrão do comando Cryptsetup através de um tubo |: Usamos o eco comando com o -n opção para evitar um personagem de nova linha a ser anexado no final da senha.

Patching Fedora 31 Anaconda Installer

Se tentarmos usar um contêiner Luks desbloqueado ao instalar o Fedora 31 via Kickstart, receberemos o seguinte
mensagem, e o processo será abortado:

O dispositivo Luks desbloqueado existente não pode ser usado para a instalação sem uma chave de criptografia especificada para este
dispositivo. Por favor, rescam o armazenamento.

Isso acontece devido a esse commit introduzido na versão Fedora 31 do instalador da Anaconda. O código verifica basicamente se um dispositivo Luks existente possui uma chave registrada, se não a instalação é abortada. O problema é que Blivet, A biblioteca Python usada pela Anaconda para gerenciar a partição adquire a chave apenas se o contêiner for aberto por ele: isso pode ser feito no instalador gráfico, mas não houver, no momento da redação, uma instrução de kickstart para desbloquear um existente Luks recipiente. Pessoalmente, comentei o compromisso explicando a situação, e um bug foi aberto no Red Hat Bugzilla.

Criando atualizações.arquivo IMG

No momento, a única solução alternativa (que eu conheço) é corrigir o código -fonte da Anaconda, comentando a linha que executa o controle introduzido com a confirmação que mencionamos acima. A boa notícia é que é muito simples de operar.

Como primeira coisa, precisamos clonar o repositório do Anaconda Git, especificamente o F31-RELEASE filial:

$ git clone https: // github.com/rhinstaller/anaconda -b f31 -lançamento


Depois que o repo é clonado, entramos no Anaconda diretório e modifique o Pyanaconda/armazenamento/verificador.py Arquivo: Tudo o que precisamos fazer é comentar a linha 619:

def set_default_checks (self): "" "Defina as verificações padrão.""" auto.checks = list () self.add_check (verify_root) self.add_check (verify_s390_constraints).add_check (verify_partition_formatting).add_check (verify_partition_sizes) self.add_check (verify_partition_format_sizes) self.add_check (verify_bootloader) self.add_check (verify_gpt_biosboot).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)
cópia de

Salvamos a modificação e, da raiz do repositório, lançamos o maquiagem script que é encontrado no scripts diretório. Para que o script seja executado, devemos ter Python2 instalado:

$ ./scripts/makeupdates

O script gerará o Atualizações.img arquivo que conterá nossas modificações. Para verificar seu conteúdo, podemos usar o Lsinitrd comando:

Atualizações de $ lsinitrd.Imagem IMG: Atualizações.IMG: 8.0k ================================================== ======================== Versão: Argumentos: Dracut Módulos: ======================== =================================================== == drwxr-xr-x 3 egdoc egdoc 0 30 de janeiro 09:29 . drwxr-xr-x 3 egdoc egdoc 0 de janeiro 09:29 execute drwxr-xr-x 3 egdoc egdoc 0 30 de janeiro 09:29 run/install drwxr-xr-x 3 egdoc egdoc 0 jan 30 09:29 run/install//install// Atualizações drwxr-xr-x 3 egdoc egdoc 0 30 de janeiro 09:29 run/install/updates/pyanaconda drwxr-xr-x 2 egdoc egdoc 0 30 de janeiro 09:29 run/install/atualizações/pyanaconda/armazenamento -rw-r- -R-- 1 EGDOC EGDOC 25443 30 de janeiro 09:29 Run/Install/Atualizações/Pyanaconda/Armazenamento/Verificador.py ================================================== ======================== 

Usaremos este arquivo para "corrigir" o instalador do Fedora 31.

Aplicando o patch

Para aplicar as modificações contidas no arquivo que acabamos de gerar, precisamos colocá -lo em algum lugar onde possamos acessá -lo facilmente, talvez via FTP ou HTTP, ou mesmo em um dispositivo de bloco local e usar o inst.Atualizações Parâmetro para fazer referência à imagem do instalador do Fedora. No menu Grub, destacamos a entrada do menu "Instalar Fedora":



Menu do instalador do Fedora 31

Depois que a linha de menu é selecionada, pressionamos a tecla TAB: A linha de comando do kernel associada à entrada é exibida na parte inferior da tela:



A linha de comando do kernel usada pela entrada "instalar fedora" tudo o que precisamos fazer agora é anexar o inst.Atualizações instrução e fornecer o caminho para o Atualizações.img arquivo que criamos. Supondo que o Kickstart e as atualizações.O arquivo IMG é acessível via HTTP em um servidor local com IP 192.168.0.37, escrevíamos:
vmlluz initrd = initrd.img inst.Stage2 = HD: Label = Fedora-S-DVD-X86_31-31 Quiet inst.Atualizações = http: // 192.168.0.37/Atualizações.img inst.KS = http: // 192.168.0.37/ks.cfg

Neste ponto, podemos pressionar Enter para inicializar. Com a modificação acima, o instalador não reclamará mais sobre
o desbloqueado Luks dispositivo e a instalação prosseguirá sem problemas.

Conclusões

Neste artigo, vimos como ajustar uma instalação do Kickstart para reutilizar um já existente Luks dispositivo, desbloqueando -o no %pré Seção do arquivo Kickstart e como aplicar uma pequena solução alternativa ao instalador do Fedora 31 Anaconda, que de outra forma falharia quando esse tipo de instalação for tentado. Se você está curioso sobre a sintaxe do Kickstart, dê uma olhada na documentação online.

Tutoriais do Linux relacionados:

  • Coisas para instalar no Ubuntu 20.04
  • Como instalar Debian em um contêiner Luks existente
  • Como instalar o Anaconda Scientific Computing Python…
  • Como executar instalações Linux sem assistência com o Kickstart
  • Como usar um arquivo como uma chave do dispositivo Luks
  • Oracle Linux vs Red Hat (RHEL)
  • Download do Linux
  • Coisas para fazer depois de instalar o Ubuntu 20.04 fossa focal linux
  • Uma introdução à automação, ferramentas e técnicas do Linux
  • Coisas para instalar no Ubuntu 22.04