17 Preparación del entorno de arranque de red #

En el siguiente ejemplo se muestra cómo configurar un servidor DHCP que asigna dinámicamente direcciones IP a los clientes y anuncia servidores, routers, dominios y archivos de arranque.

Un servidor DHCP también puede asignar direcciones IP estáticas y nombres de host a los clientes de la red. Uno de los casos de uso consiste en asignar direcciones estáticas a los servidores. Otro consiste en restringir los clientes que pueden unirse a la red permitiendo solo los que tienen direcciones IP estáticas asignadas y no proporcionar repositorios de direcciones dinámicas.

Modifique la configuración de DHCP anteriores de acuerdo con el siguiente ejemplo:

group {
 host test {
   hardware ethernet MAC_ADDRESS;
   fixed-address IP_ADDRESS;
   }
}

La declaración de host asigna un nombre de host al destino de la instalación. Para vincular el nombre de host y la dirección IP con un host determinado, debe especificar la dirección de hardware del sistema (MAC). Sustituya todas las variables utilizadas en este ejemplo por los valores reales correspondientes a su entorno y, a continuación, guarde los cambios y reinicie el servidor DHCP.

A partir de SUSE Linux Enterprise 15.0 y de ISC DHCP 4.3.x, hay circunstancias especiales que provocan que el arranque PXE y las instalaciones de AutoYaST fallen. Si el servidor DHCP no dispone de un repositorio de direcciones IP dinámicas disponibles, solo permite direcciones estáticas predefinidas por cliente y los clientes envían identificadores de cliente RFC 4361, las instalaciones de PXE/AutoYaST no funcionan. Si solo se permiten las direcciones asignadas a clientes red específicos y no se proporcionan repositorios de direcciones dinámicas, se impide que equipos aleatorios puedan unirse a la red.

Cuando se inicia un nuevo sistema en PXE, este envía una petición al servidor DHCP y se identifica a sí mismo mediante un identificador de cliente generado a partir del tipo de hardware y la dirección MAC de la interfaz de red. Se trata de un client-id RFC 2132. El servidor DHCP ofrece la dirección IP asignada. A continuación, se carga el núcleo de la instalación y se envía otra petición DHCP, pero este client-id es diferente y se envía en formato RFC 4361. El servidor DHCP no lo reconocerá como el mismo cliente y buscará una dirección IP dinámica libre, que no está disponible, por lo que la instalación se detendrá.

La solución es configurar los clientes para que envíen identificadores de cliente en formato RFC 2132. Para enviar un client-id RFC 2132 durante la instalación, utilice linuxrc para pasar el siguiente 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

El client-id DHCPv4 RFC 2132 utilizado tradicionalmente en Ethernet se crea a partir del tipo de hardware (01 para Ethernet), seguido de la dirección de hardware (la dirección MAC); por ejemplo:

01:52:54:00:02:c2:67

El client-id DHCPv4 RFC 4361 intenta corregir el problema de identificación de los equipos que tienen más de una interfaz de red. El nuevo client-id DHCPv4 tiene el mismo formato que el client-id DHCPv6. Empieza con el prefijo 0xff, en lugar del tipo de hardware, seguido por el IAID (el ID de asociación interfaz-dirección que describe la interfaz del equipo) DHCPv6, seguido del identificador único DHCPv6 (DUID), que identifica al equipo de forma exclusiva.

Mediante el uso del DUID basado en el tipo de hardware y en la dirección del hardware, el nuevo client-id DHCPv4 RFC 4361 podría tener este aspecto:

El campo xx:xx:xx:xx de la marca horaria de capa de enlace DUID (DUID-LLT) es una marca horaria creada automáticamente. Las capas de enlace DUID (DUID-LL) (00:03:00:01:$MAC) no disponen de marca horaria.

Para obtener más información acerca de uso de linuxrc, consulte AutoYaST Guide. Consulte también man 4 initrd, y la documentación de las opciones dhcp4 "create-cid", dhcp6 "default-duid" en man 5 wicked-config, wicked duid --help y wicked iaid --help.

Para instalar un servidor TFTP, utilice el siguiente procedimiento:

SUSE Linux Enterprise Server proporciona los archivos necesarios para arrancar mediante PXE en equipos con BIOS o UEFI. Se admiten las siguientes arquitecturas de hardware:

Los archivos necesarios para arrancar desde una arquitectura de hardware específica se incluyen en un paquete RPM. Instálelo en el equipo donde se ejecuta el servidor TFTP:

> sudo zypper in tftpboot-installation-SLE-OS_VERSION-ARCHITECTURE

Sustituya OS_VERSION por el número de versión de su instalación de SUSE Linux Enterprise Server (por ejemplo, SLE-15-SP3-x86_64) y ARCHITECTURE por la arquitectura de su sistema (por ejemplo, x86_64). El texto resultante tendrá un aspecto similar al siguiente: tftpboot-installation-SLE-15-SP3-x86_64. Ejecute zypper se tftpboot para buscar todas las arquitecturas y las versiones disponibles.

Los archivos se instalarán en /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE. También puede copiar los archivos para otras versiones y arquitecturas de SUSE Linux Enterprise Server en el directorio /srv/tftpboot.

Sugerencia: servicio a distintas arquitecturas

Las arquitecturas de hardware del cliente y del servidor pueden ser distintas. Por ejemplo, es posible ejecutar un servidor TFTP AMD64/Intel 64 y proporcionar un entorno de arranque para equipos cliente AArch64 instalando el paquete tftpboot-installation-SLE-15-SP3-aarch64.

Nota: directorio /srv/tftpboot/ existente

Si el directorio /srv/tftpboot/ ya existe en el equipo, todos los archivos se instalarán en /usr/share/tftpboot-installation/. Este es el caso si va a actualizar el servidor PXE desde una versión anterior de SLES.

Para solucionar este problema, copie los archivos manualmente desde /usr/share/tftpboot-installation/ a /srv/tftpboot/. También es posible eliminar /srv/tftpboot/ y volver a instalar el paquete tftpboot-installation-SLE-OS_VERSION-ARCHITECTURE.

Abra el archivo /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/net/pxelinux.cfg/default en un editor de texto. Sustituya la vía del parámetro install según la configuración, tal como se describe en el Capítulo 16, Configuración de un origen de instalación de red. Sustituya TFTP_SERVER con la dirección IP del servidor TFTP. Encontrará una descripción general de las opciones de configuración de PXELINUX en la Sección 17.3, “Opciones de configuración de 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 obtener información acerca de los parámetros de arranque que se utilizan en la línea append, consulte la Sección 7.3, “Lista de parámetros de arranque importantes”.

Si es necesario, edite /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/net/pxelinux.cfg/message para que se muestre un mensaje en el menú de arranque.

Normalmente, los archivos de configuración de GRUB2 no requieren modificaciones. Sin embargo, los ajustes por defecto no incluyen un recurso de red para el sistema de instalación. Para realizar una instalación completa de SUSE Linux Enterprise Server a través de la red, debe especificar el parámetro install en la instrucción linuxefi del archivo /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/EFI/BOOT/grub.cfg. Consulte la Sección 7.3.3, “Especificación del origen de instalación” para obtener más información sobre el parámetro install.

WOL funciona con tarjetas Ethernet alámbricas e inalámbricas compatibles.

Puede que necesite habilitar WOL en el BIOS/UEFI del sistema.

Compruebe los ajustes de BIOS/UEFI para el arranque PXE y asegúrese de que esté inhabilitado para evitar reinstalaciones accidentales.

Ajuste el cortafuegos para permitir el tráfico a través del puerto UDP 9.

Ejecute el siguiente comando para comprobar si una interfaz Ethernet con cables admite WOL:

> sudo ethtool eth0 | grep -i wake-on
Supports Wake-on: pumbg
Wake-on: g

La salida de ejemplo muestra que eth0 es compatible con WOL, indicado por el indicador g en la línea Supports Wake-on. Wake-on: g muestra que WOL ya está habilitado, por lo que esta interfaz está lista para recibir señales de activación. Si WOL no está habilitado, habilítelo con este comando:

> sudo ethtool -s eth0 wol g

Wakeup-over-wifi, o WoWLAN, requiere una interfaz de red inalámbrica que admita WoWLAN. Pruébelo con el comando iw, proporcionado por el paquete iw:

> sudo zypper in iw

Busque el nombre de su 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

En este ejemplo, el nombre del dispositivo que se debe usar para consultar la compatibilidad con WoWLAN es phy#0. Este ejemplo muestra que no se admite:

> sudo iw phy#0 wowlan show
command failed: Operation not supported (-95)

Este ejemplo muestra una interfaz que admite WoWLAN, pero no está habilitado:

> sudo iw phy#0 wowlan show
WoWLAN is disabled

Habilítelo:

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

Para utilizar WOL, instale el paquete wol en el cliente y en los equipos emisores:

> sudo zypper in wol

Instale wol-udev-rules en los equipos cliente. Este paquete instala una regla udev que habilita WOL automáticamente durante el inicio.

Obtenga la dirección MAC de la interfaz de red en el equipo cliente:

> sudo ip addr show eth0|grep ether
link/ether 7c:ef:a5:fe:06:7c brd ff:ff:ff:ff:ff:ff

En la salida de ejemplo, la dirección MAC es 7c:ef:a5:fe:06:7c.

Apague el equipo cliente y envíele una señal de activación desde otro equipo de la misma subred:

> wol 7c:ef:a5:fe:06:7c

Si el equipo de destino y el segundo dispositivo están en la misma red pero en subredes diferentes, especifique la dirección de difusión del equipo de destino:

> wol -i 192.168.0.63 7c:ef:a5:fe:06:7c

Dado que WOL se basa en dominios de difusión, el equipo remitente debe estar en la misma red, aunque puede estar en un segmento de red diferente.

Es posible enviar el paquete mágico desde una red diferente. Una forma de hacerlo es con la remisión de puertos, si el router admite la remisión de puertos a una dirección de difusión. Un método más seguro es conectarse a un host dentro de la red a través de SSH y enviar el paquete mágico desde allí.