Vai al contenutoNaviga tra le pagine: pagina precedente [tasto di scelta p]/pagina successiva [tasto di scelta n]
documentation.suse.com / Documentazione di SUSE Linux Enterprise Server / Guida alla distribuzione / Configurazione di un server di installazione / Preparazione dell'ambiente di avvio della rete
Si applica a SUSE Linux Enterprise Server 15 SP3

17 Preparazione dell'ambiente di avvio della rete

In questo capitolo è descritto come configurare i server DHCP e TFTP che forniscono l'infrastruttura necessaria per eseguire l'avvio da PXE.

È possibile installare SUSE® Linux Enterprise Server tramite un ambiente PXE (Preboot Execution Environment). L'avvio tramite PXE deve essere supportato dall'hardware client. In rete devono essere disponibili un server DHCP e un server TFTP che forniscano ai client i dati richiesti. In questo capitolo è indicata la procedura per configurare i server necessari.

Con PXE vengono avviati solo un kernel e il file initrd. È possibile utilizzarlo per eseguire l'avvio in un ambiente di installazione o in sistemi live. Per configurare le origini di installazione, vedere Capitolo 16, Configurazione di un'origine di installazione di rete.

In questa sezione vengono illustrate le attività di configurazione necessarie per scenari di avvio complessi. Vengono presentati esempi di configurazione pronti all'uso per DHCP, avvio PXE, TFTP e Wake on LAN.

Gli esempi presuppongono che i server DHCP, TFTP e NFS si trovino sullo stesso computer con indirizzo IP 192.168.1.1. Tutti i servizi possono trovarsi su computer diversi senza alcun problema. Assicurarsi di modificare gli indirizzi IP secondo necessità.

17.1 Configurazione di un server DHCP

Un server DHCP fornisce l'assegnazione di indirizzi IP dinamici (Sezione 17.1.1, «Assegnazione dinamica degli indirizzi») e statici (Sezione 17.1.2, «Assegnazione di indirizzi IP statici») ai client di rete. Pubblicizza server, instradamenti e domini. Per i server TFTP, DHCP fornisce inoltre il kernel e i file initrd. I file da caricare dipendono dall'architettura del computer di destinazione e dall'uso dell'avvio BIOS o UEFI esistente. I client trasmettono il rispettivo tipo di architettura nelle richieste DHCP. In base a tali informazioni, il server DHCP decide i file che il client deve scaricare per l'avvio.

Avvertimento
Avvertimento: errori di avvio PXE e installazione AutoYaST

A partire da SUSE Linux Enterprise 15.0 esistono condizioni speciali che determinano errori di avvio PXE e installazione AutoYaST. Per ulteriori informazioni e per la relativa soluzione, consultare la Sezione 17.1.3, «Errori di avvio PXE e installazione AutoYaST».

17.1.1 Assegnazione dinamica degli indirizzi

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.

  1. Eseguire il login come root nel computer che ospita il server DHCP.

  2. Abilitare il server DHCP eseguendo il comando systemctl enable dhcpd.

  3. Aggiungere le righe seguenti ad una configurazione di sottorete del file di configurazione del server DHCP ubicato in /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";
     }
    }

    Questo esempio di configurazione utilizza la sottorete 192.168.1.0/24 con DHCP, DNS e gateway sul server con indirizzo IP 192.168.1.1. Verificare che tutti gli indirizzi IP vengano modificati in base al layout di rete. Per ulteriori informazioni sulle opzioni disponibili in dhcpd.conf, vedere la documentazione relativa a dhcpd.conf.

  4. Riavviare il server DHCP eseguendo il comando systemctl restart dhcpd.

17.1.2 Assegnazione di indirizzi IP statici

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.

17.1.3 Errori di avvio PXE e installazione AutoYaST

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 ID client 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 l'ID client è 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 ID client 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

L'ID client 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

L'ID client DHCPv4 RFC 4361 tenta di correggere il problema di identificazione di un computer con più di un'interfaccia di rete. Il nuovo ID client DHCPv4 presenta lo stesso formato dell'ID client 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 ID client DHCPv4 RFC 4361 sarà:

  • Utilizzando gli ultimi byte dell'indirizzo MAC come IAID: ff:00:02:c2:67:00:01:xx:xx:xx:xx:52:54:00:02:c2:67

  • Se l'IAID è un numero semplice incrementato: ff:00:00:00:01:00:01:xx:xx:xx:xx:52:54:00:02:c2:67

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-LL (00:03:00:01:$MAC) non dispone della registrazione data e ora.

Per ulteriori informazioni sull'utilizzo di linuxrc, consultare la Guida di AutoYaST. Fare inoltre riferimento a man 4 initrd e alla documentazione per le opzioni dhcp4 "create-cid" e dhcp6 "default-duid" in man 5 wicked-config, wicked duid --help e wicked iaid --help.

17.2 Configurazione di un server TFTP

La seguente procedura illustra come preparare il server in modo da consentire l'avvio in remoto dei computer client con UEFI e BIOS mediante i file esportati da TFTP.

17.2.1 Installazione di un server TFTP

Per installare un server TFTP, attenersi alla procedura seguente:

  1. Installare il pacchetto tftp.

    tux > sudo zypper in tftp
  2. Rivedere la configurazione tftpd in /etc/sysconfig/tftp e aggiungere o modificare le opzioni secondo necessità. Per ulteriori dettagli, fare riferimento a man 8 tftpd. Il daemon TFTP funziona senza dover modificare la configurazione. La directory radice di default per i file è /srv/tftpboot.

  3. Assicurarsi che tftpd sia stato eseguito all'avvio e riavviarlo per visualizzare la nuova configurazione.

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

17.2.2 Installazione dei file per l'avvio

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:

  • AMD64/Intel 64

  • AArch64

  • POWER

  • IBM Z

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:

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

17.2.3 Configurazione di PXELINUX

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.

17.2.4 Preparazione dell'avvio da PXE per EFI con GRUB2

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-VERSIONE_SISTEMA_OPERATIVO-ARCHITETTURA/EFI/BOOT/grub.cfg. Fare riferimento alla Sezione 7.3.3, «Indicazione dell'origine di installazione» per ulteriori informazioni sul parametro install.

17.3 Opzioni di configurazione di PXELINUX

Le opzioni elencate di seguito sono solo una parte di tutte le opzioni disponibili per il file di configurazione di PXELINUX.

APPEND OPTIONS

Consente di aggiungere una o più opzioni alla riga di comando del kernel. Queste vengono aggiunte sia per l'avvio automatico, sia per quello manuale. Le opzioni vengono aggiunte all'inizio della riga di comando del kernel e solitamente possono essere ignorate dalle opzioni del kernel immesse esplicitamente.

APPEND -

Non aggiunge alcun elemento. APPEND, seguito da un singolo trattino come argomento in una sezione LABEL, può essere utilizzato per ignorare l'opzione APPEND generale.

DEFAULT KERNEL_OPTIONS...

Consente di impostare la riga di comando del kernel di default. Se PXELINUX viene avviato automaticamente, agisce come se le voci che seguono DEFAULT fossero state digitate al prompt di avvio, ad eccezione dell'opzione auto che viene aggiunta automaticamente, indicando un avvio automatico.

Se non sono disponibili file di configurazione o nel file di configurazione non è definita alcuna voce DEFAULT, per default il nome del kernel è «linux», senza opzioni.

IFAPPEND FLAG

Aggiunge un'opzione specifica alla riga di comando del kernel a seconda del valore di FLAG. L'opzione IFAPPEND è disponibile solo su PXELINUX. Per FLAG è previsto un valore descritto nella Tabella 17.1, «Opzioni della riga di comando del kernel generate e aggiunte da IFAPPEND»:

Tabella 17.1: Opzioni della riga di comando del kernel generate e aggiunte da IFAPPEND

Argomento

Riga di comando del kernel generata/Descrizione

1

ip=CLIENT_IP:BOOT_SERVER_IP:GW_IP:NETMASK

I segnaposto vengono sostituiti in base all'input ricevuto dal server di avvio DHCP/BOOTP o PXE.

Questa opzione non sostituisce l'esecuzione di un client DHCP nel sistema avviato. Senza rinnovi regolari, il lease acquisito dal BIOS PXE scadrà e l'indirizzo IP potrà essere riutilizzato dal server DHCP.

2

BOOTIF=MAC_ADDRESS_OF_BOOT_INTERFACE

Questa opzione è utile se si desidera evitare timeout quando il server di installazione esamina un'interfaccia LAN dopo l'altra fino a quando non ottiene una risposta da un server DHCP. Questa funzione consente a un programma initrd di determinare l'interfaccia di avvio del sistema. linuxrc legge l'opzione e utilizza l'interfaccia di rete specificate.

4

SYSUUID=SYSTEM_UUID

Aggiunge UUID sotto forma di esadecimali in minuscolo. Vedere /usr/share/doc/packages/syslinux/pxelinux.txt

LABEL LABEL KERNEL IMAGE APPEND OPTIONS...

Indica che se si immette LABEL come kernel per l'avvio, PXELINUX deve avviare invece IMAGE ed è necessario utilizzare le opzioni APPEND specificate. Tali opzioni sostituiscono quelle specificate nella sezione globale del file, prima del primo comando LABEL. L'impostazione di default di IMAGE è la stessa di LABEL e, se non viene fornita alcuna opzione APPEND, per default viene utilizzata la voce generale, se presente. Sono ammesse fino a 128 voci LABEL.

PXELINUX utilizza la sintassi seguente:

label MYLABEL
  kernel MYKERNEL
  append MYOPTIONS

Le etichette vengono modificate come se fossero nomi di file e devono essere univoche dopo essere state modificate. Le due etichette «v2.6.30» e «v2.6.31», ad esempio, non sarebbero distinguibili in PXELINUX poiché entrambe vengono modificate e risultano nello stesso nome file DOS.

Il kernel non deve essere necessariamente un kernel di Linux. Può essere anche un settore di avvio o un file COMBOOT.

LOCALBOOT TYPE

In PXELINUX, se si specifica LOCALBOOT 0 invece dell'opzione KERNEL, viene chiamata questa etichetta e viene avviato il disco locale invece del kernel.

Argomento

Descrizione

0

Consente di eseguire un avvio normale.

4

Consente di eseguire un avvio locale mediante Universal Network Driver Interface (UNDI) ancora residente in memoria.

5

Consente di eseguire l'avvio locale mediante lo stack PXE completo, incluso il driver UNDI, ancora residente in memoria.

Tutti gli altri valori non sono definiti. Se non si conoscono gli stack UNDI o PXE, specificare 0.

TIMEOUT TIME-OUT

Indica il tempo di attesa al prompt di avvio prima dell'avvio automatico, espresso in unità di 1/10 di secondo. Il timeout viene annullato quando l'utente digita un testo qualsiasi con la tastiera, presupponendo che l'utente completerà il comando iniziato. Un valore di timeout pari a zero disabilita completamente il timeout. Questa è anche l'impostazione di default. Il valore massimo di timeout possibile è 35996 (poco meno di un'ora).

PROMPT flag_val

Se flag_val è 0, il prompt di avvio viene visualizzato solo se viene premuto Shift o Alt oppure se è selezionato il blocco delle maiuscole o il blocco dello scorrimento. Questa è l'impostazione di default. Se flag_val è 1, il prompt di avvio viene sempre visualizzato.

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

Consente di visualizzare il file indicato sullo schermo quando viene premuto un tasto funzione al prompt di avvio. Può essere utilizzato per implementare la Guida online relativa al preavvio, presumibilmente per le opzioni della riga di comando del kernel. Per la compatibilità con versioni precedenti, è possibile inoltre immettere F10 come F0. Si noti che non esiste attualmente alcun modo per associare i nomi file a F11 e F12.

17.4 Preparazione del sistema di destinazione per l'avvio PXE

Preparare il BIOS del sistema per l'avvio PXE includendo l'opzione PXE nell'ordine di avvio del BIOS.

Avvertimento
Avvertimento: ordine di avvio nel BIOS

Non posizionare l'opzione PXE davanti al parametro di avvio del disco rigido nel BIOS, altrimenti il sistema cercherà di reinstallarsi a ogni avvio.

17.5 Utilizzo di Wake-On-LAN per riattivazioni remote

Wake-On-LAN (WOL) è uno standard Ethernet per la riattivazione remota di un computer attraverso l'invio di un segnale di riattivazione sulla rete. Questo segnale è denominato «pacchetto magico». Installare WOL sui computer client per abilitare le riattivazioni remote e su ogni computer che si intende utilizzare per l'invio del segnale di riattivazione. Il pacchetto magico viene sottoposto a broadcast mediante la porta UDP 9 all'indirizzo MAC dell'interfaccia di rete sul computer client.

Un computer arrestato non viene in genere spento completamente, ma passa a una modalità di risparmio energetico. Se l'interfaccia di rete supporta WOL, ascolta il segnale di riattivazione del pacchetto magico quando il computer viene spento. È possibile inviare manualmente il pacchetto magico oppure pianificare riattivazioni in un processo cron sul computer di invio.

17.5.1 Prerequisiti

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.

17.5.2 Verifica del supporto per l'interfaccia Ethernet cablata

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

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

tux > sudo ethtool -s eth0 wol g

17.5.3 Verifica del supporto per l'interfaccia wireless

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

tux > sudo zypper in iw

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

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

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

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

Abilitarlo:

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

17.5.4 Installazione e test di WOL

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

tux > sudo zypper in wol

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

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

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

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