Brieuc Jeunhomme frtest

bbp@via.ecp.fr

Logilab S.A. Questo documento spiega come impostare velocemente un server linux per fornire ciò che i client Linux senza disco richiedono per avviarsi e funzionare, utilizzando una rete IP. Include dati e testo parzialmente riscritto dal Diskless-HOWTO, dal Diskless-root-NFS-HOWTO, dalla documentazione del kernel linux, dalla &etb; documentazione di progetto, dal <sp;'s homepage, e dall'esperienza personale dell'autore, aquisita lavorando per &logilab;. Eventualmente questo documento può finire deprecando il Diskless-HOWTO e il Diskless-root-NFS-HOWTO. Prego notare che si troveranno informazioni utili nel From-PowerUp-to-bash-prompt-HOWTO e nel Thin-Client-HOWTO, e nella pagina di Claus-Justus Heine circa lo swapping NFS. 0.3 2002-04-28 bej Inclusione di molti feedback, aggiunti link a diversi progetti 0.2.2 2001-12-08 dcm Licensed GFDL 0.2.1 2001-05-21 logilab Corretta bibliografia e artheader 0.2 2001-05-19 bej Molti perfezionamenti e incluso feedback di Ken Yap. 0.1.1 2001-04-09 logilab Prima bozza pubblica. 0.1 2000-12-09 bej Boza iniziale. I recendi kernel linux offrono la possibilità di avviare una linux box interamente dalla rete, caricando il proprio kernel e il filesystem di root da un server. In questo caso, il client può usare diverse vie per per ottenere le prime istruzioni che deve eseguire quando si avvia: eprom della casa madre, speciali schede di rete che implementano i protocolli RARP, BOOTP o DHCP, cdrom, o bootloader caricati da un floppy di avvio o un hard disk locale. &logilab; ha sponsorizzato questo HOWTO. Vsitare il loro sito web per nuove versioni di questo documento. Grazie anche a &etb;, &ntb;, &plume; e <sp; sviluppatori e webmaster, che hanno reso possibile l'avvio di una workstation Linux attraverso la rete. Un grazie molto speciale va a Ken Yap, membro del &etb; project, i cui commenti sono stati grandemente d'aiuto per migliorare la qualità di questo documento. Grazie anche a Jerome Warnier, principale sviluppatore del &plume; project, Pierre Mondié, Kyle Bateman, Peter T. Breuer, Charles Howes, e Thomas Marteau per i loro commenti e i contributi. Qualche volta, acquistare un computer linux senza disco sarà più conveniente che costruirlo! Controllare la lista dei siti commerciali forniti in appendice, i quali vendono schede di rete senza disco e computer senza disco. Queste compagnie fanno produzione di massa di computer linux senza disco vendendo milioni di unità e pertanto riducendo il costo per unità. I computer senza disco diverranno sempre più popolari nei prossimi anni. Essi avranno molto successo a causa della disponibilità di schede di rete ad alta velocità a prezzi molto bassi. Oggi schede di rete a 100 Megabit per secondo (12.5 MB per sec di transfer rate) sono comuni e tra circa 1 o 2 anni schede di rete a 1000 MBit (125 MB per sec di transfer rate) diverrano molto convenienti e saranno lo standard. Nel prossimo futuro, i monitor fabbricati piazzeranno la CPU, NIC, RAM proprio dentro il monitor per formare un computer senza disco. Questo elimina il computer-box senza disco e salva spazio. Il monitor avrà la presa per il mouse, tastiera, rete RJ45 e alimentazione. I seguenti sono i benefici dell'uso di computer senza disco: Il costo totale di proprietà è molto basso in caso di computer senza disco. Il costo toale di proprietà è il costo iniziale dell'acquisto + costo di manutenzione. Il costo di manutenzione è usualmente da 3 a 5 volte il costo dell'acquisto iniziale del computer e questo costo ricorre anno dopo anno. In caso di computer senza disco, il costo della manutenzione è completamente eliminato. Tutti i salvataggi sono centralizzati su un singolo server principale. Non occorre batteria UPS, aria-condizionata, ambiente a prova di polvere per client senza disco, solo il server ha bisogno della batteria UPS, A/C e ambiente a prova di polvere. Una migliore protezione dagli attachi dei virus  - Alcuni vius di computer non possono attaccare i computer senza disco perchè non hanno nessun hard disk. Questo tipo di virus non possono fare nessun danno ai computer senza disco. Solo un singolo server box ha bisogno di essere protetto contro gli attacchi dei virus. Questo fa risparmiare milioni di dollari alle compagnie evitando l'installazione di antivirus e pulitori di hard disks. I server possono avere hard disck di grande potenza/alta performance, possono ottimizzare l'uso dello spazio su disco condividendolo tra molti utenti di computer senza disco. E' possibile avere una fault tolerance dei guasti degli hard disk usando il RAID sul server principale. Su alcune installazioni: si condivide la memoria RAM del server centrale tra molti utenti di computer senza disco. Per esempio, se molti utenti stanno eseguendo un browser web da remoto su un server, allora ci sarà solo una copia di questo browser web nella sua RAM. Sono richiesti molto pochi aministratori per manutenere il server centrale. Nessuna amministrazione sul lato client senza disco. I computer senza disco sono assolutamente senza manutenzione e senza problemi. I client senza disco hanno lunga vita. Lato client senza disco si elimina l'installazione/aggiornamenti di hardware, software. Si eliminano costi di cdrom, floppy, tape drive, modem, batterie UPS, stampanti su porta parallela, porte seriali etc... Si può operarare in posti come pavimenti di fabbrica dove un hard disk potrebbe essere troppo fragile. La cosa più importante in modo da avviare dalla rete è di avere un'attrezzatura che abilita la stazione a eseguire un bootloader, il quale prenderà il kernel sul server e lo eseguirà. Un'altra soluzione è di usare un dispositivo che caricherà un kernel locale, il quale monterà il filesystem di root sul server. Ci sono diverse soluzioni: eprom fatte in casa contenenti le prime istruzioni da eseguire quando la stazione di avvia, l'avvio con adattatori di rete capaci del BOOTP/DHCP, o un floppy locale, un piccolo hard disk, o un cdrom per caricare il kernel. Notare che alcuni venditori vendono anche stazioni capaci dell'avvio da rete: per esempio, alcune stazioni Sun implementano il protocollo BOOTP. Altri requisiti hardware dipendono dalla configurazione che si pianifica di usare: su alcuni siti, ogni applicazione eseguita dalla stazione viene eseguita remotamente sul server, questo implica che sia richiesto un server ad alta-performance, ma richiede solo stazioni leggere: dipende da cosa esse dovranno fare, 80486 CPU con 16 MB di RAM può essere sufficente. D'altro lato, se i programi applicativi sono realmente eseguiti localmente sulle stazioni, i reqiositi per le stazioni dipendono completamente da queste applicazioni. In quel caso, è richiesto un server più piccolo. Un 80486 CPU con 32 MB di RAM sarà sufficente per un piccolo numero di stazioni, ma sarà necessaria più memoria in installazioni molto grandi con centinaia o migliaia di macchine. Notare che la CPU del server non importa realmente per una tale installazione. Sono richiesti i sorgenti del kernel Linux versione 2.0 o successivi. Sono necessari anche tutti i tool richiesti per compilare il kernel linux (vedere la documentazione del kernel linux per maggiori informazioni su questo). Sono anche richiesti un demone BOOTP (anche un demone DHCP va bene, ma non si spiegherà come configurarlo), un demone NFS (se si vuole montare il filesystem di root su un server remoto). Occorrerà anche un demone TFTP se si pianifica di caricare il kernel remotamente. Per ultimo, l'utilità mknbi fornita con la &etb; distribuzione, e, se si usa LanWorks EPROMs, tipo quella inclusa nell'adattarore di rete 3c905 3com, occorretà anche l'utilità imggen, disponibile a &imggenurl;. Questa documentazione è stata scritta per amministratori di sistema con esperienza, che sono già consapevoli dei fondamenti di linux, come l'uso di grep, sed, e awk, programmazione base della shell, il processo init e gli scipt di avvio, complilazione del kernel, e configurazione server di NFS. Anche l'esperienza nel passaggio di argomenti al kernel dovrebbe aiutare. Informazioni su questi argomenti possono essere trovate rispettivamente nelle pagine man/info di grep, sed, awk, e bash, nel Bootdisk-HOWTO, nel From-PowerUp-To-Bash-Prompt-HOWTO, nel Kernel-HOWTO, nel BootPrompt-HOWTO, nella pagina man di bootparam, nella pagina man di rdev, nel NFS-HOWTO, e nella pagina di manuale di exports. Ci sono molte fonti di informazioni sull'avvio da rete, ma, e questo è il motivo per cui ho scritto questo HOWTO, nessuno descrive tutte le vie esistenti per avviare su una rete, e molti di loro sono specifici di un modo di operare. Il più utile per me è stato la documentazione fornita dal <sp;, sebbene non abbia usato i pacchetti che essi raccomandano, ho scelto di descrivere qui come procedere senza questi pacchetti, perchè essi configurano le cose in modo che ogni programma applicativo sia eseguito remotamente su un server. Informazioni utili possono anche essere trovate sul &etb; homepage del progetto. Per ultimo, si possono anche trovare informazioni utili ma succinte nell'albero dei sorgenti del kernel, in /usr/src/linux/Documentation, assumendo che l'albero del proprio kernel risieda in /usr/src/linux. Sarà altamente apprezzato qualsiasi feedback circa questo documento. Prego sentirsi liberi di scivermi a &bbpmail; se avete qualsiasi commento, correzione, o suggerimento. Si può anche usare contact@logilab.fr. This document is copyrighted (c) 2001 and is distributed under the terms of the GNU Free Documentation License. You should have received a copy along with it. If not, it is available from http://www.fsf.org/licenses/fdl.html. Hey, pensate che sia tempo di iniziare l'argomento reale, giusto? Andiamo. Uno potrebbe meravigliarsi di come una stazione possa avviarsi su una rete IP se non si conosce il proprio indirizzo IP. In fatti, tre protocolli abilitano il client a ottenere questa informazione e alcuni parametri aggiuntivi di configurazione: RARP: questo è il più semplice di questi protocolli. Comunque suppongo che non abiliti il server a specificare come il client dovrebbe scaricare il kernel, così non lo useremo (In fatti, c'è una convenzione che usa l'indirizzo IP della workstation come filename, es. un client che ha preso l'indirizzo 192.168.42.12 dal RARP potrà chiedere /tftpboot/192.168.42.12 all'TFTP, come fa il kernel linux. Il filename potrebbe anche essere la forma esadecimale dell'indirizzo IP, questo dipende dall'implementazione, e non è obbligatorio.). BOOTP: questo protocollo permette a un server di fornire al client (identificato dal proprio indirizzo MAC hardware) molte informazioni, in particolare il suo indirizzo IP, subnet mask, indirizzo broadcast, indirizzo di rete, indirizzo del gateway, host name, e path di caricamento del kernel. Questo è quello che useremo. DHCP: questo è un'estenzione del BOOTP. Quando il client ha preso i suoi parametri IP, se il kernel non è su un supporto locale (come un floppy, un cdrom, o un hard disk), il client inizierà a scaricarlo via TFTP. La sua collocazione viene fornita dal server BOOTP/DHCP. Un server (non necessariamente il server BOOTP/DHCP) dovrà anche eseguire un demone TFTP per i kernel non locali. Il kernel una volta ottenuto dopo la compilazione non può essere usato così "come è" per l'operazione BOOTP/DHCP, la sua immagine binaria deve essere modificata con l'utilità mknbi (e poi modificata di nuovo con l'utilità imggen se si usa LanWorks EPROM). L'utilià mknbi dovrebbe anche essere usata per modificare i kernel che sarano scritti su una ROM. Dopo che il kernel si è avviato, esso proverà a montare il proprio filesystem di root. Anche la locazione di questo filesystem è ottenuta attraverso BOOTP/DHCP, e esso viene montato via NFS. Questo significa che un client può usare BOOTP due volte per avviarsi: la prima volta per prendere il proprio kernel, e la seconda volta per sapere la locazione del filesystem di root (il quale può essere su un terzo server). Un'altra soluzione è di usare una ramdisk come filesystem di root. In questo caso, l'imagine della ramdisk è ottenuta con il kernel via TFTP. Quando il filesystem di root è montato, si può iniziare a respirare: si può almeno usare il proprio coltellino svizzero con i suoi sh, sed, e awk. Infatti, si dovranno personalizzare gli script di inizializzazione del filesystem del client: per esempio, si dovrà rimuovere tutti gli hard disk, floppy o cdrom e cose relative dal /etc/fstab (quando la propria stazione non sia equipaggiata con questi dispositivi), si può anche aver da inibire l'attivazione delle partizioni di swap (notare che c'è un modo per avere la swap su NFS o su dispositivi a blocchi in rete). Dovrete anche automagicamente generare tutti i file di configurazione di rete all'avvio se diversi client usano lo stesso filesystem di root remoto. Prima di tutto, compilare un kernel per i client. Suggerisco di compilarlo sul server, questo sarà utile più tardi per l'installazione dei moduli. Usare un zImage per ridurne la dimensione. Includere qualsiasi cosa occorra, ma provare a usare molti moduli quanto possibile, perchè molte implementazioni di client BOOTP non possono caricare kernel molto grandi (almeno su architetture intel x86). Includere anche il supporto alla ramdisk, supporto al protocollo NFS, filesystem di root su supporto NFS, supporto per la propria NIC, livello di autoconfigurazione IP via BOOTP del kernel; non usare moduli per questo! Poi, se si pianifica di usare lo stesso filesystem remoto di root per diversi client, aggiungere il supporto per ext2fs o altro filesystem e ramdisks (16 Megabytes di ramdisk sarà buono sulla maggior parte dei sistemi). E' possibile poi modificare gli argomenti del kernel come solito (vedere il BootPrompt-HOWTO per informazioni su questo argomento), ma si avrà un'altra opportunità di modificare gli argomenti del kernel più tardi. Dopo, se si ha intenzione di usare BOOTP, copiare la zImage del kernel sul server. Si assumerà che risieda in /tftpboot, il suo nome è zImage, il nome dell'immagine che si vuol creare da questa zImage per l'operazione di BOOTP è kernel, e il filesystem nfs di root risiederà in /nfsroot. Immettete i seguenti comandi sul server (il pacchetto mknbi dovrebbe essere installato): # cd /tftpboot # chmod 0555 zImage # chown root:root zImage # mknbi-linux zImage --output=kernel --rootdir=/nfsroot Se si stà usando LanWork EPROM, immettere anche i seguenti comandi (occorre l'utilità imggen): # mv -f kernel tmpkernel # imggen -a tmpkernel kernel # rm -f tmpkernel Il proprio kernel è pronto per l'operazione BOOTP/DHCP/ROM. Certamente non occorre far questo se si ha intenzione di usare un drive locale. E' possibile usare un ramdisk per il filesystem di root. In questo caso, il comando usato per modificare l'imagine binaria del kernel è leggermente differente. Se si sceglie di fare così, si deve abilitare il supporto per l'iniziale ramdisk (initrd), e probabilmente non occorrerà il supporto a NFS, o probabilmente si può compilare come modulo. E' il momento di dare uno sguardo a cosa accade quando si usa initrd. La piena documentazione per questo è nel proprio albero dei sorgenti del kernel, nel file Documentation/initrd.txt. Devo avvisare che non l'ho mai provato :). Quando initrd è abilitato, il bootloader prima carica il kernel e l'iniziale ramdisk in memoria. Poi, il ramdisk viene montato read-write come filesystemm di root. Il kernel cerca un file /linuxrc (un eseguibile binario o uno script che inizia con #!). Quando /linuxrc termina, il filesystem tradizionale di root viene montato come /, e viene eseguita l'usuale sequenza di boot. Così, se si vuole che la propria box esegua interamente dal ramdisk, occorre solo creare un link da /linuxrc a /sbin/init, o scrivere la uno script di shell per eseguire qualsiasi azione si voglia, e poi chiudere il computer. Dopo che il kernel è stato compilato, occorre costruire un filesystem di root per la propria installazione. Questo è spiegato nella sezione "&clientsrootbuilding;". Si assumerà qui che questo sia già stato fatto e che il filesystem di root per i propri client temporaneamente risieda in /tmp/rootfs. Occorre adesso creare un'immagine di ramdisk. un modo semplice per fare ciò è il seguente: Assicurarsi che il computer su cui si stà lavorando abbia il supporto per il ramdisk e abbia un dispositivo (/dev/ram0). Creare un filesystem vuoto con l'appropriata dimensione su questo ramdisk: # mke2fs -m0 /dev/ram0 300 Montarlo da qualche parte: # mount -t ext2 /dev/ram0 /mnt Copiare cosa occorre per il proprio filesystem di root, e creare il proprio futuro /linuxrc se non lo si vuol creare in /tmp/rootfs/linuxrc: # cp -a /tmp/rootfs/* /mnt Smontare il ramdisk: # umount /mnt Savare l'immagine del ramdisk su un file e liberarlo: # dd if=/dev/ram0 of=initrd bs=1024 count=300 # freeramdisk /dev/ram0 Quello che è stato detto sopra circa LanWork PROM rimane vero anche se si usa initrd. Dopo, occorre modificare l'immagine del kernel, come detto sopra, con l'utilità mknbi-linux. La sua invocazione differirà leggermente da sopra, sebbene (si assumerà che la propria immagine compilata risieda in /tftpboot/zImage e la propria imagine iniziale di ramdisk risieda in /tmp/initrd): # cd /tftpboot # chmod 0555 zImage # chown root:root zImage # rdev zImage /dev/ram0 # mknbi-linux zImage --output=kernel --rootdir=/dev/ram0 /tmp/initrd Esportare la directory in cui il filesystem di root del client risiederà (vedere la pagina man di exports per maggiori informazioni circa questo argomento). Più semplice è esportarla no_root_squash e rw, ma una perfetta impostazione dovrebbe esportare la maggior parte del filesystem di root root_squash e ro, e avere righe separate in /etc/exports per le directory che realmente richiedono no_root_squash e/o rw. Avviare tutto rw e no_root_squash, la sistemazione sarà fatta più tardi. Certamente, non occorerà nessun server NFS se si pianificherà di eseguire i propri client interamente dalla ramdisk. Si assume che si abbia installato il pacchetto bootpd. Il file di configurazione di default è /etc/bootptab, e la sua sintassi è dettagliata nella pagina man di bootptab. Creiamolo. Primo, aprire come root il proprio preferito editor di testi. E' vim. Si, è lui. Se no, deve diventarlo. Adesso, immettere le seguenti righe (esse sono gli attributi di default). Tutti gli attributi che si danno qui e non sovrascrivono la lista degli attributi di una macchina, saranno passati ai client): .default\ :sm=your subnet mask\ :ds=the IP address of your DNS server\ :ht=ethernet\ :dn=your domain name\ :gw=the IP address of your gateway\ :sa=the IP address of the TFTP server\ :bf=path to find the kernel image\ :rp=path of the root filesystem\ :hn Certamente, non tutti questi parametri sono richiesti, questo dipende dalla propria configurazione di rete e dall'implementazione del BOOTP, ma questi funzioneranno nella maggior parte dei casi. Poi, aggiungere un'entrata per client nella propria rete. Un'entrata dovrebbe essere tipo questa: dns of the client\ :ha=MAC address of the client\ :ip=IP address of the client L'indirizzo MAC sopra è l'indirizzo hardware esadecimale del client senza i caratteri ':'. Ecco un esempio di file /etc/bootptab: .default\ :sm=255.255.0.0\ :ds=192.168.0.2\ :ht=ethernet\ :dn=frtest.org\ :gw=192.168.0.1\ :sa=192.168.0.2\ :bf=/tftpboot/kernel\ :rp=/nfsroot\ :hn foo\ :ha=001122334455\ :ip=192.168.2.12 bar\ :ha=00FFEEDDCCBB\ :ip=192.168.12.42\ :ds=192.168.2.42 Dopo, eseguire il demone bootpd con il comando bootpd -s (è anche una buona idea aggiungerlo ai propri script di avvio), o aggiungere la seguente linea al proprio /etc/inetd.conf: bootps dgram udp wait root /usr/sbin/tcpd bootpd -i -t 120 Se si vuole testare il server BOOTP, aggiungere un'entrata al proprio /etc/bootptab e usare il programma bootptest. L'impostazione del demone TFTP non è la parte difficile: installare solo il pacchetto tftpd se ne abbiamo uno, e aggiungere la seguente riga al proprio /etc/inetd.conf (ancora, si assume che /tftpboot sia la directory dove risiede l'immagine del kernel): tftp dgram udp wait root /usr/sbin/tcpd in.tftpd /tftpboot Non dimenticare di eseguire chmod 555 alla directory /tftpboot , come la maggior parte dei server TFTP non invieranno i file se non sono leggibili da chiunque. Si dovrebbe fare attenzione alle limitazioni implicate nell'esecuzione del demone TFTP da l'inetd. La maggior parte degli inetd termineranno un servizio se questo si riavvia troppo frequentemente. Così se si hanno molti client, si dovrebbe cercare un'altro inetd tipo xinetd, o eseguire il demone TFTP in modo standalone. Adesso che si sono impostati propriamente tutti i demoni, si può riavviare inetd e prendere un caffè. Non dimenticate di dire a tutti che l'impostazione del server è conclusa, così da credersi un eroe prima di iniziare la costruzione del filesystem di root dei client. Stanchi? No non credo. Ricordarsi di essere un eroe. Ecco la parte difficile. Si costruirà il filesystem root dei client. Questo non dovrebbe essere molto duro, ma probabilmente si dovranno fare prove ed errori. Il modo più semplice per creare un filesystem di root è di utilizzare un filesystem già funzionante e personalizzarlo per le necessità dell'operazione senza disco. Certamente, si può anche costruirne uno a mano (come ai vecchi tempi) se si desidera:=), ma non si spiegherà questo qui. Prima entrare con cd nella directory root della futura stazione. Si può con sicurezza creare la futura directory /home con il comando mkdir, o copiarla da qualsiai parte si voglia (si può usare cp -a per eseguire una copia ricorsiva preservando owner, group, symlinks, e permessi). Stessa cosa per il futuro /mnt, /root, /tmp (non dimenticare di eseguire chmod 0 su essa, questo è solo un punto di montaggio dell'effettivo /tmp che si userà, perchè ad ogni workstation occorrerà avere il proprio /tmp). Poi, copiare l'esistente /bin, /sbin, /boot, e /usr dentro questa futura directory root (usare cp -a). Si può creare la directory /proc con mkdir, e eseguire chmod 0 su essa. Notare che ad alcune applicazioni occorre l'accesso di scrittura alla directory home del loro utente. La directory /lib può essere copiata con sicurezza da qualsiasi parte, ma vi si dovranno inserire gli appropriati moduli. Per fare ciò, usare i seguenti comandi (assumendo che si abbia compilato il kernel per i propri client sul server dentro /usr/src/linux, e che il filesystem di root risieda in /nfsroot): # cd /usr/src/linux # make modules_install INSTALL_MOD_PATH=/nfsroot Non dimenticare di inserire il file System.map dentro /nfsroot/boot. Un primo problema che si deve correggere è che, secondo la propria configurazione, il proprio sistema può provare a eseguire fsck sul filesystem di root all'avvio. Non dovrebbe se non c'è un hard disk nella box. La maggior parte delle distribuzioni salteranno questo fsck se viene trovato un file fastboot nella directory di root. Così, inserire i seguenti comandi se non si vuol pianificare di montare nessun hard disk: # cd /nfsroot # touch fastboot # chmod 0 fastboot Un'altro metodo è dire a fsck che il controllo di un filesystem NFS abbia sempre successo: # cd /nfsroot/sbin # ln -s ../bin/true fsck.nfs La directory /dev può anche essere copiata con sicurezza da un'altro posto dentro /nfsroot. Ma occorre preservare i permessi e i symlinks, così usare cp -a. Un'altra soluzione è di usare la caratteristica devfs del kernel 2.2.x, la quale ridurrà il consumo di memoria e incrementerà la performance, ma lo svantaggio di questo metodo è che tutti i symlinks creati in /dev saranno persi. Il punto da ricordare è che ogni workstation ha bisogno di avere il proprio /dev, così si dovrà copiarla su un ramdisk se si ha intenzione di usare diversi client e non usare devfs. Si userà ramdisk per queste directory, perchè ogni client ha bisogno di avere le proprie. Ma si ha ancora bisogno di loro all'inizio per creare la loro struttura standard. Notare che non è richiesto di fare ciò se si usa un client singolo. Così copiare queste directory (cp -a) da un'altro posto in /nfsroot. Dopo si possono fare alcune pulizie dentro /var: si può rimuovere qualsiasi cosa in /nfsroot/var/log e /nfsroot/var/run. Probabilmente si può rimuovere qualsiasi cosa in /nfsroot/var/spool/mail, se si ha intenzione di esportarlo via NFS. Si dovrà rimuovere anche i file contenenti informazioni specifiche dell'host in /nfsroot/etc per costruirle al volo durante il processo di avvio. Gli script di avvio dovranno essere personalizzati in modo da montare alcune parti del filesystem: la directory /dev, se non si usa devfs, le directory /tmp, /var, e /etc. Ecco del codice che realizzerà questo: # questa parte solo se non si usa devfs mke2fs -q -i 1024 /dev/ram0 16384 mount -n -t ext2 -o rw,suid,dev,exec, \ async,nocheck /dev/ram0 /dev # questa parte per tutti mke2fs -q -i 1024 /dev/ram1 16384 mount -n -t ext2 -o rw,suid,dev,exec, \ async,nocheck /dev/ram1 /tmp chmod 1777 /tmp cp -a /etc /tmp mke2fs -q -i 1024 /dev/ram2 16384 mount -n -t ext2 -o rw,suid,dev,exec, \ async,nocheck /dev/ram2 /etc find /tmp/etc -maxdepth 1 -exec cp -a '{}' /etc ';' mount -f -t ext2 -o rw,suid,dev,exec, \ async,nocheck,remount /dev/ram2 /etc mount -f -o remount / cp -a /var /tmp mke2fs -q -i 1024 /dev/ram3 16384 mount -t ext2 -o rw,suid,dev,exec, \ async,nocheck /dev/ram3 /var find /tmp/var -maxdepth 1 -exec cp -a '{}' /var ';' Se si ha intenzione di usare più di un singolo client, si dovrà anche modificare dei file dinamicamente all'avvio in /etc: i file che contengono l'IP e l'hostname del client. Questi file dipendono dalla propria distribuzione, ma si troveranno facilmente con pochi grep. Rimuovere da loro solo le informazioni specifiche del client, e aggiungere il codice dentro i file di avvio per rigenerare queste informazioni di nuovo all'avvio ma solo una volta che la nuova /etc è stata montata sul ramdisk! Un modo per ottenere il proprio indirizzo IP e hostname all'avvio è il seguente (se si ha il pacchetto bootpc installato sul filesystem della workstation): IPADDR="$(bootpc | awk '/IPADDR/ \ { match($0,"[A-Za-z]+") s=substr($0,RSTART+RLENGTH) match(s,"[0-9.]+") print substr(s,RSTART,RLENGTH) } ')" HOST="$(bootpc | awk '/HOSTNAME/ \ { match($0,"[A-Za-z]+") s=substr($0,RSTART+RLENGTH) match(s,"[A-Za-z0-9-]+") print substr(s,RSTART,RLENGTH) }')" DOMAIN="$(bootpc | awk '/DOMAIN/ \ { match($0,"[A-Za-z]+") s=substr($0,RSTART+RLENGTH) match(s,"[A-Za-z0-9-.]+") print substr(s,RSTART,RLENGTH) }')" Questa è una soluzione complicata, ma suppongo dovrebbe funzionare nella maggior parte dei casi. L'indirizzo IP può alternativamente essere ottenuto con l'output di ifconfig e l'hostname può essere ottenuto dall'output del comando host, ma non è portabile, perchè questi output differiscono da sistema a sistema secondo la distribuzione che si usa, e le impostazioni locali. Dopo, l'hostname dovrebbe essere impostato con il comando hostname $HOSTNAME. Quando questo è fatto, è tempo di generare al volo i file di configurazione che contengono l'indirizzo IP o l'hostname del client. Adesso, è tempo di fare la sistemazione del client. Siccome /var sarà montata su ramdisk (a meno che non si abbia un singolo client), si dovranno inviare i log ad un log server se si vuole tenerli. Un modo per fare questo è di cancellare il file /nfsroot/etc/syslog.conf e sostituirlo dal seguente file (vedere man syslog.conf per dettagli): *.* /dev/tty12 *.* @dns o l'IP ler server log Se si fa ciò, il server log dovrà eseguire syslogd con l'opzione -r (vedere la pagina di manuale di syslogd). Se si usa logrotate e si è fatto la precedente operazione, si dovrebbe sostituire il file di configurazione logrotate (/etc/logrotate.conf nella maggior parte delle box) con un file vuoto: # rm -f /etc/logrotate.conf # touch /etc/logrotate.conf Se non lo si usa, rimuovere soltanto gli script di log-rotation dalla crontab, e siccome non si avranno più file log dentro /var/log, inserire un exit 0 all'inizio dello script di log-rotation. Nel file /nfsroot/etc/fstab, rimuovere qualsiasi cosa relativa all'hard disk, lettore floppy disk, o cdrom se non si hanno tali dispositivi sulla propria workstation. Aggiungere un'entrata per la directory /var/spool/mail, la quale dovrebbe essere esportata dal server attraverso NFS o altro filesystem di rete. Probabilmente si vorrà inserire in questo file anche un'entrata per la directory /home. Si può anche commentare le righe che eseguono newaliase, attivano swap, e eseguono depmod -a e rimuovere il file /nfsroot/etc/mtab. Commentare le righe rimuovendo /fastboot, /fsckoptions, e /forcefsck nei propri script di avvio. Rimuovere anche o commentare ogni riga negli script di avvio che potrebbe provare a scrivere sul filesystem di root ad eccezione di cose veramente necessarie, le quali dovrebbero essere ridirette in qualche locazione sul ramdisk se si usano diversi client. E' il tempo di una piccola prova. FARE UN BACKUP DI QUELLO CHE SI E' APPENA CREATO /nfsroot. tar -cvvSe fa al caso. Prendersi qualche minuto per verificare se si è dimenticato nulla. Provare ad avviare un client. Guardare attentamente al monitor del client durante il processo di avvio. Oh, non ho detto di connettere uno schermo... Run, forest! Prenderne uno. Probabilmente si vedranno alcuni messaggi d'errore. Correggere i problemi, e fare frequenti salvataggi del proprio /nfsroot. Un giorno, il client si avvierà propriamente. In questo giorno, si dovranno correggere gli errori che capitano durante lo shutdown;=P. Si è parlato finora circa la configurazione dei client e server per le operazioni dopo che la richiesta BOOTP è stata inviata dal client, ma il primo problema è che la maggior parte dei computer non sono in grado di agire come client BOOTP di default. Si vedrà in questa sezione come correggere questo. Questo è il caso più semplice: alcune schede di rete forniscono un supplemento al BIOS, contenendo un client BOOTP o DHCP, così basta solo impostarle per l'operazione di BOOTP o DHCP nel BIOS, ed è fatta. Anche questi casi sono pittosto semplici: il kernel viene caricato da un drive locale, e tutto quello che il kernel deve fare è ottenere i suoi parametri di rete dal BOOTP, e montare il filesystem di root su NFS; questo non dovrebbe causare nessun problema. A proposito, un hard disk locale è un buon posto per lasciare una /var, /tmp, e una /dev... Se si ha un hard disk locale, tutto quello che si deve fare è usare lilo o il proprio bootloader preferito come di solito. Se si usa un floppy, si può usare un bootloader o semplicemente scrivere il kernel sul floppy: un kernel è avviabile direttamente. Questo abilita a usare un comando tipo il seguente: # dd if=zImage of=/dev/fd0 bs=8192 Comunque, Alan Cox ha detto in una discussione sul linux-kernel che questa caratteristica del kernel linux sarà prima o poi rimossa, allora un giorno si dovrà usare un bootloader anche sui floppy. Questo è ancora funzionante con kernel 2.4.11, ma il supporto sembra essere stato rimosso nella versione 2.4.13. Vedere il sesto capitolo del boot-disk-HOWTO per questo argomento. Certi bootloader sono consapevoli della rete, è perciò possibile usarli per scaricare l'immagine del kernel dalla rete. Alcuni di loro sono elencati sotto: &ntb;, un bootloader dedicato all'avvio da rete. &grub;, il progetto GNU GRand Unified Bootloader, il quale è veramente un bootloader di uso generale. Molte schede di rete includono uno slot in cui uno può inserire una EPROM con codice aggiuntivo BIOS. Questo abilita ad aggiungere, per esempio, capacità BOOTP al BI0S. Per fare ciò, si dovrà prima trovare come abilitare il socket EPROM. Per fare ciò può occorrere un jumper o un software speciale. Alcune schede tipo la 3Com 905B hanno slot per EEPROM i quali abilitano a modificare il software sulla EEPROM sul posto. In appendice, si troveranno le informazioni circa le EPROM e i vari tipi di chip di memoria. Per una lista di costruttori di scrittori di EPROM visitare il sito Yahoo e andare a economy->company->Hardware->Peripherals->Device programmers o controllare il vecchio Diskless-HOWTO la sezione List of EPROM burner manufacturers. Se si sceglie di creare la propria ROMS, si dovrà caricare un software capace del BOOTP o DHCP nella ROM, e poi, si sarà nel caso di NIC capaci del BOOTP o DHCP descritto sopra. Occorrerà cercare anche la propria dimensione e velocità della EPROM per la propria NIC. Alcuni metodi per fare ciò sono forniti in appendice, perchè i costruttori di NIC spesso non forniscono queste informazioni. Queste informazioni possono far risparmiare tempo. In modo da far avviare LanWork BootWare(tm) PROM corretamente un'immagine del kernel linux, il "bootsector" parte dell'imagine deve essere modificata per abilitare il boot prom per saltare correttamente nell'indirizzo di avvio dell'immagine. Il formato dell'immagine avviabile da rete creata dal tool &ntb;/&etb;'s `mknbi-linux' è diversa e non funzionerà se usata con BootWare PROM. Un bootsector modificato insieme ad un Makefile per creare un'immagine BootWare-avviabile dopo la compilazione del kernel può essere trovata a: Bwimage package: ftp://ftp.ipp.mpg.de/pub/ipp/wls/linux/bwimage-0.1.tgz Vedere anche http://www.patoche.org/LTT/net/00000096.html LanWorks BootWare Boot ROMs: http://www.3com.com/lanworks Fare riferimento al file README per i dettagli dell'installazione. Correntemente, sono supportati kernel tipo "zImage". Sfortunatamente, i parametri del kernel sono ignorati. Questa sezione è stata scritta inizialmente da Jochen Kmietsch per il Diskless-HOWTO, scrivere a: jochen.kmietsch@tu-clausthal.de per qualsiasi domanda. Questa sezione fu originariamente scritta da Hans de Goede j.w.r.degoede@et.tudelft.nl per il Diskless-root-NFS-HOWTO. L'ho modificata leggermente in modo da riflettere alcune differenze tra questo documento e il Diskless-root-NFS-HOWTO. Molto di quello detto sopra va bene anche per l'avvio da cdrom. Perchè uno dovrebbe voler avviare una macchina da cdrom? L'avvio da cdrom è interesante ovunque si voglia eseguire un'applicazione molto specifica, tipo un chiosco, un programma library database o un internet cafe, e chi non abbia una rete o un server per usare una root impostata su nfs. Adesso che si sà cosa si vuol fare e come, è tempo di creare un'impostazione di test: Per iniziare prendere una delle macchine che si vuol usare e inserirci un disco grande e un masterizzatore cd. Installare il proprio linux scelto su questa macchina, e lasciare una partizione di 650 MB libera per l'impostazione di test. Questa installazione sarà usata per fare l'immagine iso e per masterizzare il cd, così installare i tool necessari. Essa sarà usata anche per restorare qualsiasi errore che renderà l'impostazione di test inavviabile. Sulla partizione di 650 mb installare il proprio linux scelto con le impostazioni che si vogliono avere, questa sarà l'impostazione di test. Avviare l'impostazione di test. Compilare un kernel con il supporto a isofs e cdrom inclusi. Configurare l'impostazione di test come descritto sopra con il filesystem di root montato in sola lettura. Verificare che l'impostazione di test automagicamente si avvii e tutto funzioni. Avviare l'installazione principale e montare la partizione di 650 MB su /test dell'installazione principale. Inserire i seguenti righe in un file chiamato /test/etc/rc.d/rc.iso, questo file avrà origine all'inizio di rc.sysinit per creare /var: #/var echo Creating /var ... mke2fs -q -i 1024 /dev/ram1 16384 mount /dev/ram1 /var -o defaults,rw cp -a /lib/var / Editare /test/etc/rc.sysinit, commentare le righe dove la root è ri-montata rw, e aggiungere le seguenti 2 righe direttamente dopo l'impostazione del PATH: #to boot from cdrom . /etc/rc.d/rc.iso Copiare il seguente in uno script e eseguirlo per fare un modello per /var e creare i link a /tmp e /etc/mtab. #!/bin/sh echo tmp rm -fR /test/tmp ln -s var/tmp /test/tmp ### echo mtab touch /test/proc/mounts rm /test/etc/mtab ln -s /proc/mounts /test/etc/mtab ### echo var mv /test/var/lib /test/lib/var-lib mv /test/var /test/lib mkdir /test/var ln -s /lib/var-lib /test/lib/var/lib rm -fR /test/lib/var/catman rm -fR /test/lib/var/log/httpd rm -f /test/lib/var/log/samba/* for i in `find /test/lib/var/log -type f`; do cat /dev/null > $i; done rm `find /test/lib/var/lock -type f` rm `find /test/lib/var/run -type f` Rimuovere la creazione di /etc/issue* da /test/etc/rc.local: fallirà solamente. Ora avviare di nuovo la partizione di test, sarà di sola lettura proprio come un cdrom. Se qualcosa non funzionasse riavviate la partizione di lavoro, corregetela, provare di nuovo etc. O si potrebbe ri-montare / rw, correggerla, poi riavviare di nuovo direttamente nella partizione di test. Per ri-montare / rw digitare: # mount -o remount,rw / Se occorrono maggiori informazioni di quelle che possono essere trovare di sotto, prego fare riferimento al CD-Writing-HOWTO. Prima di tutto, avviare nella partizione di lavoro. Per creare un cd avviabile occorrerà un'immagine di un floppy avviabile. Il solo uso di dd di una zImage non funziona dal momento che il loader all'inizio della zimage non assomiglia al fasullo floppydrive che un cd avviabile crea. Così al suo posto useremo syslinux. Prendere boot.img da un cd di redhat. Montare boot.img dove si vuole attraverso la loopback digitando: # mount boot.img qualsiasiposto -o loop -t vfat Rimuovere tutto da boot.img eccetto ldlinux.sys e syslinux.cfg. Copiare l'imagine del kernel dalla partizione di test nel boot.img. Editare syslinux.cfg in modo tale che contenga il seguente, certamente sostituire zImage con l'appropriato nome dell'imagine: default linux label linux kernel zImage append root=/dev/<inserire qui il proprio dispositivo cdrom> Smontare boot.img: # umount qualsiasiposto Se il proprio /etc/mtab è un link a /proc/mounts, umount non libererà automagicamente /dev/loop0 così liberarlo digitando: # losetup -d /dev/loop0 Adesso che abbiamo 'imagine di boot e un install che può avviare da un montaggio in sola lettura è tempo di creare un'imagine iso del cd: Copiare boot.img in /test Eseguire cd alla directory dove si vuole memorizzare l'imagine e assicurarsi che sia una partizione con sufficente spazio libero. Adesso generare l'imagine digitando: # mkisofs -R -b boot.img -c boot.catalog -o boot.iso /test Montaggio dell'imagine attraverso il dispositivo di loopback digitando: # mount boot.iso qualcheposto -o loop -t iso9660 Smontaggio boot.iso: # umount qualcheposto Se il porprio /etc/mtab è un link a /proc/mounts umount non libererà automagicamente /dev/loop0 così liberarlo digitando: # losetup -d /dev/loop0 Assumendo di avere cdrecord installato e configurato per il proprio cd-writer digitare: # cdrecord -v speed=<velocità di scrittura desiderata> dev=<path al dispositivo generico di scrittura scsi> boot.iso Bene, il titolo di questo paragrafo la dice tutta;) Dal momento che MS-Windows on supporta l'avvio senza disco, viene presentato un semplice trucco: la soluzione è di usare software tipo &vmware; o la sua alternativa gratuita, &plex86;. Sebbene &plex86; sembri essere stato abbandonato, è possibile ancora avviare certe versioni di MS-Windows usando questo software. Questo abilita MS-Windows a essere eseguito in modo trasparente su una box linux. Le precedenti sezioni hanno discusso un semplice modo per gestire specifici file e directory delle workstation tipo /var. La maggior parte di essi sono semplicemente costruiti al volo e inseriti nella ramdisks, si può comunque preferire occuparsi di questo problema sul server NFS. Il progetto &clusternfs; fornisce un server filesystem di rete che può servire diversi file basandosi su diversi criteri incluso l'indirizzo IP del client o il nome host. L'idea di base è che se il client il cui indirizzo IP è 10.2.12.42 richiede un file chiamato, per esempio, myfile, il server cercherà un file chiamato myfile$$IP=10.2.12.42$$ e servirà questo file invece di myfile se questo è disponibile. Un modo semplice per ridurre il consumo di memoria è di inserire diverse directory create dinamicamente sullo stesso ramdisk. Per esempio, diciamo che il primo ramdisk conterrà la directory /tmp. Poi, si può spostare la directory /var/tmp su quel ramdisk con i seguenti comandi digitati sul server: # mkdir /nfsroot/tmp/var # chmod 0 /nfsroot/tmp/var # ln -s /tmp/var /nfsroot/var/tmp Un'altro buon metodo per ridurre il consumo di memoria se non si hanno locali hard disk e non si esegue swap su dispositivo a blocchi di rete è di disabilitare l'opzione Swapping su dispositivi a blocchis durante la compilazione del kernel. Se le proprie stazioni non hanno sufficente memoria e non hano hanno dischi locali, si può voler eseguire swap su NFS. Si deve essere avvisati che il codice per fare questo è ancora in sviluppo e che questo metodo è generalmente molto lento. Piena documentazione per questo può essere trovata a http://www.instmath.rwth-aachen.de/~heine/nfs-swap/. La prima cosa da fare se si vuole eseguire questa soluzione è di applicare una patch al proprio kernel (occorre una versione del kernel 2.2 o successiva). Prima scaricare la patch all'url di sopra, e fare cd in /usr/src/linux. Si assume che la patch sia in /usr/src/patch. Poi immettere il seguente comando: # cat ../patch | patch -p1 -l -s Dopo, compilare il proprio kernel normalmente e abilitare le opzioni Swapping via network sockets (EXPERIMENTAL) e Swapping via NFS (EXPERIMENTAL). Poi esportare una directory read-write e no_root_squash dal server NFS. Impostare i client così che la monterano in qualche posto (diciamo in /mnt/swap). Essa dovrebbe essere montata con un rsize e wsize più piccolo della dimensione della pagina usata dal kernel (es. 4 kilobyte su architetture Intel), altrimenti la propria macchina può andare fuori memoria a causa della frammentazione della memoria; vedere la pagina di manuale di nfs per dettagli circa rsize e wsize. Ora, per creare un file di swap di 20 MB, imettere i seguenti comandi (i quali dovrebbero essere posti negli script di inizializzazione dei client): # dd if=/dev/zero of=/mnt/swap/swapfile bs=1k count=20480 # mkswap /mnt/swap/swapfile # swapon /mnt/swap/swapfile Di certo, questo è solo per esempio, percè se si hanno diverse workstation, si dovrà cambiare il nome del file o della directory di swap, o tute le proprie workstation utilizzerano lo stesso file di swap per i propri swap... Diciamo una parola circa gli svantaggi dello swapping su NFS: il primo svantaggio è che è generalmente lento, eccetto di avere schede di rete particolamente veloci. Poi, questa possibilitànon è stata ancora testata molto bene. Per ultimo, questo non è del tutto sicuro: tutti in rete possono leggere i dati swappati. Sebbene non lo abbia mai provato personalmente, ho il rapporto che il metodo descritto di seguito funziona, almeno con recenti kernel. Il principio generale per lo swapping su dispositivi a blocchi di rete è lo stesso dello swap su NFS. Il punto buono è che non si deve applicare patch al kernel. Ma la maggior parte degli stessi svantaggi si applicano anche al metodo NBD. Per creare un file di swap di 20 MB, si deve per prima crearlo sul server, esportarlo sul client, e fare un mkswap sul file. Notare che il comando mkswap deve essere fatto sul server, perchè mkswap usa delle system-call che non sono gestite dal NBD. Inoltre, questo comando deve essere immesso dopo che il server ha iniziato l'esportazione del file, perchè i dati sul file possono essere distrutti quando il server inizia la sua esportazione. Se si assume che il nome del server sia NBDserver, il nome del client sia NBDclient, e la porta TCP usata per l'esportazione sia 1024, i comandi da digitare sul server sono i seguenti: # dd if=/dev/zero of=/swap/swapfile bs=1k count=20480 # nbd-server NBDclient 1024 /swap/swapfile # mkswap /swap/swapfile Ora, il client dovrebbe usare il seguente comando: # swapon /dev/nd0 Ancora, questo era solo per mostrare il principio generale. I nomi dei file dovrebbero anche essere dipendenti dai nomi delle workstation o dagli IP. Un'altra soluzione per fare swap su un dispositivo a blocchi di rete è di creare un filesystem ext2 sul NBD, poi creare un file regolare su questo filesystem, e per ultimo, usare mkswap e swapon per iniziare a fare swapping su di esso. Questo secondo metodo è più vicino al metodo dello swap su NFS che la la prima soluzione. I seguenti comandi, digitati sul server possono risolvere il problema: # ln -s /proc/mounts /nfsroot/etc/mtab # touch /nfsroot/proc/mounts Un modo semplice per fare ciò è di usare, sul server, un chroot e dopo eseguire i propri comandi preferiti di installazione normalmente. Per eseguire chroot nell'appropriato posto, usare il seguente comando: # chroot /nfsroot Gli utenti Debian saranno particolarmente intreressati nell'opzione --root di dpkg, la quale semplicemente dice a dpkg dove è la root del sistema prescelto. Ecco delle descrizioni sommarie di chip di memoria e loro tipi: PROM: Pronounciato prom, un acronimo per memoria programmabile di sola lettura. Una PROM è un chip di memoria sul quale i dati possono essere scritti una sola volta. Una volta che un programma è stato scritto in una PROM, rimane la per sempre. Diversamente dalla RAM, le PROM mantengono i loro contenuti quando il computer è spento. La differenza tra una PROM e una ROM (memoria a sola lettura) è che una PROM è fabbricata come una memoria blank, mentre una ROM è programmata durante il processo di fabbricazione. Per scrivere i dati in un chip PROM, occorre uno speciale dispositivo chiamato programmatore di PROM o masterizzatore PROM. Il processo di programmazione di una PROM è a volte chiamato masterizzare la PROM. Una EPROM (cancellabile programmabile memoria a sola lettura) è un tipo speciale di PROM che può essere cancellata attraverso la sua esposizione alla luce ultravioletta. Una volta che è cancellata, essa può essere riprogrammata. Una EEPROM è simile ad una PROM, ma richiede solo l'elettricità per essere cancellata. EPROM: Acronimo per memoria cancellabile programmabile sola lettura, e prounciata e-prom, EPROM è uno speciale tipo di memoria che ritiene i suoi contenuti fino a che viene esposta alla luce ultravioletta. La luce ultravioletta pulisce i suoi contenuti, rendendo possibile riprogrammare la memoria. Per scrivere e cancellare una EPROM, occorre uno speciale dispositivo chiamato programmatore di PROM o masterizzatore PROM. Una EPROM differisce da una PROM dal fatto che una PROM può essere scritta solo una volta e non può essere cancellata. Le EPROM sono usate largamente nei personal computer perchè esse fanno si che il produttore possa modificare il contenuto della PROM prima che il computer sia effettivamente consegnato. Questo significa che i bug possono essere rimossi e le nuove versioni installate in breve prima della consegna. Una nota sulla tecnologia EPROM: I bit di una EPROM sono programmati iniettando elettroni con un elevato voltaggio nel floating gate di un transistor field-effect dove si vuole un bit a 0. Gli elettroni intrappolati la, causano la conduttività del transistor, leggendolo come 0. Per concellare la EPROM, agli elettroni intrappolati viene data sufficente energia per uscira dal floating gate bombardando il chip con radiazioni ultraviolette attraverso la finestra al quarzo. Per prevenire la lenta cancellazione per l' esposizione per periodi di anni alla luce del sole e alla luce fluorescente, questa finestra al quarzo nel normale uso viene coperta con un'etichetta opaca. EEPROM: Acronimo per memoria electricamente cancellabile programmabile di sola lettura. Pronunciata double-e-prom o e-e-prom, una EEPROM è uno speciale tipo di PROM che può essere cancellata esponendola a una carica elettrica. Come gli altri tipi di PROM, la EEPROM ritiene i suoi contenuti anche quando l'alimentazione è spenta. Come anche altri tipi di ROM, EEPROM non è veloce come la RAM. EEPROM è simile alla memoria flash (a volte chiamata flash EEPROM). La pricipale differenza è che EEPROM richiede che i dati vengano scritti o cancellati un byte per volta quando la flash memory permette che i dati siano scritti o cancellati in blocchi. Questo rende la flash memory più veloce. FRAM: Abbreviazione di memoria ferroelettrica ad acceso casuale, un tipo di memoria non-volatile sviluppata da Ramtron International Corporation. FRAM combina la velocità di accesso della DRAM e SRAM con la non-volatilità della ROM. A causa della sua alta velocità, sostituisce la EEPROM in molto dispositivi. Il termine stesso FRAM è un marchio di Ramtron. NVRAM: Abbreviazione di memoria Non-Volatile a accesso casuale, un tipo di memoria che ritiene i suoi contenuti quando l'alimentazione è spenta. Un tipo di NVRAM è SRAM che è resa non-volatile connettendola a una fonte di alimentazione costante come una batteria. Un'altro tipo di NVRAM usa chip EEPROM per salvare i suoi contenuti quando l'alimentazione è spenta. In questo caso, NVRAM è composta da una combinazione di chip SRAM e EEPROM. Bubble Memory: Un tipo di memoria non-volatile composta da un sottile strato di materiale che può essere facilmente magnetizzato solo in una direzione. Quando un campo magnetico viene applicato all'area circolare di questa sostanza che non è magnetizzata nella stessa direzione, l'area viene ridotta ad un circolo più piccolo, o bolla. Una volta si credeva largamente che le memoria a bolla sarebbero diventate una delle tecnologie leader di memoria, ma queste promesse non sono state rispettate. Altre memorie di tipi non-volatili, come EEPROM, sono sia più veloci che meno costose delle memorie a bolla. Flash Memory: Uno speciale tipo di EEPROM che può essere cancellata e riprogrammata in blocchi invece che un byte alla volta. Molti PC moderni hanno il loro BIOS memorizzato su un chip di memoria flash così che può facilmente essere aggiornato se necessario. Tale BIOS è avvolte chiamato un BIOS flash. una memoria flash è popolare anche nei modem perchè abilita il costruttore del modem a supportare nuovi protocolli appena diventano standardizzati. Questa sezione proviene dal &etb; documentazione di progetto versione 5.0. Fornisce suggerimenti per determinare la dimensione e la velocità delle EPROM da usare con una particolare NIC La più piccola EPROM che è accettata dalle schede di rete è di 8k EPROM (2764). 16 kB (27128) o 32 kB (27256) sono la norma. Alcune schede arriveranno fino a 64 kB EPROM (27512). (Spesso si vedrà un C dopo il 27, es. 27C256. Questo indica un CMOS EPROM, il quale è equivalente alla versione non-C e è una buona cosa perchè ha un consumo energetico più basso.) Si voglia usare la più piccola EPROM possibile così da non occupare più dell'area di memoria superiore perchè può occorrere alle altre estensioni del BIOS che possono aver bisogno dello spazio. Comunque si voglia ottenere anche un buon prezzo per l'EPROM. Attualmente le EPROM 32 kB e 64 kB (27256 e 27512) sembrano essere le più economiche per unità. EPROM più piccole sembrano essere più costose perchè sono fuori dai flussi principali di produzione. Se non si trova nella documentazione quale capacità di EPROM la scheda richiede, solo per le NIC ISA, può essere fatto provando e sbagliando. (le NIC PCI non abilitano la EPROM fino a che il BIOS non lo permette.) Prendere una ROM con dei dati sopra (un generatore di carattere ROM) e inserirlo nel socket. Fare attenzione di non usare un'estenzione BIOS per questo test perchè può rilevare e attivare e prevenire l'avvio del proprio computer. Usando il programma di debug sotto DOS, eseguire il dump di varie regioni dello spazio di memoria. Si scoprirà di poter vedere i dati nella finestra di memoria da CC00:0 a CC00:3FFF (= 4000 hex = 16384 locazioni decimali). Questo indica che occorre una EPROM da 16 kB. Comunque se si vede un alias in parti dello spazio di memoria, significa che la regione da CC00:0 a CC00:1FFF è duplicata da CC00:2000 a CC00:3FFF, allora si deve inserire una EPROM da 8 kB in uno slot da 16 kB e occorre provare una EPROM più grande. Notare che a causa della compatibilità in alto delle EPROM a 28 pin, più o meno, è possibile probabilmente usare una EPROM a capacità più grande in uno slot nato per una più piccola. Le linee con indirizzo più alto probabilmente saranno tenute in alto così che occorrerà programmare l'imagine nella metà di sopra o nel quarto di sopra di una EPROM più grande, secondo le circostanze. Comunque si dovrebbe controllare due volte il voltaggio sui pin abilitati con la documentazione e un tester perchè EPROM CMOS non amano pin variabili. Se la ROM è più grande della dimensione dell'immagine, per esempio, una ROM a 32 kB contenente un'immagine di 16 kB, allora si può mettere l'imagine in una delle metà della ROM. A volte si leggerà il consiglio di mettere due copie dell'immagine nella ROM. Questo funzionerà ma non è raccomandato perchè la ROM sarà attivata due volte se è una ROM legacy e può non funzionare affatto se è una ROM PCI/PnP. E' tollerato da Etherboot perchè il codice controlla se è già stata attivata e la seconda attivazione non farà nulla. Il metodo raccomandato è di riempire la metà non utilizzata con dati a blank. E' raccomandato a tutti i dati perchè è il naturale stato della EPROM e implica meno lavoro per il programmatore di PROM. Ecco un comando Unix che genererà 16384 byte di 0xFF e lo unirà con una ROM di 16 kB in un'imagine di 32 kB per il proprio programmatore di PROM. # (perl -e 'print "\xFF" x 16384'; cat bin32/3c509.lzrom) > 32kbimage La velocità occorsa dalla EPROM dipende da come è connessa al bus del computer. Se la EPROM è direttamente connessa al bus del computer, come nel caso di molti cloni economici NE2000, probabilmente si dovrà prendere un'EPROM che è veloce almeno come le ROM usate per il BIOS principale. Tipicamente 120-150 ns. Alcune schede di rete mediano l'accesso alla EPROM attraverso un sistema di circuiti e questo può inserire stati di attesa così che possano essere usate EPROM più lente. Incidentalmente la lentezza della EPROM non influisce molto sulla velocità dell'esecuzione di Etherboot perchè Etherboot copia se stesso in RAM prima dell'esecuzione. Dico che Netboot fa lo stesso. Se si possiede l'hardware per programmare EPROM, c'è una bella collezione di utilità di conversione del formato file EPROM a http://www.canb.auug.org.au/~millerp/srecord.html. I file prodotti dal processo di costruzione di Etherboot sono binari puri. Un semplice convertitore di binari a formato esadecimale Intel può essere trovato nel sito web di Etherboot a http://etherboot.sourceforge.net/bin2intelhex.c. In alternativa si può usare l'utilità objcopy, inclusa nel pacchetto binutils: # objcopy --input-target binary --output-target ihex binary.file intelhex.file # objcopy --input-target ihex --output-target binary intelhex.file binary.file Etherboot è pensato per fare ROM conformi al PnP per NIC PCI. E' stato rintracciato un bug di vecchia data negli headers. Per cui sono in giro alcuni vecchi BIOS difettosi così ho scritto uno script in Perl swapdevids.pl per modificare l'header dove necessario. Si dovrà sperimentarlo in entrambi i modi per trovare quale funziona. O si potrebbe eseguire un dump di un'immagine ROM che funziona (es. RPL, PXE ROM) usando lo script Perl disrom.pl. I campi da guardare sono Dispositivo (base, sub, interfaccia) Tipo. Dovrebbe essere 02 00 00, ma alcuni BIOS vogliono 00 00 02 dovuto all'ambiguità nella specifica originale. L'originale Diskless-HOWTO menziona i nomi dei seguenti venditori di computer senza disco: Linux Systems Labs Inc., USA http://www.lsl.com. Cliccare su "Shop On-line" e poi cliccare su "HardWare" dove sono elencati tutti i computer senza disco. Phone 1-888-LINUX-88. Diskless Workstations Corporation, USA http://www.disklessworkstations.com. Unique Systems of Holland Inc., Ohio, USA http://www.uniqsys.com

&disklesshowtourl;

&disklessrootnfshowtourl;

&bootdiskhowtourl;

Un insieme di utilità e documentazione per stazioni senza disco, basate sulla distribuzione red hat.

<spurl;

Un progetto iniziale il quale scopo è di fornire un insieme di utilità per stazioni senza disco e server associati, basato dulla distribuzione debian.

&plumeurl;

&logilaburl;

&powerup2bashurl;

&thinclienturl;

&cdwritingurl;

&etburl;

Un software non free di macchina virtuale.

&vmwareurl;

Un software free di macchina virtuale.

&plex86url;