  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
  <http://www.vmware.com> 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  <http://www.uk.research.att.com/vnc>.


    Linux Systems Labs Inc., USA  <http://www.lsl.com> Si selezioni
     "Shop On-line" e poi "HardWare" e verranno elencati tutti i
     computer diskless. Telefono: 1-888-LINUX-88.


    Diskless Workstations Corporation, USA
     <http://www.disklessworkstations.com>


    Unique Systems of Holland Inc., Ohio, USA  <http://www.uniqsys.com>

  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 <http://www.vmware.com> con Linux che
  pu ospitare Windows 95/98/NT.  Linux sar il SO "ospitante" e Windows
  95/NT sar il SO "ospitato".  VMWare <http://www.vmware.com> 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 <http://www.vmware.com> i computer Linux diskless pos
  sono far girare sia programmi Linux che MS Windows 95.  Il sito VMWare
   su  <http://www.vmware.com>.

  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
  <http://www.uk.research.att.com/vnc>

  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:

    <http://www.ltsp.org>


    <http://www.disklessworkstations.com>


    <http://www.slug.org.au/etherboot>


    <http://metalab.unc.edu/Linux/HOWTO/XFree86-Video-Timings-
     HOWTO.html>

     Argomenti correlati che vale la pena vedere:

    NCD X-terminal  <http://www.linuxdoc.org/HOWTO/mini/NCD-X-
     Terminal.html>

  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
     <http://dir.yahoo.com/Business_and_Economy/Companies/Computers/Hardware/Peripherals/Device_Programmers/>


    Advanced Research Technology B.V <http://www.artbv.nl/ > -
     sviluppo, produzione e vendita di strumenti di programmazione
     elettronica; sviluppo di hardware e software.

    Advin Systems Inc. <http://www.advin.com > - dispositivi
     programmatori basati su PC che supportano i tipi di package e le
     teconologie dei dispositivi pi recenti.

    Andromeda Research Labs <http://www.arlabs.com > - produce un
     sistema portatile per la programmazione di eprom e dispositivi.

    B and C Microsystems, Inc <http://www.bcmicro.com/> - offre
     strumenti di verifica e duplicazione/programmazione di schede
     PCMCIA (PC), schede ISA/PCI, SIMM, memorie (incluse le FLASH), PLD.

    BP Microsystems <http://www.bpmicro.com/ > - programmatori di
     dispositivi.

    Bytek <http://www.bytek.com > - 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 <http://www.logicaldevices.com/ > -
     offre un ampio spettro di soluzioni per la programmazione dei
     dispositivi.

    Dataman Programmmers Ltd. <http://www.dataman.com/ > - produce
     programmatori/emulatori hand-help di EPROM. Vende anche
     programmatori basati su PC e programmatori Gang-Pro.

    General Device Instruments <http://www.generaldevice.com/ > -
     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. <http://hilosystems.com.tw > -
     produttore di programmatori universali e gang.

    ICE Technology <http://www.icetech.com/ > - programmatori EPROM e
     di dispositivi universali che supportano memorie, microcontrollori
     e dispositivi logici programmabili.

    Iceprom <http://www.inabyte.com/iceprom.html > - memorie a sola
     lettura programmabili e cancellabili in-circuit.

    Incept Ltd. <http://www.incept.ie >

    International Microsystems Inc <http://www.imtest.com > -
     Programmatori gang affidabili ad elevata velocit (PROM, FLASH,
     microcontrollori, schede di memoria PCMCIA).

    JED Microprocessors Pty. Ltd. <http://www.jedmicro.com.au > -
     inseritelo in una porta D25 per stampante e programmate qualsiasi
     dispositivo FLASH ed EPROM a 28 o 32 pin.

    Logical Devices, Inc <http://www.logicaldevices.com > - dispositivi
     di programmazione di PLD, FPGA, PROM, microcontrollori. Produttore
     di compilatori CUPL per logiche programmabili e dei programmatori
     ALLPRO e Chipmaster.

    MCL Systems <http://www.mcl.dk > - 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 <http://www.mqp.com > - produttore di programmatori
     di dispositivi universali, programmatori gang, software di
     produzione e convertitori di package. Elevata efficenza ed
     affidabilit.

    Needham's Electronics <http://www.quiknet.com/~needhams/ > -
     produttore di programmatori di dispositivi.

    NP Programming Services <http://www.npps.com/ > - fornisce
     programmazione di memorie e parti logiche.

    Program Automation, Inc. <http://www.progauto.com > - compagnia di
     servizio indipendente specializzata nella programmazione di grossi
     volumi di PROM, inclusi CI flash.

    Stag Programmers Inc <http://www.stagusa.com > - produttore di
     programmatori prom e logici, produzione di strumenti di
     manipolazione e cancellatori UV.

    Sunrise Electronics <http://www.sunriseelectronics.com > -
     programmatori di dispositivi universali, programmatori gang e in-
     circuit con supporto a vita.

    System General Co. <http://www.sg.com.tw > - programmatori di
     dispositivi, scrittori di EPROM e tester di CI.

    Tribal Microsystems <http://www.tribalmicro.com > - programmatori
     di dispositivi gang e universali, emulatori di EPROM e 8051,
     zoccoli per il burn-in e per la produzione.

    Universal Device Programmers <http://www.xeltek.com/ >




  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  <http://www.slug.org.au/etherboot/> e

  2. NETBOOT  <http://www.han.de/~gero/netboot.html>

  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 <http://www.ltsp.org>

  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  <http://www.ltsp.org>.
  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 <id del processo inetd>
  ______________________________________________________________________



  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:
  <http://www.slug.org.au/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/<indirizzo IP del DC> (nella 2.1 e
  precedenti: /tftpboot/<nome del DC in bootptab>) 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 <<EOF
  Ora, in /tftpboot/$1/etc, editare

                  sysconfig/network
                  sysconfig/network-scripts/ifcfg-eth0
                  fstab
                  conf.modules

  e configurare

                  rc.d/rc3.d
  EOF
  ______________________________________________________________________



  Ecco uno script illustrativo per duplicare il filesystem root:












  ______________________________________________________________________
  #!/bin/sh
  if [ $# != 2 ]
  then
          echo Usage: $0 olddir newdir
          exit 1
  fi

  cd /tftpboot

  if [ ! -d $1 ]
  then
          echo $1 is not a directory
          exit 1
  fi

  umask 022

  mkdir -p $2

  # facciamo cos
  for d in home mnt proc tmp usr
  do
          mkdir $2/$d
  done

  chmod 1777 $2/tmp

  touch $2/fastboot
  chattr +i $2/fastboot

  # linkiamo questi
  for d in bin lib sbin
  do
          (cd $1; find $d -print | cpio -pl ../$2)
  done

  # copiamo questi
  for d in dev etc root var
  do
          cp -a $1/$d $2
  done

  cat <<EOF
  Ora, in /tftpboot/$2/etc, editare

          sysconfig/network
          sysconfig/network-scripts/ifcfg-eth0
          fstab (forse)
          conf.modules (forse)

  e configurare

          rc.d/rc3.d
  EOF
  ______________________________________________________________________



  6.7.  X-terminal

  Sul server, ci si assicuri che il DC corrisponda ad un'apposita voce
  in /etc/X11/xdm/Xaccess e si commenti il :0 in /etc/X11/xdm/Xservers.
  Poi ci si assicuri che xdm venga eseguito dagli script di init.


  Sul client, eseguire X -query server

  Si otterr la finestra di login di xdm, dopo di che tutti i propri
  client X gireranno sul server.

  Riguardo l'uso di altre applicazioni, si potrebbe usare la tecnica
  diskless per router netboot, server di stampa (ma non devono essere
  server di stampa in spooling), applicazioni standalone, ecc.

  7.  PROM LanWorks BootWare

  Questa informazione pu far risparmiare del tempo.  Per fare in modo
  che le PROM LanWorks BootWare(tm) facciano partire correttamente
  un'immagine del kernel Linux, la parte "bootsector" dell'immagine deve
  essere modificata in modo tale da permettere alle prom di boot di
  saltare dritto all'indirizzo iniziale dell'immagine.  Il formato
  dell'immagine avviabile via rete creato dal programma `mknbi-linux' di
  netboot/etherboot  diverso e non girer se usato con le PROM
  BootWare.

  Un bootsector modificato ed un Makefile utili per creare un'immagine
  avviabile da BootWare, fatta la compilazione del kernel, pu essere
  trovata presso:

    Il pacchetto Bwimage
     <ftp://ftp.ipp.mpg.de/pub/ipp/wls/linux/bwimage-0.1.tgz>

    Vedere anche <http://www.patoche.org/LTT/net/00000096.html>

    ROM di boot LanWorks BootWare <http://www.3com.com/lanworks>

  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
  <http://www.slug.org.au/etherboot/>.  Questo documento spiega come
  installare, configurare e usare il pacchetto Etherboot.

  9.  Netboot

  Netboot  stato scritto da Zurck zu Gero. Il sito principale 
  <http://www.han.de/~gero/netboot.html>.

  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
  <http://www.han.de/~gero/netboot/english/spec.html>.


  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
  <http://www.han.de/~gero/netboot/archive/maillist.html>


    I driver 3com sono presso
     <http://support.3com.com/infodeli/tools/nic>

    I driver Accton sono qui
     <http://www.accton.com/accton/drivers/adapter.html>

    Artisoft <http://www.artisoft.com>

    CNET <http://www.cnet.com.tw>

    Compaq <http://www.compaq.com/support/networking>

    D-Link <http://www.dlink.com>

    Microdyne <http://www.mcdy.com/marketin/prodman/prodcat.htm>

    Parecchie schede PCI NE2000 sono basate sui chipset Realtek.  Si
     prendano i driver qui
     <http://www.realtek.com.tw/cn/driver/driver.htm>

    Standard Microsystems Corp <http://www.smc.com/support.html>

    Surecom <http://www.sure-com.net>

    Thomas Conrad corp
     <http://www.compaq.com/support/networking/OutOfProduction.html>

    Winbond <http://www.winbond.com.tw>

    Xircom <http://www.xircom.com>

    La pagina Webopaedia <http://www.sandybay.com/pc-
     web/network_interface_card_NIC.htm> sulle schede di rete.

    La pagina dei driver
     <http://www.evitech.fi/~jarnomn/files/drivers/net_d.html> di Jargon
     con parecchi driver per le vecchie schede di rete.

    Etherboot <http://www.slug.org.au/etherboot/>.  Questo  un
     progetto simile al Netboot ma basato sul codice bootrom BSD.

    Come tirar fuori un Terminale X Window
     <http://www.menet.umn.edu/~kaszeta/unix/xterminal/index.html> dal
     vostro vecchio o antiquato PC.

    Elenco delle impostazioni dei ponticelli
     <http://www.slug.org.au/NIC/index.html> per varie schede di rete.
     Questa pagina contiene anche parecchi altri buoni link.

    Freefire <http://sites.inka.de/lina/freefire-l/tools.html>  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
     <http://metalab.unc.edu/LDP/HOWTO/Diskless-root-NFS-HOWTO.html>

    Linux goodies  <http://www.aldev.8m.com> o
     <http://www.aldev.webjump.com>

  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-<os>,
              ove <os> 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 <http://sunsite.unc.edu/LDP/HOWTO/Diskless-HOWTO-15.html>.

  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 <http://sunsite.unc.edu/LDP/HOWTO/Diskless-HOWTO-16.html>.

  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 <http://sunsite.unc.edu/LDP/HOWTO/Diskless-HOWTO-17.html>.

  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
     <ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/other-formats/>

    Il formato testo semplice  in:
     <ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO>

    Le traduzioni in altre lingue come Francese, Tedesco, Spagnolo,
     Cinese e Giapponese sono in
     <ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO>.  Qualsiasi aiuto da
     parte vostra per tradurlo in altre lingue  gradito.

     Questo documento  stato scritto usando gli "SGML tools" che
     possono essere ottenuti da: <http://www.sgmltools.org>.  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:

    <http://sunsite.unc.edu/LDP/HOWTO/CVS-HOWTO.html>

   possibile trovare questo documento anche presso i seguenti siti
  mirror:

    <http://www.caldera.com/LDP/HOWTO/CVS-HOWTO.html>


    <http://www.WGS.com/LDP/HOWTO/CVS-HOWTO.html>

    <http://www.cc.gatech.edu/linux/LDP/HOWTO/CVS-HOWTO.html>

    <http://www.redhat.com/linux-info/ldp/HOWTO/CVS-HOWTO.html>

    Altri siti mirror pi vicini (dal punto di vista dell'indirizzo di
     rete) possono essere trovati presso
     <http://sunsite.unc.edu/LDP/hmirrors.html>.  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  <http://www.cs.wisc.edu/~ghost>

  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.







