Diskless Nodes HOWTO document for Linux Robert Nemkin buci@math.klte.hu , Al Dev (Alavoor Vasudevan - Curatore di questo HOWTO) alavoor@yahoo.com , Markus Gutschke markus+etherboot@gutschke.com , Ken Yap ken.yap@acm.org , Gero Kuhlmann gero@gkminix.han.de v 12.0, 10 luglio 2000 Questo documento descrive come preparare una macchina Linux diskless (senza dischi). Dato che la tecnologia sta avanzando rapidamente, le schede di rete stanno diventando più economiche e molto più veloci - al momento l'ethernet a 100 MBit è standard e tra circa uno o due anni le schede ethernet a 1000 MBit, ossia 1 GigaBit, diventeranno uno standard industriale. Con le schede di rete ad alta velocità l'accesso remoto diventerà veloce quanto l'accesso al disco locale, il che ren­ derà i nodi diskless una possibile alternativa alle workstation nelle LAN. Inoltre i nodi diskless eliminano i costi di aggiornamento del software e i costi di amministrazione di sistema, tipo backup e recu­ pero, che verranno centralizzati da parte del server. I nodi diskless inoltre permettono la "condivisione/ottimizzazione" delle CPU central­ izzate del server, della memoria, dei dischi rigidi, dei lettori di nastri e dei lettori di CDrom. I nodi diskless permettono la mobilità degli utenti, cioè gli utenti possono effettuare il log on da uno qualsiasi dei nodi diskless e non sono legati ad una workstation. Le macchine Linux diskless eliminano completamente la necessità di avere floppy disk, lettori CDrom, lettori di nastri e dischi rigidi locali. Un nodo diskless ha SOLO una scheda di rete, 8MB RAM, una CPU di fas­ cia bassa ed una semplicissima scheda madre senza slot o altri connet­ tori per dischi rigidi, modem, CDrom, floppy ecc. Con i nodi Linux diskless si possono eseguire programmi su una macchima Linux remota dotata di 64 CPU SMP o anche su di un supercomputer Linux! I nodi diskless abbassano il "costo totale di possesso" del sistema. Questo documento è copyright di Robert Nemkin e degli altri autori preceden­ temente elencati. La politica di copyright è GPL. Grazie a Bela Kis bkis@cartan.math.klte.hu per aver tradotto in inglese la versione iniziale, v 0.0.3, di questo documento (che era un mini-howto). Traduzione in italiano di Fabrizio Stefani, 3 agosto 2000. 1. Comprare è più economico che assemblare! Prima o poi comprare un computer linux diskless diventerà più economico che assemblarlo! Si vedano i seguenti siti commerciali che vendono computer Linux diskless e schede di rete per computer Linux diskless. Queste società producono grosse quantità di computer Linux diskless e vendendone milioni di unità possono ridurne il costo unitario. Tutte le prime 1000 compagnie USA della classifica di Fortune nel prossimo futuro sostituiranno i PC MS Windows con computer Linux diskless poiché questi possono far girare programmi sia Linux che MS Windows 95 (tramite il software BIOS VMWare). VMWare NON è un emulatore ma ha un BIOS che permette di installare Windows 98/NT come SO ospite di Linux. È possibile usare il comando 'xhost' e l'ambiente DISPLAY dal nodo diskless per eseguire i programmi Windows95/Linux. Vedere 'man xhost' su Linux. Per eseguire programmi per Windows95/NT su nodi diskless Linux, è possibile anche usare il Virtual Network Computing (VNC). Lo si può scaricare da . · Linux Systems Labs Inc., USA Si selezioni "Shop On-line" e poi "HardWare" e verranno elencati tutti i computer diskless. Telefono: 1-888-LINUX-88. · Diskless Workstations Corporation, USA · Unique Systems of Holland Inc., Ohio, USA Se siete intenzionati a comprare dei computer Linux diskless, potreste essere molto interessati alla lettura completa di questo documento. 2. Computer diskless con Microsoft Windows 95/NT !! Sebbene Microsoft Windows 95/NT NON supporti nodi diskless esiste una intelligente scappatoia per aggirare l'ostacolo. La Microsoft corporation ne sarà sorpresa!! 2.1. Il pacchetto VMWare Usare il BIOS software VMWare con Linux che può ospitare Windows 95/98/NT. Linux sarà il SO "ospitante" e Windows 95/NT sarà il SO "ospitato". VMWare NON è un emulatore ma ha un BIOS che permette di installare Windows 95/98/NT come SO ospite di Linux. Installare VMWare sul server Linux e poi installare Windows 95/NT in VMWare. È possibile usare il comando 'xhost' e l'ambiente DISPLAY da qualsiasi nodo diskless. Vedere 'man xhost' su Linux. Sul nodo diskless digitare: ______________________________________________________________________ export DISPLAY=server_hostname:0.0 ______________________________________________________________________ dove server_hostname è il nome della macchina server. Lanciare un X- terminal con ______________________________________________________________________ xterm ______________________________________________________________________ Usando VMWare i computer Linux diskless pos­ sono far girare sia programmi Linux che MS Windows 95. Il sito VMWare è su . 2.2. Il pacchetto VNC della AT&T È possibile anche usare la tecnologia VNC (Virtual Network Computing) del gigante delle telecomunicazioni AT&T. VNC è rilasciata sotto GPL ed è software libero. Usando VNC è possibile eseguire programmi per Windows 95/NT su computer diskless Linux, ma che in realtà girano su un server remoto Windows 95/NT. VNC è reperibile presso 3. Vantaggi dei computer diskless I computer Linux diskless diventeranno immensamente popolari e saranno il prodotto di questo e del prossimo secolo. I computer Linux diskless avranno grande successo a causa della disponibilità di schede di rete ad alta velocità a prezzi bassissimi. Oggi le schede di rete a 100 Megabit per secondo (velocità di trasferimento di 12.5 MB per secondo) sono comuni e fra circa uno o due anni le schede di rete a 1000 Mbit (velocità di trasferimento di 125 MB per secondo) diventeranno molto economiche e saranno lo standard. Nel prossimo futuro i costruttori di monitor metteranno CPU, NIC e RAM proprio dentro il monitor realizzando un computer diskless! Così facendo si elimina il case del computer diskless e si risparmia spazio. Il monitor avrà delle uscite per il mouse, la tastiera, una presa RJ45 per la rete e una per l'alimentazione. Di seguito sono elencati i vantaggi dell'uso di computer diskless: · I computer diskless Linux possono eseguire SIA programmi MS Windows 95/NT SIA programmi Linux. · Il costo totale di possesso è molto basso per i computer diskless. Il costo totale di possesso è pari al costo iniziale di acquisto più il costo di manutenzione. Il costo di manutenzione è di solito da 3 a 5 volte il costo iniziale di acquisto del computer e tale costo ricorre di anno in anno. Per i computer diskless il costo di manutenzione viene completamente eliminato!! · Tutti i backup sono centralizzati su un singolo server principale. · I dati sono più sicuri essendo situati sul server. · Per i client diskless non c'è nessun bisogno di batterie UPS, condizionamento d'aria, ambienti privi di polvere; solo il server ne ha bisogno. · Protezione dall'attacco di virus: i virus per computer non possono attaccare i computer diskless poiché essi non hanno nessun disco rigido. I virus non possono fare nessun danno ai computer diskless. Solo una singola macchina server deve essere protetta dall'attacco dei virus; ciò fa risparmiare all'azienda milioni di dollari rendendo inutile l'installazione di vaccini e la pulizia dei dischi rigidi!! · Il server può avere dischi rigidi di grande potenza ed elevate prestazioni, può ottimizzare l'uso dello spazio disco condividendo quello necessario a più utenti di computer diskless. La tolleranza ai guasti del disco rigido è ottenibile usando tecniche RAID sul server principale. · Il server può avere più CPU a 64 bit funzionanti in SMP o anche essere un supercomputer Linux. La potenza delle CPU può essere condivisa da più utenti di computer diskless. · È possibile la condivisione della RAM da parte di più utenti di computer diskless. Per esempio, se diversi utenti stanno usando un web browser, nella RAM del server ci sarà una sola copia del browser. Nel caso di PC Windows 95, diversi utenti devono invece avere ciascuno una copia individuale del browser nella RAM locale e si avrà così uno spreco di memoria RAM. · I computer Linux diskless possono far girare programmi su server multipli usando "xhost" e l'ambiente DISPLAY. · Sono necessari pochissimi amministratori per gestire il server centrale al contrario dei client PC Windows 95 che richiedono parecchi amministratori. · Amministrazione zero da parte dei client diskless. I computer diskless non hanno assolutamente bisogno di manutenzione e non creano nessun problema. · Lunga vita dei client diskless; più di 100 anni senza aggiornamenti di hardware o software. · Eliminazione dell'installazione/aggiornamento di hardware e software da parte dei client diskless. · Eliminazione del costo di cdrom, floppy, lettori di nastri, modem e batterie UPS, porte parallele per le stampanti, porte seriali, ecc. · Possono funzionare in luoghi, tipo i pavimenti delle fabbriche, in cui i dischi rigidi potrebbero risultare troppo fragili. 4. Linux Terminal Server Project - LTSP LTSP è un progetto di codice open source per costruire computer Linux diskless. Nel sito LTSP si trovano i pacchetti RPM per Linux Redhat e quelli per Linux Debian che possono far risparmiare un sacco di tempo. I capitoli successivi in questo documento sono da intendersi solo per fini accademici ed è possibile leggerli se si ha del tempo libero. Si visiti il sito LTSP e i siti correlati presso: · · · · Argomenti correlati che vale la pena vedere: · NCD X-terminal 5. Scrittori di EPROM e chip di memoria Nei capitoli successivi servono le seguenti informazioni riguardo gli scrittori di EPROM. 5.1. Chip di memoria non volatile Segue una breve descrizione dei chip di memoria e un elenco dei tipi esistenti. · PROM: Pronuncia prom, acronimo di programmable read-only memory (memoria a sola lettura programmabile). Una PROM è un chip di memoria in cui i dati possono essere scritti una sola volta. Una volta che un programma è stato scritto in una PROM resta lì per sempre. Al contrario delle RAM, le PROM mantengono il loro contenuto anche quando il computer viene spento. La differenza fra una PROM e una ROM (read only memory - memoria a sola lettura) è che la PROM viene costruita come memoria vuota, mentre la ROM viene programmata durante il processo di fabbricazione. Per scrivere dei dati in una PROM è necessario usare uno speciale dispositivo chiamato programmatore PROM o scrittore PROM. Il processo di programmazione di una PROM è anche chiamato "bruciare la PROM". Una EPROM (erasable programmable read only memory) è un tipo particolare di PROM che può essere cancellata esponendola a luce ultravioletta. Una volta cancellata può essere riprogrammata. Una EEPROM è simile ad una PROM, ma necessita solo di elettricità per essere cancellata. · EPROM: Acronimo di erasable programmable read-only memory (memoria a sola lettura programmabile e cancellabile), si pronuncia è-prom. La EPROM è un tipo particolare di memoria che mantiene il suo contenuto finché non viene esposta a luce ultravioletta. La luce ultravioletta ne cancella il contenuto, rendendo possibile riprogrammare la memoria. Per scrivere e cancellare una EPROM serve un particolare dispositivo chiamato programmatore PROM o scrittore PROM. Una EPROM differisce da una PROM nel fatto che una PROM può venire scritta una sola volta e non può essere cancellata. Le EPROM sono ampiamente diffuse nei personal computer perché consentono al produttore di cambiare i contenuti delle EPROM prima che il computer venga effettivamente consegnato. Ciò significa che è possibile eliminare dei bug e possono essere installate delle nuove versioni subito prima della consegna. Una nota riguardo la tecnologia EPROM: i bit di una EPROM vengono programmati iniettando degli elettroni aventi elevata tensione nei gate flottanti dei transistor ad effetto di campo in cui si vuole un bit a 0. Gli elettroni così intrappolati provocano la conduzione del transistor e fanno leggere uno 0. Per cancellare la EPROM si fornisce agli elettroni abbastanza energia per fuggire dal gate flottante, cosa che si fa bombardando il chip con radiazione ultravioletta attraverso la finestrella di quarzo. Per impedire la lenta cancellazione, ad opera della luce del sole e di luci fluorescenti, della durata di anni, la finestrella di quarzo, durante l'uso normale, viene coperta con una etichetta opaca. · EEPROM: Acronimo di electrically erasable programmable read-only memory (memoria a sola lettura programmabile e cancellabile elettricamente). Si pronuncia e-è-prom o è-è-prom. La EEPROM è un particolare tipo di PROM che può essere cancellata esponendola ad una carica elettrica. Come gli altri tipi di PROM, la EEPROM mantiene il suo contenuto anche se viene tolta l'alimentazione. Così come gli altri tipi di ROM, la EEPROM non è veloce quanto la RAM. La EEPROM è simile alle memorie flash (a volte chiamate flash EEPROM). La differenza fondamentale è che nella EEPROM i dati vanno scritti un byte alla volta, mentre le meorie flash consentono la scrittura e la cancellazione in blocchi; ciò rende le memorie flash più veloci. · FRAM: Abbreviazione di Ferroelectric Random Access Memory (memoria ad accesso casuale ferroelettrica), un tipo di memoria non volatile sviluppata dalla Ramtron International Corporation. La FRAM combina la velocità di accesso delle DRAM e SRAM con la non volatilità delle ROM. A causa della sua velocità sta rimpiazzando le EEPROM in parecchi dispositivi. Il termine FRAM è un marchio registrato dalla Ramtron. · NVRAM: Abbreviazione di Non-Volatile Random Access Memory (memoria non volatile ad accesso casuale), è un tipo di memoria che mantiene il suo contenuto quando viene tolta l'alimentazione. Un tipo di NVRAM è la SRAM quando viene resa non volatile collegandola ad una fonte di alimentazione continua tipo una batteria. Un altro tipo di NVRAM usa i chip EEPROM per salvare il suo contenuto quando viene tolta l'alimentazione. In tal caso la NVRAM è composta da una combinazione di chip SRAM e EEPROM. · Memoria a bolle: È un tipo di memoria non volatile costituita da un sottile strato di materiale che può essere facilmente magnetizzato in una sola direzione. Quando ad un'area circolare di questa sostanza viene applicato un campo magnetico che non è magnetizzato nella stessa direzione, l'area si riduce ad un piccolo cerchietto, o bolla. Una volta in molti ritenevano che le memorie a bolle sarebbero diventate una tecnologia cardine fra le tecnologie di memorizzazione, ma tali promesse non sono state mantenute. Altri tipi di memorie non volatili, come le EEPROM, sono più veloci e meno costose delle memorie a bolle. · Memorie Flash: Sono un tipo particolare di EEPROM che possono essere cancellate e riprogrammate a blocchi piuttosto che un byte alla volta. Parecchi PC moderni hanno il loro BIOS memorizzato su un chip di memoria flash, in modo da poter essere facilmente aggiornato, se necessario. Un tale BIOS è anche chiamato flash BIOS. Le memoria flash sono diffuse anche nei modem, perché permettono al costruttore di modem di supportare nuovi protocolli non appena vengono standardizzati. 5.2. Elenco di produttori di scrittori EEPROM Per trovare un elenco di produttori di scrittori EPROM si visiti il sito Yahoo (NdT: il sito .com, non quello .it) e si vada in economy->company->Hardware->Peripherals->Device programmers. · L'URL di Yahoo riguardo le EPROM è a · Advanced Research Technology B.V - sviluppo, produzione e vendita di strumenti di programmazione elettronica; sviluppo di hardware e software. · Advin Systems Inc. - dispositivi programmatori basati su PC che supportano i tipi di package e le teconologie dei dispositivi più recenti. · Andromeda Research Labs - produce un sistema portatile per la programmazione di eprom e dispositivi. · B and C Microsystems, Inc - offre strumenti di verifica e duplicazione/programmazione di schede PCMCIA (PC), schede ISA/PCI, SIMM, memorie (incluse le FLASH), PLD. · BP Microsystems - programmatori di dispositivi. · Bytek - progetto, sviluppo, produzione e vendita di sistemi basati su microprocessori, sistemi di elettronica modulare usati per programmare e verificare dispositivi a semiconduttori. La linea di prodotti comprende il ChipBurner. · Concentrated Programming Ltd - offre un ampio spettro di soluzioni per la programmazione dei dispositivi. · Dataman Programmmers Ltd. - produce programmatori/emulatori hand-help di EPROM. Vende anche programmatori basati su PC e programmatori Gang-Pro. · General Device Instruments - Programmatori di dispostivi a CI. Programmatori universali e Gang per Pld, flash, microcontrollori, Prom, EEProm, memorie, Epld, Mach e molti altri dispositivi a CI. · HI-LO System Research Co., Ltd. - produttore di programmatori universali e gang. · ICE Technology - programmatori EPROM e di dispositivi universali che supportano memorie, microcontrollori e dispositivi logici programmabili. · Iceprom - memorie a sola lettura programmabili e cancellabili in-circuit. · Incept Ltd. · International Microsystems Inc - Programmatori gang affidabili ad elevata velocità (PROM, FLASH, microcontrollori, schede di memoria PCMCIA). · JED Microprocessors Pty. Ltd. - inseritelo in una porta D25 per stampante e programmate qualsiasi dispositivo FLASH ed EPROM a 28 o 32 pin. · Logical Devices, Inc - dispositivi di programmazione di PLD, FPGA, PROM, microcontrollori. Produttore di compilatori CUPL per logiche programmabili e dei programmatori ALLPRO e Chipmaster. · MCL Systems - nuovo metodo non solo di programmazione ma anche di sviluppo di nuovo hardware con unità di controllo integrata. E non serve essere esperti. · MQP Electronics - produttore di programmatori di dispositivi universali, programmatori gang, software di produzione e convertitori di package. Elevata efficenza ed affidabilità. · Needham's Electronics - produttore di programmatori di dispositivi. · NP Programming Services - fornisce programmazione di memorie e parti logiche. · Program Automation, Inc. - compagnia di servizio indipendente specializzata nella programmazione di grossi volumi di PROM, inclusi CI flash. · Stag Programmers Inc - produttore di programmatori prom e logici, produzione di strumenti di manipolazione e cancellatori UV. · Sunrise Electronics - programmatori di dispositivi universali, programmatori gang e in- circuit con supporto a vita. · System General Co. - programmatori di dispositivi, scrittori di EPROM e tester di CI. · Tribal Microsystems - programmatori di dispositivi gang e universali, emulatori di EPROM e 8051, zoccoli per il burn-in e per la produzione. · Universal Device Programmers 6. Introduzione al boot via rete e all'Etherboot Questo capitolo è stato scritto da Ken Yap e spiega come avviare il proprio computer da un programma immagazzinato in una memoria non volatile senza accedere al proprio disco rigido. È una tecnica ideale per gestire e configurare una "fattoria" di macchine linux. 6.1. Cos'è il boot via rete? Il boot via rete è una vecchia idea; l'idea di base è che il computer abbia un qualche codice di bootstrap nella memoria non volatile, cioè un chip ROM, che gli permetterà di contattare un server per ottenere i file di sistema attraverso un collegamento di rete. 6.2. Come funziona Perché sia possibile un boot attraverso la rete il computer deve ricevere: 1. un'identità, 2. un'immagine del sistema operativo e, 3. di solito, un file system funzionante. Consideriamo un computer diskless (DC) che abbia una ROM per il boot via rete. Potrebbe essere uno di vari DC identici, come possiamo distinguere questo computer dagli altri? C'è una informazione che è unica per quel computer (in realtà per il suo adattatore di rete) ed è il suo indirizzo Ethernet. Ogni adattatore Ethernet nel mondo ha un indirizzo Ethernet univoco di 48 bit; ciò perché ad ogni costruttore di hardware Ethernet sono stati assegnati dei blocchi di indirizzi. Per convenzione tali indirizzi sono scritti con cifre esadecimali, con i due punti che separano ogni gruppo di due cifre; ad esempio: 00:60:08:C7:A3:D8. I protocolli usati per ottenere un indirizzo IP, dato un indirizzo Ethernet, sono chiamati Boot Protocol (BOOTP) e Dynamic Host Configuration Protocol (DHCP, protocollo di configurazione dinamica dell'host). DHCP è una evoluzione di BOOTP. Nella nostra discussione, salvo ove diversamente specificato, tutto ciò che si applica a BOOTP vale anche per DHCP (in realtà dire che BOOTP e DHCP traducono solo indirizzi Ethernet è una piccola bugia; nella loro lungimiranza, i progettisti hanno dato a BOOTP e DHCP la possibilità di funzionare con qualsiasi tipo di indirizzo hardware, ma Ethernet è quello che verrà usato nella maggioranza dei casi). Un esempio di scambio BOOTP funziona così: DC: Salve, il mio indirizzo hardware è 00:60:08:C7:A3:D8, per favore dammi il mio indirizzo IP. server BOOTP: (guardando nel database degli indirizzi) Il tuo nome è aldebaran, il tuo indirizzo IP è 192.168.1.100, il tuo server è 192.168.1.1, il file da cui effettuare il boot è /tftpboot/vmlinux.nb (più qualche altra informazione). Ci si potrebbe chiedere come ha fatto il DC a trovare l'indirizzo del server BOOTP la prima volta. La risposta è che non l'ha fatto; la richiesta BOOTP è stata diffusa in broadcast sulla rete locale e qualsiasi server BOOTP in grado di rispondere lo ha fatto. Dopo aver ottenuto un indirizzo IP, il DC deve scaricare l'immagine di un sistema operativo ed eseguirlo. Qui viene usato un altro protocollo Internet chiamato Trivial File Transfer Protocol (TFTP - protocollo elementare per il trasferimento file). Il TFTP è una specie di versione ridotta dell'FTP --- non c'è autenticazione e funziona sullo User Datagram Protocol (UDP) invece che sul Transmission Control Protocol (TCP). È stato scelto l'UDP al posto del TCP a causa della semplicità; l'implementazione dell'UDP sul DC può essere abbastanza piccola da permettere di farne facilmente entrare il codice in una ROM. Visto che l'UDP è un codice orientato ai blocchi, al contrario di uno orientato al protocollo, il trasferimento avviene blocco per blocco, in questo modo: DC: Dammi il blocco 1 di /tftpboot/vmlinux.nb. server TFTP: Eccolo. DC: Dammi il blocco 2. ...e così via, finché non viene trasferito l'intero file. L'handshaking è basato su una semplice conferma di ogni blocco e la perdita di pacchetti è gestita ritrasmettendo dopo un timeout. Quando sono stati ricevuti tutti i pacchetti la ROM di boot della rete passa il controllo all'entry point dell'immagine del sistema operativo. Concludendo, per poter eseguire un sistema operativo deve essere fornito un filesystem principale. Il protocollo usato da Linux e da altri Unix di solito è il Network File System (NFS - file system di rete), sebbene siano possibili altre scelte. In questo caso il codice non deve risiedere nella ROM ma può essere parte del sistema operativo che si è appena scaricato. Comunque il sistema operativo deve essere capace di girare con un file system principale che sia un NFS invece che un vero disco. Linux ha le variabili di configurazione necessarie per compilare una versione che possa farlo. 6.3. Il boot via rete in pratica Il Net Loader è un programmino che gira come estensione del BIOS, di solito su una EPROM nel NIC. Esso gestisce le richieste BOOTP e i caricamenti TFTP e poi trasferisce il controllo all'immagine caricata. Usa i protocolli TCP/IP ma l'immagine caricata non deve necessariamente essere Linux; può essere qualunque cosa, anche DOS. Possono anche essere caricate da un floppy per effettuare delle prove o per provare impostazioni temporanee. Oltre alle ROM di boot commerciali ci sono DUE fonti di pacchetti per il boot via rete. Implementazioni libere (free) di loader per reti TCP/IP sono: 1. ETHERBOOT e 2. NETBOOT Innanzi tutto bisogna accertarsi che la propria scheda di rete sia supportata da Etherboot o da Netboot. Eventualmente bisognerà trovare una persona disposta a mettere il codice in una EPROM (Erasable Programmable Read Only Memory) al posto proprio, ma all'inizio si può effettuare il boot via rete da un floppy. Per creare un floppy di boot nella distribuzione viene fornito uno speciale blocco di boot. Questo piccolo programma di 512 byte carica in memoria i blocchi del disco che lo seguono nel floppy e inizia l'esecuzione. Quindi, per fare un floppy di boot, uno deve solo concatenare il blocco di boot con il binario Etherboot contenente il driver per una scheda di rete, in questo modo: ______________________________________________________________________ # cat floppyload.bin 3c509.lzrom > /dev/fd0 ______________________________________________________________________ Si prenda il pacchetto nfdboot (disponibile presso il proprio sito mirror Linux preferito nella directory /pub/Linux/system/Linux-boot). Esso contiene una immagine bootprom per le schede di rete (come la wd8013) che può essere scritta direttamente. Vedere anche il sito LTSP presso Prima di inserire il floppy per il boot via rete bisogna preparare tre servizi su Linux: 1. BOOTP (o DHCP) 2. TFTP e 3. NFS. Non è necessario prepararli tutti e tre contemporaneamente, si può farlo un passo alla volta, accertandosi che ogni passo funzioni prima di passare al successivo. 6.3.1. Bootp Si installi Bootp. Vedere bootp*.rpm sul cdrom Redhat Linux. Vedere anche i pacchetti RPM sul sito LTSP presso . Vedere anche le pagine di manuale unix 'man 5 bootptab', 'man 8 bootpd', 'man 8 bootpef', 'man 8 bootptest'. Bisogna poi assicurarsi che il server stia aspettando richieste bootp. Il demone può essere lanciato direttamente col comando ______________________________________________________________________ bootpd -s ______________________________________________________________________ oppure usando inetd; si editi il file /etc/inetd.conf e si inserisca una riga come la seguente: ______________________________________________________________________ bootps dgram udp wait root /usr/sbin/in.bootpd bootpd ______________________________________________________________________ Inserire o togliere il commento dalle seguenti due righe in /etc/ser­ vices: ______________________________________________________________________ bootps 67/tcp # server BOOTP tftp 69/udp # server TFTP ______________________________________________________________________ Se si è dovuto modificare /etc/inetd.conf allora è necessario far ripartire inetd inviando al processo il segnale HUP. ______________________________________________________________________ kill -HUP ______________________________________________________________________ Poi, bisogna dare a bootp un database per mappare gli indirizzi Ethernet con indirizzi IP. Questo database è in /etc/bootptab. Bisogna modificarlo inserendo gli indirizzi IP del proprio gateway, del server dns e gli indirizzi ethernet delle proprie macchine diskless. Il database contiene righe aventi la forma: ______________________________________________________________________ aldebaran.foo.com:ha=006008C7A3D8:ip=192.168.1.100:bf=/tftpboot/vmlinuz.nb ______________________________________________________________________ Possono essere specificate altre informazioni, ma cominceremo nel modo facile. Un altro esempio di /etc/bootptab è: ______________________________________________________________________ global.prof:\ :sm=255.255.255.0:\ :ds=192.168.1.5:\ :gw=192.168.1.19:\ :ht=ethernet:\ :bf=linux: machine1:hd=/export/root/machine1:tc=global.prof:ha=0000c0863d7a:ip=192.168.1.140: machine2:hd=/export/root/machine2:tc=global.prof:ha=0800110244e1:ip=192.168.1.141: machine3:hd=/export/root/machine3:tc=global.prof:ha=0800110244de:ip=192.168.1.142: ______________________________________________________________________ global.prof è una generica traccia per le voci di host, in cui: · il campo sm contiene la maschera di sottorete · il campo ds contiene l'indirizzo del Domain Name Server · il campo gw contiene l'indirizzo predefinito del gateway · il campo ht contiene il tipo di hardware del supporto di rete · il campo bf contiene il nome del file di boot Dopo di che, ogni macchina deve avere una riga in cui: · il primo campo contiene il nome dell'host · il campo hd contiene la directory del file di boot · la traccia globale può essere inclusa nel campo tc · il campo ha contiene l'indirizzo hardware della scheda ethernet · il campo ip contiene l'indirizzo ip assegnato Ora si faccia il boot del DC col floppy e questi dovrebbe rilevare la propria scheda Ethernet e diffondere una richiesta BOOTP. Se tutto va bene il server dovrebbe rispondere al DC con l'informazione richiesta. Poiché /tftpboot/vmlinux.nb ancora non esiste, quando proverà a caricare il file fallirà. Ora occorre compilare un kernel speciale, uno in cui sia abilitata l'opzione per montare il filesystem principale dal NFS. Bisogna anche abilitare l'opzione per prendere l'indirizzo IP del kernel dalla risposta BOOTP originale. Si deve compilare il driver Linux per il proprio adattatore di rete dentro al kernel, invece che caricarlo come modulo. È possibile scaricare un ramdisk iniziale di modo che il caricamento dei moduli funzioni, ma questo è qualcosa che si può fare in seguito. Non si può installare direttamente la zImage risultante dalla compilazione del kernel, deve essere prima convertita in una immagine marcata. Una immagine marcata è una normale immagine del kernel con un header speciale che dice al bootloader di rete dove vanno i byte nella memoria e da quale indirizzo iniziare il programma. Per creare tale immagine marcata va usato un programma chiamato mknbi-linux. Questa utility si trova nella distribuzione Etherboot. Dopo che è stata generata l'immagine la si metta nella directory /tftpboot col nome specificato in /etc/bootptab. Si renda tale file leggibile da tutti perché il server tftp non ha privilegi speciali. Riguardo TFTP, vedere tftp*.rpm sul cdrom Redhat Linux. Il TFTP (Trivial File Transfer Protocol) è un protocollo per il trasferimento di file, come ftp ma molto più semplice, il che è d'aiuto per codificarlo nelle EPROM. TFTP può essere usato in due modi: · tftp semplice: significa che il client può accedere al vostro intero file system. È il più semplice ma è anche un grosso buco di sicurezza (chiunque può prendere il vostro file con le password via tftp). · tftp sicuro: il server tftp usa una chiamata di sistema chroot.2 per cambiare la sua directory di root. Qualsiasi cosa al di fuori della nuova directory di root sarà completamente inaccessibile. Visto che la directory chroot diventa la nuova directory di root, l'hd indicato in bootptab deve riflettere la nuova situazione. Ad esempio: quando si usa il tftp insicuro, il campo hd conterrà il path completo per la directory di boot, cioè /export/root/machine1. Quando si usa il tftp sicuro con /export come directory di root, allora /export diventa / e il campo hd dovrà essere /root/machine1. Tftpd viene di solito avviato da inetd con una riga in /etc/inetd.conf simile alla seguente: ______________________________________________________________________ tftp dgram udp wait root /usr/sbin/tcpd in.tftpd -s /tftpboot #tftp dgram udp wait root /usr/sbin/in.tftpd tftpd /export ______________________________________________________________________ Di nuovo, si riavvii inetd con un segnale HUP e si riprovi il boot; stavolta dovrebbe scaricare l'immagine del kernel ed eseguirla. Si otterrà che il boot va avanti fino al punto in cui prova a montare un filesystem principale. A questo punto per procedere bisogna configurare ed esportare le partizioni NFS. 6.3.2. Filesystem principale NFS Per vari motivi, non è una buona idea usare il filesystem principale del server come filesystem principale del DC. Il primo semplicemente è che lì ci sono diversi file di configurazione e in quel modo il DC prenderà l'informazione sbagliata. Un altro è la sicurezza; è pericoloso permettere l'accesso in scrittura alla root del server (e, per diversi motivi, l'accesso in scrittura al filesystem principale è indispensabile). Comunque la buona notizia è che un filesystem principale per il DC non è molto grande, solo 30 MB circa, e buona parte di esso può essere condiviso fra più DC. Idealmente, per costruire un filesystem principale bisogna sapere quali file si aspetta di vedere lì la vostra distribuzione del sistema operativo. Per il boot sono cruciali i file di device, quelli in /sbin e in /etc. È possibile evitare gran parte del lavoraccio copiando un filesystem principale esistente e modificando alcuni file per il DC. Nella distribuzione Etherboot c'è un tutorial ed alcuni link ad un paio di script di shell che servono per creare un tale filesystem principale per il DC partendo da un filesystem principale esistente su un server. Nella documentazione di Etherboot ci sono anche dei suggerimenti su come risolvere i problemi, visto che questa è spesso la parte più insidiosa della preparazione. Il kernel Linux fatto su misura per il DC si aspetta di vedere il filesystem principale in /tftpboot/(indirizzo IP del DC), ad esempio: /tftpboot/192.168.1.100 nel suddetto caso. Ciò, volendo, può essere modificato durante la configurazione del kernel. Ora si crei, o si modifichi, /etc/exports sul server e si aggiunga una riga così fatta: ______________________________________________________________________ /tftpboot/192.168.1.100 aldebaran.foo.com(rw,no_root_squash) ______________________________________________________________________ L'accesso rw è necessario per vari servizi di sistema. L'attributo no_root_squash impedisce al sistema NFS di mappare l'ID del root su un altro. Se questi non è specificato vari demoni e generatori di log non saranno contenti. Si avviino, o riavviino, i servizi NFS (rpc.portmap e rpc.mountd) e si riprovi il boot senza dischi. Se va tutto bene il kernel dovrebbe essere in grado di montare un filesystem principale e proseguire il boot fino al prompt di login. Più probabilmente ci si accorgerà che ci sono diverse cose non configurate a dovere. La maggior parte delle distribuzioni Linux sono orientate verso le operazioni su disco e necessitano di un po' di modifiche per andar bene per un boot diskless. La più comune causa di fallimento è dovuta al fatto che il processo di boot fa affidamento ai file sotto /usr, che di solito viene importata da un server più tardi nel processo di boot. Due possibili soluzioni sono: 1. Fornire i pochi file richiesti sotto una piccola directory /usr sul filesystem principale, che verrà poi sovrascritta quando verrà importato /usr; 2. Modificare il path in modo che cerchi i file nel filesystem principale. I file da modificare sono sotto /tftpboot/192.168.1.100 (si ricordi che questa è la directory principale del DC). Si potrebbero voler montare altre directory dal server, come /usr (che può essere esportata in sola lettura). 6.3.3. Scrivere la EPROM Quando si è ottenuto di poter fare il boot dalla rete senza nessun problema, si potrebbe voler mettere il codice in una EPROM. 6.4. Utilizzi del boot via rete I terminali X sono un naturale utilizzo del boot via rete. La mancanza di dischi sul terminale lo rende più silenzioso e contribuisce a rendere piacevole l'ambiente di lavoro. La macchina idealmente dovrebbe avere 16MB o più di memoria e la miglior scheda video che si riesce a trovargli. Questo è l'utilizzo ideale per un 486 di fascia alta, o un Pentium di fascia bassa, che è diventato obsoleto a causa dell'evoluzione dell'hardware. Altri usano il boot via rete per cluster di macchine in cui l'uso del DC è leggero e non giustifica la presenza di un disco; cioè un cluster di macchine in un'aula scolastica. 6.5. Per maggiori informazioni Il primo posto in cui fermarsi è la home page di Etherboot: Lì si troveranno link ad altre risorse, inclusa una mailing list a cui iscriversi, in cui vengono discussi problemi e soluzioni. Documenti correlati: · NFS-root Mini Howto, in /usr/doc/HOWTO/mini o sul cdrom Linux. · Linux Networking-HOWTO di Terry Dawson, in /usr/doc/HOWTO o sul cdrom Linux 94004531@postoffice.csu.edu.au · NET-3-Howto, in /usr/doc/HOWTO o sul cdrom Linux. · /usr/src/linux/README riguardo la configurazione e la compilazione di nuovi kernel. 6.6. Configurazione del Linux Redhat Il DC richiede di montare /tftpboot/ (nella 2.1 e precedenti: /tftpboot/) come sua '/' tramite NFS dal server. Bisogna esportarlo dal server (rw, no_root_squash) perché il DC ci vuole scrivere (file di log, ecc). La directory di root / deve contenere /sbin, /lib, /etc, /var, /tmp, /root, /dev e /proc. /sbin, /bin e /lib possono essere una copia di un sistema Linux Redhat esistente. Possono essere condivise tra tutti i DC. Ma solo link fisici. A proposito, non si facciano link agli originali sul server. /etc, /var e /dev devono essere copie non condivisibili. Si aggiustino ad hoc /etc/sysconfig/network, /etc/sysconfig/network- scripts/ifcfg-eth0, /etc/fstab, /etc/conf.modules e altri. Disabilitare tutti i servizi di rete che non servono. Togliere da /var tutta la roba di cui non si ha bisogno, ad es. i db RPM e i file lpd. /root e /proc dovrebbero semplicemente esistere. /tmp dovrebbe esistere ed essere mode 1777. Probabilmente si vorrà creare i mount point /usr e /home. /usr può essere montato ro (read only - a sola lettura). Dovrebbero bastare circa 10 MB per DC più circa 15 MB per i file condivisi. A proposito: se i propri DC sono identici anche l'immagine del kernel può essere condivisa. Ecco uno script illustrativo per creare il primo filesystem root: ______________________________________________________________________ #!/bin/sh if [ $# != 1 ] then echo Usage: $0 client-IP-addr exit 1 fi cd / umask 022 mkdir -p /tftpboot/$1 # facciamo così for d in home mnt proc tmp usr do mkdir /tftpboot/$1/$d done chmod 1777 /tftpboot/$1/tmp touch /tftpboot/$1/fastboot chattr +i /tftpboot/$1/fastboot # copiamo questi cp -a bin lib sbin dev etc root var /tftpboot/$1 cat < · Vedere anche · ROM di boot LanWorks BootWare Si faccia riferimento al file README per i dettagli riguardanti l'installazione. Al momento sono supportati solo i kernel di tipo "zImage". Sfortunatamente i parametri del kernel vengono ignorati. Per questa sezione si ringrazia Jochen Kmietsch; per qualsiasi domanda spedire una email a: jochen.kmietsch@tu-clausthal.de. 8. Etherboot Etherboot è un pacchetto per creare immagini ROM che possono scaricare, attraverso la rete, codice che va eseguito su un computer x86. Tipicamente il computer sarà senza dischi e il codice sarà Linux, ma queste non sono le uniche possibilità. Questo documento si trova presso la Etherboot Home Page . Questo documento spiega come installare, configurare e usare il pacchetto Etherboot. 9. Netboot Netboot è stato scritto da Zurück zu Gero. Il sito principale è . 9.1. Introduzione Il seguente elenco mostra solo qualche esempio dei possibili usi di Netboot: · Spooler di stampa · Server per terminali · Terminale X11 · Sistema per il log dei dati · Network-Computer (NC) · Altro ancora .... Per trovare l'immagine del kernel la bootrom usa il protocollo BOOTP, così come definito negli ``RFC 951'' e ``RFC 1533'', per recuperare le informazioni necessarie per il boot e poi carica l'effettiva immagine usando il protocollo TFTP, definito nel ``RFC 1350''. Le specifiche dettagliate per il processo di boot via rete possono essere trovate in . 9.2. Mailing list Esiste una mailing list dedicata al boot via rete. Per iscriversi basta semplicemente preparare una email contenente la riga subscribe netboot nel corpo del messaggio e spedirla a majordomo@baghira.han.de L'oggetto della mail non è importante. Dopo la sottoscrizione, è possibile inviare messaggi alla lista scrivendo a netboot@baghira.han.de. 9.3. Netboot, link utili L'archivio della mailing list di Netboot è presso · I driver 3com sono presso · I driver Accton sono qui · Artisoft · CNET · Compaq · D-Link · Microdyne · Parecchie schede PCI NE2000 sono basate sui chipset Realtek. Si prendano i driver qui · Standard Microsystems Corp · Surecom · Thomas Conrad corp · Winbond · Xircom · La pagina Webopaedia sulle schede di rete. · La pagina dei driver di Jargon con parecchi driver per le vecchie schede di rete. · Etherboot . Questo è un progetto simile al Netboot ma basato sul codice bootrom BSD. · Come tirar fuori un Terminale X Window dal vostro vecchio o antiquato PC. · Elenco delle impostazioni dei ponticelli per varie schede di rete. Questa pagina contiene anche parecchi altri buoni link. · Freefire è la home page del progetto Freefire, che elenca molte risorse riguardanti argomenti sulla sicurezza di rete. 10. URL correlate · Vedere il 'Diskless-root-NFS-HOWTO' presso · Linux goodies o 11. Nota sul copyright Copyright policy is GNU/GPL as per LDP (Linux Documentation project). LDP is a GNU/GPL project. Additional restrictions are - you must retain the author's name, email address and this copyright notice on all the copies. If you make any changes or additions to this document than you should intimate all the authors of this document. La politica di copyright è GNU/GPL come per il LDP (Linux Documentation project). LDP è un progetto GNU/GPL. Le restrizioni aggiuntive sono: bisogna mantenere su tutte le copie i nomi degli autori, gli indirizzi email e questa nota sul copyright. Se si fanno dei cambiamenti o delle aggiunte a questo documento bisogna comunicarlo a tutti gli autori. 12. Appendice A - Istruzioni di installazione I N S T A L L A Z I O N E Panoramica del processo di installazione ======================================== Per sua natura, questo pacchetto necessita di almeno due computer. Uno funge da server e (almeno) un altro sarà configurato come client diskless. Di conseguenza questa guida all'installazione è divisa in quattro sezioni: 1.) Compilazione e installazione di programmi di utilità sul server 2.) Creazione di una immagine avviabile del sistema operativo scelto 3.) Preparazione del server 4.) Preparazione del client, compresa la bootrom Il server deve supportare il TCP/IP e alcuni protocolli basati su questo standard di rete. Molto probabilmente questo sarà un server di tipo Unix. Sebbene probabilmente sia possibile usare anche, ad esempio, dei server su cui gira OS/2 o Windows-NT, tutti i programmi relativi ai server di questo pacchetto, al momento, possono essere compilati soltanto su sistemi di tipo Unix. Tale requisito è indipendente dal sistema operativo che verrà avviato più tardi sul client diskless. Quindi, anche se si desidera avviare MS-DOS sul (sui) client, è necessario almeno un computer Unix per la compilazione del programma e per la generazione di tutti i file di boot. In seguito, quando tutti i file necessari saranno stati compilati, è possibile usare qualsiasi server si desideri. Questo pacchetto contiene due parti principali: 1.) I sorgenti ed i binari della bootrom. Questa parte viene installata sul client diskless. Tutti i programmi, ad eccezione dei programmi di utilità, sono già precompilati. Nei sorgenti non ci sono ulteriori opzioni modificabili o aggiustabili da parte dell'utente; quindi non è necessario avere accesso agli strumenti di sviluppo a 16 bit per usare la bootrom, è sufficiente usare i binari forniti. Per permettere alla bootrom di accedere alla scheda di rete nel client diskless è necessario un driver. Al momento la bootrom supporta solo i così detti packet driver, come quelli che si usano di solito nei sistemi MS-DOS per interfacciare uno stack di rete con l'hardware. Con questo pacchetto sono necessari solo i binari del packet driver, quindi qui non è necessario ricompilare nulla. È possibile trovare packet driver precompilati per la maggior parte delle più diffuse schede di rete su qualsiasi mirror FTP SimTel (si chiama Crynwr packet driver collection) e, per quelli che non hanno accesso ad Internet, alcuni di tali binari sono inclusi in questo pacchetto. Un'altra buona fonte per il packet driver della propria scheda di rete potrebbe essere il produttore della stessa. Come minimo, i più noti produttori (per esempio 3Com e SMC) forniscono i packet driver di tutta la loro linea di prodotti. I packet driver forniti dai produttori sono di solito più veloci e più facili da installare di quelli della raccolta Crynwr e, a volte, sono in grado di determinare la configurazione dell'hardware durante l'esecuzione, cosa che i driver di Crynwr non riescono a fare. Tuttavia esiste la limitazione che è possibile usare solo packet driver eseguibili di tipo COM. Gli eseguibili di tipo EXE non sono ancora supportati. 2.) Un insieme di programmi per generare sul server delle immagini avviabili via rete. Tali programmi sono chiamati mknbi-, ove identifica il sistema operativo che poi girerà sul client diskless. Al momento sono supportati solo Linux ed MS-DOS. C'è un altra esigenza che non può passare inosservata. Sebbene sia possibile preparare una ROM di boot, dalle funzionalità leggermente limitate, che occupi meno di 16Kb, la dimensione solita per una scheda di rete è tra 16Kb e 32Kb. Quindi nel comprare una scheda di rete bisognerebbe prenderne una che accetti EPROM da 32Kb. Questo è lo standard per quasi tutte le schede dei principali produttori, ma è noto che la maggior parte delle economiche NE2000 accettino solo 16Kb al massimo. Va notato anche che alcune schede di rete di 3Com e SMC permettono, tramite i loro programmi di configurazione, di selezionare dimensioni di 32Kb o più per la ROM, ma poi sulla scheda accettano solo ROM da 16Kb! Compilazione e installazione dei programmi di utilità sul server ================================================================ Questo pacchetto usa l'autoconf GNU per configurare il processo di compilazione dei programmi di utilità. Non si dovrebbe avere nessun problema nel compilare tali programmi su un qualsiasi sistema Unix. 1.) Posizionarsi nella directory netboot e lanciare ./configure. È uno script di configurazione generato da autoconf che controlla i file header e altri dettagli specifici del sistema. Il programma di utilità mknbi contiene dei moduli assembler Intel che poi gireranno sul client diskless. Se si vogliono assemblare tali moduli sono necessari as86 e ld86 (che possono essere recuperati gratuitamente sui sistemi Unix). Comunque sono disponibili i file già assemblati e quindi in effetti tali programmi non servono. Configure ne verifica l'esistenza e crea i Makefiles di conseguenza. Per una spiegazione delle opzioni disponibili per configure basta lanciarlo con l'opzione --help. Sono disponibili delle opzioni aggiuntive: --disable-mknbi-linux --disable-mknbi-dos Queste opzioni vanno scelte se non si vuole creare nessuna delle corrispondenti utilità mknbi. C'è anche un'altra opzione di configure: --enable-bootrom Va usata solo se si vuole ricompilare la bootrom stessa. Se si vogliono usare i binari precompilati tale opzione non è necessaria. Vedere il file INSTALL.bootrom riguardo il modo in cui ricompilare la bootrom. 2.) Controllare che tutti i Makefile generati e i config.h siano corretti per il proprio sistema. 3.) Compilare tutti i programmi con make clean make Ciò compilerà tutti i programmi, tranne quelli disabilitati durante la fase di configurazione. NOTA IMPORTANTE: alcuni Makefile usano ifdef, che non è comprensibile a tutti i make. Se si riceve un errore da make (di solito del tipo: "missing delimiter", manca un delimitatore) allora ci si procuri e si installi sul proprio sistema il make GNU! I sistemi System V sono i più noti per avere tale problema. 4.) Se si desidera installare i programmi di utilità in modo permanente sul proprio sistema si esegua make install Ciò installerà anche le corripondenti pagine di manuale per futuri riferimenti. Comunque è perfettamente lecito saltare questo passo e lanciare i programmi mknbi dalle loro directory sorgenti. Per favore si osservi che all'interno delle loro directory sorgenti sono chiamati semplicemente "mknbi". Quindi se in seguito si legge di lanciare mknbi-dos, bisogna invece usare "./mknbi-dos/mknbi", se i programmi sono stati installati senza dare 'make install'. Creazione di una immagine del sistema operativo avviabile via rete ================================================================== Questo passo del processo di installazione dipende da quale sistema operativo si vuole far avviare dai propri client diskless. Tutto quello che viene descritto in questo capitolo non dipende dal fatto che si stia lavorando su un sistema Linux. È possibile usare qualsiasi sistema UNIX per creare le immagini avviabili via rete. Linux: Con Linux ci sono così tante opzioni che non è possibile elencarle tutte in questo testo. Per i dettagli si faccia riferimento alla pagina di manuale di mknbi-linux. Qui descriveremo solo i modi più comuni per preparare un client diskless Linux. Primo: bisogna decidere dove il client Linux monterà il suo filesystem root. Può essere una directory su un server NFS o un ramdisk. Configurare il proprio kernel Linux concordemente. Per usare un filesystem root su un server NFS bisogna includere nel kernel il supporto per reti TCP/IP ed anche quello per i filesystem NFS. Non è possibile caricare il supporto NFS usando un modulo poiché deve essere disponibile già al momento dell'avvio. In più, durante la configurazione del kernel, bisogna anche selezionare il supporto NFSROOT. Tuttavia, non è necessario il supporto per BOOTP o RARP. Di conseguenza, se si vuole usare il supporto per i ramdisk, il tipo di filesystem che si userà sul ramdisk deve essere compilato in modo permanente nel kernel. In tal caso deve essere incluso anche initrd. 1.) Configurazione del filesystem principale su NFS Poi si copi il proprio kernel Linux nella directory corrente e si lanci mknbi-linux: mknbi-linux -d rom -i rom -k zImage -o bootImage Si è supposto che l'immagine del proprio kernel si chiami zImage. Ne verrà fuori una immagine caricabile via rete di nome bootImage. 2.) Configurazione del filesystem principale su ramdisk Se si vuole usare un ramdisk come dispositivo principale bisogna prima creare una immagine del ramdisk. Probabilmente il modo più semplice per preparare una tale immagine è di usare un floppy, sebbene sia possibile anche usare un loopback device se si sta lavorando su un sistema Linux. Innanzitutto si formatti il floppy e vi si prepari un filesystem. Poi vi si copino tutti i file e i programmi che si vorranno (in seguito) avere sul filesystem principale del client diskless. Bisognerebbe poi provare il floppy di boot; per far ciò si copi il proprio kernel su un altro floppy, con dd, e si imposti il suo device principale su floppy usando rdev: dd if=zImage of=/dev/fd0 rdev /dev/fd0 /dev/fd0 Ora si avvii il proprio client diskless usando tale floppy di boot. Quando il kernel è partito chiederà di inserire il floppy di boot e di premere invio. Il disco di boot verrà montato. Se tutto funziona come previsto si può creare una immagine avviabile da rete. Reinserire il floppy di boot nel proprio server (o dovunque si trovi tale directory di boot da rete) e digitare: dd if=/dev/fd0 of=ramImage gzip -9 ramImage mknbi-linux -d ram -i rom -r ramImage.gz -k zImage -o bootImage Come sopra, ciò darà un file bootImage contenente il kernel Linux avviabile da rete. MS-DOS: Per avviare il DOS sul proprio client diskless bisogna avere MS-DOS versione 5.0 o successiva. Windows-95 possiede un DOS interno chiamato versione 7.0, quindi non dovrebbero esserci problemi. Versioni più vecchie di MS-DOS non funzioneranno sicuramente. Non ho avuto la possibilità di provare nessun altro DOS tipo il Novell-DOS o il DR-DOS. Chi li prova mi racconti. Primo: bisogna creare una directory contenente tutti i file che il client vedrà sul suo drive di avvio (A: oppure C:). Questa può essere la directory principale su un floppy DOS o una qualsiasi directory sullo stesso sistema su cui si è installato mknbi-dos. Nel primo caso deve essere un floppy contenente un sistema DOS avviabile, cioè che è stato creato con format a: /s su un sistema DOS. Se la directory si trova in un sistema UNIX, bisogna copiarsi da soli i due file di sistema msdos.sys e io.sys, che fanno parte dell'MS-DOS, nella directory in questione. Per far ciò, suggerisco di usare mread degli MTools, che sono liberamente disponibili per praticamente tutti i sistemi UNIX. Dopo aver creato la directory, o il floppy, che diventerà il drive di avvio dei client, bisogna copiarci dentro tutti gli altri file necessari. Probabilmente ci andranno messi programmi utili a configurare l'ambiente di rete sul client. Quando si editano i file di testo per il client si tenga conto che, di solito, devono essere in formato MS-DOS, con le righe che terminano con la coppia Carriage-Return/Linefeed invece che solo con Linefeed come si usa sui sistemi UNIX. Quando si è terminata la preparazione della directory di boot del client, come prima cosa si faccia una copia dell'immagine del floppy disk e poi si lanci mknbi-dos per creare l'immagine avviabile da rete: dd if=/dev/fd0 of=fdImage mknbi-dos -r fdImage -o bootImage Assunto che il floppy sia stato inserito nel drive fd0 del sistema UNIX, verrà creato un file chiamato bootImage. Se si è usata una directory UNIX si sostituisca fdimage col suo nome. mknbi-dos si accorgerà automaticamente se è una directory, un file normale, o un device a blocchi. Di default, mknbi-dos crea un'immagine avviabile da rete che in seguito monterà sul client il ram disk come drive A:. Se invece si vuole che il ram disk sia montato come C:, bisogna aggiungere l'opzione '-c' nella chiamata di mknbi-dos. La differenza fra il montare il ram disk come floppy (A:) o come disco rigido (C:), è che montato come floppy il ram disk può essere rimosso successivamente, magari dopo che è stato caricato un redirezionatore di rete che rende il ram disk obsoleto; ciò non è invece possibile con un disco rigido virtuale. D'altra parte, usando il disco rigido come C: è possibile specificare una diversa dimensione del ramdisk tramite l'opzione '-s'. Per maggiori informazioni si faccia riferimento alla pagina di manuale di mknbi-dos. Preparazione del server ======================= La preparazione del server dipende dal tipo di server che si sta usando, quindi tutte le spiegazioni che seguono in questo capitolo possono servire solo come guida generica. Bisogna riferirsi alla documentazione del proprio server come fonte decisiva. Quando viene avviata la bootrom sul client essa prova innanzi tutto a chiedere ad un server bootp informazioni come i numeri IP e il nome del file con l'immagine di avvio. Un tale programma di server bootp viene in genere chiamato bootpd. La maggior parte dei server Sun usano invece un programma server bootp chiamato bootparamd. C'è da osservare che _non_ è possibile usare bootparamd come sostituto di bootpd poiché i due programmi usano protocolli diversi; piuttosto si installi sulla propria Sun uno dei bootpd pubblicamente disponibili. Poi bisogna copiare il file bootImage, che è stato creato nel passo precedente, in una directory accessibile pubblicamente (ad esempio chiamata /boot). Se si vogliono avviare più client diskless è possibile usare lo stesso file bootImage per tutti. Tuttavia, se la configurazione è fatta per un ramdisk (con Linux o DOS) e l'immagine del ramdisk contiene diversi file di informazione per ogni client, bisognerà ovviamente avere un diverso file bootImage per ciascun client. Poi bisogna preparare un file di descrizione del boot per bootpd, che di solito si chiama /etc/bootptab. Per maggiori informazioni si consulti la documentazione del proprio server. Comunque, le voci in tale file di solito saranno qualcosa di questo tipo (per ogni client diskless): client1:hd=/boot:vm=auto:ip=192.109.225.66:\ :ht=ethernet:ha=004001417173:\ :bf=bootImage-client1:rp=/boot/client1/root il marcatore 'hd' indica la home directory e 'bf' è il nome del file bootImage che si è creato al passo precedente. Quindi il path completo del file bootImage per il client diskless chiamato "client1", con questa voce d'esempio, sarà /boot/bootImage-client1 Il marcatore 'ip' indica l'indirizzo IP del client, 'ht' il tipo di rete a cui è connesso il client e 'ha' il suo indirizzo hardware. Il marcatore 'vm=auto' dice a bootpd di usare la stessa codifica del produttore della bootrom. Se il proprio client diskless dovrà usare il suo filesystem principale via NFS bisognerà anche specificare la directory sul server che verrà montata in seguito tramite il marcatore 'rp'. Invece, se il proprio client diskless usa un ramdisk è possibile omettere 'rp'. Quando si sceglie di usare la bootrom standard col display driver ANSI (per maggiori informazioni vedere più avanti) si potrebbe anche preparare un menu per lasciar scegliere all'utente fra i diversi file contenenti le immagini di avvio. Per sapere come realizzare una tal cosa si veda il file INSTALL.menu. Personalmente raccomando di usare prima il modo standard di preparare il file bootptab come descritto sopra; sarà sempre possibile aggiungere un menu in seguito. Ovviamente bisogna anche ricordarsi di fare in modo che bootpd giri sul server, all'avvio tramite /etc/rc (o con qualche meccanismo del genere) o tramite inetd. Di nuovo, vedere la documentazione del proprio server per sapere come fare. Il passo successivo effettuato dalla bootrom, dopo aver fatto la richiesta al server bootp, è di caricare il file con l'immagine di avvio specificato dai marcatori 'hd' e 'bf' in /etc/bootptab. Per far ciò si usa un protocollo chiamato tftp. Quindi si dovrà poi preparare sul server un processo demone per questo protocollo. Un tale demone di solito si chiama tftpd e bisogna di nuovo ricordarsi di fare in modo che tftpd stia girando, in genere tramite inetd. Dato che il protocollo TFTP è un modo di accesso al server tftpd molto insicuro, di solito tale accesso viene ristretto (tramite tftpd stesso, o con un wrapper TCP/IP tipo tcpd). Ad esempio, tcpd usa delle tabelle di controllo d'accesso all'host che vengono memorizzate in /etc/hosts.allow e /etc/hosts.deny. Per maggiori informazioni vedere tftpd(8), tcpd(8), hosts_access(5) e la documentazione del proprio server. Se si è scelto un ramdisk per la directory principale del client diskless allora la preparazione del server è finita; ma se il client userà NFS (direttamente per avviare Linux o usando programmi contenuti nel ramdisk) allora bisogna preparare tutto l'occorrente per montare una directory NFS sul server. Ciò in genere implica l'esecuzione di diversi programmi: portmap, mountd, nfsd e opzionalmente ugidd. Ma per usare mountd e nfsd bisogna specificare i permessi che consentono al client di accedere alle directory necessarie sul server. I suddetti permessi vengono di solito impostati tramite un file chiamato /etc/exports, che per il nostro client d'esempio somiglia al seguente: # # Export directories for client1 (diskless workstation) # /boot/client1/root client1(rw,link_absolute) /boot/client1/usr client1(rw,link_absolute) Se si usa 'map-daemon' per mappare i numeri UID e GID sul server bisogna ricordarsi anche di configurare e lanciare ugidd sul server. Si consulti la documentazione del proprio server per avere maggiori informazioni riguardo alla configurazione delle esportazioni NFS. Forse è il caso di consultare anche le pagine di manuale di portmap(8), nfsd(8), mountd(8) e ugidd(8). Si ricordi inoltre che l'accesso ad ognuno di tali servizi sul proprio server dovrebbe essere limitato tramite tcpd. Un altro passo importante è riempire la directory principale del client diskless. Essa deve contenere tutti i file necessari al client per avviarsi e montare altre directory via NFS (come un filesystem /usr tipo quello specificato nell'esempio precedente di /etc/exports). Come configurare tale directory principale va ben oltre lo scopo di questa documentazione; diamo solo un suggerimento: se sul proprio server _non_ sta girando Linux bisognerà fare attenzione a come sono assegnati i numeri principale/secondario nella directory /boot/client1/root/dev. Ad esempio usando semplicemente mknod su un server AIX potrebbe dare dei numeri principale/secondario errati quando la directory viene poi esportata su un client diskless Linux. Con alcune configurazioni, AIX aggiunge un certo scostamento a tutti i numeri primari rendendoli inutilizzabili con Linux. Per maggiori informazioni si faccia riferimento al manuale del proprio server. Se il proprio client usa Linux si potrebbero trovare alcuni utili suggerimenti nel file Documentation/nfsroot.txt. Preparazione del client, inclusa la compilazione della bootrom ============================================================== Finora si è dovuto lavorare solo sul server (con la sola eccezione dell'avviare il proprio client diskless da un dischetto per controllare la correttezza del filesystem principale). Come ultimo passo possiamo ora occuparci della preparazione del client stesso. Il primo passo è di configurare la scheda di rete del client diskless. Per far ciò si faccia riferimento al manuale fornito con la scheda di rete. Alcune schede richiedono l'inserimento di ponticelli, altre hanno dei programmi di configurazione da eseguire. Dopo aver configurato l'interfaccia di rete è il caso di scriversi i parametri hardware necessari, come gli indirizzi I/O, gli indirizzi di memoria, il numero della linea interrupt o il canale DMA, visto che tali informazioni potrebbero servire più tardi nella fase di configurazione. Poi si passi nella directory netboot sul proprio sistema UNIX (quello in cui si trova questo file di documentazione) e si digiti make bootrom Così verranno compilati tutti i programmi di utilità necessari, quindi si esegua il programma di configurazione. Esso chiederà innanzitutto quale kernel di bootrom si vuole usare. Il kernel minimo è obbligatorio per le schede di rete che accettano solo fino a 16 KB di ROM; kernel86 può essere usato per l'avvio su sistemi a 16 bit (precedenti ai 386), per esempio per avviare l'MS-DOS. A meno che non si abbiano necessità particolari va scelto il kernel standard. Poi bisogna specificare il packet driver da usare con la propria scheda di rete. È possibile scegliere uno dei driver forniti o usarne uno proprio. Se si vuole usare il proprio driver bisogna dare il path completo, relativo al proprio server, del pacchetto col driver in binario e bisogna anche indicare tutte le opzioni necessarie per lanciarlo. Non si specifichino qui opzioni che portano il packet driver in modo windows o che gli permettano di lavorare per sistemi diskless; tali opzioni sono solo per bootrom di reti Novell e non sono necessarie per questa bootrom. Se si usa uno dei driver elencati il programma di configurazione chiederà tutte le informazioni sull'hardware necessarie per far girare il packet driver che si è scelto. Di solito verrà chiesto l'indirizzo I/O della scheda di rete, il suo numero di interrupt e il numero del canale DMA. Si osservi che vengono chieste solo le informazioni strettamente necessarie. Bisogna avere le specifiche della propria scheda di rete a portata di mano quando vengono chieste tali informazioni. Alcuni packet driver sono in grado di rilevare le informazioni sull'hardware in fase di esecuzione e quindi non richiederanno nessun altra informazione. Se non si è scelto il kernel minimo allora il programma di configurazione chiederà se si vuole siano inclusi dei driver addizionali. Innanzi tutto permetterà di scegliere il driver per il display ANSI, che consente di disegnare sullo schermo dei graziosi menu con il kernel della bootrom standard. Poi è possibile selezionare il programma di debugging del packet driver (è un modulo aggiuntivo che serve per tracciare problemi di rete e di solito non è necessario). Esso mostra la prima coppia di byte di tutti i pacchetti (in cui gli header UDP/IP sono codificati) passando poi al packet driver in fase di avvio del client diskless. Si selezioni questo modulo di debug solo se si riscontrano problemi durante il processo iniziale di avvio dalla rete della bootrom _e_ si sanno interpretare le informazioni degli header UDP/IP. Il programma di configurazione chiederà anche se si vogliono installare nella bootrom altri moduli aggiuntivi. Tali moduli devono essere dei programmi di tipo COM standard DOS che potrebbero, ad esempio, preimpostare la scheda di rete in uno stato particolare prima che parta il packet driver, oppure potrebbero configurare una linea seriale per supportare l'avvio tramite connessione PPP o SLIP (la raccolta di pacchetti Crynwr contiene anche un driver per pacchetti SLIP che non è fornito con questo pacchetto). Comunque si tenga presente che la dimensione totale della immagine definitiva della bootrom non può superare i 64 kB. Quando si è risposto a tutte le domande il programma di configurazione crea il kernel della bootrom con tutti i moduli scelti, poi comprime il file risultante ed aggiunge il codice di avvio della bootrom. Una volta che il programma di configurazione ha finito, si troveranno due nuovi file nella directory corrente: image.flo - questo file può essere scritto su un floppy usando dd image.rom - l'immagine da bruciare in una EPROM Bisogna ora copiare image.flo in un floppy usando dd if=image.flo of=/dev/fd0 e poi avviare il proprio client diskless usando tale floppy. Se è tutto pronto (inclusa la propria scheda di rete) si vedrà il codice della bootrom che parte, fa richiesta al server bootp e carica il file con l'immagine di avvio. Quando tutto funziona come richiesto si può andare avanti e scrivere il codice image.rom in una EPROM. Per le istruzioni su come farlo si consulti il manuale del proprio scrittore di EPROM. Di solito bisognerà convertire il file immagine in un formato speciale (ad esempio il formato esa di Intel o Motorola). Si inserisca la EPROM nello zoccolo della propria scheda di rete e si accenda il sistema diskless. Si dovrebbe veder partire la bootrom. Un altro modo di mettere il codice bootrom nel proprio client è di usare la scheda Flash-EPROM (chiamata FlashCard), di cui è possibile trovare uno schema e un modello di circuito stampato in questo pacchetto. È possibile scrivere direttamente image.rom nella FlashCard - non serve nessuna conversione in esa. Riguardo l'uso e la programmazione della FlashCard si veda la documentazione nella directory di FlashCard. Qualora si vogliano creare nuove bootrom senza dover sempre avere i sorgenti a portata di mano, è possibile installare i binari creati durante il processo di configurazione tramite il comando make bootrom_install Così si copieranno nella directory $prefisso/lib/netboot (dove $prefisso è /usr/local o il prefisso specificato nell'esecuzione del configure GNU) tutti i binari necessari per creare nuove bootrom. Il path tipico sarà /usr/local/lib/netboot. Verrà anche installato lo script makerom in $prefisso/bin; così sarà sufficiente battere makerom per creare una nuova bootrom. Appendice: Ricompilare la bootrom ================================= Se, per qualunque motivo, si vuole ricompilare la bootrom, si consulti il file INSTALL.bootrom per ottenere maggiori informazioni. Comunque non è necessario ricompilare la bootrom solo per poterla usare! 13. Appendice B - Risoluzione dei problemi R I S O L U Z I O N E D E I P R O B L E M I Se si incontra un qualsiasi problema durante l'installazione o l'uso di questo pacchetto, per favore come prima cosa si legga il seguente testo e tutta la documentazione pertinente. In particolare, se si hanno dei problemi nel configurare il server, è il caso di consultare la documentazione del server. Si faccia anche riferimento al manuale utente della propria scheda di rete o alla documentazione del sistema operativo dei client diskless. Comunque, se ancora non si riesce a risolvere il problema per conto proprio, è possibile inviarmi una email presso gero@gkminix.han.de Gli utenti che parlano tedesco possono mandarmi mail in tedesco. Altrimenti vi prego di scrivere in inglese. Ho ricevuto delle email in un inglese così penoso che non sono riuscito nemmeno a capire quale fosse il problema; in tal caso non posso essere d'aiuto. Vi prego inoltre di scusarmi, ma non posso rispondere a domande fattemi per posta normale o per telefono; semplicemente non ho il tempo per occuparmene. Se si decide di mandarmi una email, per favore si descriva il proprio problema nella maniera più precisa possibile. Di solito è utile mandare parti rilevanti dei file di configurazione (devo pagarmi da solo l'accesso ad Internet, quindi, per favore, si citi nella forma più breve possibile). Riguardo i problemi con le bootrom, di solito aiuta riportare _esattamente_ l'output dello schermo, ma anche includere qualsiasi messaggio d'errore. Inoltre si descriva nella maniera più fedele possibile come si è creato il problema, così che io possa provare a simularlo sul mio hardware. Inoltre si osservi che non posso essere d'aiuto riguardo qualsiasi problema relativo al server, visto che ci sono tantissimi sistemi diversi sul mercato. Lo stesso vale riguardo i problemi con le schede di rete; semplicemente non dispongo delle possibilità economiche per comprare tutte le schede presenti sul mercato per provarle. Personalmente uso le schede NE2000 e WD8013, quindi probabilmente posso essere d'aiuto con queste. Se trovate un problema che sembra essere un bug nel codice apprezzerei veramente che mi mandaste una nota. E se aveste anche una soluzione per quel bug apprezzerei ancor più il vostro messaggio. Oltre a contattarmi direttamente c'è anche una mailing list riguardante il boot via rete a cui ci si può iscrivere. Si scriva una mail a majordomo@baghira.han.de contenente il messaggio 'subscribe netboot' nel corpo del testo (il subject della mail non è importante). Gli iscritti alla mailing list potrebbero essere in grado di aiutarvi con qualsiasi problema doveste incontrare nel preparare un client diskless. Oltre a ciò io uso tale lista per comunicare l'uscita di ogni nuova versione del pacchetto netboot. Problema: Il mio sistema operativo OS/XY non è supportato da netboot Fornirei volentieri il supporto per tutti i sistemi operativi sul mercato, ma non ho le risorse per farlo. Tuttavia, se desiderate che un certo sistema operativo venga supportato, mettetevi in contatto con me. Dovreste comunque fornirmi una copia funzionante e provvista di licenza di quel sistema operativo. Siete anche invitati a scrivere un vostro boot loader e a mandarmelo affinché lo includa in netboot sotto i termini della GPL GNU. Problema: Provando a preparare una bootrom ottengo un errore di compilazione Gli script di installazione richiedono la compilazione di un paio di programmi di utilità che sono necessari solo durante la compilazione della bootrom. Essi vanno compilati su un sistema Unix; quindi, se ottenete un errore, per favore comunicatemelo, così che io possa includere una patch nelle prossime versioni. Problema: Ottengo un errore da make che dice qualcosa tipo "missing delimiter" Alcuni Makefile usano degli ifdef, che compilatori più vecchi non capiscono. Anche alcuni sistemi più "moderni", come lo SCO Open-Server 5, hanno tali problemi. In tal caso dovete procurarvi e installare il make GNU sul vostro sistema (che è comunque la scelta migliore). Problema: La bootrom non parte affatto O avete un floppy nel vostro lettore, oppure avete un disco rigido installato con una partizione segnata come attiva e la bootrom è stata fatta in modo tale da lasciare effettuare al BIOS la ricerca di partizioni attive all'avvio. Entrambi i casi inducono il sistema ad effettuare l'avvio dal supporto avviabile anziché dalla bootrom. Semplicemente togliete il floppy o usate fdisk per segnare tutte le partizioni come non avviabili (cioè inattive). In alternativa, potete anche preparare la bootrom in modo tale che non permetta al BIOS di cercare partizioni avviabili. Il programma che effettivamente crea la bootrom ('makerom', viene chiamato quando si lancia 'make bootrom') vi chiederà se volete farlo dopo aver selezionato l'immagine kernel della bootrom. Problema: La bootrom si comporta stranamente dopo l'avvio e può anche inchiodare l'intero sistema Se avete compilato i programmi mknbi su un sistema avente i byte in ordine big endian (come i sistemi Motorola o PPC) ciò potrebbe indicare che il programma di configurazione non è stato in grado di trovare l'ordine giusto dei byte. Potrebbe anche essere che ci sia un bug nel codice di ordinamento dei byte. Inoltre alcuni sistemi, come gli SPARC, non permettono l'accesso ai dati su indirizzi non allineati. Di solito 'configure' dovrebbe accorgersi di tali condizioni. Comunque, se 'configure' non è in grado di rilevare correttamente il tipo di sistema che state usando, correggete a mano il file config.h e riprovate. Per favore, comunicate tali condizioni ed annotate anche quale sistema avete usato per l'installazione. Problema: Il packet driver non è in grado di partire correttamente Innanzitutto controllate quale messaggio d'errore stampa il packet driver. Di solito questo problema è il risultato di una non corretta configurazione della scheda di rete, quindi controllate che usi un indirizzo I/O, una linea di interrupt e un canale DMA (se applicabile) per conto suo, e che il packet driver usi i valori giusti. Un altro problema comune con le schede ethernet che usano la memoria condivisa (come le schede WD80?3) è la sovrapposizione di tale memoria condivisa con l'area della rom usata dalla bootrom. In tal caso scegliete un diverso indirizzo di memoria condivisa. Se funziona, dovreste poi controllare di aver configurato correttamente il packet driver attraverso il programma di configurazione della bootrom. Di solito il packet driver stampa come si aspetta che sia l'hardware, così potete usare tali informazioni per controllare la vostra configurazione. Problema: La bootrom mi dice che non c'è abbastanza memoria ma ho xx megabyte installati Questo problema è un risultato del fatto che il BIOS avvia la bootrom nel modo reale del processore. La bootrom è quindi in grado di accedere solo al primo megabyte inferiore della memoria, indipendentemente da quanti ne siano installati. Inoltre 384 kB di esso sono riservati per la ROM e la memoria video, quindi restano solo 640 kB. Sfortunatamente alcuni sistemi riservano anche parte di questi 640 kB per dati interni del BIOS. Questa è chiamata area dati estesa del BIOS e si sa che è usata nella maggior parte dei sistemi PS/2. Ma anche altri BIOS usano tale area dati estesa del BIOS che è generalmente selezionabile nella configurazione del BIOS. Quindi dovreste provare a deselezionare tale caratteristica. Se ciò non è possibile allora siete sfortunati - spiacente. Problema: La bootrom non riceve una risposta bootp e si blocca stampando dei puntini Innanzi tutto bisogna controllare se bootpd gira sul proprio server o se è avviato correttamente da inetd. Poi bisogna controllare che /etc/bootptab del server sia configurato correttamente. Specialmente l'indirizzo hardware, il nome e l'indirizzo IP del client devono essere corretti. La maggior parte dei server bootp hanno la capacità di scrivere informazioni di debugging in un file di log. Usate tale capacità per controllare che il vostro server riceva veramente le richieste bootp dalla bootrom del client e che invii una risposta valida. Cercate anche i messaggi d'errore nel file di log. Anche se il proprio bootpd non scrive in un file di log distinto, potrebbe usare syslog sul vostro sistema, quindi va cercato il nome del file di log nel file di configurazione di syslogd e poi cercate gli errori al suo interno. Se potete usare un programma di tracciamento degli errori, come tcpdump, sarà possibile controllare che la bootrom invii richieste corrette e che il server stia rispondendo correttamente. In tal caso è più probabile che sia un problema nella bootrom e quindi bisogna creare una nuova immagine della bootrom con il modulo di debugging del packet driver, che è incluso. Bisognerebbe poi vedere i pacchetti di richiesta della bootrom che sono in uscita e le risposte del server in entrata. Se non ci sono pacchetti in arrivo, sebbene abbiate verificato che il server sta inviando risposte corrette, allora potrebbe esserci un problema con la vostra scheda di rete. L'avete configurata correttamente? C'è attaccato un cavo (non vi sto prendendo in giro, sono cose che succedono veramente)? Se non funziona niente provate ad avviare il client diskless col sistema operativo scelto e provate ad accedere alla scheda di rete usando gli strumenti di quel sistema operativo. Se il server non invia pacchetti di risposta ma il file di log di bootpd indica delle risposte corrette, potrebbe essere un problema di impostazione arp sul vostro server. Di solito l'arp non dovrebbe interessarvi, tuttavia alcune vecchie versioni di bootpd per Linux hanno dei problemi in tal senso che potrebbero essere risolti impostando manualmente la tabella arp. Problema: La bootrom riceve una risposta da bootp ma non riesce a caricare il file con l'immagine di boot Questo è probabilmente un problema dovuto alla configurazione di tftpd sul server. tftpd è in esecuzione quando avviate il codice della bootrom? Se no controllate che inetd sia configurato correttamente. Potrebbe anche esserci un wrapper TCP/IP che gira sul vostro server e che proibisce l'accesso al servizio tftp (che è notoriamente molto insicuro e quindi candidato per essere avviato da un wrapper per la sicurezza in Internet, come tcpd). Controllate tutti i file di configurazione d'accesso di tcpd. Inoltre tftpd deve essere in grado di accedere al file con l'immagine di avvio. Di solito, per motivi di sicurezza, gira come utente con privilegi molto modesti e potrebbe non avere il permesso per leggere il file con l'immagine di boot; quindi dovete controllare e configurare correttamente i permessi del file con l'immagine di boot. Problema: Il boot loader dell'immagine riporta un errore Congratulazioni! Avete appena scoperto un bug nel boot loader. Per favore comunicatemelo. Problema: Quando uso il menu di bootrom per caricare il sistema Unix senza il disco fisso locale, mi dà un misterioso messaggio d'errore (in particolare, SCO Unix dice che non è in grado di aprire il boot device). Tuttavia, l'avvio senza la bootrom funziona senza problemi. Alcuni sistemi operativi, in particolar modo i sistemi di tipo Unix, leggono la tabella delle partizioni dopo l'avvio e provano a trovarsi da soli la loro partizione di boot. Quando si usa la bootrom non è necessario segnare la partizione Unix come avviabile, quindi il loader di avvio di Unix fallisce. Per risolvere tale problema segnate la partizione Unix come attiva con un qualche programma fdisk. Per evitare che incominci a girare al posto della bootrom, create la bootrom in modo tale che essa non permetta al BIOS di cercare partizioni di boot sugli hard disk installati (il programma 'makerom', che parte quando lanciate 'make bootrom', vi chiederà se volete farlo dopo aver selezionato una immagine del kernel). Problema: Sto caricando Linux sul mio client diskless e il kernel mi dice di inserire un floppy di boot e di premere enter. Innanzi tutto dovete controllare di aver preparato correttamente il vostro kernel. Deve avere il supporto per il filesystem principale integrato. Se volete usare come root una directory montata via NFS il kernel deve avere il supporto TCP/IP installato. Inoltre deve avere un driver integrato per la vostra scheda di rete e NFS e NFSROOT devono essere entrambi specificati. Se usate un ramdisk il suo supporto deve essere integrato, insieme al supporto per il filesystem con cui avete formattato l'immagine del ramdisk. Prego, osservate che il kernel caricato non è in grado di usare moduli all'avvio (può farlo solo _dopo_ che il filesysem principale è stato montato, non prima), quindi tutto deve essere compilato in modo monolitico. Se il kernel non è in grado di montare la sua root via NFS, ciò potrebbe avere diverse cause. Serve che tutti gli indirizzi nel file /etc/bootptab siano corretti e che i diritti di accesso sul server siano impostati correttamente (non solo quelli in /etc/exports ma anche i permessi per la directory da montare). Se sono corretti controllate che sul server stia girando un portmapper e che abbia registrato correttamente i servizi mountd e nfsd. In genere ciò si può fare tramite il comando rpcinfo -p Notate che i servizi mostrati qui sono solo quelli il cui processo server sta realmente girando. L'output di rpcinfo dovrebbe quindi somigliare a: program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100003 2 udp 2049 nfs 100003 2 tcp 2049 nfs 100005 1 udp 663 mountd 100005 1 tcp 665 mountd Comunque i numeri di porta potrebbero essere diversi. Quando il kernel inizia a montare la directory principale NFS, esso emette il nome che quella directory ha sul server. Dovrebbe essere lo stesso di quello configurato in /etc/bootptab. Controllate che sia corretto. Se non lo è potete provare ad usare l'opzione -d di mknbi-linux per specificare esplicitamente il nome. Se il kernel riceve un errore dall'nfsd del server, stampa un numero definito concordemente al protocollo NFS. I numeri che si presentano più spesso sono: 1 - permesso di accesso alla directory negato 2 - la directory non esiste 5 - errore di I/O sul filesystem del server 13 - nfsd non riesce ad accedere alla directory 20 - il path non è una directory 63 - il path è troppo lungo Osservate che i programmi nfsd e mountd leggono solo /etc/exports all'avvio; se in seguito avete cambiato tale file dovete riavviare entrambi i demoni. In più, con nfsd nelle versioni per Linux precedenti la 2.1, incontrerete dei problemi con i file speciali, tipo i socket di dominio UNIX o i file speciali a blocchi/caratteri sulle vostre partizioni NFS. Dovreste quindi usare le versioni più recenti disponibili. Problema: Il kernel Linux monta correttamente la sua root ma non mi dà un prompt di login. 1.) Ciò potrebbe essere dovuto ad una non corretta installazione del filesystem principale (vedere il n.2, sotto). Tuttavia, è anche possibile che il vostro server abbia riportato i numeri primario e secondario errati per il dispositivo console, sebbene li abbiate specificati correttamente nella directory principale montata via NFS. So di questo problema con i server AIX e HP-UX, ma potrebbe verificarsi anche su quegli altri che non trasferiscono i device speciali, perché Linux invece ne ha bisogno. Una soluzione per risolvere questo problema è di avviare il client diskless con una immagine su ramdisk come sua root e poi montare quella che dovrebbe-essere la directory root sul server usando NFS. Poi potete creare i file speciali nella directory dev usando il programma mknod per Linux e quindi usare la root NFS montando di nuovo la bootimage. Un altro modo è di provare a scoprire in che modo il sistema operativo del server codifica i numeri primario/secondario sul suo filesystem. Per esempio, HP-UX usa numeri di dispositivo a 32 bit, con gli 8 bit più significativi che rappresentano il numero primario e i 24 bit meno significativi che rappresentano il numero secondario del device: primario << 24 | secondario ==> aaaaaaaabbbbbbbbbbbbbbbbbbbbbbbb In questa rappresentazione (a) indica un bit del numero primario e (b) un bit del numero secondario. Linux invece usa il seguente schema: primario << 8 | secondario ==> 0000000000000000aaaaaaaabbbbbbbb Ora, il protocollo NFS trasferisce questi 32 bit proprio come sono, senza nessuna interpretazione riguardo i numeri primario/ secondario. Ciò significa che tutti i bit importanti nella rappresentazione Linux entrano nel numero secondario in HP-UX. Quindi, se si crea un device sul server HP-UX, bisogna sempre dargli un numero primario zero e comporre il numero secondario nel modo suddetto per Linux. Ad esempio, per fare in modo che Linux veda un device 5/2 nella sua directory /dev (montata con NFS), bisogna comporre il numero secondario del device su HP-UX come segue: 5 << 8 | 2 ==> 1282 In tal modo il device da creare sul server HP-UX è 0/1282, di modo che Linux, una volta che il filesystem è stato montato via NFS, vedrà 5/2. 2.) Un'altra causa di questo problema potrebbe essere che il processo init non è partito affatto. Ciò potrebbe essere dovuto a delle librerie condivise in modo errato, che il client potrebbe riuscire a vedere ma senza un appropriato file ld.so.cache. Oppure le librerie condivise non sono raggiungibili affatto dal client. Bruce Janson e Markus Gutschke hanno raccolto un discreto elenco di possibilità che dovreste controllare: - non avete una copia privata delle directory /, /etc, /var, ... - nella vostra directory /dev mancano le voci /dev/zero e/o /dev/null oppure le voci dei device sono condivise con un server che usa diversi numeri primario e secondario (cioè un server su cui non sta girando Linux - vedere sopra). - nella vostra directory /lib mancano delle librerie (molto probabilmente libc* e/o libm*) oppure non ha i file loader ld*.so*. - avete trascurato di lanciare ldconfig per aggiornare /etc/ldconfig.cache oppure non avete un file di configurazione per ldconfig. - i vostri file /etc/inittab e/o /etc/rc.d/* non sono stati adattati ai client. - al vostro kernel mancano alcune fondamentali capacità che andavano scelte in fase di compilazione (tipo il supporto per filesystem NFS, il boot via rete, trans- name (opzionale), il supporto per i file ELF, il supporto per la rete, i driver per la vostra scheda ethernet). - manca l'eseguibile init (in una delle directory note al kernel: /etc, /sbin, ?) - manca /etc/inittab - manca /dev/tty? - manca /bin/sh - programmi di sistema che insistono nel voler creare/ scrivere al di fuori di /var (gli esempi tipici sono mount e /etc/mtab*). Problema: Impossibile compilare la bootrom Per favore, mettetevi in contatto con me se incontrate qualsiasi problema durante la ricompilazione della bootrom. 14. Appendice C - RFC 951 Bootstrap Protocol (BOOTP) N.d.T.: La RFC, nel documento originale, era presente solo per fini accademici, per università o istituti di ricerca; in questa traduzione non è riportata. Se interessa leggerla si faccia riferimento alla RFC originale . 15. Appendice D - RFC 1533 DHCP Options and BOOTP Vendor Extensions N.d.T.: La RFC, nel documento originale, era presente solo per fini accademici, per università o istituti di ricerca; in questa traduzione non è riportata. Se interessa leggerla si faccia riferimento alla RFC originale . 16. Appendice E - RFC 1350 The TFTP Protocol (Revision 2) N.d.T.: La RFC, nel documento originale, era presente solo per fini accademici, per università o istituti di ricerca; in questa traduzione non è riportata. Se interessa leggerla si faccia riferimento alla RFC originale . 17. Altri formati di questo documento Questo documento è pubblicato in 11 formati diversi, ossia: DVI, Postscript, Latex, Adobe Acrobat PDF, LyX, GNU-info, HTML, RTF (Rich Text Format), testo semplice, pagine di manuale Unix e SGML. · È possibile ottenere questo HOWTO come singolo archivio tar nei formati HTML, DVI, Postscript o SGML da · Il formato testo semplice è in: · Le traduzioni in altre lingue come Francese, Tedesco, Spagnolo, Cinese e Giapponese sono in . Qualsiasi aiuto da parte vostra per tradurlo in altre lingue è gradito. Questo documento è stato scritto usando gli "SGML tools" che possono essere ottenuti da: . Compilando i sorgenti otterrete dei comandi come: · sgml2html CVS-HOWTO.sgml (per generare file html) · sgml2rtf CVS-HOWTO.sgml (per generare file RTF) · sgml2latex CVS-HOWTO.sgml (per generare file latex) I documenti LaTeX possono essere convertiti in file PDF semplicemente generando una versione in Postscript usando sgml2latex (e dvips) e poi rielaborando il risultato col comando distill di Acrobat, come mostrato sotto: ______________________________________________________________________ bash$ man sgml2latex bash$ sgml2latex nomefile.sgml bash$ man dvips bash$ dvips -o nomefile.ps nomefile.dvi bash$ distill nomefile.ps bash$ man ghostscript bash$ man ps2pdf bash$ ps2pdf input.ps output.pdf bash$ acroread output.pdf & ______________________________________________________________________ Oppure si può usare il comando ps2pdf di Ghostscript. ps2pdf emula quasi tutte le funzionalità del prodotto Acrobat Distiller della Adobe: converte i file PostScript in file Portable Document Format (PDF). ps2pdf è realizzato tramite un brevissimo script (un file batch) che invoca Ghostscript selezionando uno speciale "output device" chiamato pdfwrite. Per poter usare ps2pdf, il device pdfwrite deve essere stato incluso nel makefile quando Ghostscript è stato com­ pilato. Per i dettagli vedere la documentazione sulla compilazione di Ghostscript. Questo documento si trova presso: · È possibile trovare questo documento anche presso i seguenti siti mirror: · · · · · Altri siti mirror più vicini (dal punto di vista dell'indirizzo di rete) possono essere trovati presso . Scegliere un sito ed andare direttamente nella directory /LDP/HOWTO/CVS-HOWTO.html Per poter vedere il documento in formato dvi si usi il programma xdvi. Il programma xdvi si trova nel pacchetto tetex-xdvi*.rpm del Linux RedHat che può essere rintracciato attraverso i pulsanti di menu ControlPanel | Applications | Publishing | TeX. Per leggere il documento dvi usare il comando: xdvi -geometry 80x90 howto.dvi man xdvi e ridimensionare la finestra col mouse. Per navigare usare i tasti freccia, Pag Su, Pag Giù; è possibile usare anche i tasti 'f', 'd', 'u', 'c', 'l', 'r', 'p' e 'n' per muoversi su, giù, centro, pagina successiva, pagina precedente, ecc. Per eliminare il menu expert pre­ mere 'x'. È possibile leggere i file postscript usando il programma 'gv' (ghostview) o 'ghostscript'. Il programma ghostscript è nel pacchetto ghostscript*.rpm e il programma gv è in quello gv*.rpm di Linux Redhat; possono essere rintracciati attraverso i pulsanti di menu ControlPanel | Applications | Graphics. Il programma gv è molto più amichevole di ghostscript. Ghostscript e gv sono disponibili anche per altre piattaforme come OS/2, Windows 95 e NT, questo documento è visibile anche su tali piattaforme. · Ghostscript per Windows 95, OS/2 e per tutti i sistemi operativi è disponibile presso Per leggere il documento postscript usare il comando: gv howto.ps ghostscript howto.ps È possibile leggere il documento in formato HTML usando i browser Netscape Navigator, Microsoft Internet explorer, Redhat Baron Web o uno qualsiasi degli altri 10 web browser. È possibile leggere il formato latex, l'output di LyX, usando LyX, un front-end di X-Windows per latex. .