Newsgroup: it.comp.os.linux.sys
Titolo: Boot via rete

L'unica esperienza di boot via rete che ho è per il software dei telefoni voip caricato via PXE.
 
In caso di server, se volessi avere macchine senza disco e caricare tutto via rete, tutto il sistema (quindi ipoteticamente i 5-6GB di dati), dove vanno, tutti in RAM?

gandalf.co...@gmail.com
 ha scritto:

Di solito no, puoi forzare il caricamento del sistema in ram, come si
fa per alcune live, ma normalmente quello che serve serve caricare in
ram è il kernel, il resto viene letto/scritto dal disco del server.
NFS nacque [anche] per quello.
-- 
    Ciao   |Save our planet!             Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@bofhland.org
 

 (quindi ipoteticamente i 5-6GB di dati), dove vanno, tutti in RAM?
 
Come ti hanno detto, via nfs.
L'estate scorsa ci ho sbattuto molto la testa. Ne č saltata fuori una
mini guida:
 
http://montellug.it/wiki/index.php?title=MintNetInstall#Configurazione_per_il_netboot_di_una_normale_installazione_linux
 
 
Questa č la parte che dovrebbe interessare a te. Sono poche righe per
trasformare una normale installazione in installazione di rete.
Il resto del documento verte su come fare un'installazione di rete. In
ogni caso, si tratta della mia esperienza e dei casini che ho avuto io.
Tu magari potresti averli differenti.
 
P. S.: nel tuo caso, se dovessi fare l'installazione di piů macchine e
trovi un modo per non replicare n volte tutto il file system, fai un
fischio.

 fischio.
 
All'epoca usai delle immagini qcow, ma questo dovrebbe fare al caso tuo
(che, se ho letto bene, usi NFS)
 
https://github.com/russross/cownfs
 
 
Enrico

 NFS nacque [anche] per quello.
 
Quindi in soldoni tramite PXE carico il kernel, poi durante la fase di boot il resto del sistema viene caricato via NFS e facendo un boot via NFS eventuali scritture vanno verso l'NFS stesso quindi, non mi girano in ram.
 
Dico bene?

 fischio.
 
Beh, si, diciamo che devo poter avviare un gran numero di server (30-40) via rete (sono senza disco) tutti identici eccetto la configurazione di:
 - hostname
 - ip
 - 2 file di configurazione esatti.
 
quindi se fosse possibile avviare il tutto partendo da una singola immagine e far riconfigurare il sistema tramite uno script creato adhoc in fase di boot (in modo tale da dover customizzare solo lo script, server per server, e non l'intero FS), sarei a cavallo.

 Dico bene?
 
In soldoni, č cosě.
PXE lancia una specie di bootstrap in rete, bootp o tftp forniscono il
minimo indispensabile per "mappare" il disco nfs, caricare il kernel e
fare il mount del file system remoto.
Una volta che il kernel č in funzione e il file system č montato, puoi
trattarlo come se fosse una macchina "normale" con un luuungo cavo hd.


 e non l'intero FS), sarei a cavallo.
 
Ho fatto una cosa simile per un paio di cluster... prendendo spunto
dalla gestione di alternatives di Debian.
 
Ho creato una dir /srv/config con sotto una gerarchia di directory
contenenti le configurazioni e le parti specifiche di un server generico
 
/srv/config/etc/...
/srv/config/var/lib/...
 
e ho sostituito i files in /etc, in /var/lib, ecc. da differenziare tra
i server con dei link simbolici che puntano al file o directory omonimi
sotto /srv/config.
 
Per esempio
	/etc/apache2/ => /srv/config/etc/apache2/
	/etc/postfix/ => /srv/config/etc/postfix/
	/etc/resolv.conf => /srv/config/etc/resolv.conf
	/var/spool/postfix/ => /srv/config/var/spool/postfix/
ecc.ecc.
 
E poi (nel mio caso con glusterfs) ho creato una serie di configurazioni
analoghe a quella sopra specifiche per i server:
/srv/replica/server1/etc/...
/srv/replica/server1/var/lib/...
/srv/replica/server1/etc/...
/srv/replica/server2/var/lib/...
 
Quindi c'ï¿œ uno script che parte molto presto in fase di boot ed esegue
il bind della directory specifica su quella generica
 
mount -o bind /srv/replica/server1 /srv/config
 
Con glusterfs il limite ï¿œ che il servizio parte tardi nella fase di
boot, quindi non posso gestire in questo modo molti files di
configurazione e alcuni servizi devono essere restartati dopo il mount,
ma nel tuo caso sarebbe tutto piï¿œ semplice partendo da nfs sin dal boot.
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left

 [cut]
 
Aspetta che non ti seguo, non avendolo mai fatto.
Mi *potrebbe* star bene anche caricare tutto in ram, devo valutare, comunque sia, quello che vorrei fare è avere un server con una o più immagini con il rootfs dei vari nodi che devono fare il boot via rete. La configurazione dei nodi sarà identica, eccetto per alcuni parametri che posso modificare al volo in fase di boot, magari con uno script di init, ma se fosse possibile farli caricare già 'corretti' tanto meglio. (ad esempio la configurazione delle interfacce di rete o la configurazione di altri demoni)
 
I nodi devono partire, caricare il rootfs via rete e poi, volendo, tenerselo tutto in ram. Per me è tassativo poter gestire più versioni del rootfs, in modo tale che se durante un upgrade (che farò aggiornando la copia master sul server storage [chroot /srv/master && apt-get update]) un nodo dovesse riavviarsi, non si corra il rischio di fargli caricare la versione sulla quale sto attualmente lavorando.
 
Quindi, ricapitolando, posso seguire le innumerevoli guide per il boot via PXE, ma non mi è chiaro come fargli caricare i file da una directory piuttosto che da una immagine. Devo tassativamente usare una share NFS (o analoga) montata su / oppure c'è qualche parametro nella configurazione di PXE che mi permette di copiare tutto quello che c'è sul server TFTP e buttarlo in RAM ?
Non voglio usare una immagine, è molto più scomoda.
 
Spero di essere stato chiaro...

 Quindi, ricapitolando, posso seguire le innumerevoli guide per il boot via PXE, ma non mi è chiaro come fargli caricare i file da una directory piuttosto che da una immagine. Devo tassativamente usare una share NFS (o analoga) montata su / oppure c'è qualche parametro nella configurazione di PXE che mi permette di copiare tutto quello che c'è sul server TFTP e buttarlo in RAM ?
 
Sembra che si possa istruire il kernel a fare il boot via TFTP/FTP.
Il primo è comodo perchè è già installato sul server storage (dato che serve al pxe per caricare la configurazione) ma vuole una lista di file da leggere (facilmente creabile con una riga di find), il secondo è invece automatico ma richiederebbe l'installazione di un server ftp sullo storage.
 
Al limite, posso usare GlusterFS come share NFS, mi sa che si fa prima, ma come faccio a dirgli di caricarlo tutto in ram ?

> ma come faccio a dirgli di caricarlo tutto in ram ?
 
Ti consiglio di vedere come fa finnix.


 Ti consiglio di vedere come fa finnix.
 
Aspetta, il mio problema non è come fare il boot via rete, bensì come poter gestire decine e decine di host partendo da una singola share nfs (o quel che è) ma caricando singoli file customizzati in base all'host.
 
Potrei tentare di riconfigurare tutto al volo mediante uno script in fase di boot, ma non son sicuro di riuscire a farlo per tutti i servizi.
 
Se ho ben capito, con il tuo sistema, tutti i nodi avrebbero anche una copia della configurazione degli altri, ma caricherebbero solo quella "propria" grazie al bind in fase di boot. Questo mi pare un po rischioso, la compromissione di un nodo esporrebbe la configurazione di tutti gli altri. Inoltre, il primo aggiornamento fatto a colpi di apt-get rischierebbe di spaccare tutto sovrascrivendo il link simbolico.

 ï¿œ) ma caricando singoli file customizzati in base all'host.
 
Allora dai un'occhiata a ThinStation.


 Allora dai un'occhiata a ThinStation.
 
Mi pare faccia tutto internamente tramite degli script, non credo ci sia una sorta di standard. (mi riferisco ad esempio alla struttura di pxe, che carica la configurazione in base al mac)
 
Comunque, farò alcune prove con una immagine create mediante multistrap (viene circa 100M, quindi l'uso di RAM è trascurabile) ed uno script di autoconfigurazione al boot. Ciò che cambia sono sostanzialmente gli IP (che gestisco però con dhcp) ed alcune righe in un singolo file di configurazione e che posso customizzare in fase di boot.


funge tutto via rete... tranne che la live distro (come hanno già scritto) non 
preveda una opzione per il caricamento in memoria. 
p.s.: il thin client SunRay, per esempio, ha solo 8MB di RAM. E il 
funzionamento è sempre quello.

 
 
 
nel tuo DHCP server avresti potuto usare:
option root-path "10.0.1.4:/srv/replica/server1"
option root-path "10.0.1.5:/srv/replica/server2"
option root-path "10.0.1.6:/srv/replica/server3"
option root-path ....
e poi, ovviamente, ad ogni mac assegni uno specifico ip.
 
Non mi è chiara la necessità di effettuare un "mount bind" ... forse mi sono 
perso qualcosa.