17 Preparazione dell'ambiente di avvio della rete #

Il seguente esempio illustra come configurare un server DHCP che assegna in modo dinamico gli indirizzi IP ai client e pubblicizza server, instradamenti, domini e file di avvio.

Un server DHCP può anche assegnare indirizzi IP statici e nomi host ai client di rete. Un caso d'uso consiste nell'assegnare indirizzi statici ai server. Un altro caso è quello che limita la possibilità di entrare a far parte della rete ai soli client con indirizzi IP statici assegnati e che non fornisce pool di indirizzi dinamici.

Modificare la configurazione DHCP di cui sopra in base al seguente esempio:

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

La dichiarazione host assegna un nome host alla destinazione di installazione. Per associare il nome host e l'indirizzo IP a un host specifico, è necessario specificare l'indirizzo hardware (MAC) del client. Sostituire tutte le variabili utilizzare nell'esempio con i valori effettivi corrispondenti all'ambiente, quindi salvare le modifiche e riavviare il server DHCP.

A partire da SUSE Linux Enterprise 15.0 e ISC DHCP 4.3.x esistono circostanze specifiche che determinano errori di avvio PXE e installazione AutoYaST. Se un server DHCP non dispone di un pool di indirizzi IP dinamici, ma consente solo indirizzi statici predefiniti per client, e i client inviano identificatori RFC 4361, si verificano errori di avvio PXE e installazione AutoYaST. Per evitare che computer casuali entrino a far parte della rete, consentire solo indirizzi assegnati a specifici client di rete e non fornire pool di indirizzi dinamici.

Se un nuovo sistema viene avviato in PXE, invia una richiesta al server DHCP e si autoidentifica mediante un identificatore client creato in base al tipo di hardware e all'indirizzo MAC dell'interfaccia di rete. Si tratta di un client-id RFC 2132. Il server DHCP fornisce quindi l'indirizzo IP assegnato. Viene quindi caricato il kernel di installazione, che invia un'altra richiesta DHCP, ma in questo caso il client-id è diverso e viene inviato in formato RFC 4361. Il server DHCP non lo riconosce come lo stesso client e cercherà un indirizzo IP dinamico libero, che non è disponibile. L'installazione si arresta.

La soluzione consiste nel configurare l'invio di ID client RFC 2132. Per inviare un client-id RFC 2132 durante l'installazione, utilizzare linuxrc per passare il seguente 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

Il client-id DHCPv4 RFC 2132 in genere utilizzato nella rete Ethernet viene creato in base al tipo di hardware (01 per Ethernet), seguito dall'indirizzo hardware (MAC); ad esempio:

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

Il client-id DHCPv4 RFC 4361 tenta di correggere il problema di identificazione di un computer con più di un'interfaccia di rete. Il nuovo client-id DHCPv4 presenta lo stesso formato del client-id DHCPv6. Inizia con il prefisso 0xff, anziché con il tipo di hardware, seguito dall'IAID DHCPv6, ovvero l'ID di associazione dell'indirizzo di interfaccia che descrive l'interfaccia sul computer, seguito dal DUID, l'identificatore univoco DHCPv6 del computer.

Utilizzando il DUID basato sul tipo e sull'indirizzo hardware di cui sopra, il nuovo client-id DHCPv4 RFC 4361 sarà:

Il campo xx:xx:xx:xx nel DUID-LLT, ovvero la registrazione data e ora del livello di collegamento DUID, indica la data e ora di creazione. Un DUID-Link-Layer (DUID-LL) (00:03:00:01:$MAC) non dispone della registrazione data e ora.

Per ulteriori informazioni sull'utilizzo dilinuxrc, vedere la AutoYaST Guide. Inoltre, consultare man 4 initrd e la documentazione per le opzioni dhcp4 "create-cid", dhcp6 "default-duid" in man 5 wicked-config, wicked duid --help e wicked iaid --help.

Per installare un server TFTP, attenersi alla procedura seguente:

In SUSE Linux Enterprise Server vengono forniti i file necessari per eseguire l'avvio da PXE in computer BIOS o UEFI. Sono supportate le seguenti architetture hardware:

I file richiesti per l'avvio da una specifica architettura hardware sono inclusi in un pacchetto RPM. Installarli nel computer sul quale viene eseguito il server TFTP:

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

Sostituire OS_VERSION con il numero di versione dell'installazione di SUSE Linux Enterprise Server in uso, ad esempio SLE-15-SP3-x86_64, e ARCHITECTURE con l'architettura del sistema, ad esempio x86_64. Il testo risultante sarà: tftpboot-installation-SLE-15-SP3-x86_64. Eseguire zypper se tftpboot per cercare tutte le versioni e le architetture disponibili.

I file verranno installati in /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE. È inoltre possibile copiare altre versioni e architetture di SUSE Linux Enterprise Server nella directory /srv/tftpboot.

Suggerimento: gestione di architetture diverse

L'architettura hardware di un client e un server può variare. Ad esempio, è possibile eseguire un server TFTP AMD64/Intel 64 e fornire un ambiente di avvio per computer client AArch64 installando il pacchetto tftpboot-installation-SLE-15-SP3-aarch64.

Nota: directory /srv/tftpboot/ esistente

Se sul computer esiste già la directory /srv/tftpboot//, tutti i file verranno installati in /usr/share/tftpboot-installation/, come nel caso in cui si effettua l'upgrade del server PXE da una release precedente di SLES.

Per correggere il problema, copiare i file manualmente da /usr/share/tftpboot-installation/ in /srv/tftpboot/. In alternativa, rimuovere /srv/tftpboot/ e installare di nuovo il pacchetto tftpboot-installation-SLE-OS_VERSION-ARCHITECTURE.

Aprire il file /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/net/pxelinux.cfg/default in un editor. Sostituire il percorso del parametro install in base alla configurazione descritta nel Capitolo 16, Configurazione di un'origine di installazione di rete. Sostituire anche TFTP_SERVER con l'indirizzo IP del server TFTP. Per una panoramica delle opzioni di configurazione di PXELINUX, vedere Sezione 17.3, «Opzioni di configurazione di 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

Per i dettagli sui parametri di avvio utilizzati nella riga append, vedere Sezione 7.3, «Elenco dei parametri di avvio importanti».

Se necessario, modificare /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/net/pxelinux.cfg/message per visualizzare un messaggio nel menu di avvio.

In genere i file di configurazione GRUB2 non richiedono modifiche. Tuttavia, le impostazioni predefinite non includono una risorsa di rete per l'installazione del sistema. Per eseguire un'installazione completa di SUSE Linux Enterprise Server tramite la rete, è necessario specificare il parametro install nell'istruzione linuxefi del file /srv/tftpboot/SLE-OS_VERSION-ARCHITECTURE/EFI/BOOT/grub.cfg. Fare riferimento alla Sezione 7.3.3, «Indicazione dell'origine di installazione» per ulteriori informazioni sul parametro install.

WOL è compatibile con le schede Ethernet cablate e wireless che supportano lo standard.

Potrebbe essere necessario abilitare WOL nel BIOS/UEFI del sistema.

Verificare le impostazioni del BIOS/UEFI relative all'avvio PXE e accertarsi che sia disabilitato per evitare reinstallazioni accidentali.

Regolare il firewall per consentire il traffico sulla porta UDP 9.

Eseguire il seguente comando per capire se un'interfaccia Ethernet cablata supporta WOL:

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

L'esempio mostra che eth0 supporta WOL, indicato dal flag g nella riga Supports Wake-on. Wake-on: g indica che WOL è già abilitato, quindi l'interfaccia è pronta per ricevere segnali di riattivazione. Se WOL non è abilitato, abilitarlo con questo comando:

> sudo ethtool -s eth0 wol g

Wakeup-Over-Wifi, o WoWLAN, richiede un'interfaccia di rete wireless che supporti WoWLAN. Testarlo con il comando iw, fornito dal pacchetto iw:

> sudo zypper in iw

Individuare il nome del 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

In questo esempio, il nome del dispositivo da utilizzare per eseguire query sul supporto WoWLAN è phy#0. Questo esempio mostra che non è supportato:

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

Questo esempio mostra un'interfaccia che supporta WoWLAN, ma lo standard non è abilitato:

> sudo iw phy#0 wowlan show
WoWLAN is disabled

Abilitarlo:

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

Per utilizzare WOL, installare il pacchetto wol sui computer client e di invio:

> sudo zypper in wol

Installare wol-udev-rules sui computer client. Il pacchetto installa una regola udev che abilita WOL automaticamente all'avvio.

Ottenere l'indirizzo MAC dell'interfaccia di rete sul computer client:

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

Nell'esempio, 7c:ef:a5:fe:06:7c è l'indirizzo MAC.

Arrestare il computer client e inviare un segnale di riattivazione da un altro computer sulla stessa sottorete:

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

Se il computer di destinazione e il secondo dispositivo sono sulla stessa rete, ma in sottoreti diverse, specificare l'indirizzo broadcast per il computer di destinazione:

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

Poiché WOL si basa su domini broadcast, il computer di invio deve trovarsi sulla stessa rete, anche se in un segmento di rete diverso.

È possibile inviare il pacchetto magico da una rete diversa. Un metodo è costituito dal port forwarding, se è supportato dal router a un indirizzo broadcast. Un metodo più sicuro consiste nel connettersi a un host all'interno della rete tramite SSH e inviare il pacchetto da qui.