Postazioni diskless usando Gentoo LinuxQuesta guida intende illustrare la creazione di una rete formata da postazioni diskless, basate su Gentoo Linux. Nella rete sono presenti svariate guide che si occupano di questo argomento, purtroppo la maggior parte risultano complicate. Invece questa guida intende essere il più semplice possibile, in modo da aiutare anche le persone che sono alle prime armi con Linux. Una postazione "diskless" è un comune computer sprovvisto delle consuete periferiche di avvio quali: dischi fissi, lettori floppy e lettori di cdrom. La postazione diskless esegue la procedura d'avvio tramite la scheda di rete, pertanto è richiesta la presenza di un server che le fornisca lo spazio fisico su cui salvare i propri dati. D'ora in avanti ci si riferirà al server con il termine di master, mentre con il termine slave si fa riferimento alla postazione diskless. Come detto in precedenza lo slave esegue la procedura d'avvio tramite la propria scheda di rete, per poterlo fare è necessario avere una scheda di rete che supporti i protocolli PXE o Etherboot. Per sapere se la propria scheda di rete sia tra quelle compatibili consultare la lista presente sul sito Etherboot.org. La maggior parte delle schede di rete (comprese quelle integrate sulle schede madri) di recente produzione supporta PXE. Sul PC master dovrebbe essere installato Gentoo Linux e dovrebbe esserci abbastanza spazio libero per contenere anche l'intero file system degli slave. Inoltre è necessario controllare d'avere due schede di rete sul pc master, una collegata ad internet e l'altra collegata alla rete locale. 2. Configurazione del master e degli slave Il kernel è il cuore del sistema operativo, è un programma che permette a tutti i programmi presenti di interfacciarsi con l'hardware della propria macchina. Quando un computer è avviato il BIOS legge delle istruzioni presenti in un settore riservato del disco fisso; queste istruzioni non sono altro che il boot loader, il quale si preoccupa di caricare il kernel. In seguito sarà il kernel a gestire tutti i processi in esecuzione. Per ulteriori informazioni sul kernel e su come configurarlo è consigliata la lettura di questa guida. Configurazione del kernel della postazione master Il kernel della postazione master non ha limiti di dimensione, sono solo richieste alcune opzioni. Per attivarle occorre entrare nel menu di configurazione del kernel tramite i seguenti comandi:
A questo punto si presenta un'interfaccia grafica: si tratta di un'alternativa più rapida rispetto alla modifica a mano del file /usr/src/linux/.config. Se il proprio attuale kernel è funzionante è consigliabile farne una copia da tenere al sicuro. Per farlo digitare, all'uscita dell'interfaccia grafica, i seguenti comandi:
Entrare nei seguenti sotto-menu e controllare che le opzioni elencate siano impostate come compilate staticamente (e NON come dei moduli). Le opzioni elencate di seguito sono relative ad un kernel della serie 2.6.10. Nel caso si desideri utilizzare un kernel differente il listato seguente potrebbe variare leggermente. Accertarsi d'avere selezionato le voci indicate di seguito:
Se si desidera utilizzare il packet filtering è possibile compilare le sue sotto-opzioni modularmente. Per configurare correttamente il proprio firewall è consigliata la lettura del capitolo numero 12 del Manuale sulla sicurezza per Gentoo .
Dopo aver riconfigurato il kernel del master è necessario procedere alla sua compilazione:
Infine aggiungere una nuova voce per il nuovo kernel all'interno di lilo.conf o di grub.conf, a seconda del proprio bootloader. Ora che il nuovo file bzImage è stato copiato nella directory /boot è possibile riavviare il sistema per attivare le nuove modifiche. Configurare il kernel degli slave E' consigliabile compilare il kernel degli slave senza moduli, dato che la presenza dei moduli renderebbe la procedura d'avvio remoto difficoltosa. Inoltre il kernel degli slave deve essere il più piccolo e compatto possibile, in modo da essere efficiente al momento dell'avvio. Compilare il kernel degli slave nello stesso percorso in cui è stato compilato quello del master. Per evitare confusione e inutili sprechi di tempo è consigliabile fare una copia della configurazione del kernel del master. Digitare semplicemente:
Procedere ora alla configurazione del kernel degli slave nello stesso modo con cui è stato configurato quello del master. Se si desidera lavorare su una configurazione "pulita" (ovvero senza avere le opzioni selezionate precedentemente per il master) è possibile recuperare il file /usr/src/linux/.config iniziale digitando:
Ora è possibile lanciare nuovamente l'interfaccia grafica di configurazione del kernel digitando:
Accertarsi d'avere selezionato le seguenti voci come compilate staticamente e NON come moduli:
Ora non resta altro che compilare il kernel dello slave. In questa fase è opportuno prestare molta attenzione controllando che non siano sovrascritti e/o eliminati i moduli compilati precedentemente per il master (sempre se presenti).
Ora creare una directory sul master per contenere i file di sistema richiesti dallo slave. E' possibile scegliere il percorso che si preferisce, ad esempio questo: /diskless. Ora copiare il file bzImage dello slave all'interno della directory /diskless:
Configurare il file system iniziale dello slave Il file system del master e dello slave possono essere modificati a proprio piacimento, al momento è interessante avere un file system iniziale con le giuste configurazioni ed i punti di mount esatti. Per prima cosa è necessario creare all'interno di /diskless una directory per la prima postazione slave. Ogni slave ha bisogno della sua directory di root (/) riservata, infatti la condivisione di alcuni file di sistema potrebbe causare problemi con i permessi e soprattutto gravi crash. E' possibile chiamare queste directory come si preferisce ma, per motivi pratici, è consigliabile usare l'indirizzo ip dello slave (dato che essi sono unici e non danno luogo a confusioni). Per esempio, nel caso in cui il primo slave avesse il seguente ip 192.168.1.21:
Molti file presenti in /etc devono essere modificati per potere funzionare sullo slave. Copiare la directory /etc del master all'interno della directory di root dello slave:
Il filesystem non è ancora pronto, ci sono ancora da creare diversi punti di mount e directory. Per crearli digitare:
La maggior parte delle directory create precedentemente dovrebbero essere familiari. Directory quali /dev o /proc vengono popolate all'avvio dello slave, le restanti sono montate in seguito. È necessario anche modificare il file /diskless/192.168.1.21/etc/conf.d/hostname per riflettere l'hostname dello slave. I file binari, le librerie ed i restanti file verranno inseriti più avanti, prima dell'avvio dello slave. Anche se la directory /dev sarà popolata successivamente da udev, è comunque necessario creare il device console. Altrimenti si avrà il messaggio d'errore: "unable to open initial console".
3. Configurazione del server DHCP La sigla DHCP significa: Dynamic Host Configuration Protocol. Il server DHCP è il primo computer con cui gli slave comunicano all'avvio. Lo scopo principale del server DHCP è l'assegnazione degli indirizzi IP. Volendo, il server DHCP può assegnare gli indirizzi IP in base all'indirizzo MAC della scheda di rete dello slave. Non appena lo slave ottiene un indirizzo IP il server DHCP gli fornisce le indicazioni su dove trovare il suo file system iniziale ed il suo kernel. Prima di iniziare è meglio controllare il funzionamento di alcune cose. Per prima cosa controllare la connessione di rete:
È opportuno controllare che il dispositivo eth0 sia funzionante. Dovrebbe apparire circa così:
E' importante che appaia la voce MULTICAST, se non compare è necessario ricompilare il proprio kernel attivando il supporto a multicast. Se la rete non ha ancora un server DHCP è necessario crearne uno:
Invece se la rete ha già un server DHCP non c'è da fare altro che configurarlo in maniera da supportare il protocollo PXE. Configurazione del server DHCP Bisognerà modificare solamente il file /etc/dhcp/dhcpd.conf prima d'avviare il proprio server. Si può semplicemente copiare il file di configurazione d'esempio, modificandolo in seguito:
Si tratta di un file indentato che dovrebbe apparire così:
Il blocco d'opzioni di rete condivise è facoltativo e dovrebbe essere usato per tutti gli IP che si desidera assegnare alla stessa tipologia di rete. Si deve dichiarare almeno una subnet, mentre il blocco d'opzioni relativo al gruppo è opzionale e consente di raggruppare le opzioni tra i vari elementi. Un buon esempio per il file dhcpd.conf è questo:
L'indirizzo IP in indicato dopo la voce next-server sarà richiesto nel file indicato alla voce filename. Questo indirizzo IP dovrebbe essere quello del server tftp, che solitamente è in esecuzione sul master. Il nome del file indicato nella voce filename ha come percorso relativo /diskless (questo dipende dalle impostazioni relative al server tftp, impostazioni che verranno analizzate successivamente). All'interno del blocco di opzioni della voce host alla voce hardware ethernet si specifica un indirizzo MAC, alla voce fixed-address si indica un indirizzo IP da assegnare staticamente all'indirizzo MAC indicato in precedenza. Per ulteriori informazioni è consigliabile la lettura dell'ottima pagina man di dhcpd.conf, ci sono infatti molte altre opzioni che vanno oltre gli scopi di questa guida. E' possibile leggere la pagina man digitando:
Prima di lanciare lo script d'avvio del server dhcp modificare il file /etc/conf.d/dhcp in maniera che assomigli a questo:
La variabile IFACE corrisponde al dispositivo di rete su cui il server DHCP resta in ascolto, in questo caso eth0. Nel caso di complesse tipologie di rete, con più dispositivi di rete, potrebbe essere necessario aggiungere più valori alla variabile IFACE. Per avviare il server dhcp digitare:
Per avviare il server dhcp fin dall'avvio del master digitare:
Possibili problemi con il server DHCP E' possibile verificare l'avvio di una postazione remota leggendo il file /var/log/syslog.log. Se la postazione esegue con successo la procedura di boot, verso la fine del file messages si dovrebbero avere delle linee come queste:
Nel caso in cui si ottenga il seguente messaggio esistono degli errori all'interno del file di configurazione, ma il server continua comunque a funzionare correttamente in broadcast.
Ogni volta che sono fatte delle modifiche alla configurazione è necessario riavviare il server dhcp. Per riavviarlo digitare:
4. Configurare il server TFTP e l'avvio tramite PXE e/o Etherboot La sigla TFTP significa Trivial File Transfer Protocol. Il server TFTP ha la funzione di fornire agli slave il loro kernel ed il loro filesystem iniziale. Tutti i kernel ed i filesystem degli slave saranno conservati sul server TFTP, è quindi una buona idea avviare il server TFTP sul master. E' consigliabile utilizzare l'ebuild tftp-hpa. Si tratta di un'implementazione scritta dall'autore di SYSLINUX che funziona molto bene con PXE. Per installarlo digitare:
Modificare il file /etc/conf.d/in.tftpd. All'interno si deve specificare, con la variabile INTFTPD_PATH, il percorso della directory di root del server tftp e, nella variabile INTFTPD_OPTS, le opzioni con cui avviare il server tftp. Il file dovrebbe essere simile a quello riportato di seguito:
L'opzione -l indica che il server resta in ascolto senza richiedere l'avvio di inetd. L'opzione -v indica che il server scrive nei file di log molte informazioni in più rispetto al solito. L'opzione -s /diskless specifica la directory di root del vostro server tftp. Per avviare il server tftp digitare:
In questo modo il server tftp viene avviato usando le opzioni specificate in /etc/conf.d/in.tftpd. Se si desidera avviare il server tftp ad ogni avvio del master digitare:
E' possibile saltare questa sezione se si ha intenzione di utilizzare solamente Etherboot. PXELINUX è un bootloader di rete, equivalente a LILO o GRUB, che fa uso di un server TFTP. Sostanzialmente è un insieme di istruzioni che spiegano al pc dove reperire il proprio kernel ed il proprio filesystem. Come tutti i bootloader anche PXELINUX permette il passaggio di parametri all'avvio del kernel. E' necessario procurarsi il file pxelinux.0 che è contenuto nel pacchetto SYSLINUX (il cui autore è H. Peter Anvin). E' possibile installare questo pacchetto digitando:
Prima d'avviare il server tftp si deve configurare pxelinux. Per prima cosa copiare il binario di pxelinux all'interno della directory /diskless:
Questo crea una configurazione predefinito per il bootloader. L'eseguibile pxelinux.0 andrà a cercare, all'interno della directory in cui è contenuto il file pxelinux.cfg, un file il cui nome sia l'equivalente in esadecimale dell'indirizzo IP del client. Nel caso in cui non trovi il file allora ne cerca un altro il cui nome è identico al precedente, senza però l'ultimo gruppo di numeri sulla destra (i numeri sono separati tra di loro da un punto); continua a ripetere questa operazione fino a quando non ci sono più punti all'interno del nome del file da cercare. A partire dalla versione 2.05 syslinux per prima cosa cerca un file il cui nome deriva dall'indirizzo mac. Se non è trovato nessun file allora è eseguita la procedura di scoperta descritta precedentemente. Se non è trovato nessun file allora è usato il file default.
Analizzare ora il file default:
Alla variabile DEFAULT corrisponde il percorso completo dell'immagine del kernel compilata precedentemente per lo slave. Nella variabile APPEND sono specificati gli argomenti da passare al kernel al momento del caricamento. Dato che è stato compilato il kernel dello slave con il supporto a NFS_ROOT_SUPPORT, allora qui si specifica il percorso del file system remoto. Il primo IP è quello del master, mentre il secondo è la directory creata all'interno di /diskless per contenere il file system iniziale dello slave.
Etherboot carica l'immagine del kernel da un server TFTP. Così come PXE, anche Etherboot è equivalente a LILO o GRUB. Il programma mknbi permette di creare varie immagini d'avvio. E' necessario installare il pacchetto mknbi, al suo interno si trova tutto il necessario per creare immagini del kernel utili per il boot da remoto. Questo programma crea un'immagine del kernel preconfigurata a partire dal kernel originale.
In questa sezione si crea una semplice immagine d'avvio di etherboot. Dato che il server dhcp fornisce ai client il percorso della loro directory di root (è stata specificata all'interno del dhcp.conf con l'opzione option root-path) in questo momento non si deve indicarla. Per ulteriori informazioni è consigliabile la lettura della pagina man di mknbi:
Procedere ora alla creazione delle immagini d'avvio. In questa fase si creano delle immagini d'avvio in ELF in grado di fornire al kernel le informazioni relative al dhcp ed al percorso del filesystem remoto; inoltre si forza il kernel a cercare nella rete un server dhcp.
Problemi comuni con l'avvio tramite rete Ci sono un paio di modi per individuare gli errori che si verificano durante la fase d'avvio remoto. Per prima cosa è possibile utilizzare un programma chiamato tcpdump. Per installarlo digitare:
Ora è possibile controllare il traffico della propria rete, accertandosi che le iterazioni client/server funzionino a dovere. Se non si riesce a vedere il traffico tra i due host bisogna controllare un paio di cose. Il primo controllo è verificare che i due host siano collegati fisicamente in maniera corretta, e che il cavo di rete non sia danneggiato. Se il client/server non ricevele richieste destinate ad una certa porta allora verificare la presenza di eventuali firewall e la loro configurazione. Per leggere il traffico tra due pc digitare:
E' possibile utilizzare tcpdump per visualizzare il traffico relativo ad una particolare porta. Per ascoltare il traffico sulla porta di tftp digitare:
Un errore molto comune è il seguente: "PXE-E32: TFTP open time-out". Solitamente è dovuto alle regole di alcuni firewall. Se si sta usando TCPwrappers si consiglia di controllare i file /etc/hosts.allow e etc/hosts.deny controllando che siano impostati correttamente. Ricordare che al client dove essere consentito di connettersi al server. NFS significa Network File System. Il server NFS viene utilizzato per fornire lo spazio di lavoro agli slave. Il server NFS può essere configurato in vari modi, ma questi esulano dagli intenti di questa guida. Molti servizi dei client e dei server non sono in ascolto su una determinata porta, ma si affidano alle RPC (Remote Procedure Calls). Quando il servizio è inizializzato si mette in ascolto su una porta a caso e poi registra questa porta tramite l'uso di Portmapper. NFS si affida alle RPC e pertanto Portmapper deve essere in esecuzione prima del suo avvio. Il server NFS richiede delle opzioni abilitate all'interno del kernel, nel caso non siano selezionate è necessario ricompilare il kernel del master. Per controllare rapidamente la selezione di queste opzioni digitare:
Se il kernel è stato configurato correttamente si dovrebbe avere un risultato simile al seguente:
Per installare il pacchetto contenente i programmi di NFS digitare:
Questo pacchetto installa i programmi richiesti per un corretto funzionamento di NFS, preoccupandosi di risolvere tutte le loro dipendenze. I principali file da configurare sono:
All'interno del file /etc/exports sono specificate le directory da condividere, come condividerle e a chi condividerle. Il file fstab dello slave viene modificato in maniera tale da montare il filesystem che il master condivide. Una configurazione tipica del file /etc/exports del master dovrebbe apparire così:
Il primo campo indica la directory da esportare, quello successivo indica a chi e come condividerla. Il secondo campo può essere diviso in due parti: nella prima si indica chi può accedere alla condivisione, nel secondo campo si indicano i suoi permessi sulla directory. I permessi possono essere di sola lettura(ro), lettura e scrittura (rw). Gli attributi no_root_squash e no_all_squash sono importanti per le proprie postazioni remote in quanto evitano crash e perdite di dati durante le operazioni di lettura e scrittura. Il file /diskless/192.168.1.21/etc/fstab dello slave dovrebbe essere simile al seguente:
Nell'esempio la variabile master è semplicemente l'hostname del master, oppure il suo indirizzo IP. Il primo campo indica la directory che deve essere montata, il secondo campo indica il punto in cui montarla. Il terzo campo indica il filesystem da utilizzare, questo deve essere NFS per ogni punto di mount NFS. Il quarto campo indica varie opzioni che saranno usate durante il mount (per approfondimenti consultare le pagine man di mount(1)). Molti utenti hanno riscontrato difficoltà usando dei punti di mount soft, pertanto sono stati usati solo punti di mount hard. Per ottimizzare il proprio sistema si consiglia di leggere le varie opzioni applicabili a /etc/fstab. L'ultimo file da modificare è /etc/conf.d/nfs. In questo file sono specificate alcune opzioni che sono usate all'avvio di nfs. Dovrebbe essere simile al seguente:
È necessario cambiare il parametro RPCNFSDCOUNT inserendo il numero di postazioni remote che sono presenti nella propria rete. Per avviare il server nfs utilizzare lo script situato in /etc/init.d. Basta digitare:
Per avviare il server nfs all'avvio del master digitare:
6. Completare il filesystem dello slave A questo punto è possibile sincronizzare il filesytem dello slave con quello del master fornendo i binari necessari, ma mantenenndo i file propri dello slave.
Configurare le opzioni di rete delle postazioni diskless Per evitare che gli script di rete eseguiti all'avvio saturino la connessione al server NFS, è necessario modificare opportunamente il file /etc/conf.d/net presente in ogni postazione diskless client.
Aggiungere tutti gli script d'avvio che si desidera all'interno di /diskless/192.168.1.21/etc/runlevels. Tutto dipende da ciò che gli slave dovranno svolgere.
Questa è la fine, è ora di avviare il proprio slave. In bocca al lupo! I contenuti di questo documento sono rilasciati sotto la licenza Creative Commons - Attribution / Share Alike. |
|