17 Preparando o ambiente de boot de rede #
Este capítulo descreve como configurar um servidor DHCP e TFTP que fornecem a infraestrutura necessária para inicialização com PXE.
É possível instalar o SUSE® Linux Enterprise Server por meio de um PXE (Preboot Execution Environment). O hardware do cliente precisa suportar a inicialização via PXE. A rede precisa ter um servidor DHCP e um servidor TFTP para fornecer os dados necessários aos clientes. Este capítulo guiará você pela configuração dos servidores necessários.
O PXE inicializa apenas um kernel e um initrd. Ele pode ser usado para inicialização em um ambiente de instalação ou em sistemas ativos. Para configurar as fontes de instalação, consulte o Capítulo 16, Configurando uma fonte de instalação de rede.
Esta seção aborda as tarefas de configuração necessárias em cenários complexos de inicialização. Contém exemplos de configurações prontas para aplicar referentes a DHCP, inicialização PXE, TFTP e Wake on LAN.
Os exemplos consideram que os servidores DHCP, TFTP e NFS residem na mesma máquina com o IP 192.168.1.1
. Todos os serviços podem residir em máquinas diferentes sem nenhum problema. Mude os endereços IP conforme necessário.
17.1 Configurando um servidor DHCP #
Um servidor DHCP oferece atribuições de endereço IP tanto dinâmico (Seção 17.1.1, “Atribuição dinâmica de endereço”) quanto estático (Seção 17.1.2, “Atribuindo endereços IP estáticos”) aos clientes de rede. Ele divulga servidores, rotas e domínios. Para servidores TFTP, o DHCP também inclui os arquivos kernel e initrd. Os arquivos que precisam ser carregados dependem da arquitetura da máquina de destino e se o boot de BIOS ou UEFI legado foi utilizado. Os clientes transmitem o tipo de arquitetura nas solicitações DHCP. Com base nessas informações, o servidor DHCP decide de quais arquivos o cliente deve fazer download para inicialização.
A partir do SUSE Linux Enterprise 15.0, há condições especiais que causam falha no boot do PXE e nas instalações do AutoYaST. Consulte a Seção 17.1.3, “Falhas na instalação do PXE e do AutoYaST” para obter mais informações e saber a solução.
17.1.1 Atribuição dinâmica de endereço #
O exemplo a seguir mostra como configurar um servidor DHCP que atribui dinamicamente endereços IP a clientes e divulga servidores, roteadores, domínios e arquivos de boot.
Efetue login como
root
na máquina que hospeda o servidor DHCP.Habilite o servidor DHCP executando
systemctl enable dhcpd
.Anexe as linhas seguintes a uma configuração de sub-rede do arquivo de configuração de seu servidor DHCP localizado em
/etc/dhcpd.conf
:# The following lines are optional option domain-name "my.lab"; option domain-name-servers 192.168.1.1; option routers 192.168.1.1; option ntp-servers 192.168.1.1; ddns-update-style none; default-lease-time 3600; # The following lines are required option arch code 93 = unsigned integer 16; # RFC4578 subnet 192.168.1.0 netmask 255.255.255.0 { next-server 192.168.1.1; range 192.168.1.100 192.168.1.199; default-lease-time 3600; max-lease-time 3600; if option arch = 00:07 or option arch = 00:09 { filename "/EFI/x86/grub.efi"; } else if option arch = 00:0b { filename "/EFI/aarch64/bootaa64.efi"; } else { filename "/BIOS/x86/pxelinux.0"; } }
Este exemplo de configuração usa a sub-rede
192.168.1.0/24
com o DHCP, o DNS e o gateway no servidor com o IP192.168.1.1
. Verifique se todos os endereços IP mudam de acordo com o layout da rede. Para obter mais informações sobre as opções disponíveis emdhcpd.conf
, consulte a página de manual sobredhcpd.conf
.Reinicie o servidor DHCP executando
systemctl restart dhcpd
.
17.1.2 Atribuindo endereços IP estáticos #
Um servidor DHCP também pode atribuir endereços IP estáticos e nomes de host aos clientes de rede. Um caso de uso é atribuir endereços estáticos a servidores. Outro caso de uso é restringir os clientes que podem ingressar na rede àqueles com os endereços IP estáticos atribuídos e sem fornecer pools de endereços dinâmicos.
Modifique a configuração DHCP acima de acordo com o exemplo a seguir:
group { host test { hardware ethernet MAC_ADDRESS; fixed-address IP_ADDRESS; } }
A declaração de host atribui um nome de host ao destino da instalação. Para vincular o nome de host e o endereço IP a um host específico, você deve especificar o endereço de hardware (MAC) do cliente. Substitua todas as variáveis usadas neste exemplo pelos valores reais que correspondem ao seu ambiente e, em seguida, grave as mudanças e reinicie o servidor DHCP.
17.1.3 Falhas na instalação do PXE e do AutoYaST #
A partir do SUSE Linux Enterprise 15.0 e do ISC DHCP 4.3.x, há circunstâncias especiais que causam falha no boot do PXE e nas instalações do AutoYaST. Se o seu servidor DHCP não tiver um pool de endereços IP dinâmicos disponíveis, mas permitir apenas endereços estáticos predefinidos por cliente, e os clientes enviarem identificadores de cliente RFC 4361, as instalações do PXE/AutoYaST não funcionarão. (Ao permitir apenas os endereços atribuídos a clientes de rede específicos sem fornecer pools de endereços dinâmicos, você impede que máquinas aleatórias ingressem na rede.)
Quando um novo sistema é iniciado no PXE, ele envia uma solicitação ao servidor DHCP e se identifica usando um identificador de cliente criado com base no tipo de hardware e no endereço MAC da interface de rede. Trata-se de um client-id
RFC 2132. Em seguida, o servidor DHCP oferece o endereço IP atribuído. Na sequência, o kernel de instalação é carregado e envia outra solicitação DHCP, mas o client-id
é diferente e enviado no formato RFC 4361. O servidor DHCP não o reconhecerá como sendo o mesmo cliente e procurará um endereço IP dinâmico livre, que não está disponível, e a instalação será interrompida.
A solução é configurar os clientes para enviar IDs de cliente RFC 2132. Para enviar um client-id
RFC 2132 durante a instalação, use linuxrc
para especificar o seguinte comando ifcfg
:
ifcfg=eth0=dhcp,DHCLIENT_CLIENT_ID=01:03:52:54:00:02:c2:67, DHCLIENT6_CLIENT_ID=00:03:52:54:00:02:c2:67
O client-id
DHCPv4 RFC 2132 que costuma ser usado no Ethernet é construído com base no tipo de hardware (01
para Ethernet) e seguido pelo endereço do hardware (endereço MAC), por exemplo:
01:52:54:00:02:c2:67
O client-id
DHCPv4 RFC 4361 tenta corrigir o problema de identificação de uma máquina que tem mais de uma interface de rede. O novo client-id
DHCPv4 tem o mesmo formato que o client-id
DHCPv6. Ele começa com o prefixo 0xff
, em vez do tipo de hardware, seguido pelo IAID (o ID de associação de endereço de interface que descreve a interface na máquina) DHCPv6, seguido pelo Identificador Exclusivo (DUID, DHCP Unique Identifier) DHCPv6, que identifica a máquina exclusivamente.
Ao usar o DUID acima baseado no endereço do hardware e no tipo de hardware, o novo client-id
DHCPv4 RFC 4361 é:
Ao usar os últimos bytes do endereço MAC como o IAID:
ff:00:02:c2:67:00:01:xx:xx:xx:xx:52:54:00:02:c2:67
Quando o IAID é um número incrementado simples:
ff:00:00:00:01:00:01:xx:xx:xx:xx:52:54:00:02:c2:67
O campo xx:xx:xx:xx na Marcação de Horário de Camada de Link DUID (DUID-LLT, DUID-Link-Layer Timestamp) é a marcação de horário da criação. Uma Camada de Link DUID (DUID-LL, DUID-Link-Layer) (00:03:00:01:$MAC
) não tem uma marcação de horário.
Para obter mais informações sobre como usar o linuxrc
, consulte o AutoYaST Guide. Consulte também man 4 initrd
e a documentação para ver as opções dhcp4
"create-cid"
, dhcp6 "default-duid"
em man 5 wicked-config
, wicked duid
--help
e wicked iaid --help
.
17.2 Configurando um servidor TFTP #
O procedimento a seguir descreve como preparar o servidor para que as máquinas cliente com UEFI e BIOS possam ser inicializadas remotamente usando os arquivos exportados pelo TFTP.
17.2.1 Instalando um servidor TFTP #
Para instalar um servidor TFTP, siga o procedimento abaixo:
Instale o pacote
tftp
.>
sudo
zypper in tftp
Revise a configuração do
tftpd
em/etc/sysconfig/tftp
e adicione ou mude as opções conforme necessário. Consulte aman 8 tftpd
para obter mais detalhes. O daemon do TFTP funciona sem mudar a configuração. O diretório raiz padrão para os arquivos é/srv/tftpboot
.Verifique se o
tftpd
foi iniciado no momento da inicialização e reinicie-o para ler a nova configuração.>
sudo
systemctl enable tftp.socket
>
sudo
systemctl restart tftp.socket
17.2.2 Instalando arquivos para inicialização #
O SUSE Linux Enterprise Server fornece os arquivos necessários para inicialização via PXE nas máquinas BIOS ou UEFI. As seguintes arquiteturas de hardware são suportadas:
AMD64/Intel 64
AArch64
POWER
IBM Z
Os arquivos necessários para a inicialização de uma arquitetura de hardware específica estão incluídos em um pacote RPM. Instale-o na máquina que executa o servidor TFTP:
>
sudo
zypper in tftpboot-installation-SLE-OS_VERSION-ARCHITECTURE
Substitua OS_VERSION pelo número da versão da instalação do SUSE Linux Enterprise Server, por exemplo, SLE-15-SP3-x86_64, e ARCHITECTURE pela arquitetura do seu sistema, como x86_64
. Desse modo, o texto resultante terá a seguinte aparência: tftpboot-installation-SLE-15-SP3-x86_64. Execute zypper se tftpboot
para pesquisar todas as arquiteturas e versões disponíveis.
Os arquivos serão instalados em /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE
. Você também pode copiar os arquivos de outras versões e arquiteturas do SUSE Linux Enterprise Server para o diretório /srv/tftpboot
.
A arquitetura do hardware do cliente e do servidor pode variar. Por exemplo, você pode executar um servidor TFTP AMD64/Intel 64 e fornecer um ambiente inicializável para as máquinas cliente AArch64 instalando o pacote tftpboot-installation-SLE-15-SP3-aarch64.
/srv/tftpboot/
existente
Se o diretório /srv/tftpboot/
já existe na máquina, todos os arquivos são instalados em /usr/share/tftpboot-installation/
. Esse é o caso do upgrade do servidor PXE de uma versão anterior do SLES.
Para corrigir esse problema, copie os arquivos manualmente de /usr/share/tftpboot-installation/
para /srv/tftpboot/
. Se preferir, remova o /srv/tftpboot/
e reinstale o pacote tftpboot-installation-SLE-OS_VERSION-ARCHITECTURE.
17.2.3 Configurando o PXELINUX #
Abra o arquivo /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/net/pxelinux.cfg/default
em um editor. Substitua o caminho para o parâmetro install
de acordo com a sua configuração, conforme descrito no Capítulo 16, Configurando uma fonte de instalação de rede. Substitua também TFTP_SERVER pelo endereço IP do servidor TFTP. Para obter uma visão geral das opções de configuração PXELINUX, consulte a Seção 17.3, “Opções de configuração PXELINUX”.
default linux # install label linux ipappend 2 kernel boot/ARCHITECTURE/loader/linux append initrd=boot/ARCHITECTURE/loader/initrd instsys=tftp://TFTP_SERVER/SLE-OS_VERSION-ARCHITECTURE/boot/ARCHITECTURE/root install=PROTOCOL://SERVER_IP:/PATH display message implicit 1 prompt 1 timeout 50
Para obter detalhes sobre os parâmetros de boot que são usados na linha append
, consulte a Seção 7.3, “Lista de parâmetros de boot importantes”.
Se necessário, edite o /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/net/pxelinux.cfg/message
para exibir uma mensagem no menu de boot.
17.2.4 Preparando o boot PXE para EFI com GRUB2 #
Normalmente, os arquivos de configuração do GRUB2 não exigem modificações. No entanto, as configurações padrão não incluem um recurso de rede para o sistema de instalação. Para executar uma instalação completa do SUSE Linux Enterprise Server pela rede, você precisa especificar o parâmetro install
na instrução linuxefi
do arquivo /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/EFI/BOOT/grub.cfg
. Consulte a Seção 7.3.3, “Especificando a fonte de instalação” para obter mais informações sobre o parâmetro install
.
17.3 Opções de configuração PXELINUX #
As opções relacionadas aqui são um subconjunto de todas as opções disponíveis para o arquivo de configuração PXELINUX.
APPEND OPTIONS
Adiciona uma ou mais opções à linha de comando do kernel. São adicionadas para inicializações manuais e automáticas. As opções são adicionadas no início da linha de comando do kernel, normalmente permitindo que as opções de kernel digitadas explicitamente as substituam.
APPEND -
Não anexa nada.
APPEND
com um único hífen como argumento em uma seçãoLABEL
pode ser usado para anular umAPPEND
global.DEFAULT KERNEL_OPTIONS...
Configura a linha de comando padrão do kernel. Quando o PXELINUX é inicializado automaticamente, ele executa as entradas especificadas, anexando a opção
auto
.Se não houver nenhum arquivo de configuração ou nenhuma entrada DEFAULT definida no arquivo de configuração, o padrão será o nome do kernel “linux” sem opções.
IFAPPEND FLAG
Adiciona uma opção específica à linha de comando do kernel de acordo com o valor FLAG. A opção
IFAPPEND
está disponível apenas no PXELINUX. FLAG espera um valor, descrito em Tabela 17.1, “Opções de linha de comando do kernel geradas e adicionadas doIFAPPEND
”:Tabela 17.1: Opções de linha de comando do kernel geradas e adicionadas doIFAPPEND
#Argumento
Linha de comando do kernel gerada/descrição
1
ip=CLIENT_IP:BOOT_SERVER_IP:GW_IP:NETMASK
Os marcadores são substituídos de acordo com a entrada do servidor DHCP/BOOTP ou boot PXE.
Observe que essa opção não substitui a execução de um cliente DHCP no sistema inicializado. Sem as renovações regulares, o aluguel adquirido pelo BIOS PXE vai expirar, disponibilizando o endereço IP para reutilização do servidor DHCP.
2
BOOTIF=MAC_ADDRESS_OF_BOOT_INTERFACE
Essa opção é útil para evitar tempos de espera quando o servidor de instalação investiga uma interface LAN em seguida da outra, até obter uma resposta de um servidor DHCP. Essa opção permite que um programa initrd determine de qual interface o sistema foi inicializado. O linuxrc lê essa opção e utiliza essa interface de rede.
4
SYSUUID=SYSTEM_UUID
Adiciona UUIDs como hexadecimais em minúsculas, consulte
/usr/share/doc/packages/syslinux/pxelinux.txt
LABEL LABEL KERNEL IMAGE APPEND OPTIONS...
Se LABEL foi inserido como o kernel de boot, indica que o PXELINUX deve inicializar a IMAGE e que as opções
APPEND
especificadas devem ser usadas. Elas substituem as que foram especificadas na seção global do arquivo, antes do primeiro comandoLABEL
. O padrão para IMAGE é o mesmo de LABEL e, se não for fornecido nenhumAPPEND
, o padrão será usar a entrada global (se houver). Até 128 entradasLABEL
são permitidas.E PXELINUX usa a seguinte sintaxe:
label MYLABEL kernel MYKERNEL append MYOPTIONS
Os rótulos são desmembrados como se fossem nomes de arquivo e deverão ser exclusivos após o desmembramento. Por exemplo, não seria possível distinguir os dois rótulos “v2.6.30” e “v2.6.31” em PXELINUX, pois ambos são desmembrados em um mesmo nome de arquivo do DOS.
O kernel não precisa ser do Linux. Ele também pode ser um setor de boot ou um arquivo COMBOOT.
LOCALBOOT TYPE
Em PXELINUX, especificar
LOCALBOOT 0
em vez de uma opçãoKERNEL
significa chamar este rótulo específico e causa uma inicialização de disco local em vez de uma inicialização de kernel.Argumento
Descrição
0
Executa uma inicialização normal
4
Executa uma inicialização local com o driver UNDI (Universal Network Driver Interface) ainda residente na memória
5
Realiza uma inicialização local com toda a pilha PXE, incluindo o driver UNDI, ainda residente na memória
Todos os outros valores são indefinidos. Se você não sabe quais são as pilhas UNDI ou PXE, especifique
0
.TIMEOUT TIME-OUT
Indica quanto tempo esperar no prompt de boot até inicializar automaticamente, em unidades de 1/10 de segundo. O tempo de espera é cancelado quando o usuário digita algo no teclado, considerando que ele concluirá o comando que começou. O tempo de espera zero desabilita completamente o tempo de espera (que é também o padrão). O valor do tempo de espera máximo possível é 35996 (pouco menos de uma hora).
PROMPT flag_val
Se
flag_val
for 0, o prompt de boot apenas será exibido se a tecla Shift ou Alt for pressionada ou se Caps Lock ou Scroll Lock estiver ativado (padrão). Seflag_val
for 1, o prompt de boot sempre será exibido.F2 FILENAME F1 FILENAME ..etc.. F9 FILENAME F10 FILENAME
Exibe o arquivo indicado na tela quando uma tecla de função é pressionada no prompt de boot. Isso pode ser usado para implementar a ajuda online de pré-inicialização (supostamente para as opções de linha do comando do kernel). Para compatibilidade com versões anteriores, 10 também pode ser digitado como
F0
F. Observe que ainda não há um meio de vincular nomes de arquivo a F11 e F12.
17.4 Preparando o sistema de destino para boot PXE #
Prepare o BIOS do sistema para a inicialização PXE incluindo a opção PXE na ordem de inicialização do BIOS.
Não coloque a opção PXE na frente do parâmetro de boot do disco rígido no BIOS. Do contrário, o sistema tentaria se reinstalar sempre que fosse inicializado.
17.5 Usando wake-on-LAN para ativações remotas #
Wake-on-LAN (WOL) é um padrão Ethernet para ativar remotamente um computador enviando para ele um sinal de ativação pela rede. Esse sinal é chamado de “magic packet”. Instale o WOL nas máquinas cliente para habilitar as ativações remotas e em todas as máquinas que deseja usar para enviar o sinal de ativação. O magic packet é transmitido pela porta UDP 9 para o endereço MAC da interface de rede na máquina cliente.
Quando são encerrados, geralmente os computadores não são totalmente desligados, mas permanecem em um modo de baixa energia. Quando a interface de rede suporta WOL, ela escuta o sinal de ativação magic packet quando a máquina é desligada. Você pode enviar o magic packet manualmente ou programar as ativações em um Cron na máquina de envio.
17.5.1 Pré-requisitos #
O WOL funciona com placas Ethernet com e sem fio compatíveis.
Talvez seja necessário habilitar o WOL no BIOS/UEFI do sistema.
Verifique as configurações de BIOS/UEFI para boot PXE e confirme se ele está desabilitado para evitar reinstalações acidentais.
Ajuste o firewall para permitir o tráfego pela porta UDP 9.
17.5.2 Verificando o suporte a Ethernet com fio #
Execute o seguinte comando para verificar se uma interface Ethernet com fio suporta WOL:
>
sudo
ethtool eth0 | grep -i wake-on Supports Wake-on: pumbg Wake-on: g
A saída de exemplo mostra que eth0 suporta WOL, indicado pelo flag g
na linha Supports Wake-on
. Wake-on: g
mostra que o WOL já está habilitado, portanto, essa interface está pronta para receber sinais de ativação. Se o WOL não estiver habilitado, habilite-o com este comando:
>
sudo
ethtool -s eth0 wol g
17.5.3 Verificando o suporte à interface wireless #
Wakeup-over-wifi, ou WoWLAN, requer uma interface de rede wireless com suporte a WoWLAN. Faça o teste com o comando iw
, que faz parte do pacote iw:
>
sudo
zypper in iw
Encontre o nome do seu dispositivo:
>
sudo
iw dev phy#0 Interface wlan2 ifindex 3 wdev 0x1 addr 9c:ef:d5:fe:01:7c ssid accesspoint type managed channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz txpower 20.00 dBm
Neste exemplo, o nome do dispositivo a ser usado para consultar o suporte a WoWLAN é phy#0
. Este exemplo mostra que ele não é suportado:
>
sudo
iw phy#0 wowlan show command failed: Operation not supported (-95)
Este exemplo mostra uma interface com suporte a WoWLAN, mas ele não está habilitado:
>
sudo
iw phy#0 wowlan show WoWLAN is disabled
Habilite-o:
>
sudo
iw phy#0 wowlan enable magic-packet WoWLAN is enabled: * wake up on magic packet
17.5.4 Instalando e testando o WOL #
Para usar o WOL, instale o pacote wol nas máquinas cliente e de envio:
>
sudo
zypper in wol
Instale o wol-udev-rules nas máquinas cliente. Esse pacote instala uma regra udev que habilita o WOL automaticamente na inicialização.
Obtenha o endereço MAC da interface de rede na máquina cliente:
>
sudo
ip addr show eth0|grep ether link/ether 7c:ef:a5:fe:06:7c brd ff:ff:ff:ff:ff:ff
Na saída de exemplo, 7c:ef:a5:fe:06:7c
é o endereço MAC.
Encerre a máquina cliente e envie a ela um sinal de ativação de outro computador na mesma sub-rede:
>
wol 7c:ef:a5:fe:06:7c
Se a máquina de destino e o segundo dispositivo estiverem na mesma rede, mas em sub-redes diferentes, especifique o endereço de broadcast da sua máquina de destino:
>
wol -i 192.168.0.63 7c:ef:a5:fe:06:7c
Como o WOL usa os domínios de broadcast, a máquina de envio deve estar na mesma rede, embora ela possa estar em um segmento de rede diferente.
É possível enviar o magic packet de uma rede diferente. Um método é o encaminhamento de porta, quando o roteador oferece suporte a encaminhamento de porta para um endereço de broadcast. Um método mais seguro é conectar-se a um host da rede via SSH e enviar o magic packet desse host.