Ir al contenidoIr a la navegación de la página: página anterior [tecla de acceso p]/página siguiente [tecla de acceso n]
documentation.suse.com / Documentación de SUSE Linux Enterprise Server / Guía de distribución / Configuración de un servidor de instalación / Preparación del entorno de arranque de red
Se aplica a SUSE Linux Enterprise Server 15 SP3

17 Preparación del entorno de arranque de red

 

En este capítulo se describe cómo configurar servidores DHCP y TFTP que proporcionen la infraestructura necesaria para el arranque con PXE.

SUSE® Linux Enterprise Server se puede instalar a través de un entorno de ejecución previa al arranque (PXE). El hardware cliente debe admitir el arranque mediante PXE. La red debe disponer de un servidor DHCP y un servidor TFTP que proporcione los datos necesarios a los clientes. En este capítulo encontrará información que le ayudará a configurar los servidores necesarios.

PXE solo arranca un núcleo e initrd. Se puede utilizar para arrancar un entorno de instalación o sistemas Live. Para configurar los orígenes de instalación, consulte el Capítulo 16, Configuración de un origen de instalación de red.

En esta sección se describen las tareas de configuración necesarias en entornos de arranque complejos. Contiene ejemplos de configuración listos para usar para DHCP, arranque en PXE, TFTP y Wake on LAN.

Los ejemplos presuponen que los servidores DHCP, TFTP y NFS se encuentran en el mismo equipo con la dirección IP 192.168.1.1. Todos los servicios pueden residir en distintos equipos. Asegúrese de cambiar las direcciones IP según sea necesario.

17.1 Configuración de un servidor DHCP

 

Un servidor DHCP proporciona asignaciones de direcciones IP tanto dinámicas (Sección 17.1.1, “Asignación de direcciones dinámicas”) como estáticas (Sección 17.1.2, “Asignación de direcciones IP estáticas”) a los clientes de la red. Se anuncian servidores, routers y dominios. En el caso de los servidores TFTP, DHCP también proporciona los archivos de núcleo y de initrd. Los archivos que se cargan dependen de la arquitectura del equipo de destino y de si se utiliza un arranque BIOS tradicional o UEFI. Los clientes transmiten su tipo de arquitectura en las peticiones DHCP. En función de esta información, el servidor DHCP decide qué archivos debe descargar el cliente para el arranque.

Aviso
Aviso: fallo en la instalación de PXE y AutoYaST

A partir de SUSE Linux Enterprise 15.0, hay condiciones especiales que provocan que el arranque PXE y las instalaciones de AutoYaST fallen. Consulte la Sección 17.1.3, “Fallos en la instalación de PXE y AutoYaST” para obtener más información y la solución.

17.1.1 Asignación de direcciones dinámicas

 

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.

  1. Inicie sesión como usuario root en la máquina que aloje el servidor DHCP.

  2. Para habilitar el servidor DHCP, ejecute el comando systemctl enable dhcpd.

  3. Añada las siguientes líneas a una configuración de subred del archivo de configuración del servidor DHCP que se encuentra en /etc/dhcp.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";
 }
}

    En este ejemplo de configuración se utiliza la subred 192.168.1.0/24 con los servicios DHCP, DNS y gateway en el servidor con la dirección IP 192.168.1.1. Recuerde modificar todas las direcciones IP según la estructura de la red. Para obtener más información acerca las opciones disponibles en dhcpd.conf, consulte la página de Man de dhcpd.conf.

  4. Para reiniciar el servidor DHCP, ejecute el comando systemctl restart dhcpd.

17.1.2 Asignación de direcciones IP estáticas

 

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.

17.1.3 Fallos en la instalación de PXE y AutoYaST

 

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:

  • Usando los últimos bytes de la dirección MAC como IAID: ff:00:02:c2:67:00:01:xx:xx:xx:xx:52:54:00:02:c2:67

  • Si el IAID simplemente en un número incremental: ff:00:00:00:01:00:01:xx:xx:xx:xx:52:54:00:02:c2:67

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 sobre cómo usar linuxrc, consulte la Guía de AutoYaST. Consulte también el archivo man 4 initrd y la documentación sobre las opciones dhcp4 "create-cid" y dhcp6 "default-duid" en man 5 wicked-config y sobre wicked duid --help y wicked iaid --help.

17.2 Configuración de un servidor TFTP

 

El siguiente procedimiento describe cómo se prepara el servidor para que los equipos cliente con UEFI y BIOS puedan arrancarse de forma remota usando archivos exportados por TFTP.

17.2.1 Instalación de un servidor TFTP

 

Para instalar un servidor TFTP, utilice el siguiente procedimiento:

  1. Instale el paquete tftp. 

    tux > sudo zypper in tftp

  2. Revise la configuración de tftpd en /etc/sysconfig/tftp y añada o modifique las opciones según sea necesario. Consulte man 8 tftpd para obtener más información. El daemon TFTP funciona sin necesidad de modificar la configuración. El directorio raíz por defecto para los archivos es /srv/tftpboot.

  3. Asegúrese de que tftpd se inicia durante el arranque y reinícielo para leer la nueva configuración. 

    tux > sudo systemctl enable tftp.socket
tux > sudo systemctl restart tftp.socket

17.2.2 Instalación de archivos para el arranque

 

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:

  • AMD64/Intel 64

  • AArch64

  • POWER

  • IBM Z

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: 

tux > 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 las arquitecturas de SUSE Linux Enterprise Server en el directorio /srv/tftpboot.

Sugerencia
Sugerencia: servicio a distintas arquitecturas

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

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

17.2.3 Configuración PXELINUX

 

Abra el archivo /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/net/pxelinux.cfg/default en un editor. 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.

17.2.4 Preparación del arranque PXE para EFI con GRUB2

 

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-VERSIÓN_SO-ARQUITECTURA/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.

17.3 Opciones de configuración de PXELINUX

 

A continuación aparecen algunas de las opciones disponibles para el archivo de configuración de PXELINUX.

APPEND OPCIONES

Añada una o más opciones a la línea de comandos del núcleo. Éstas se añaden para arranques automáticos y manuales. Las opciones se añaden al principio de la línea de comandos del núcleo, y normalmente admiten que las opciones del núcleo introducidas explícitamente las sobrescriban.

APPEND -

No añade nada. Se puede utilizar APPEND con un solo guion como argumento en una sección LABEL para anular un valor de APPEND global.

DEFAULT OPCIONES_NÚCLEO...

Establece la línea de comandos del núcleo por defecto. Si PXELINUX arranca de manera automática, actúa como si las entradas posteriores a DEFAULT se hubieran escrito en el indicador de inicio, excepto la opción auto que se añade de manera automática, lo que indica un arranque automático.

Si no hay ningún archivo de configuración o ninguna entrada DEFAULT definida en el archivo de configuración, el valor por defecto es el nombre del núcleo “linux”, sin opciones.

IFAPPEND FLAG

Añade una opción específica a la línea de comando del núcleo dependiendo del valor de FLAG. La opción IFAPPEND solo está disponible en PXELINUX. FLAG espera un valor, descrito en Tabla 17.1, “Opciones de líneas de comandos del núcleo generadas y añadidas desde IFAPPEND”:

Tabla 17.1: Opciones de líneas de comandos del núcleo generadas y añadidas desde IFAPPEND
 

Argumento

Línea de comando del núcleo generada/Descripción

1 

ip=CLIENT_IP:BOOT_SERVER_IP:GW_IP:NETMASK

Los espacios reservados se reemplazan según la entrada del servidor de arranque DHCP/BOOTP o PXE.

Tenga en cuenta que esta opción no sustituye a la ejecución de un cliente DHCP en el sistema arrancado. Sin renovaciones regulares, la asignación adquirida por el BIOS PXE caducará, con lo que la dirección IP vuelve a estar disponible para que la reutilice el servidor DHCP.

2 

BOOTIF=MAC_ADDRESS_OF_BOOT_INTERFACE

Esta opción resulta útil para evitar interrupciones cuando el servidor de instalación sondea una interfaz LAN tras otra hasta que recibe respuesta de un servidor DHCP. Esta opción permite que un programa initrd determine desde qué interfaz se ha arrancado el sistema. linuxrc lee esta opción y utiliza la interfaz de red.

4 

SYSUUID=SYSTEM_UUID

Añade UUID en formato hexadecimal en minúscula, ver /usr/share/doc/packages/syslinux/pxelinux.txt

LABEL ETIQUETA KERNEL IMAGEN APPEND OPCIONES...

Indica que si ETIQUETA se introduce como el núcleo que se debe arrancar, PXELINUX debe arrancar en su lugar IMAGEN y se deben usar las opciones de APPEND especificadas. Reemplazarán a las indicadas en la sección global del archivo, antes del primer comando LABEL. El valor por defecto de IMAGEN es el mismo que LABEL y, si no se introduce ningún APPEND, el valor por defecto consiste en utilizar la entrada global (si hubiera alguna). Se permiten hasta 128 entradas LABEL.

PXELINUX utiliza la siguiente sintaxis: 

label MYLABEL
  kernel MYKERNEL
  append MYOPTIONS

Las etiquetas se truncan como si fueran nombres de archivo, y deben ser únicas después del truncamiento. Por ejemplo, dos etiquetas como “v2.6.30” y “v2.6.31” no podrán distinguirse en PXELINUX, ya que ambas se truncan con el mismo nombre de archivo de DOS.

No es necesario que el núcleo sea de Linux. También puede tratarse de un sector de arranque o de un archivo COMBOOT.

LOCALBOOT TIPO

En PXELINUX, especificar LOCALBOOT 0 en lugar de una opción de KERNEL significa la invocación de esa etiqueta en particular y provoca un arranque del disco local en lugar de un arranque del núcleo.

Argumento

Descripción

0

Realiza un arranque normal

4

Realiza un arranque local con el controlador Universal Network Driver Interface (UNDI) aún residente en memoria

5

Realiza un arranque local con el stack de PXE completo, incluido el controlador UNDI, aún residente en memoria

Los demás valores no están definidos. Si desconoce los stacks UNDI o PXE, especifique 0.

TIMEOUT TIEMPO LÍMITE

Indica cuánto tiempo deberá esperar en el indicador de inicio antes de arrancar automáticamente, en décimas de segundo. El tiempo límite queda cancelado cuando el usuario pulsa alguna tecla, en cuyo caso se asume que será este quien complete el comando iniciado. Un tiempo límite de cero inhabilita la opción de tiempo límite (es el ajuste por defecto). El máximo valor posible para el valor del tiempo límite es de 35996 (algo menos de una hora).

PROMPT valor_de_indicador

Si flag_val es 0, muestra el indicador de inicio solo si se pulsan las teclas Mayús o Alt, o si están activados, Bloq Mayús o Bloq Despl (es la opción por defecto). Si valor_de_indicador es 1, siempre se muestra el indicador de inicio. 

F2  FILENAME
F1  FILENAME
..etc...
F9  FILENAME
F10 FILENAME

Muestra en la pantalla el archivo indicado cuando se pulsa una tecla de función en el indicador de inicio. También se puede utilizar para implementar una ayuda en línea para antes del arranque (normalmente para las opciones de la línea de comandos del núcleo). Por compatibilidad con versiones anteriores, F10 también puede introducirse como F0. Tenga en cuenta que no es posible asociar nombres de archivos a F11 ni F12.

17.4 Preparación del sistema de destino para arranque en PXE

 

Prepare el BIOS del sistema para arranque en PXE incluyendo la opción de PXE en el orden de arranque del BIOS.

Aviso
Aviso: orden de arranque del BIOS

No coloque la opción de PXE por encima del parámetro de arranque desde disco duro en el BIOS. De lo contrario, el sistema intentará reinstalarse cada vez que lo arranque.

17.5 Uso de Wake-on-LAN para reactivaciones remotas

 

Wake-on-LAN (WOL) es un estándar Ethernet para activar de forma remota un equipo enviándole una señal de activación a través de una red. Esta señal se denomina “paquete mágico”. Instale WOL en los equipos cliente para habilitar las activaciones remotas y en todos los equipos que desee utilizar para enviar la señal de activación. El paquete mágico se difunde a través del puerto UDP 9 a la dirección MAC de la interfaz de red del equipo cliente.

Cuando los equipos se apagan, normalmente no lo hacen por completo, sino que permanecen en modo de bajo consumo. Si la interfaz de red admite WOL, escucha la señal de activación del paquete mágico cuando el equipo está apagado. Puede enviar el paquete mágico manualmente o programar reactivaciones en una tarea cron en el equipo remitente.

17.5.1 Requisitos previos

 

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.

17.5.2 Verificación de la compatibilidad con Ethernet por cable

 

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

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

tux > sudo ethtool -s eth0 wol g

17.5.3 Verificación de la compatibilidad de la interfaz inalámbrica

 

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: 

tux > sudo zypper in iw

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

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: 

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

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

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

Habilítelo: 

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

17.5.4 Instalación y prueba de WOL

 

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

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

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

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

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