* [gentoo-docs-it] Aggiornamento diskless-howto
@ 2006-10-30 14:59 99% Flavio Castelli
0 siblings, 0 replies; 1+ results
From: Flavio Castelli @ 2006-10-30 14:59 UTC (permalink / raw
To: gentoo-docs-it
[-- Attachment #1: Type: text/plain, Size: 235 bytes --]
file: diskless-howto.xml
versione: 1.22
revisione: 1.27
Ciao
Flavio
--
|§ micron<- ICQ #118796665
|§ GPG Key:
|§ ~ Keyserver: pgp.mit.edu
|§ ~ KeyID: 6D632BED
~ "Progress is merely a realisation of utopias" ~
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: diskless-howto.xml --]
[-- Type: text/xml; charset="us-ascii"; name="diskless-howto.xml", Size: 51603 bytes --]
<?xml version='1.0' encoding="UTF-8"?>
<!-- $Header: /var/www/www.gentoo.org/raw_cvs/gentoo/xml/htdocs/doc/en/diskless-howto.xml,v 1.27 2006/10/22 23:23:04 nightmorph Exp $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link="/doc/it/diskless-howto.xml" lang="it">
<title>Postazioni diskless usando Gentoo Linux</title>
<author title="Ricerca">
<mail link="ma53@drexel.edu">Michael Andrews</mail>
</author>
<author title="Redazione">
<mail link="unsolo@sysrq.no">Kristian Jerpetjoen</mail>
</author>
<author title="Revisione">
<mail link="swift@gentoo.org">Sven Vermeulen</mail>
</author>
<author title="Revisione">
<mail link="neysx@gentoo.org">Xavier Neys</mail>
</author>
<author title="Traduzione">
<mail link="micron@bglug.it">Flavio Castelli</mail>
</author>
<abstract>
Questo HOWTO illustra la realizzazione di una rete diskless tramite l'uso di Gentoo Linux
</abstract>
<!-- I contenuti di questo documento sono distribuiti con la licenza CC-BY-SA -->
<!-- Per maggiori informazioni consultare il sito web http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>
<version>1.22</version>
<date>2006-10-22</date>
<chapter>
<title>Introduzione</title>
<section>
<title>Prefazione</title>
<body>
<p>
Questo HOWTO intende illustrare la creazione di una rete formata da postazioni <e>diskless</e>,
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.
</p>
</body>
</section>
<section>
<title>Cosa è un PC diskless?</title>
<body>
<p>
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 riferiremo al server con il termine di <e>master</e>, mentre con il termine <e>slave</e> 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 consultate la lista presente sul sito <uri link="http://www.etherboot.org">Etherboot.org</uri>. La maggior parte delle schede di rete (comprese quelle
integrate sulle schede madri) di recente produzione supporta PXE.
</p>
</body>
</section>
<section>
<title>Prima di iniziare</title>
<body>
<p>
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.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Configurazione del master e degli slave</title>
<section>
<title>Cosa è il kernel</title>
<body>
<note>
Se si desidera utilizzare le proprie postazioni all'interno di un cluster openMosix è necessario controllare di utilizzare un
kernel con applicate le patch necessarie ad openMosix. L'ebuild relativo si può trovare all'interno del portage, nel
percorso <path>sys-kernel/openmosix-sources</path>. Per compilare un kernel funzionante con openMosix è consigliata la lettura dell'<uri link="openmosix-howto.xml">openMosix HOWTO</uri>
</note>
<p>
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.
</p>
<p>
Per ulteriori informazioni sul kernel e su come configurarlo è consigliata la lettura di <uri link="http://www.tldp.org/HOWTO/Kernel-HOWTO.html">
questa</uri> guida.
</p>
</body>
</section>
<section>
<title>Configurazione del kernel della postazione master</title>
<body>
<p>
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:
</p>
<pre caption="Configurare il kernel del master">
# <i>cd /usr/src/linux</i>
# <i>make menuconfig</i>
</pre>
<p>
A questo punto si presenta un'interfaccia grafica: si tratta di un'alternativa più
rapida rispetto alla modifica a mano del file <path>/usr/src/linux/.config</path>. 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:
</p>
<pre caption="Fare una copia della configurazione del kernel del master">
# <i>cp .config .config_funzionante</i>
</pre>
<p>
Entrare nei seguenti sotto-menu e controllate che le opzioni elencate siano impostate come compilate staticamente (e <e>NON</e> 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:
</p>
<pre caption="Opzioni per il kernel del master">
Code maturity level options --->
[*] Prompt for development and/or incomplete code/drivers
Device Drivers --->
Networking options --->
<*> Packet socket
<*> Unix domain sockets
[*] TCP/IP networking
[*] IP: multicasting
[ ] Network packet filtering (replaces ipchains)
File systems --->
Network File Systems --->
<*> NFS server support
[*] Provide NFSv3 server support
<comment>
Se si intende accedere a internet tramite il master e avere un firewall sicuro è consigliabile attivare il supporto a iptables.
</comment>
[*] Network packet filtering (replaces ipchains)
IP: Netfilter Configuration --->
<*> Connection tracking (required for masq/NAT)
<*> IP tables support (required for filtering/masq/NAT)
</pre>
<p>
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 della <uri
link="http://www.gentoo.org/doc/it/gentoo-security.xml#doc_chap12">Guida Gentoo alla sicurezza</uri>.
</p>
<note>
Queste opzioni del kernel sono da intendersi come un'aggiunta alle vostre attuali opzioni, esse non intendono
rimpiazzare completamente la propria configurazione del kernel.
</note>
<p>
Dopo aver riconfigurato il kernel del master è necessario procedere alla sua compilazione:
</p>
<pre caption="Ricompilare il kernel del master ed i suoi moduli">
# <i>make && make modules_install</i>
<comment>(Accertarsi che /boot sia montata prima di copiarvi i file)</comment>
# <i>cp arch/i386/boot/bzImage /boot/bzImage-master</i>
</pre>
<p>
Infine aggiungere una nuova voce per il nuovo kernel all'interno di
<path>lilo.conf</path> o di <path>grub.conf</path>, a seconda del proprio bootloader.
Ora che il nuovo file bzImage è stato copiato nella directory <path>/boot</path> è possibile riavviare il sistema per attivare le nuove modifiche.
</p>
</body>
</section>
<section>
<title>Configurare il kernel degli slave</title>
<body>
<p>
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. Si compili il kernel degli slave nello stesso percorso in cui abbiamo
compilato quello del master.
</p>
<p>
Per evitare confusione e inutili sprechi di tempo è consigliabile fare una copia della configurazione del kernel del
master. Digitare semplicemente:
</p>
<pre caption="Fare un bakup della configurazione del kernel del master">
# <i>cp /usr/src/linux/.config /usr/src/linux/.config_master</i>
</pre>
<p>
Si procede 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 <path>/usr/src/linux/.config</path> iniziale digitando:
</p>
<pre caption="Ripristinare il .config di default">
# <i>cd /usr/src/linux</i>
# <i>cp .config_master .config</i>
</pre>
<p>
Ora è possibile lanciare nuovamente l'interfaccia grafica di configurazione del kernel digitando:
</p>
<pre caption="Configurare il kernel dello slave">
# <i>cd /usr/src/linux</i>
# <i>make menuconfig</i>
</pre>
<p>
Accertarsi d'avere selezionato le seguenti voci come compilate staticamente e <e>NON</e> come moduli:
</p>
<pre caption="Opzioni obbligatorie del kernel dello slave">
Code maturity level options --->
[*] Prompt for development and/or incomplete code/drivers
Device Drivers --->
[*] Networking support
Networking options --->
<*> Packet socket
<*> Unix domain sockets
[*] TCP/IP networking
[*] IP: multicasting
[*] IP: kernel level autoconfiguration
[*] IP: DHCP support (NEW)
File systems --->
Network File Systems --->
<*> file system support
[*] Provide NFSv3 client support
[*] Root file system on NFS
</pre>
<note>
Un'alternativa all'uso di un server dhcp è la creazione di un server BOOTP.
</note>
<impo>
E' importante che i driver della scheda di rete siano compilati staticamente (e non come un modulo) all'interno
del kernel degli slave. Ad ogni modo l'uso dei moduli generalmente non dovrebbe rappresentare un problema.
</impo>
<p>
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).
</p>
<pre caption="Compilare il kernel dello slave">
# <i>cd /usr/src/linux</i>
# <i>make</i>
</pre>
<p>
Ora creare una directory sul master per contenere i file si sistema richiesti dallo slave. E' possibile scegliere il percorso che
si preferisce, ad esempio questo: <path>/diskless</path>. Ora copiare il file bzImage dello slave all'interno
della directory <path>/diskless</path>:
</p>
<note>
Nel caso in cui si stia lavorando con architetture differenti potrebbe essere utile salvare ogni file di configurazione del
kernel come <path>.config_arch</path>. Fare la medesima cosa con le immagini del kernel: salvarle all'interno di
<path>/diskless</path> come <path>bzImage_arch</path>.
</note>
<pre caption="Copiare il kernel dello slave">
# <i>mkdir /diskless</i>
# <i>cp /usr/src/linux/arch/i386/boot/bzImage /diskless</i>
</pre>
</body>
</section>
<section>
<title>Configurare il file system iniziale dello slave</title>
<body>
<p>
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 <path>/diskless</path> una directory per la prima postazione slave. Ogni slave ha bisogno della sua
directory di root (<path>/</path>) 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 <c>192.168.1.21</c>:
</p>
<pre caption="Creazione della directory remota di root per uno slave">
# <i>mkdir /diskless/192.168.1.21</i>
</pre>
<p>
Molti file presenti in <path>/etc</path> devono essere modificati per potere funzionare sullo slave. Copiare la directory
<path>/etc</path> del master all'interno della directory di root dello slave:
</p>
<pre caption="Creazione di /etc per lo slave">
# <i>cp -r /etc /diskless/192.168.1.21/etc</i>
</pre>
<p>
Il filesystem non è ancora pronto, ci sono ancora da creare diversi punti di mount e directory. Per crearli digitare:
</p>
<pre caption="Creazione dei punti di mount e delle directory dello slave">
# <i>mkdir /diskless/192.168.1.21/home</i>
# <i>mkdir /diskless/192.168.1.21/dev</i>
# <i>mkdir /diskless/192.168.1.21/proc</i>
# <i>mkdir /diskless/192.168.1.21/tmp</i>
# <i>mkdir /diskless/192.168.1.21/mnt</i>
# <i>chmod a+w /diskless/192.168.1.21/tmp</i>
# <i>mkdir /diskless/192.168.1.21/mnt/.initd</i>
# <i>mkdir /diskless/192.168.1.21/root</i>
# <i>mkdir /diskless/192.168.1.21/sys</i>
# <i>mkdir /diskless/192.168.1.21/var</i>
# <i>mkdir /diskless/192.168.1.21/var/empty</i>
# <i>mkdir /diskless/192.168.1.21/var/lock</i>
# <i>mkdir /diskless/192.168.1.21/var/log</i>
# <i>mkdir /diskless/192.168.1.21/var/run</i>
# <i>mkdir /diskless/192.168.1.21/var/spool</i>
# <i>mkdir /diskless/192.168.1.21/usr</i>
# <i>mkdir /diskless/192.168.1.21/opt</i>
<comment>(solo per openMosix)</comment>
# <i>mkdir /diskless/192.168.1.21/mfs</i>
</pre>
<p>
La maggior parte delle directory create precedentemente dovrebbero essere familiari. Directory quali
<path>/dev</path> o <path>/proc</path> vengono popolate all'avvio dello slave, le restanti sono montate in
seguito. E' necessario anche editare il file <path>/diskless/192.168.1.21/etc/conf.d/hostname</path> per riflettere l'hostname dello
slave. I file binario, le librerie ed i restanti file vengono inseriti più avanti, prima dell'avvio dello slave.
</p>
<p>
Anche se la directory <path>/dev</path> sarà popolata successivamente da <c>udev</c>, è comunque necessario creare il device <path>console</path>. Altrimenti si avrà il messaggio d'errore: "unable to open initial console".
</p>
<pre caption="Creazione del device console in /dev">
# <i>mknod /diskless/192.168.1.21/dev/console c 5 1</i>
</pre>
</body>
</section>
</chapter>
<chapter>
<title>Configurazione del server DHCP</title>
<section>
<title>A proposito del server DHCP</title>
<body>
<p>
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.
</p>
</body>
</section>
<section>
<title>Prima di iniziare</title>
<body>
<p>
Prima di iniziare è meglio controllare il funzionamento di alcune cose. Per prima cosa controlliamo la connessione di
rete:
</p>
<pre caption="Controllo della configurazione di rete">
# <i>ifconfig eth0 multicast</i>
# <i>ifconfig -a</i>
</pre>
<p>
E' opportuno controllare che il dispositivo <e>eth0</e> sia funzionante. Dovrebbe apparire circa così:
</p>
<pre caption="Un dispositivo eth0 funzionante">
eth0 Link encap:Ethernet HWaddr 00:E0:83:16:2F:D6
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:26460491 errors:0 dropped:0 overruns:2 frame:0
TX packets:32903198 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 txqueuelen:100
RX bytes:2483502568 (2368.4 Mb) TX bytes:1411984950 (1346.5 Mb)
Interrupt:18 Base address:0x1800
</pre>
<p>
E' importante che appaia la voce <e>MULTICAST</e>, se non compare è necessario ricompilare il proprio kernel attivando il supporto a multicast.
</p>
</body>
</section>
<section>
<title>Installazione del server DHCP</title>
<body>
<p>
Se la rete non ha ancora un server DHCP è necessario crearne uno:
</p>
<pre caption="Installazione del server dhcp">
# <i>emerge dhcp</i>
</pre>
<p>
Invece se la rete ha già un server DHCP non c'è da fare altro che configurarlo in maniera da supportare il protocollo PXE.
</p>
</body>
</section>
<section>
<title>Configurazione del server DHCP</title>
<body>
<p>
Dovrete modificare solamente il file <path>/etc/dhcp/dhcpd.conf</path> prima d'avviare il vostro server. Potete
semplicemente copiare il file di configurazione d'esempio, modificandolo in seguito:
</p>
<pre caption="Modificare il file di configurazione del server dhcp">
# <i>cp /etc/dhcp/dhcpd.conf.sample /etc/dhcp/dhcpd.conf</i>
# <i>nano -w /etc/dhcp/dhcpd.conf</i>
</pre>
<p>
Si tratta di un file indentato che dovrebbe apparire così:
</p>
<pre caption="File dhcpd.conf d'esempio">
<comment># opzioni globali</comment>
ddns-update-style none;
shared-network LOCAL-NET {
<comment># opzioni di rete condivise</comment>
subnet 192.168.1.0 netmask 255.255.255.0 {
<comment> # opzioni relative alle varie subnet</comment>
host slave{
<comment> # opzioni relative ad uno specifico host</comment>
}
group {
<comment> # opzioni relative ad un determinato gruppo</comment>
}
}
}
</pre>
<p>
Il blocco d'<c>opzioni di rete condivise</c> è facoltativo e dovrebbe essere usato per tutti gli IP che si desidera
assegnare alla stessa tipologia di rete. Si deve dichiarare almeno una <c>subnet</c>, mentre il blocco d'opzioni
relativo al <c>gruppo</c> è opzionale e consente di raggruppare le opzioni tra i vari elementi. Un buon esempio per il file
<path>dhcpd.conf</path> è questo:
</p>
<pre caption="Esempio del file dhcpd.conf">
# DHCP configuration file for DHCP ISC 3.0
ddns-update-style none;
# Definizione delle opzioni relative a PXE
# Code 1: Indirizzo IP multicast del server di boot
# Code 2: Porta UDP che il client dovrebbe monitorare per le risposte MTFTP
# Code 3: Porta UDP su cui il server MTFTP è in attesa delle richieste MTFTP
# Code 4: Numero di secondi di inattività prima che il client inizi un nuovo trasferimento MTFTP
# Code 5: Numero di secondi di inattività prima che il client provi a riavviare un trasferimento MTFTP
option space PXE;
option PXE.mtftp-ip code 1 = ip-address;
option PXE.mtftp-cport code 2 = unsigned integer 16;
option PXE.mtftp-sport code 3 = unsigned integer 16;
option PXE.mtftp-tmout code 4 = unsigned integer 8;
option PXE.mtftp-delay code 5 = unsigned integer 8;
option PXE.discovery-control code 6 = unsigned integer 8;
option PXE.discovery-mcast-addr code 7 = ip-address;
subnet 192.168.1.0 netmask 255.255.255.0 {
class "pxeclients" {
match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
option vendor-class-identifier "PXEClient";
vendor-option-space PXE;
# Deve essere indicata almeno una delle opzioni PXE relative alla propria scheda di rete, solo così
# le schede dei client capiscono che c'è un server compatibile PXE. E' necessario mettere il
# valore 0.0.0.0 alla variabile MCAST IP, in questo modo i client capiscono che non c'è un
# server TFPT multicast (il valore 0.0.0.0 indica l'assenza dell'host).
option PXE.mtftp-ip 0.0.0.0;
# Questo è il nome del file che la scheda di rete del client deve scaricare.
filename "pxelinux.0";
# Questo è l'indirizzo del server presso il quale è possibile scaricare il file.
<comment># Utilizzare l'indirizzo IP del master</comment>
next-server 192.168.1.1;
}
<comment># Se si sta utilizzando etherboot senza una specifica immagine</comment>
class "etherboot" {
if substring (option vendor-class-identifier, 0, 9) = "Etherboot" {
filename "/diskless/vmlinuz";
}
}
pool {
max-lease-time 86400;
default-lease-time 86400;
<comment># Questa opzione evita che dei pc non autorizzati ottengano un IP</comment>
deny unknown clients;
}
host slave21 {
<comment># Utilizzare l'indirizzo MAC dello slave</comment>
hardware ethernet 00:40:63:C2:CA:C9;
<comment># Fornire allo slave un indirizzo IP statico</comment>
fixed-address 192.168.1.21;
server-name "master";
<comment># Se necessario indicare l'indirizzo IP del vostro gateway</comment>
option routers 192.168.1.1;
<comment># Se necessario indicare l'indirizzo IP del vostro server DNS</comment>
option domain-name-servers 192.168.1.1;
option domain-name "mydomain.com";
<comment># Utilizzare l'hostname dello slave</comment>
option host-name "slave21";
<comment># Etherboot e pxe eseguono l'avvio con una specifica immagine</comment>
option root-path "/diskless/192.168.1.21";
if substring (option vendor-class-identifier, 0, 9) = "Etherboot" {
filename "/vmlinuz_arch";
} else if substring (option vendor-class-identifier, 0,9) ="PXEClient" {
filename "/pxelinux.0";
}
}
}
</pre>
<note>
Nulla impedisce di utilizzare insieme l'avvio tramite PXE e quello tramite Etherboot.
Il codice illustrato precedentemente è soltanto un esempio.
Nel caso incontriate problemi è raccomandata la consultazione della documentazione di DHCPd.
</note>
<p>
L'indirizzo IP in indicato dopo la voce <c>next-server</c> sarà richiesto nel file indicato alla voce <c>filename</c>
Questo indirizzo IP dovrebbe essere quello del server tftp, che solitamente è in esecuzione sul master. Il nome del file
indicato nella vece <c>filename</c> ha come percorso relativo <path>/diskless</path> (questo dipende dalle
impostazioni relative al server tftp, impostazioni che analizzeremo successivamente). All'interno del blocco di opzioni
della voce <c>host</c> alla voce <c>hardware ethernet</c> si specifica un indirizzo MAC, alla voce <c>fixed-address</c>
si indica un indirizzo IP da assegnare staticamente all'indirizzo MAC indicato in precedenza. E' consigliabile
fare uso anche della voce <c>host-name</c>, la quale non indica altro che l'hostname di un particolare slave. Per
ulteriori informazioni è consigliabile la lettura dell'ottima pagina man di <path>dhcpd.conf</path>, ci sono infatti molte
altre opzioni che vanno oltre gli scopi di questa guida. E' possibile leggere la pagina man digitando:
</p>
<pre caption="Leggere la pagina man di dhcpd.conf">
# <i>man dhcpd.conf</i>
</pre>
</body>
</section>
<section>
<title>Avviare il server DHCP</title>
<body>
<p>
Prima di lanciare lo script d'avvio del server dhcp modificare il file <path>/etc/conf.d/dhcp</path> in maniera che
assomigli a questo:
</p>
<pre caption="Esempio del file /etc/conf.d/dhcp">
IFACE="eth0"
<comment># inserire altre eventuali opzioni</comment>
</pre>
<p>
La variabile <c>IFACE</c> corrisponde al dispositivo di rete su cui il server DHCP resta in ascolto, in questo caso
<c>eth0</c>. Nel caso di complesse tipologie di rete, con più dispositivi di rete, potrebbe essere necessario
aggiungere più valori alla variabile <c>IFACE</c>. Per avviare il server dhcp digitare:
</p>
<pre caption="Avviare il server dhcp sul master">
# <i>/etc/init.d/dhcp start</i>
</pre>
<p>
Per avviare il server dhcp fin dall'avvio del master digitare:
</p>
<pre caption="Avviare il server dhcp all'avvio del master">
# <i>rc-update add dhcp default</i>
</pre>
</body>
</section>
<section>
<title>Possibili problemi con il server DHCP</title>
<body>
<p>
E' possibile verificare l'avvio di una postazione remota leggendo il file <path>/var/log/syslog.log</path>.
Se la postazione esegue con successo la procedura di boot, verso la fine del file <path>messages</path> si dovrebbero
avere delle linee come queste:
</p>
<pre caption="Possibili linee create nel file di log dal server dhcp">
DHCPDISCOVER from 00:00:00:00:00:00 via eth0
DHCPOFFER on 192.168.1.21 to 00:00:00:00:00:00 via eth0
DHCPREQUEST for 192.168.1.21 from 00:00:00:00:00:00 via eth0
DHCPACK on 192.168.1.21 to 00:00:00:00:00:00 via eth0
</pre>
<note>
Da questo file di log è possibile anche scoprire gli indirizzi MAC degli slave.
</note>
<p>
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.
</p>
<pre caption="Possibile errore del server dhpc">
no free leases on subnet LOCAL-NET
</pre>
<p>
Ogni volta che sono fatte delle modifiche alla configurazione è necessario riavviare il server dhcp.
Per riavviarlo digitare:
</p>
<pre caption="Riavviare il server dhcp sul master">
# <i>/etc/init.d/dhcpd restart</i>
</pre>
</body>
</section>
</chapter>
<chapter>
<title>Configurare il server TFTP e l'avvio tramite PXE e/o Etherboot </title>
<section>
<title>A proposito del server TFTP</title>
<body>
<p>
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.
</p>
</body>
</section>
<section>
<title>Installare il server TFTP</title>
<body>
<p>
E' consigliabile utilizzare l'ebuild <c>tftp-hpa</c>. Si tratta di un'implementazione scritta dall'autore di SYSLINUX che
funziona molto bene con PXE. Per installarlo digitare:
</p>
<pre caption="Installazione del server tfp">
# <i>emerge tftp-hpa</i>
</pre>
</body>
</section>
<section>
<title>Configurare il server TFTP</title>
<body>
<p>
Modificare il file <path>/etc/conf.d/in.tftpd</path>. All'interno si deve specificare, con la
variabile <c>INTFTPD_PATH</c>, il percorso della directory di root del server tftp e, nella variabile
<c>INTFTPD_OPTS</c>, le opzioni con cui avviare il server tftp. Il file dovrebbe essere simile a quello riportato
di seguito:
</p>
<pre caption="Esempio del file /etc/conf.d/in.tftpd">
INTFTPD_PATH="/diskless"
INTFTPD_OPTS="-l -v -s ${INTFTPD_PATH}"
</pre>
<p>
L'opzione <c>-l</c> indica che il server resta in ascolto senza richiedere l'avvio di inetd. L'opzione <c>-v</c>
indica che il server scrive nei file di log molte informazioni in più rispetto al solito.
L'opzione <c>-s /diskless</c> specifica la directory di root del vostro server tftp.
</p>
</body>
</section>
<section>
<title>Avviare il server TFTP</title>
<body>
<p>
Per avviare il server tftp digitate:
</p>
<pre caption="Avviare il server tftp sul master">
# <i>/etc/init.d/in.tftpd start</i>
</pre>
<p>
In questo modo il server tftp viene avviato usando le opzioni specificate in <path>/etc/conf.d/in.tftpd</path>.
Se si desidera avviare il server tftp ad ogni avvio del master digitate:
</p>
<pre caption="Avviare automaticamente il server tftp all'avvio">
# <i>rc-update add in.tftpd default</i>
</pre>
</body>
</section>
<section>
<title>A proposito di PXELINUX</title>
<body>
<p>
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.
</p>
</body>
</section>
<section>
<title>Prima di iniziare</title>
<body>
<p>
E' necessario procurarsi il file <path>pxelinux.0</path> che è contenuto nel pacchetto <c>SYSLINUX</c> (il cui
autore è H. Peter Anvin). E' possibile installare questo pacchetto digitando:
</p>
<pre caption="Installare syslinux">
# <i>emerge syslinux</i>
</pre>
</body>
</section>
<section>
<title>Configurare PXELINUX</title>
<body>
<note>
Non è richiesto Etherboot
</note>
<p>
Prima d'avviare il server tftp si deve configurare pxelinux. Per prima cosa copiare il binario di pxelinux
all'interno della directory <path>/diskless</path>:
</p>
<pre caption="Configurare il bootloader remoto">
# <i>cp /usr/lib/syslinux/pxelinux.0 /diskless</i>
# <i>mkdir /diskless/pxelinux.cfg</i>
# <i>touch /diskless/pxelinux.cfg/default</i>
</pre>
<p>
Questo crea una configurazione di default per il bootloader. L'eseguibile <path>pxelinux.0</path> andrà a cercare,
all'interno della directory in cui è contenuto il file <path>pxelinux.cfg</path>, 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 <path>default</path>.
</p>
<pre caption="Sequenza di file cercati da PXE all'interno di pxelinux.cfg/">
<comment>(Lo 01 iniziale indica un'interfaccia Ethernet, i byte successivi coincidono con l'indirizzo MAC dello slave.</comment>
01-00-40-63-c2-ca-c9
<comment>(IP assegnati in esadecimale)</comment>
C0A80115
C0A8011
C0A801
C0A80
C0A8
C0A
C0
C
default
</pre>
<note>
Tutti i caratteri sono minuscoli.
</note>
<p>
Si analizzi ora il file <path>default</path>:
</p>
<pre caption="Esempio del file pxelinux.cfg/default">
DEFAULT /bzImage
APPEND ip=dhcp root=/dev/nfs nfsroot=192.168.1.1:/diskless/192.168.1.21
</pre>
<p>
Alla variabile <c>DEFAULT</c> corrisponde il percorso completo dell'immagine del kernel compilata precedentemente
per lo slave. Nella variabile <c>APPEND</c> sono specificati gli argomenti da passare al kernel al momento del
caricamento. Dato che è stato compilato il kernel dello slave con il supporto a <c>NFS_ROOT_SUPPORT</c>, 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 <path>/diskless</path> per contenere il file system iniziale dello slave.
</p>
</body>
</section>
<section>
<title>A proposito di Etherboot</title>
<body>
<note>
E' possibile evitare l'uso di Etherboot se si ha intenzione di usare PXE.
</note>
<p>
Etherboot carica l'immagine del kernel da un server TFTP. Così come PXE, anche Etherboot è equivalente a LILO o
GRUB. Il programma <c>mknbi</c> permette di creare varie immagini d'avvio.
</p>
</body>
</section>
<section>
<title>Prima di iniziare</title>
<body>
<p>
E' necessario installare il pacchetto <c>mknbi</c>, 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.
</p>
<pre caption="Installare mknbi">
# <i>emerge mknbi</i>
</pre>
</body>
</section>
<section>
<title>Configurare Etherboot</title>
<body>
<p>
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 <path>dhcp.conf</path> con l'opzione
<c>option root-path</c>) in questo momento non si deve indicarla. Per ulteriori informazioni è consigliabile la lettura della man page di mknbi:
</p>
<pre caption="Lettura della man page di mknbi">
# <i>man mknbi</i>
</pre>
<p>
Si procede 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.
</p>
<pre caption="Creazione delle immagini netboot">
# <i>mkelf-linux -ip=dhcp /diskless/bzImage > /diskless/vmlinuz </i>
</pre>
<note>
Per le immagini relative ad una determinata architettura è necessario specificare <c>bzImage_arch</c> e
<c>vmlinuz_arch</c>.
</note>
</body>
</section>
<section>
<title>Problemi comuni con l'avvio tramite rete</title>
<body>
<p>
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 <c>tcpdump</c>. Per installarlo digitare:
</p>
<pre caption="Installing tcpdump">
# <i>emerge tcpdump</i>
</pre>
<p>
Ora è possibile controllare il traffico della vostra rete, accertandosi che le iterazioni client/server funzionino a dovere.
Se non si riesce a vedere il traffico tra i due host dovete controllare un paio di cose. Per primo 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 riceve le 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:
</p>
<pre caption="Monitorare il traffico tra il client ed il server usando tcpdump">
# <i>tcpdump host </i><comment>client_ip</comment><i> and </i><comment>server_ip</comment>
</pre>
<p>
E' possibile utilizzare <c>tcpdump</c> per visualizzare il traffico relativo ad una particolare porta. Per ascoltare il traffico
sulla porta di tftp digitare:
</p>
<pre caption="Visualizzare il traffico diretto alla porta del server tftp">
# <i>tcpdump port 69</i>
</pre>
<p>
Un errore molto comune è il seguente: "PXE-E32: TFTP open time-out". Solitamente è dovuto alle regole di alcuni
firewall. Se si sta usando <c>TCPwrappers</c> vi consigliamo di controllare i file <path>/etc/hosts.allow</path> e
<path>etc/hosts.deny</path> controllando che siano impostati correttamente. Ricordare che al client dove essere
consentito di connettersi al server.
</p>
</body>
</section>
</chapter>
<chapter>
<title>Configurare il server NFS</title>
<section>
<title>A proposito del server NFS</title>
<body>
<p>
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.
</p>
</body>
</section>
<section>
<title>A proposito di Portmapper</title>
<body>
<p>
Molti servizi dei client e dei server non sono in ascolto su una determinata porta, ma si affidano alle RPCs (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 RPCs e pertanto Portmapper deve essere in esecuzione prima
del suo avvio.
</p>
</body>
</section>
<section>
<title>Prima di iniziare</title>
<body>
<p>
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:
</p>
<pre caption="Verificare il supporto di NFS all'interno del kernel del master">
# <i>grep NFS /usr/src/linux/.config_master</i>
</pre>
<p>
Se il kernel è stato configurato correttamente si dovrebbe avere un risultato simile al seguente:
</p>
<pre caption="Kernel configurato con il supporto a NFS">
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETFILTER is not set
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V4 is not set
# CONFIG_NFSD_TCP is not set
</pre>
</body>
</section>
<section>
<title>Installare il server NFS</title>
<body>
<p>
Per installare il pacchetto contenente i programmi di NFS digitare:
</p>
<pre caption="Installare le nfs-utils">
# <i>emerge nfs-utils</i>
</pre>
<p>
Questo pacchetto installa i programmi richiesti per un corretto funzionamento di NFS, preoccupandosi di risolvere
tutte le loro dipendenze.
</p>
</body>
</section>
<section>
<title>Configurare il server NFS</title>
<body>
<p>
I principali file da configurare sono:
</p>
<pre caption="File di configurazione di Nfs">
/etc/exports
/diskless/192.168.1.21/etc/fstab
/etc/conf.d/nfs
</pre>
<p>
All'interno del file <path>/etc/exports</path> 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.
</p>
<p>
Una configurazione tipica del file <path>/etc/exports</path> del master dovrebbe apparire così:
</p>
<pre caption="Esempio del file /etc/exports del master">
<comment># aggiungete un linea come questa per ogni slave</comment>
/diskless/192.168.1.21 192.168.1.21(sync,rw,no_root_squash,no_all_squash)
<comment># comune a tutti gli slave</comment>
/opt 192.168.1.0/24(sync,ro,no_root_squash,no_all_squash)
/usr 192.168.1.0/24(sync,ro,no_root_squash,no_all_squash)
/home 192.168.1.0/24(sync,rw,no_root_squash,no_all_squash)
<comment># se si desidera avere dei log comuni</comment>
/var/log 192.168.1.21(sync,rw,no_root_squash,no_all_squash)
</pre>
<p>
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(<c>ro</c>), lettura e scrittura (<c>rw</c>). Gli attributi <c>no_root_squash</c> e <c>no_all_squash</c> sono importanti per le nostre postazioni remote in quanto evitano crash e perdite di dati durante le operazioni di lettura e scrittura.
Il file <path>/diskless/192.168.1.21/etc/fstab</path> dello slave dovrebbe essere simile al seguente:
</p>
<pre caption="Esempio del file fstab di uno slave">
<comment># queste voci sono essenziali</comment>
master:/diskless/192.168.1.21 / nfs sync,hard,intr,rw,nolock,rsize=8192,wsize=8192 0 0
master:/opt /opt nfs sync,hard,intr,ro,nolock,rsize=8192,wsize=8192 0 0
master:/usr /usr nfs sync,hard,intr,ro,nolock,rsize=8192,wsize=8192 0 0
master:/home /home nfs sync,hard,intr,rw,nolock,rsize=8192,wsize=8192 0 0
none /proc proc defaults 0 0
<comment># voci utili ma opzionali</comment>
master:/var/log /var/log nfs hard,intr,rw 0 0
<comment>(solo se si sta configurando un cluster openMosix)</comment>
none /mfs mfs dfsa=1 0 0
</pre>
<p>
Nell'esempio la variabile <e>master</e> è 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 vostro sistema si consiglia di leggere le varie opzioni applicabili a <path>/etc/fstab</path>.
</p>
<p>
L'ultimo file da modificare è <path>/etc/conf.d/nfs</path>. In questo file sono specificate alcune opzioni che sono usate
all'avvio di nfs. Dovrebbe essere simile al seguente:
</p>
<pre caption="Esempio del file /etc/conf.d/nfs presente sul master">
# Config file for /etc/init.d/nfs
# Number of servers to be started up by default
RPCNFSDCOUNT=8
# Options to pass to rpc.mountd
RPCMOUNTDOPTS=""
</pre>
<p>
E' necessario cambiare il parametro <c>RPCNFSDCOUNT</c> inserendo il numero di postazioni remote che sono presenti
nella propria rete.
</p>
</body>
</section>
<section>
<title>Avviare il server NFS</title>
<body>
<p>
Per avviare il server nfs utilizzare lo script situato in
<path>/etc/init.d</path>. Basta digitare:
</p>
<pre caption="Avviare il server nfs">
# <i>/etc/init.d/nfs start</i>
</pre>
<p>
Per avviare il server nfs all'avvio del master digitare:
</p>
<pre caption="Avviare il server nfs all'avvio del master">
# <i>rc-update add nfs default</i>
</pre>
</body>
</section>
</chapter>
<chapter>
<title>Completare il filesystem dello slave</title>
<section>
<title>Copiare i file mancanti</title>
<body>
<p>
A questo punto è possibile sincronizzare il filesytem dello slave con quello del master fornendo i binari necessari, ma mantendo
i file propri dello slave.
</p>
<pre caption="Creazione del filesystem dello slave">
# <i>rsync -avz /bin /diskless/192.168.1.21</i>
# <i>rsync -avz /sbin /diskless/192.168.1.21</i>
# <i>rsync -avz /lib /diskless/192.168.1.21</i>
</pre>
<note>
E' stato usato il comando <c>rsync -avz</c> al posto di <c>cp</c> per mantenere i collegamenti simbolici ed i
permessi dei file copiati.
</note>
</body>
</section>
<section>
<title>Script di inizializzazione</title>
<body>
<p>
Gli script di base cercano di lanciare <e>checkroot</e>, ciò ovviamente non ha alcun senso per il slave.
Per risolvere questo problema è possibile modificare lo script di avvio <path>/diskless/192.168.1.21/sbin/rc</path>,
questa però è una soluzione pericolosa e molto difficile; inoltre dopo ogni sincronizzazione del filesystem dello slave
sarebbe necessario ripetere questa operazione. Esiste però un trucco: avere un file <path>/fastboot</path> all'avvio del proprio
sistema. Questo file indica a <e>checkroot</e> di non compiere alcun controllo all'avvio. Purtroppo <e>checkroot</e>
cancella il file <path>/fastboot</path> al termine della procedura d'avvio, si deve quindi ricreare questo file prima
dello spegnimento/riavvio dello slave. Basta digitare i seguenti comandi:
</p>
<pre caption="Evitare che gli script d'avvio compiano un controllo sul filesystem">
<comment>(Si crea il file /fastboot per il prossimo avvio)</comment>
# <i>touch /diskless/192.168.1.21/fastboot</i>
<comment>(Si crea il file /fastboot ad ogni avvio)</comment>
# <i>echo "touch /fastboot" >> /diskless/192.168.1.21/etc/conf.d/local.start</i>
</pre>
<p>
Dato che i filesystem remoti devono essere smontati il più tardi possibile bisogna modificare il file <path>/etc/init.d/netmount</path> nel seguente modo:
</p>
<pre caption="Modificare /etc/init.d/netmount">
depend() {
<i>before *</i>
</pre>
<note>
La versione 1.11.* e successive di baselayout non necessitano di questa modifica.
</note>
<p>
Se si sta usando un file system live, non bisogna dimenticarsi di eseguire <c>depscan.sh</c> per risolvere le dipendenze dei servizi. Si possono ignorare tranquillamente gli eventuali messaggi d'avvertimento relativi alle collisioni con /etc/init.d/checkroot. Questo è possibile perchè checkroot è disabilitato dal file fastboot creato nel paragrafo precedente.
</p>
<p>
A questo punto si è liberi d'aggiungere tutti gli script d'avvio che si desidera all'interno di
<path>/diskless/192.168.1.21/etc/runlevels</path>; aggiungere tutti quelli che si desidera che siano
avviati sulla propria postazione remota.
</p>
<warn>
<e>NON utilizzare</e> il comando <c>rc-update</c> per rimuovere o aggiungere gli script dal runlevel dello slave mentre si è
collegati sul master. Infatti questo provocherebbe un cambiamento al runlevel del master e non dello slave. Si deve
creare i collegamenti a mano, oppure collegarsi allo slave fisicamente (tramite tastiera e monitor) oppure da remoto (per esempio tramite ssh).
</warn>
<pre caption="Tipici runlevel di uno slave">
/diskless/192.168.1.21/etc/runlevels/:
total 16
drwxr-xr-x 2 root root 4096 2003-11-09 15:27 boot
drwxr-xr-x 2 root root 4096 2003-10-01 21:10 default
drwxr-xr-x 2 root root 4096 2003-03-13 19:05 nonetwork
drwxr-xr-x 2 root root 4096 2003-02-23 12:26 single
/diskless/192.168.1.21/etc/runlevels/boot:
total 0
lrwxrwxrwx 1 root root 20 2003-10-18 17:28 bootmisc -> /etc/init.d/bootmisc
lrwxrwxrwx 1 root root 19 2003-10-18 17:28 checkfs -> /etc/init.d/checkfs
lrwxrwxrwx 1 root root 17 2003-10-18 17:28 clock -> /etc/init.d/clock
lrwxrwxrwx 1 root root 22 2003-10-18 17:28 domainname -> /etc/init.d/domainname
lrwxrwxrwx 1 root root 20 2003-10-18 17:28 hostname -> /etc/init.d/hostname
lrwxrwxrwx 1 root root 22 2003-10-18 17:28 localmount -> /etc/init.d/localmount
lrwxrwxrwx 1 root root 19 2003-10-18 17:28 modules -> /etc/init.d/modules
lrwxrwxrwx 1 root root 18 2003-10-18 17:28 net.lo -> /etc/init.d/net.lo
lrwxrwxrwx 1 root root 20 2003-10-18 17:28 netmount -> /etc/init.d/netmount
lrwxrwxrwx 1 root root 21 2003-10-18 17:28 rmnologin -> /etc/init.d/rmnologin
lrwxrwxrwx 1 root root 19 2003-10-18 17:28 urandom -> /etc/init.d/urandom
/diskless/192.168.1.21/etc/runlevels/default:
total 0
lrwxrwxrwx 1 root root 23 2003-10-18 17:28 consolefont -> /etc/init.d/consolefont
lrwxrwxrwx 1 root root 19 2003-10-18 17:28 distccd -> /etc/init.d/distccd
lrwxrwxrwx 1 root root 19 2003-10-18 17:28 keymaps -> /etc/init.d/keymaps
lrwxrwxrwx 1 root root 17 2003-10-18 17:28 local -> /etc/init.d/local
lrwxrwxrwx 1 root root 16 2003-10-18 17:28 sshd -> /etc/init.d/sshd
lrwxrwxrwx 1 root root 21 2003-10-18 17:28 syslog-ng -> /etc/init.d/syslog-ng
lrwxrwxrwx 1 root root 17 2003-10-18 17:28 vixie-cron -> /etc/init.d/vixie-cron
/diskless/192.168.1.21/etc/runlevels/nonetwork:
total 0
lrwxrwxrwx 1 root root 17 2003-10-18 17:28 local -> /etc/init.d/local
/diskless/192.168.1.21/etc/runlevels/single:
total 0
</pre>
<p>
Questa è la fine, è ora di avviare il proprio slave.
In bocca al lupo!
</p>
</body>
</section>
<!--
<section>
<title>An alternative : ClusterNFS</title>
<body>
<warn>
This is mentioned only because a reviewer of this document is using this
solution. Be aware that Gentoo <e>does not</e> support ClusterNFS. It is not in
portage and requires changes to a baselayout init script. <b>Use at your own
risks</b>.
</warn>
<p>
If you don't fancy having a distinct root for each slave because it needs some
maintenance when upgrading files from the master directories, you could share
the same root across all nodes, master and slaves included. This means all your
machines need to be compatible because you will have only one set of binaries.
You also need to be aware that this might have security issues because all of
your master root will be exported through NFS.
</p>
<p>
If you still want to try out this alternative, visit the ClusterNFS <uri
link="http://clusternfs.sourceforge.net/">home page</uri>, download the
software and read the doc.
</p>
<p>
To make it short, all files are shared and the files that need to be different
between master and all slaves are copied to <path>file$$CLIENT$$</path>. When a
slave requests <path>file</path>, ClusterNFS will notice the existence of
<path>file$$CLIENT$$</path> and send it instead. Files that need to be
different on each node are copied to <path>file$$IP=192.168.1.21$$</path>.
The same applies to directories.
</p>
<p>
Very shortly, this is what differs from the installation procedure described
above:
</p>
<ul>
<li>You do not need NFS server support in your master kernel</li>
<li>Install ClusterNFS <e>after</e> you emerge nfs-utils</li>
<li>Make slave copies of files and directories as described below</li>
<li>Do not create a root dir for each node</li>
<li>Export only / in your <path>/etc/exports</path> file</li>
<li>
Only mount / via NFS in the slave <path>/etc/fstab$$CLIENT$$</path> file
</li>
<li>Edit <path>/etc/init.d/nfs</path> as described below</li>
<li>
Edit <path>/etc/conf.d/local.start$$CLIENT$$</path> as described below
</li>
</ul>
<pre caption="Files that need to be different between master and slaves">
/etc/conf.d/local.start$$CLIENT$$
/etc/conf.d/local.stop$$CLIENT$$<comment> (Probably empty)</comment>
/etc/crontab$$CLIENT$$<comment> (Probably empty, master takes care of chores)</comment>
/etc/exports$$CLIENT$$<comment> (Empty, slaves do not export NFS mounts)</comment>
/etc/fstab$$CLIENT$$
/etc/hostname$$IP=192.168.1.21$$<comment> (Name your slaves)</comment>
/etc/mtab$$IP=192.168.1.21$$
/etc/runlevels$$CLIENT$$<comment> (Clean separation between master and slave boot scripts)</comment>
/fastboot$$CLIENT$$
/tmp$$IP=192.168.1.21$$
/var$$IP=192.168.1.21$$<comment> (Create subdirs as in /var)</comment>
</pre>
<pre caption="Editing /etc/init.d/nfs">
ebegin "Starting NFS daemon"
start-stop-daemon - -start - -quiet - -exec \
<comment># Add - -translate-names option</comment>
$nfsd - - - -translate-names
eend $? "Error starting NFS daemon"
# Check if we support NFSv3
ebegin "Starting NFS mountd"
<comment># Comment the following two lines (ClusterNFS only knows NFS v2)</comment>
# rpcinfo -u localhost nfs 3 &>/dev/null || \
# RPCMOUNTDOPTS="$RPCMOUNTDOPTS - -no-nfs-version 3"
start-stop-daemon - -start - -quiet - -exec \
$mountd - - $RPCMOUNTDOPTS 1>&2
eend $? "Error starting NFS mountd"
</pre>
<pre caption="Editing /etc/conf.d/local.start$$CLIENT$$">
<comment>(Add this line)</comment>
touch /fastboot\$\$CLIENT\$\$
</pre>
</body>
</section>
-->
</chapter>
</guide>
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2006-10-30 14:59 99% [gentoo-docs-it] Aggiornamento diskless-howto Flavio Castelli
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox