17 Preparando o ambiente de boot de rede #

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.

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.

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 é:

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 Guia do AutoYaST. Consulte também man 4 initrd e a documentação referente às opções dhcp4 "create-cid", dhcp6 "default-duid" em man 5 wicked-config, wicked duid --help e wicked iaid --help.

Para instalar um servidor TFTP, siga o procedimento abaixo:

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:

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:

tux > 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/SLES-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.

Dica: Atendendo a arquiteturas diferentes

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 .

Nota: Diretório /srv/tftpboot/ existente

Se o diretório /srv/tftpboot/ já existir na máquina, todos os arquivos serã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/. Você também pode remover o /srv/tftpboot/ e reinstalar o pacote tftpboot-installation-SLE-OS_VERSION-ARCHITECTURE .

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 SERVIDOR_TFTP 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.

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.

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.

Execute o seguinte comando para verificar se uma interface Ethernet com fio suporta WOL:

tux > 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:

tux > sudo ethtool -s eth0 wol g

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 :

tux > sudo zypper in iw

Encontre o nome do seu dispositivo:

tux > 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:

tux > 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:

tux > sudo iw phy#0 wowlan show
WoWLAN is disabled

Habilite-o:

tux > sudo iw phy#0 wowlan enable magic-packet
WoWLAN is enabled:
* wake up on magic packet

Para usar o WOL, instale o pacote wol nas máquinas cliente e de envio:

tux > 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:

tux > 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:

tux > 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:

tux > 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.