Figura 2-1. Installazione di LTSP - Schermata principale
<
jam@LTSP.org>
Copyright © 2004 James A. McQuillan
| Diario delle Revisioni | ||
|---|---|---|
| Revisione 4.1.3-en | 2004-06-20 | Revisionato da: jam |
| Revisione 4.1.3-0-it | 2005-03-09 | Revisionato da: af |
| Revisione 4.1.3-0c-it | 2005-03-21 | Revisionato da: eag |
| Revisione 4.1.3-0d-it | 2005-03-22 | Revisionato da: af |
| Revisione 4.1.3-0e-it | 2005-03-23 | Revisionato da: cp |
| Revisione 4.1.3-0f-it | 2005-04-18 | Revisionato da: af |
Il sistema GNU/Linux è una piattaforma ideale per sviluppare una rete leggera di terminali utilizzando computer privi di disco fisso (thin clients). Lo scopo principale di questo documento è di mostrare come installare ed utilizzare questi clients usando LTSP. Inoltre questo documento descrive molte delle problematiche che si incontrano con client senza disco fisso in generale.
Il progetto LTSP fornisce un modo semplice per (ri)utilizzare dei computer a basso costo come terminali, sia in modo grafico che in modo testo, collegandoli ad un server GNU/Linux.
In una tipica situazione d'ufficio su ogni scrivania vengono normalmente utilizzati computer abbastanza potenti, basati su processori Intel o compatibili, ognuno con molti gigabytes di spazio su disco fisso. Ciascun utente memorizza i propri dati sul disco rigido presente nel computer e molto raramente vengono effettuati dei backup.
Ha veramente un senso avere un computer completo su ciascuna scrivania?
Secondo noi no. Possiamo migliorare questa situazione.
. Fortunatamente c'è un'alternativa. Utilizzando LTSP, si possono usare anche PC piuttosto datati o comunque di scarse prestazioni. Basta, eventualmente rimuovere, il disco rigido, il floppy ed il CDRom, ed aggiungere una scheda di rete con supporto per il boot da rete. La maggior parte delle schede di rete ha un alloggio ove inserire una ROM che permette il boot da rete.
Durante la fase di accensione (la fase di boot), il computer senza dischi ottiene le informazioni necessarie per far funzionare la rete (come il proprio numero IP) ed il kernel Linux (la parte fondamentale di questo sistema operativo) dal server, quindi accede ai dischi (monta il root filesystem) tramite il servizio NFS.
Il computer della postazione di lavoro (workstation) può essere configurato nei 3 modi sotto descritti:
Si utilizza X Windows. La workstation può essere usata per accedere a qualsiasi applicazione presente sul server o su altri server eventualmente presenti all'interno della stessa rete.
La workstation può instaurare una o più sessioni telnet con il server. Ogni sessione telnet viene collocata in uno schermo virtuale separato. Sono possibili più sessioni in contemporanea fino ad un massimo di 9 sessioni. Premendo i tasti da Alt-F1 a Alt-F9 sarà possibile passare da una sessione ad un'altra.
La workstation può essere configurata in modo da fornire direttamente e semplicemente una linea di comando (la bash shell) sulla console. Questo può essere molto utile in alcuni casi, ad esempio quando è necessario, in fase di configurazione correggere eventuali problemi che possono insorgere con il sistema X Window o con il collegamento NFS.
La cosa veramente interessante è che si possono avere una gran quantità di workstation (terminali) serviti da un solo server con sistema GNU/Linux. Quante potranno essere le workstation (i terminali)? Quante possano essere dipende dalla dimensione e dalle capacità del server e da quali e quante applicazioni verranno usate nello stesso momento.
Non è raro avere 50 workstations, tutte con Mozilla e OpenOffice aperti, utilizzando un server con due processori P4-2.4 con 4GB di ram. Sappiamo che questa configurazione funziona egregiamente ed il carico medio raramente va al di sopra 1.0!
Né l'autore né il distributore né il traduttore di questo documento e neppure qualsiasi persona che ad esso abbia contribuito, potrà essere ritenuta in qualche modo responsabile per qualsiasi danno fisico, finanziario, morale o di qualsiasi altro tipo che possa verificarsi seguendo i suggerimenti presenti in questo testo.
Questo documento è coperto da copyright dall'anno 2004 da parte di James McQuillan, e viene fornito (rilasciato) sotto i termini della Licenza denominata GNU Free Documentation License, che è qui sotto inclusa per riferimento.
Tutti i marchi citati sono proprietà dei rispettivi proprietari.
Far partire (fargli fare il boot) un computer da usare come terminale (workstation) che sia senza dischi richiede un certo numero di passi. La comprensione di cosa accade nei vari passi del procedimento, renderà più facile risolvere eventuali problemi, nel caso dovessero insorgere.
Ci sono quattro servizi di base che sono necessari per far partire una workstation (un terminale) con LTSP. Questi sono:
Il sistema LTSP è molto flessibile. Ognuno dei servizi qui sopra elencati può essere fornito dallo stesso server o da più server. Negli esempi descriveremo il caso di una semplice configurazione in cui c'è un solo server, che fornisce tutti i servizi qui sopra elencati.
Ognuno dei suddetti metodi per l'avvio sarà spiegato di seguito in questo capitolo.
Il file di swap verrà attivato utilizzando il comando swapon.
Questo causerà l'esecuzione di alcune istruzioni elencate nel file /etc/inittab.
Si possono inserire ulteriori sessioni nel file inittab, se lo si desidera.
Nel file lts.conf c'è un parametro chiamato XSERVER. Se questo parametro manca o ha il valore " auto", allora verrà fatto un rivelamento automatico della scheda video. Se la scheda video di tipo PCI o AGP, allora i codici PCI Vendor e Device Id verranno letti e verrà fatta una ricerca nel file /etc/vidlist.
Se la scheda video è supportata da Xorg 6.7 la routine pci_scan ritornerà il nome del modulo del driver. Se è supportata soltanto da XFree86 3.3.6, pci_scan ritornerà il nome del server X che deve essere utilizzato. Lo script startx riconosce la differenza perché i nomi dei vecchi server di XFree 3.3.6 iniziano per 'XF86_', mentre i nomi dei nuovi moduli di X di Xorg sono tipicamente dei nomi scritti in minuscolo, come, ad esempio,ati o trident.
Il file di configurazione XF86Config sarà creato in base ai parametri presenti nel file /etc/lts.conf.
Questo causerà un po' di confusione agli inizi. Mentre si è seduti davanti alla workstation si avrà una sessione che è eseguita sul server. Tutti i comandi verranno eseguiti sul server, ma l'output sarà mostrato sullo schermo della workstation.
Il caricamento del kernel Linux dentro la memoria della workstation può essere ottenuto in più modi.
Etherboot è un progetto open-source molto popolare per il bootrom (boot da rom). Contiene i driver per molte delle schede di rete più comuni e funziona molto bene con LTSP.
Il kernel linux deve contenere il tag mknbi-linux , che fa preparare il kernel per poter fare il boot da rete facendo eseguire prima del kernel del codice aggiuntivo e, una volta caricato ed eseguito il kernel, facendo utilizzare initrd. Il kernel linux deve contenere il tag mknbi-linux, che fa preparare il kernel per poter fare il boot da rete, premettendo al kernel una parte di codice aggiuntivo e collegando (lo script o il demone) initrd alla fine del kernel.
I kernel che vengono forniti con LTSP hanno già questo tag e sono pronti per fare il boot con Etherboot.
Etherboot può essere anche scritto su di un floppy. Questa cosa è molto comoda per fare dei test.
La parte delle specifiche del 'Wired for Management' della fine del 1990 includono una specifica per la tecnologia del bootrom conosciuta come Pre-boot Execution Environment e comunemente abbreviata in PXE.
Un bootrom PXE può caricare al massimo un file di 32 kB. Un kernel Linux è molto più grande di questa dimensione. Pertanto dobbiamo configurare PXE per far sì che, come secondo passo, caricato un boot-loader chiamato pxelinux. Pxelinux è sufficientemente piccolo da poter essere caricato ed è a conoscenza di come caricare file più grandi, come il kernel Linux.
Managed Boot Agent (MBA) è un bootrom della società emBoot . emBoot era la divisione Lanworks della 3Com. MBA in realtà è quattro bootrom in uno. Può gestire PXE, TCP/IP. RPL e Netware.
L'implementazione MBA di PXE funziona molto bene. Può essere utilizzato con pxelinux per far fare il boot di un kernel Linux.
Anche il metodo TCP/IP può essere utilizzato, ma il kernel deve prima essere preparato con un'utility chiamata imggen.
Netboot, come Etherboot, è un progetto software gratuito che fornisce immagini per il boot ROM gratuite. La differenza è che un wrapper del drive NDIS o al driver di pacchetti che viene spedito con la scheda di rete
Ci sono due metodi per far effettuare il boot ad una workstation LTSP con un floppy. Il primo metodo consiste nel copiare l'Etherboot nel boot sector del floppy. Quindi tutto funziona come nel caso del bootrom. Il codice letto dal boot record del floppy viene eseguito, la scheda di rete viene inizializzata e il kernel viene caricato in memoria dal server via rete.
L'altro metodo consiste nello scrivere il kernel e l'initrd sul floppy e fare il boot dal floppy. Tuttavia è estremamente più veloce caricare il boot dalla rete.
Si utilizza LILO o GRUB per caricare dal disco fisso il kernel Linux e l'initrd. Oppure si può caricare l'immagine Etherboot bootrom dal disco fisso e agire come nel caso del bootrom.
Un disco CD-ROM con capacità di boot può essere caricato in memoria. Anche qui si può caricare l'intero kernel e l'initrd oppure l'immagine Etherboot.
Esattamente come nel caso si un CD-ROM, di un disco floppy o di un disco fisso si può usare un dispositivo di memoria USB per far fare il boot. Anche qui si può caricare direttamente il kernel Linux e l'initrd oppure si può caricare il modulo Etherboot.
La cosa migliore è pensare a LTSP come ad una distribuzione completa di Linux, che si aggiunge ad una distribuzione normlmente utilizzata per installare linux su un computer. La distribuzione host può essere quella che preferite. In realtà non c'è neppure alcuna reale motivo per cui il server debba aver il sistema operativo Linux. L'unico requisito necessario è che il sistema operativo del server sia in grado di fornire i servizi NFS (Network File System). La maggior parte dei sistemi operativi Unix è in grado di fornire questo servizio. In effetti anche alcune versioni di Microsoft Windows possono essere configurate per funzionare come server LTSP.
L'implementazione di un server LTSP avviene in tre passi.
Dalla versione 4.1 in poi, LTSP è dotata di un insieme di utility per l'installazione e la gestione dei pacchetti client di LTSP. (I programmi che sono eseguiti dai clienti leggeri) e per configurare i servizi sul server LTSP.
Lo strumento per l'amministrazione si chiama ltspadmin e lo strumento per la configurazione si chiama ltspcfg. Entrambi questi strumenti fanno parte del pacchetto ltsp-utils.
Il pacchetto ltsp-utils è disponibile sia nel formato RPM sia in quello TGZ Scegliete quello che preferite o che è migliore per voi e seguite le relative istruzioni .
Fate il download dell'ultima versione del pacchetto RPM delle ltsp-utils ed installatelo con il comando seguente:
rpm -ivh ltsp-utils-0.1-0.noarch.rpm |
Fate il download dell'ultima versione del pacchetto TGZ delle ltsp-utilitis ed installatelo con i comandi seguenti:
tar xzf ltsp-utils-0.1-0.noarch.tgz cd ltsp_utils ./install.sh cd .. |
Una volta che è stata completata l'istallazione del pacchetto ltsp-utils, si ha a disposizione il comando ltspadmin. Questa utility permette di gestire i pacchetti del client LTSP. L'utility svolge il compito di interrogare il deposito per i download di LTSP e di ottenere l'elenco dei pacchetti attualmente disponibili.
Lanciate il comando ltspadmin e vedrete una schermata come quella riportata qui:
Da questa schermata potete scegliere "Install/Update" (Installa/Aggiorna). Se è la prima volta che si utilizza questa utility verrà mostrata la schermata di configurazione del programma d'installazione, come mostrato nella seguente figura.
nella schermata di configurazione si possono impostare alcuni parametri che saranno utilizzati dal programma d'installazioe per fare il download dei pacchetti LTSP e per installarli. Questi parametri sono:
(Da dove prelevare i pacchetti) Specifica l'URL del deposito dei pacchetti. Tipicamente sarà http://www.ltsp.org/ltsp-4.1. Tuttavia nel caso in cui si voglia installare i pacchetti da un supporto locale (come un disco fisso o un CD), si può utilizzare una URL che inizi per file: . Ad esempio se i pacchetti sono su un CD-ROM e questo CD_ROM è stato montato sotto la directory /mnt/cdrom, allora il valore per questa opzione sarà: file:///mnt/cdrom. (Fate attenzione devono esserci tre barre dopo i due punti).
(In quale directory volete mettere i file e le sottodirectory del client LTSP). Questa è la direcotry sul server dove volete che saranno messi i file e le sotto directory del client LTSP. Tipicamente sarà: /opt/ltsp. La directory specificata, se non esiste di già, verrà creata automaticamente.
A partire da questa directory verranno create una directory principale per ciascuna delle architetture supportate. Attualmente soltanto l'architettura x86 è ufficialmente supportata da LTSP, ma ci sono diverse persone che stanno lavorando a dei porting verso altre architetture (cioè stanno lavorando a rendere i programmi funzionanti anche su altre architetture), come ad esempio PPC e Sparc.
(Proxy per le connessioni HTTP) se il server è protetto da un firewall e se le connessioni al web devono passare dal proxy, questo parametro permette di configurare il programma d'installazione per poter utilizzare il proxy. Il valore da inserire deve contenere la URL del proxy, compreso di protocollo e numero di porta, come ad esempio: http://firewall.yourdomain.com:3128 .
Se non c'è alcun proxy o non è necessario utilizzarlo, questo parametro deve essere impostato a "none".
(Proxy per le connessioni FTP) Se i pacchetti sono collocati su un server FTP ed è necessario passare attraverso un proxy FTP, questo parametro permette di specificare le necessarie informazioni. La sintassi è simile al caso del Proxy per la connessione HTTP.
Se non c'è alcun proxy o non è necessario utilizzarlo, questo parametro deve essere impostato a "none".
Una volta inserito le necessarie informazioni nella schermata di configurazione, il programma d'installazione farà una richiesta a chi contiene i pacchetti e otterrà la lista dei componenti al momento disponibili.
Figura 2-3. Installazione di LTSP - Lista dei componenti
Potete selezionare i componenti uno ad uno. Per selezionare un componente, muovete la barra evidenziata sulla riga del componente voluto e premete il tasto 'I'. Per selezionare tutti i componenti basta premere il tasto 'A'. Nella maggior parte dei casi probabilmente è questa la cosa da fare. In questo modo potete supportare la più vasta gamma di hardware come client.Ci sono alcuni tasti che possono essere utilizzati per spostarsi all'interno dello schermo. Per ottenere una schermata d'aiuto potete premere il tasto 'H'.
Se volete vedere la lista dei pacchetti che sono presenti in un certo componente, premete il tasto 'S', e verrà mostrata la lista dei pacchetti. Verrà indicata la versione attualmente installata e l'ultima versione disponibile.
Una volta terminata la selezione, uscite dalla schermata di selezione dei componenti, premenro il tasto 'S'. Il programma vi chiederà se volete realmente installare o aggiornare i pacchetti selezionati. Rispondete premendo il tasto ' Y' per fare iniziare il download e l'installazione dei pacchetti selezionati.
I servizi principali necessari per permettere l'avvio (il boot) delle workstation LTSP sono i quattro qui sotto elencati:
Il programma ltspcfg permette di configurare tutti e quattro questi servizi. Inoltre permette di configurare molti altri parametri necessari a LTSP.
Si può accedere a ltspcfg da ltspadmin, oppure può essere lanciato da riga di comando digitando ltspcfg.
Una volta lanciato il programma ltspcofg, verrà fatta una scansione (un'analisi) del server per accertarsi di cosa sia installato sul server e quali programmi siano in esecuzione. Verrà visualizzata una schermata del tipo:
Figura 2-6. ltspcfg - Schermata iniziale
Questa schermata mostra tutto ciò che è stato cercato dal programma.Per configurare i parametri di configurazione premete il tasto ' C'. Verrà mostrato il menù di configurazione Dal menù di configurazione dovete controllare sotto ogni voce che tutti i parametri siano correttamente configurati per servire le workstation LTSP.
Figura 2-7. ltspcfg - Schermata dei servizi
La variabile Runlevel viene usata dal programma init. Nei sistemi operativi Linux ed Unix il sistema può essere in uno specifico "Runlevel" tra più possibili Runlevel. I Runlevel 2 e 3 in genere sono utilizzati per avere il server in modalità testo. Il Runlevel 5 rende il sistema in modalità grafica.
Normalmente, per un server LTSP, si utilizza il Runlevel 5. La maggior parte dei servizi sono già configurati per rispondere alle le richieste NFS e XDMCP quando il sistema è in Runlevel 5. Se un programma non è già configurato per questo, verrà configurato in tale modo da questa utilità.
(selezione dell'interfaccia) Nel caso di sistemi con più di un'interfaccia (scheda) di rete, bisogna specificare su quale interfaccia sono collegati i client Thin (i terminali).
Il programma di configurazione, una volta nota quale sia l'interfaccia da utilizzare, creerà gli altri file di configurazione in modo opportuno. Tra i quali i file dhcpd.conf e /etc/exports.
(Configurazione del DHCP) Il sistema DHCP deve essere configurato per poter fornire le necessarie informazioni alle workstation. I parametri necessari sono fixed-address, filename, subnet-mask, broadcast-address e root-path.
Utilizzando questo menù il programma sarà in grado di creare il file di configurazione dhcpd.conf e il programma dhcpd verrà attivato all'avvio del server.
(Configurazione del TFTP) Il servizio TFTP viene utilizzato dalle workstation (client) per fare il download del kernel linux. Per far sì che il kernel possa essere fornito in questo modo il servizio tftpd deve essere attivato sul server.
(Configurazione della mappa delle porte) Il Portmapper è utilizzato dai servizi RPC, quali ad esempio NFS.
(Configurazione di NFS) Il servizio NFS permette di far fare il mount di directory locali da parte di computer remoti. Nella configurazione LTSP è necessario che questo servizio sia attivo sul server per permettere alle workstation di fare il mount del proprio root filesystem dal server.
Questo menù permette di configurare l'avvio di NFS all'avvio del server. I dettagli sul file di configurazione /etc/exports e sulla sua creazione vengono dati più avanti in questa sezione.
(Configurazione del XDMCP) XDMCP è l'abbreviazione di "X Display Manager Control Protocol" (Protocollo di Controllo e Gestione di Diplay X). Il server X invia una richiesta al programma di gestione (manager) del server per ottenere un finestra grafica di login.
I display manager di uso più comune sono XDM, GDM e KDM. Questo menù mostra i display manager disponibili e indica quale è stato selezionato.
Per ragioni di sicurezza, il Display Manager è configurato di default (come impostazione predefinita) per rifiutare le connessioni remote delle workstation. Questa è, in genere, la causa del comune problema di vedere soltanto una schermata nera con una cursore a forma di X. Il programma ltspcfg può essere utilizzato, in genere, per configurare il display manager in modo da consentire la connessione da parte di workstation (terminali) remoti.
(Creare delle linee di riferimento all'interno del file /etc/hosts) Molti servizi, tra cui NFS e il Display manager, hanno bisogno di avere una mappa di corrispondenza tra gli indirizzi IP della workstation e il nome del computer (hostname). Si può utilizzare e configurare , a questo scopo, il Berkeley Intenet Naming Daemon (BIND),ma bisogna essere certi che il sistema reverses (per il riconoscimento a ritroso) sia configurato in modo corretto. Probabilmente utilizzare bind è il miglior modo per ottenere lo scopo, tuttavia la spiegazione della configurazione di bind è al di là degli scopi di questa documentazione e del programma ltspcfg.
Un metodo più semplice per configurare la mappa di corrispondenza tra gli indirizzi IP e i nomi dei computer (hostname) è quello di utilizzare il file /etc/hosts.
(Creare delle linee di riferimenteo nel file /etc/hosts.allow) Alcuni servizi usano un sistema di sicurezza chiamato tcpwrappers. Questo sistema viene configurato tramite il file /etc/hosts.allow. Questo menù permette di configurare questo file.
(Creare il file /etc/exports) Questo è il file utilizzato da NFS, per determinare quali sono le directory che è consentito che vengano montate da una macchina remota. Questo menù permette di creare e configurare questo file.
(Creare il file lts.conf) La configurazione di ogni singola workstation viene stabilita da delle linee del file lts.conf. Se si utilizzano workstation recenti con il bus PCI, non dovrebbe essere necessario inserire alcuna linea aggiuntiva al file lts.conf file. Tuttavia è necessario che questo file esista. Questo menù creerà un file lts.conf con delle configurazione preimpostate (default).
A questo punto è necessario fornire al server LTSP le informazioni specifiche di ogni singola workstation. Ci sono tre file che contengono le informazioni specifiche delle singole workstation.
La workstation ha bisogno di un indirizzo IP e di altre informazioni. Riceverà le seguenti informazioni dal server DHCP:
Nella configurazione mostrata in esempio abbiamo scelto che l'indirizzo IP sia gestito dal server DHCP, che lo assegna alle workstation.
Durante l'esecuzione dello script ltsp_initialize, viene installato un file dhcpd.conf di esempio. Potete copiare il file /etc/dhcpd.conf.example come file /etc/dhcpd.conf ed usarlo come base per la vostra configurazione del dhcp. Bisogna modificare questo file per adattarlo alle specifico ambiente in cui sono presenti le workstation e il server.
default-lease-time 21600;
max-lease-time 21600;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.0.255;
option routers 192.168.0.254;
option domain-name-servers 192.168.0.254;
option domain-name "ltsp.org";
option root-path "192.168.0.254:/opt/ltsp/i386";
shared-network WORKSTATIONS {
subnet 192.168.0.0 netmask 255.255.255.0 {
}
}
group {
use-host-decl-names on;
option log-servers 192.168.0.254;
host ws001 {
hardware ethernet 00:E0:18:E0:04:82;
fixed-address 192.168.0.1;
filename "/lts/vmlinuz.ltsp";
}
}
|
Figura 2-8. /etc/dhcpd.conf
A partire dalla vesione 2.09pre2 di LTSP, non c'è più bisogno di specificare quale particolare kernel caricare in memoria. Il pacchetto standard del kernel supporta tutte le schede di rete supportate da Linux. Nel pacchetto del kernel distribuito da LTSP ci sono due file per il kernel. Uno che ha applicata la Linux Progress Patch (LPP) e l'altro che non le ha. I nomi di questi file sono
vmlinuz-2.4.9-ltsp-5 vmlinuz-2.4.9-ltsp-lpp-5 |
Probabilmente avete notato che questi file del kernel risiedono nella directory /tftpboot/lts, ma nella punto dove inserire il nome del file ("filename") nel file /etc/dhcpd.conf manca la parte iniziale del nome del path, /tftpboot . Questo è dovuto al fatto che a partire dalla versione 7.1 di Red Hat TFTP viene eseguito con l'opzione '-s'. Questo fa sì che il demone tftpd viene eseguito in modalità sicura. Pertanto viene eseguito all'avvio un chroot alla directory /tftpboot. Pertanto tutti i file accessibili al demone tftpd sono relativi alla directory /tftpboot.
Altre distribuzioni di Linux potrebbero non avere l'opzione '-s' impostata per tftpd. In questo caso dovete aggiungere il prefisso /tftpboot al nome del path del kernel.
Mappa tra gli indirizzi IP address e il nome del computer (hostname)
I computer utilizzano normalmente soltanto l'indirizzo IP per comunicare. Tuttavia noi umani abbiamo bisogno di dare dei nomi ai computer perché è troppo difficile ricordare tutti i numeri. Da qui entra in gioco la necessità di usare DNS o il file /etc/hosts. Questa mappa di corrispondenza tra gli indirizzi IP e il nome dei computer (hostname) di solito non è necessaria. Tuttavia è necessario nel caso di un ambiente LTSP, perché se non ci fosse il sistema NFS darebbe dei permessi erronei quando una workstation tenta di montare il filesystem principale.
Oltre ai problemi con NFS, se la workstation non è compresa nel file /etc/hosts, potrebbero esserci problemi con i display manager GDM o KDM.
Nel file lts.conf ci sono parecchie voci che possono configurate.
Il file lts.conf ha una sintassi semplice. C'è una sezione di default (per i valori predefiniti) chiamata [default] e poi possono esserci delle sezioni per ciascuna singola workstation. La workstation può essere identificata dal nome del computer (hostname), dall'indirizzo IP oppure dal MAC-address.
Un tipico file lts.conf è mostrato qui sotto:
#
# Config file for the Linux Terminal Server Project (www.ltsp.org)
#
[Default]
SERVER = 192.168.0.254
XSERVER = auto
X_MOUSE_PROTOCOL = "PS/2"
X_MOUSE_DEVICE = "/dev/psaux"
X_MOUSE_RESOLUTION = 400
X_MOUSE_BUTTONS = 3
USE_XFS = N
LOCAL_APPS = N
RUNLEVEL = 5
[ws001]
USE_NFS_SWAP = Y
SWAPFILE_SIZE = 48m
RUNLEVEL = 5
[ws002]
XSERVER = XF86_SVGA
LOCAL_APPS = N
USE_NFS_SWAP = Y
SWAPFILE_SIZE = 64m
RUNLEVEL = 3
|
Esempio 2-1. lts.conf file
La seguente è una lesta di alcune voci:
Se la vostra scheda video è PCI e è supportata da X.org 6.7.0, allora avete bisogno soltanto del pacchetto lts_x_core package, che contiene tutti i moduli driver per X4.
Ci sono parecchi pacchetti per XFree86 3.3.6 disponibili per LTSP. Questo nel caso in cui la vostra scheda video non sia supportata da X.org 6.7.0.
Potete mettere una linea di configurazione nel file lts.conf per ogni workstation oppure potete metterne una nella sezione default, che verrà condivisa da tutte le workstation.
La nostra workstation, usata nell'esempio, ha una scheda video con chipset Intel i810 video e viene correttamente rivelata dal rivelamento automatico. Pertanto non abbiamo bisogno di una linea di configurazione XSERVER nel file lts.conf file. La linea di configurazione XSERVER può essere specificata, se volete, oppure può essere posta ad 'auto' per indicare che deve essere effettuato l'autodetect.
Se vogliamo utilizzare la workstation n modalità grafica dobbiamo indicare come Runlevel il valore '5'. Questo viene fatto con l'apposita linea di configurazione del file lts.conf.
Con il programma ltspcfg, si può guardare lo stato corrente dei tutti i servizi necessari con LTSP. Dal menù principale (main menu) di ltspcfg premendo il tasto ' S' viene mostrato lo stato corrente.
Una volta configurato il server è arrivato il momento di configurare la workstation.
Il progetto LTSP copre tutto quello che succede dopo che il kernel è caricato in memoria. Ci sono diversi metodi per caricare il kernel in memoria. Tra questi ci sono: Etherboot, Netboot, PXE e disco floppy.
Se la vostra scheda di rete ha il supporto PXE o se lo ha il vostro computer, potete usarlo per caricare il kernel Linux. PXE è una tecnologia bootrom, simile a Etherboot or Netboot.
Potreste essere in grado di utilizzare il bootrom PXE sulla vostra scheda di rete. Bisogna cambiare il settaggio nel BIOS per far sì che il "Boot from LAN" sia la prima scelta tra i metodi di boot, invece di "floppy" o "hard disk".
Il sistema PXE ha la limitazione di essere in grado di caricare soltanto file che siano non più grandi di 32 kB. Il kernel di LInux è parecchio più grande. Pertanto non è possibile caricare direttamente il kernel Linux con PXE. Bisogna caricare qualcosa come un 'Network Bootstrap Program' o NBP.
Uno degli NBP disponibili per caricare il kernel Linux chiamato pxelinux.0. Fa parte del pacchetto syslinux per il kernel sviluppato da H. Peter Anvin.
Il pacchetto del kernel fornito con LTSP comprende lo NBP pxelinux.0 e i file di configurazione necessari per caricare il kernel Linux sul disco ram iniziale.
Il funzionamento avviene in questo modo:
Questo è un esempio di un file di configurazione per pxelinux:
prompt=0
label linux
kernel bzImage-2.4.24-ltsp-4
append init=/linuxrc rw root=/dev/ram0 initrd=initrd-2.4.24-ltsp-4.gz
|
|
Etherboot è un programma software che permette di creare immagini ROM che possono essere downlodate sulla scheda Ethernet per essere eseguita da un computer x86. Molte schede di rete hanno un'alloggio in cui può essere collocato un chip ROM. Il codice Etherboot può essere collocato in questo chip ROM. | ||
| -- Ken Yap | ||
Etherboot è disponibile come Open Source, con la licenza GNU General Public License, Version 2 (GPL2).
Per usare Etherboot, se avete una scheda Ethernet cone il bootrom Etherboot, avete bisogno di cambiare la configurazione del BIOS per dirgli di fare l'avvio dalla LAN ("Boot from LAN") prima di tentare di fare il boot dai dischi floppy o dall'harddisk.
Se non avete un bootrom Etherboot potete o fare un bootrom o potete fare un disco floppy con l'immagine di Etherboot nel suo boot sector.
Etherboot supporta un numero molto grande di schede di rete. Più di 200 modelli, e di nuovi ne vengono continuamene aggiunti Sia che decidiate di fare un dico floppy sia che mettiate il codice nel chip Eprom, avrete bisogno di conoscere il modello di scheda di rete che avete.
Per le vecchie schede di rete di tipo ISA non è così tanto importante determinare il tipo di scheda. Per prima cosa la maggior parte di queste schede sono schede ne2000 oppure 3Com 3c509. Vi basta prendere il driver Etherboot giusto, quello che utilizza il giusto sistema di collegamento a seconda della vostra scheda tra il 10 base-2 (Coax, per il cavo coassiale) e il 10 base-T (Twisted pair, per il cavo con i fili intrecciati).
Con le schede di rete PCI è essenziale che sia scelto il driver Etherboot che combaci con il numeri PCI Vendor e Device ID della scheda di rete.
Alcune volte può andarvi bene e conoscete esattamente quale sia il modello della vostra scheda perché c'è scritto sulla scheda e corrisponde esattamente alla descrizione di uno dei moduli di Etherboot. Tuttavia in molti casi dovrete ottenere i numeri di identificazione PCI.
se la vostra workstation) ha un disco floppy potete fare il boot con un disco tomsrtbt (Tom's Root Boot). Altrimenti se la vostra workstation ha un lettore di CD-ROM potete fare il boot con un disco Knoppix. Se non siete in grado di caricare il kernel Linux sulla vostra workstation allora la vostra unica speranza è quella di spostare la scheda di rete su un computer che riesca a fare il boot.
Una volta che avete avviato Linux, potete usare il comando lspci con l'opzione '-n'
[root@jamlap root]# lspci -n
0000:00:00.0 Class 0600: 8086:7190 (rev 03)
0000:00:01.0 Class 0604: 8086:7191 (rev 03)
0000:00:03.0 Class 0607: 104c:ac1c (rev 01)
0000:00:03.1 Class 0607: 104c:ac1c (rev 01)
0000:00:07.0 Class 0680: 8086:7110 (rev 02)
0000:00:07.1 Class 0101: 8086:7111 (rev 01)
0000:00:07.2 Class 0c03: 8086:7112 (rev 01)
0000:00:07.3 Class 0680: 8086:7113 (rev 03)
0000:00:08.0 Class 0401: 125d:1978 (rev 10)
0000:01:00.0 Class 0300: 1002:4c4d (rev 64)
0000:06:00.0 Class 0200: 8086:1229 (rev 09)
|
[root@jamlap root]# lspci -n | grep "Class 0200"
0000:06:00.0 Class 0200: 8086:1229 (rev 09)
|
Potete prelevare il pacchetto Etherboot package e configurarlo per il tipo di bootrom di cui avete bisogno. Quindi compilate il sorgente per produrre un immagine del bootrom che può essere scritta in EPROM oppure su un disco floppy.
Una soluzione più semplice è andare sul sito web www.Rom-O-Matic.net di Marty Connor.
Marty ha fatto un eccellente lavoro mettendo in piedi un'interfaccia per il web per la configurazione e la compilazione necessaria per creare un immagine bootrom con Etherboot. Sul suo sito, selezionate il tipo di scheda di rete che avete, e che tipo si immagine volete. Inoltre avete la possibilità di modificare alcune opzioni di configurazine del Etherboot. A questo punto premete il pulsante 'Get ROM' (ottieni ROM) e una immagine personalizzata del bootrom verrà generata in breve tempo.
Per avere il formato per il chip ROM scegliete 'Floppy Bootable ROM Image'. Questa scelta aggiunge un header di 512 byte che fa sì che il boot loader venga caricato in memoria da dove poi viene eseguito.
Dopo alcuni secondi che avete premuto il bottone, il vostro browser farà comparire una finestra pop-up "Save As" (o "Salva con nome") in cui sceglierete il nome con cui salvare il file sul vostro computer.
Una volta che avete salvata l'immagine sul vostro disco fisso dovete scriverla sul vostro floppy. Inserite il disco floppy nel vostro lettore di floppy e date il seguente comando per scrivere sul floppy:
dd if=Etherboot_Image of=/dev/fd0 |
Per scrivere l'immagine sulla eprom serve un sistema per la programmazione di EPROM. Questo strumento hardware ha un costo che varia, a seconda dei modelli, da poche centinaia di dollari a parecchie migliaia di dollari (da poche centinaia di euro a parecchie migliaia di euro)
Le modalità da seguire per creare il bootrom dipende completamente da sistema di programmazione di EPROM. Questo va al di là dello scopo di questa documentazione.
Se il server e la workstation sono configurati in modo corretto basterà inserire il disco floppy di boot e accendere il computer workstation.
Il codice Etherboot sarà letto dal floppy e messo in memoria, la scheda di rete viene identificata e inizializzata, viene inviata la richiesta dhcp attraverso la rete e la risposta sarà inviata dal server e il kernel sarà scaricato nella workstation. Quando il kernel avrà inizializzato l'hardware della workstation, partirà X windows e apparirà sullo schermo della workstation la schermata di login, come nell'esempio qui sotto.
Figura 4-1. Schermata di Login
A questo punto puoi loggarti. Un punto importante da tenere bene a mente è che entri e ti loggi sul server. Tutti i comandi che eseguti vengono in realtà eseguiti sul server e mostrano l'output sulla workstation. Qesta è la forza, di X Windows.
Puoi eseguire qualsiasi programma che è supportato dal server.
Un computer così collegato oltre ad essere una workstation con una funzionalità completa in modalità GUI (grafica) o in modialità a caratteri, può servire anche da server di stampa. Fino a 3 stampanti possono essere attaccate alla porte parallele e seriali.
Tutto questo in maniera completamente trasparente per l'utente della workstation. Non si noterà neppure la piccola quantità di traffico che va dalla workstation alla stampante.
LTSP usa il programma lp_server sulla workstation (terminale) per reindirizzare i lavori di stampa dal server alla stampante attaccata ad una delle porte della workstation (terminale).
Alcune linee del file di configurazione lts.conf permettono di abilitare le stampati sulla workstation.
[ws001]
PRINTER_0_DEVICE = /dev/lp0
PRINTER_0_TYPE = P
|
Sono disponibili molte ozoioni. Maggiori informazioni per la configurazione delle stampanti sono disponibili nella sezione di spiegazione del file di configurazione lts.conf.
La configurazione della parte del server riguarda la definizione delle code di stampa (print queue), utilizzando lo strumento di configurazione delle stampanti sul server.
Nella distribuzione Red Hat 7.2 sono presenti strumenti di configurazioni delle stampa sia grafici che in modalità caratteri. Lo strumento grafico (GUI) si chiama printconf-gui, e quello in modalità testo si chiama printconf-tui . Versioni precedenti di Red Hat hanno un programma che si chiama printtool. Il programma printtool c'è anche in Red Hat 7.2, ma lancerà printconf-gui. Le altre distribuzione di Linux dispongono di un proprio strumento per la configurazione delle stampanti printer configuration tool.
Figura 5-1. Aggiungere una nuova stampante con printconf-gui
Dopo aver lanciato lo strumento di configurazione delle stampanti bisogna aggiungere una nuova stampante,. Il programma lp_server permette alla workstation (terminale) di emulare un server di stampa HP JetDirect print server. Basta che create una stampante JetDirect.
Dovete dare un nome alla coda di stampa. Il nome può essere qualsiasi cosa, ma risulta più utile dare un nome che abbia un significato. Il nome della coda di stampa può contenere soltanto i seguenti caratteri:
Il nome della coda di stampa scelto nell'esempio di sopra è ws001_lp. Un nome di questo genere rende facile ricordarsi che è attaccata alla workstation (terminale) ws001.
Figura 5-2. Dettagli Informazioni di Printconf-gui
Vi sono due campi da configurare necessariamente per poter comunicare con la stampante:
La prima stampante connessa alla workstation (terminale) sarà sulla porta TCP/IP 9100. La seconda stampante sarà sulla porta 9101, e la terza sulla porta 9102.
Una caratteristica che è stata affinata nella versione 4.0 di LTSP è quella denominata Screen Scripts (Script per le sessioni dello schermo). Questi script permettono di far partire sessioni di diverso tipo.
Si può specificare più di uno screen script per una workstation. In questo modo si ottengono delle sessioni multiple. Possono essere sessioni di diverso tipo o sessioni dello stesso tipo. Per esempio è possibile specificare nel seguente modo:
SCREEN_01 = startx
SCREEN_02 = shell
|
Si possono specificare fino a 12 screen script per workstation. Tuttavia nella maggior parte dei casi basta averne uno solo.
I possibili tipi di screen scripts sono:
Questo script lancerà il server X con l'opzione -query. Con questa opzione verrà fatta una richiesta XDCPM al display manager del server per ottenere una schermata di login sullo schermo.
Questo script lancerà una finestra shell sul terminale. Questo serve principalmente per risolvere eventuali problemi con la workstation. Fornisce una sessione sul sulla workstation e non sul server. Pertanto non è utile per eseguire delle applicazioni.
Questo script lancia una sessione telnet che si connetterà al server dando una sessione in modalità carattere con il server.
Di default telnet si connetterà al server LTSP. Se volete indicare un server differente, potete passare il suo nome sulla stessa linea del nome del screen script. Per esempio:
SCREEN_01 = telnet server2.mydomain.com |
Questo script lancerà il programma rdesktop,che si collegherà ad un server Microsoft Window server. Sulla linea è possibile specificare, dopo il nome dello screen script, qualsiasi opzione rdesktop. Per esempio, se si vuole specificare il server a cui connettersi, si può fare nel seguente modo:
SCREEN_01 = rdesktop -f w2k.mydomain.com |
I file che contengono gli screen script risiedono nella directory /opt/ltsp/i386/etc/screen.d Potete anche creare il vostro script personalizzato e collocarlo in questa directory. La cosa migliore, in questo caso, è partire da uno script già esistente ed usarlo come esempio.
Se, dopo aver seguito quanto descritto nei capitoli precedenti, la vostra workstation non si avvia allora dovete seguire il processo per la risoluzione degli errori (trubleshooting) dell'installazione. Cioè dovete seguire i passi qui sotto descritti.
La prima cosa da fare è determinare fino a che punto del procedimento d'avvio è riuscita ad arrivare la workstation.
Quando parte il boot dal floppy dovrebbe apparire qualcosa del tipo:
loaded ROM segment 0x0800 length 0x4000 reloc 0x9400 Etherboot 5.0.1 (GPL) Tagged ELF for [LANCE/PCI] Found AMD Lance/PCI at 0x1000, ROM address 0x0000 Probing...[LANCE/PCI] PCnet/PCI-II 79C970A base 0x1000, addr 00:50:56:81:00:01 Searching for server (DHCP)... <sleep> |
L'esempio riportato qui sopra mostra cosa dovreste aspettarvi di vedere quando avviene il boot da floppy. Se non viengono visualizzati questi messaggi, che indicano che è partito l'Etherboot, allora probabilmente il dischetto floppy è sbagliato: o il dischetto floppy è danneggiato o l'immagine non è stata scritta sul floppy in modo corretto.
Se viene visualizzato un messaggio del tipo riportato qui sotto, allora probabilmente vuol dire che l'immagine che è stata generata non è quella adatta per la vostra scheda di rete.
ROM segment 0x0800 length 0x8000 reloc 0x9400 Etherboot 5.0.2 (GPL) Tagged ELF for [Tulip] Probing...[Tulip]No adapter found <sleep><abort> |
Se arriva al punto in cui rivela la scheda di rete e mostra il corretto MAC address, allora il dischetto floppy è probabilmente corretto e funzionante.
Dopo che la scheda è stata inizializzata, viene inviato una richiesta DHCP in broadcasting sulla rete locale, per trovare il server DHCP.
Se la workstation riceve una risposta valida dal server DHCP, allora significa che la scheda di rete è stata configurata correttamente. Potete rendervi conto che tutto, fino a qui, è andato bene dal fatto che sullo schermo vengano visualizzate le informazioni sull'indirizzo IP . Qui sotto è riportato ad esempio cosa potrebbe apparire:
ROM segment 0x0800 length 0x4000 reloc 0x9400 Etherboot 5.0.1 (GPL) Tagged ELF for [LANCE/PCI] Found AMD Lance/PCI at 0x1000, ROM address 0x0000 Probing...[LANCE/PCI] PCnet/PCI-II 79C970A base 0x1000, addr 00:50:56:81:00:01 Searching for server (DHCP)... <sleep>Me: 192.168.0.1, Server: 192.168.0.254, Gateway 192.168.0.254 |
Se invece appare il seguente messaggio sulla workstation, seguito da tanti messaggi <sleep>, allora c'è qualcosa che non va. Tuttavia è possibile che appaiono uno o due messaggi <sleep> e dopo la risposta del DHCP in questo caso la situazione è normale.
Searching for server (DHCP)... |
Scoprire dove sia l'errore può essere, a volte, difficile. Ecco alcune cose da controllare.
La workstation è fisicamente connessa alla stessa rete cui è connesso il server?
Quando la workstation viene accesa, controllate che si accendano le luci del link su tutte le connessioni.
Se la connessione è diretta dalla workstation al server (senza passare da hub o switch) accertatevi che state utilizzando un cavo cross-over. Se state passando da un hub o da uno switch, allora accertatevi che state utilizzando un cavo dritto (chiamato anche patch cable) sia dalla workstation all'hub che dall'hub al server.
Bisogna determinare si il sistema dhcpd sia in funzione sul server. Questo può essere determinato in diversi modi.
Il programma dhcpd normalmente diventa demone in background e alcolta la porta udp numero 67. Provate a eseguire il comando netstat e guardate se c'è qualcosa in ascolto su quella porta. Dando il comando:
netstat -an | grep ":67 " |
udp 0 0 0.0.0.0:67 0.0.0.0:* |
Tuttavia il fatto che netstat mostri che c'è qualcosa che sta ascoltando la porta udp numero 67 non vuol dire che sia sicuramente dhcpd ad ascoltare. Potrebbe essere bootpd, ma è poco probabile perché bootp non è più presente nella maggior parte delle distribuzioni Linux.
Per accertarvi che dhcpd sia in esecuzione, provate a eseguire il comando ps.
ps aux | grep dhcpd |
root 23814 0.0 0.3 1676 820 ? S 15:13 0:00 /usr/sbin/dhcpd root 23834 0.0 0.2 1552 600 pts/0 S 15:52 0:00 grep dhcp |
Se non vedete alcuna riga che ostra che dhcp è in esecuzione dovete controllare che il server sia configurato per il runlevel 5 e che il sistema è configurato in modo che dhcpd venga avviato quando il sistema è in runlevel 5. Sui sistemi basati su Red Hat potete usare ntsysv per controllare questa cosa.
Potete tentare di avviare il dhcpd con questo comando:
service dhcpd start |
Il file /etc/dhcpd.conf ha una linea per la workstation in esame?
Dovete fare un controllo incrociato del indirizzo fisso (fix-address) nel file di configurazione per accertarsi che corrisponda alla workstation.
Usate il seguente comando e guardate cosa vi dice:
ipchains -L -v |
Chain input (policy ACCEPT: 229714 packets, 115477216 bytes): Chain forward (policy ACCEPT: 10 packets, 1794 bytes): Chain output (policy ACCEPT: 188978 packets, 66087385 bytes): |
Usate il seguente comando e guardate cosa vi dice:
iptables -L -v |
Chain INPUT (policy ACCEPT 18148 packets, 2623K bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 17721 packets, 2732K bytes) pkts bytes target prot opt in out source destination |
Provate a guardare il file /var/log/messages mentre la workstaion si sta avviando. Potete utilizzar il seguente comando:
tail -f /var/log/messages |
server dhcpd: DHCPDISCOVER from 00:50:56:81:00:01 via eth0 server dhcpd: no free leases on subnet WORKSTATIONS server dhcpd: DHCPDISCOVER from 00:50:56:81:00:01 via eth0 server dhcpd: no free leases on subnet WORKSTATIONS |
Etherboot usa il TFTP per prelevare il kernel Linux dal server. Il TFTP è un protocollo relativamente semplice, ma ogni tanto è possibile che ci si imbatta in qualche problema nel farlo funzionare.
Se vedete un messaggio simile a questo:
Loading 192.168.0.254:/lts/vmlinuz-2.4.24-ltsp-4......... |
Se invece non compaiono i puntini, allora c'è qulache problema. Tra le possibilità da considerare ci sono:
Se tftpd non è configurato in modo che venga eseguito allora certamente non sarà in grado di rispondere alle richieste della workstation. Controllate se è in esecuzione con netstat usando un comando del tipo:
[root@bigdog]# netstat -anp | grep ":69 "
udp 0 0 0.0.0.0:69 0.0.0.0:* 453/inetd
|
Vi sono due metodi per avviare tftpd, Sono inetd e il più moderno xinetd
inetd usa un file di a configurazione chiamato /etc/inetd.conf. Accertatevi che in questo file la riga che fa partire tftpd NON sia commentata. la linea dovrebbe essere qualcosa di simile a:
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd -s /tftpboot
|
xinetd usa una directorycon contiene dei file individuali di configurazione. Ciascun file per ogni servizio. Se il vostro server utilizza xinetd, allora il file di configurazione per ftpd si chiama /etc/xinetd.d/tftp. Qui sotto c'è un esempio di come può essere questo file:
service tftp
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot
}
|
Il kernel deve essere in un posto a cui il demone tftpd possa accedere. Se l'opzione '-s' è stata specificata per il demone tftpd, allora qualunque cosa la workstation richieda deve essere richiesta relativamente alla directory /tftpboot . Pertanto, se il parametro filename nel file /etc/dhcpd.conf ha il valore /lts/vmlinuz-2.4.24-ltsp-4, il kernel dovrà in realtà essere /tftpboot/lts/vmlinuz-2.4.24-ltsp-4
Ci sono parecchie motivi per cui potrebbero essere la causa per cui non riesca a montare il filesystem principale. Tra queste:
Se ricevete il seguente messaggio d'errore:
Kernel panic: No init found. Try passing init= option to kernel. |
Se ricevete il seguente messaggio d'errore:
Root-NFS: Server returned error -13 while mounting /opt/ltsp/i386 |
Controllate il file /var/log/messages per vedere se riuscite a scoprire qualcosa. Una linea del tipo:
Jul 20 00:28:39 bigdog rpc.mountd: refused mount request from ws004
for /opt/ltsp/i386 (/): no export entry
|
Risolvere i problemi di NFS può rivelarsi una cosa complicata. Comprendere come dovrebbe essere il setup e quali sono gli strumenti utili a dignosticare il problema renderà sicuramente le cose più facili.
Ci sono tre demoni che devono essere in esecuzione sul server perché NFS funzioni correttamente. portmap, nfsd e mountd.
Se vedete dei messaggi del tipo:
Looking up port of RPC 100003/2 on 192.168.0.254 portmap: server 192.168.0.254 not responding, timed out Root-NFS: Unable to get nfsd port number from server, using default Looking up port of RPC 100005/2 on 192.168.0.254 portmap: server 192.168.0.254 not responding, timed out Root-NFS: Unable to get mountd port number from server, using default mount: server 192.168.0.254 not responding, timed out Root-NFS: Server returned error -5 while mounting /opt/ltsp/i386 VFS: unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device "nfs" or 02:00 Please append a correct "root=" boot option Kernel panic: VFS: Unable to mount root fs on 02:00 |
ps -e | grep portmap |
30455 ? 00:00:00 portmap |
netstat -an | grep ":111 " |
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN udp 0 0 0.0.0.0:111 0.0.0.0:* |
Potete avviare portmap con il comando:
/etc/rc.d/init.d/portmap start |
NFS ha 2 daemoni che sevono essere in funzione: nfsd e mountd. Entrambi vengono fatti partire dallo script /etc/rc.d/init.d/nfs.
Potete utilizzare il comando ps per accertarvi che siano in esecuzione.
ps -e | grep nfs ps -e | grep mountd |
Normalmente dovreste essere in grado di far eseguire lo script di avvio con il parametro restart che dovrebbe farli ripartire tutte e due. Tuttavia lo script /etc/rc.d/init.d/nfs, per qualche oscura ragione, non riavvia nfsd, bensì riavvia solo mountd (forse questo è un bug). Pertanto dovete dare questi due comandi in sequenza:
/etc/rc.d/init.d/nfs stop /etc/rc.d/init.d/nfs start |
Se entrambi i due demoni sono in funzione ma NFS continua a non funzionare potete controllare che si siano registrati a portmap utilizzando il comando rpcinfo
rpcinfo -p localhost |
program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100021 1 udp 32771 nlockmgr 100021 3 udp 32771 nlockmgr 100021 4 udp 32771 nlockmgr 100005 1 udp 648 mountd 100005 1 tcp 651 mountd 100005 2 udp 648 mountd 100005 2 tcp 651 mountd 100005 3 udp 648 mountd 100005 3 tcp 651 mountd 100024 1 udp 750 status 100024 1 tcp 753 status |
Beh ... Probabilmente è la parte più difficile della configurazione della workstation LTSP è proprio riuscire ad avere il server X configurato correttamente. Se sate usando una scheda video abbastanza recente ed è supportata da Xservers di Xorg e avete un monitor abbastanza recente, che possa utilizzare un vasto numero di possibili frequenza, allora il lavoro dovrebbe essere abbastanza semplice. Nel caso in cui non funzioni in genere è molto probabile che sia dovuto al fatto che si sta usando lo X server non adatto al tipo di scheda video.
Scoprire se il server X non funziona è relativamente semplice: in questo caso o non partirà neppure o quanto mostrato sullo schermo non è corretto.
Quando la workstation è pronta per far partire il server X chiama lo script startx, che avvia il sever X sulla workstation locale, con il parametro -query che punta al server, su cui deve essere in funzione un display manager come XDM, GDM o KDM.
Poiché il server X è avviato dallo script startx che a sua volta è avviato dal programma init, quando fallisce il programma init tenterà nuovamente di lanciarlo. init continuerà questa procedura (loop) di provare a lanciare il server X 10 volte e poi deciderà di abbandonare perché pensa che stia avvenendo un respawning troppo velocemente. Alla fine di tutto questo un messaggio di errore del server X dovrebbe essere rimasto sullo schermo.
Aspettare che il server X fallisca per 10 volte è abbastanza frustrante. Un modo per evitare questa attesa è di avviare la workstation in runlevel 3 in modo che il server X NON venga avviato automaticamente. Quando avviate la workstation in questo modo otterrete un prompt della shell bash. Dal prompt della shell bash potrete avviare il server X manualmente con il comando:
sh /tmp/start_ws |
Il display manager è il demone che è in esecuzione sul server in attesa che un server X lo contatti. Quando viene effettuato un contatto apre una finestra di login sullo schermo, dando la possibilità all'utente di loggarsi sul server.
I tre più comuni display manager sono:
Se siete in questa situazione significa che il server X è in esecuzione ma che non è stato in grado di contattare il display manager. Alcuni possibili motivi sono:
Nelle versioni recenti di Redhat (dalla 7.0 in poi), il display manager viene fatto partire da init. Nel file /etc/inittab c'è una riga del tipo:
x:5:respawn:/etc/X11/prefdm -nodaemon |
Quale sia il display manager di default dipende da quali pacchetti siano stati installati. Se è stato installato Gnome allora il display manager di default è GDM. Se GDM non è stato installato allora prefdm controllerà se è stato installato KDE, nel qual caso il display manager di default sarà KDM. Se non è stato installato neanche KDE allora il display manager di default sarà XDM.
Potete usare il comando netstatper vedere se c'è un windows manager in funzione. Sul server date il seguente comando:
netstat -ap | grep xdmcp |
udp 0 0 *:xdmcp *:* 1493/gdm |
Se vedete una linea simile a quella mostrata sopra, che indica chiaramente che c'è un display manager in ascolto, allora rimane da accertarsi se la workstation stia inviando correttamente la richiesta XDMCP al giusto server.
All'interno del file lts.conf può esserci un parametro che specifica l'indirizzo IP del server su cui c'è il display manager. Le linee con questi parametri sono opzionali, ma se presenti devono essere di questo tipo:
XDM_SERVER = 192.168.0.254 |
Se il parametro 'XDM_SERVER' non è presente allora sarà usato il valore presente nel parametro 'SERVER'. se presente. Se non presente allora sarà usato 192.168.0.254.
Dovete accertarvi che l'indirizzo IP, indipendentemente da come sia specificato, sia realmente l'indirizzo IP corretto del server su cui è in funzione il display manager.
Se avete scoperto che il display manager è in funzione, allora è possibile che sia stato configurato per ignorare le richieste XDMCP provenienti da computer remoti. Occorre controllare il file di configarizione dello specifico display manager che è in funzione per verificare che sia configurato in maniera opportuna.
La configurazione di default di XDM nella distribuzione Red Hat è quella di disabilitare la possibilità che una workstation remota ottenga il login. Lo script ltsp_initialize dovrebbe fare in modo di abilitare queste connessioni. Potrebbe però essere che questo non funzioni. Se non funziona dovete controllare il fie /etc/X11/xdm/xdm-config. Controlalte che ci sia una linea del tipo:
DisplayManager.requestPort: 0 |
Un altro file di configurazione importante a riguardo dei login remoti con XDM è il file /etc/X11/xdm/Xaccess . In questo file DEVE esserci una linea che inizi con un asterisco '*'. Questa linea è normalmente presente nel file, ma nelle ditribuzioni Red Hat è commentata. Lo scirpt ltsp_initialize dovrebbe aver sistemato questa situazione. Tuttavia se dovesse continuare a sembrare che XDM non funziona dovete controllare questo file. Una linea valida deve essere di questo tipo:
* #any host can get a login window |
Le nuove versioni di KDM hanno un file chiamato kdmrc. Le diverse distribuzioni di Linux collocano questo file in diversi punti. Nel caso di Red Hat 7.2 è in /etc/kde/kdm/kdmrc. Per trovare dove sia in altre distribuzioni utilizzate il comando locate.
C'è una sessione, che si chiama [Xdmcp], che controlla se una workstation remota possa ottenere la login. Assicuratevi che il parametro Enable sia impostato a true.
Le versioni più vecchie di KDM usano il file di configurazione di XDM che è collocato in /etc/X11/xdm.
GDM usa un gruppo di file di configurazione. Sono collocati nella directory /etc/X11/gdm.
Il file principale da guardare è il file gdm.conf. Guardate la sezione [xdmcp]. Dovrebbe esserci un parametro, all'interno di questa sezione, chiamato 'Enable'. Questo parametro deve essere impostato a '1' o a 'true' a seconda delle versioni di GDM. Qui sotto è riportato un esempio:
[xdmcp] Enable=true HonorIndirect=0 MaxPending=4 MaxPendingIndirect=4 MaxSessions=16 MaxWait=30 MaxWaitIndirect=30 Port=177 |
Notate la linea 'Enable=true'. Le versioni più vecchi utilizzano '0' e '1' per indicare Disable e Enable delle connessioni remote XDMCP. Le versioni più moderne utilizzano 'false' e 'true'.
Ci sono alcune decisioni da prendere a riguardo del kernel che si vuole far girare sulla workstation. Potete decidere di utilizzare un versione standard del kernel, disponibile per il download, oppure di costruirne uno voi stessi. E dovete decidere se volete visualizzare le schermate grafiche, complete con la barra di progressione, cosa possibile grazie al Linux Progress Patch (LPP).
Il pacchetto del kernel fornito con LTSP contiene in realtà due kernel. Una con la Linux Progress Patch già applicata e configurata, e l'altra che non ha questa patch applicata.
Entrambi i kernel hanno la patch NFS Swap applicata.
Ci sono due modi di configurare un kernel per LTSP. Il metodo usuale è quello di utilizzare un 'Disco Ram Iniziale' o initrd in breve. L'immagine initrd immagine è un piccolo filesystem che viene aggiunto al kernel. Il filesystem initrd è caricato in memoria e quando il kernel ha finito il boot lo monta come filesystem principale. Ci sono alcuni vantaggi ad utilizzare l'immagine initrd. Come prima cosa permette di compilare i driver per le schede di rete come moduli e di caricare il modulo corretto durante il boot. Questo permette di avere un solo kernel che è in grado di supportare praticamente tutte le schede di rete. Un altro vantaggio è che possiamo eseguire il client DHCP nello spazio dell'utente anziché nello spazio del kernel. Eseguire il client DHCP nello spazio dell'utente fornisce un migliore controllo sulle opzioni richieste e ricevute dal server. Inoltre questo fa diventare il kernel un po' più piccolo. L'altro modo di configurare il kernel è senza initrd. La costruzione di un kernel senza initrd richiede che il driver della specifica scheda di rete sia staticamente unito al kernel e richiede che siano impostati i parametri IP-Autoconfig e "Root filesystem on NFS" quando si compila il kernel. Il vantaggio di non utilizzare initrd è che leggermente più piccolo e farà fare il boot più velocemente. Una volta che la workstation è stata avviata ed è in funzione teoricamente non c'è alcuna differenza a riguardo di come funzioni la workstation.
Il kernel standard per LTSP include un disco ram iniziale (initrd) che si prende carico di identificare la scheda di rete e di fare la richiesta DHCP nello spazio dell'utente. Uno degli obiettivi ricercati nel fare questa immagine è stata quella di farla più piccola possibile. Per questo motivo abbiamo scelto di utilizzare la libreria uClinux al posto della libc e busybox per le utility necessarie durante il boot.
Se volete costruirvi il vostro kernel dovete procurarvi il pacchetto ltsp_initrd_kit. Contiene la gerarchia del filesystem principale e uno script per costruire l'immagine.
Quando si costruisce un kernel personalizzato, è generalmente una buona idea partire con dei sorgenti non modificati, presi direttamente dal sito ftp.kernel.org. Questo perché molte distribuzioni, tra cui ad esempio Red Hat, applicano molte patch ai sorgenti e l'insieme dei sorgenti che forniscono non coincide con quello ufficiale del kernel.
Scaricate il pacchetto dei sorgenti del kernel di vostra scelta e salvatelo nella directory /usr/src. I kernel sono collocati nella directory /pub/linux/kernel del server ftp ftp.kernel.org ftp server. Avrete bisogno di una versione recente (la 2.4.x ), perché avete bisogno di includere il supporto devfs.
Inoltre se volete applicare le patch per lo swapping su NFS o la Linux Progress Patch (LPP), avrete bisogno di prendere le patch che corrispondono alla versione del kernel che vi siete procurati. Al momento della scrittura di questo documento la versione 2.4.9 del kernel è la più nuova che supporta queste caratteristiche.
In questo esempio useremo il kernel 2.4.9 kernel. Il percorso completo è ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.9.tar.bz2
Scomprimete i sorgenti del kernel nella directory /usr/src. Dovete prestare attenzione perché quando scomprimete il file tar verrà scompresso nella directory linux . Potreste già avere una directory chiamata linux con un diversa versione del codice sorgente e di certo non volete che uno copra l'altro. Pertanto,prima di estrarre il file tar, controllate se già esiste una directory con il nome linux e se esiste rinominatela con un altro nome.
Il pacchetto dei sorgenti che abbiamo scaricato è stato compresso con l'utility di compressione bzip2. Pertanto dobbiamo scomprimerla prima di passarla al programma tar. Potete utilizzare il seguente programma per estrarre il pacchetto:
bunzip2 <linux-2.4.9.tar.bz2 | tar xf - |
mv linux linux-2.4.9 |
cd linux-2.4.9 |
In genere modifico il file Makefile prima di configurare il nuovo kernel. Nella parte iniziale del file Makefile c'è una variabile chiamata EXTRAVERSION . La imposto a 'ltsp-1'. In questo modo il numero di versione completo del kernel diventa '2.4.9-ltsp-1', cosa che permette di identificare questo kernel nel seguito. Dopo aver fatto questo la parte iniziale del file Makefile sarà qualcosa del tipo:
VERSION = 2 PATCHLEVEL = 4 SUBLEVEL = 9 EXTRAVERSION = -ltsp-1 KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) |
Dopo aver estratto il kernel, potreste volere applicare alcune patch. Ad esempio la patch per NFS Swap o quella per il la barra d'avanzamento (Linux Progress Patch). Queste patch DEVONO essere applicate PRIMA di configurare il kernel (se volete applicarle).
La patch NFS Swap permette al kernel della workstation di utilizzare un file di swap collocato sul server NFS. Mentre in genere si raccomanda di avere abbastanza memoria sulla workstation da non richiedere lo swapping, in alcuni casi, specie nel caso di vecchi computer, potrebbe essere difficile aggiungere altra memoria. La possibilità di fare lo seap tramite NFS può rendere utilizzabile un computer altrimenti inutilizzabile.
Se la directory corrente è /usr/src/linux-2.4.9, e la patch è in /usr/src, potete dare il seguente comando per verificare la patch:
patch -p1 --dry-run <../linux-2.4.9-nfs-swap.diff |
patch -p1 <../linux-2.4.9-nfs-swap.diff |
La patch Linux Progress Patch (LPP) permette di configurare un'immagine grafica che venga mostrata durante la fase d'avvio. I normali messaggi che apparirebbero sullo schermo sono dirottati ad un altro schermo tty e alcune speciali istruzioni, aggiunte agli script d'avvio, fanno sì che l'avanzamento della barra mostrata sullo schermo rifletta l'avanzamento del processo d'avvio.
come nel caso della patch NFS Swap patch potete verificare questa patch con il comando:
patch -p1 --dry-run <../lpp-2.4.9 |
patch -p1 <../lpp-2.4.9 |
Potete ora eseguire il programma che preferite per la configurazione. Tra le varie possibilità ci sono:
Utility di configurazione del kernel nella versione X Windows.
Utility di configurazione del kernel nella versione basata su curses
Utility di configurazione del kernel nella versione con una semplice interfaccia a caratteri riga per riga.
La configurazione del kernel per l'uso di initrd richiede che siano impostate le seguenti opzioni:
Il supporto per il filesystem /dev deve essere abilitato. Questa impostazione si trova nella sezione 'File systems'. NON specificate 'Automatically mount at boot'. L'operazione di mount di questo filesystem verrà fatto dallo script /linuxrc.
Le workstations LTSP hanno bisogno del supporto del kernel per i dischi RAM. Questa impostazione è nella sezione 'Block devices'.
Anche questo deve essere attivato.
Dovete accertarvi che il kernel che stato costruendo possa veramente essere eseguito sulla CPU della workstation. Controllate la sezione 'Processor type and features'. Dovete anche disattivare il supporto SMP, a meno che non abbiate veramente delle CPU multiple.
La workstation monta il filesystem principale tramite NFS, pertanto è necessario che il supporto per il client NFS sia attivato.
La configurazione del the kernel per l'uso senza initrd è diversa da quella con initrd per alcuni aspetti:
Le workstation LTSP hanno bisogno del supporto del kernel per i dischi RAM. Questa impostazione è nella sezione 'Block devices'.
Questa opzione deve essere disabilitata.
Questo deve essere abilitato. Questa impostazione dà informazioni a kernel di configurare automaticamente l'interfaccia di rete ethernet eth0, basandosi su valori passati al kernel sulla linea di comando.
Non è necessario specificare le opzioni DHCP, BOOTP o RARP perché il bootrom Etherboot ha già effettuato la richiesta DHCP o BOOTP e avrà reso disponibile il valore dell'indirizzo IP al kernel passandolo come parametro alla linea di comando del kernel. Questo evita al kernel dei dover effettuare lui una richiesta.
Quando non viene utilizzato initrd, bisogna scrgliere il driver per la specifica scheda che corrisponda alla scheda di rete utilizzata . Deve essere staticamente unito al kernel (e non compilato come modulo), perché l'interfaccia di rete deve essere utilizzata prima che venga montato il filesystem principale. Questa è una differenza importante rispetto al kernel con initrd.
Dalla versione 2.09pre2 di LTSP, è necessario il supporto devfs. Questo supporto è necessario sia che si utilizzi initrd sia che non si utilizzi initrd.
Quando NON si utilizza initrd il filesystem /dev DEVE essere montato dal kernel, durante il boot. Dite 'Y' (sì) a questa opzione.
La workstation monta il filesystem principale tramite NFS, pertanto è necessario che il supporto per il client NFS sia attivato.
Per rendere le cose più facili, una copia del file .config è incluso nel pacchetto ltsp_initrd_kit. Potete copiare questo file nella directory /usr/src/linux-2.4.9 .
Quando avete terminato di selezionare o deselezionare i parametri del kernel, dovete passare alla sua creazione (build). Per creare il kernel dovete dare il seguenti comandi:
make dep make clean make bzImage make modules make modules_install |
make dep && make clean && make bzImage && make modules && make modules_install |
Il novo kernel, una volta creato, si troverà nel file /usr/src/linux-2.4.9/arch/i386/boot/bzImage.
Per fare in modo che Etherboot possa gestire il kernel Linux deve essere preparato per questo. Questa operazione si chiama contrassegnatura ('Tagging') del kernel. Questa operazione aggiungerà un pezzo di codice al kernel che verrà eseguito prima che il controllo sia passato al kernel. Lo strumento per eseguire questa contrassegnatura si chiama 'mknbi-linux'.
Il pacchetto ltsp_initrd_kit include uno script shell chiamato buildk che include tutte i comandi necessari per preparare l'immagine del kernel per il boot tramite rete.
Quando si prepara LTSP, una delle cose che bisogna tenere a mente è che bisogna considerare diverse configurazioni hardware per le workstation. Ovviamente le combinazioni di processore, scheda video e scheda video che abbiamo presente oggi non sarà quella che avremo bisogno tra tre mesi quando aggiungeremo altre workstation alla rete.
Per questo motivo è stato creato un modo per specificare la configurazione di ogni workstation. Il file di configurazione si chiama lts.conf ed è collocato nella directory /opt/ltsp/i386/etc.
Il formato del file lts.conf permette di definire alcune impostazioni di 'default' e alcune impostazioni per le specifiche workstation. Se tutte le vostre workstation sono identiche, potete specificare tutte le impostazioni di configurazione nella sezione '[Default]'.
Qui sotto è riportato un file lts.conf d'esempio:
[Default]
SERVER = 192.168.0.254
X_MOUSE_PROTOCOL = "PS/2"
X_MOUSE_DEVICE = "/dev/psaux"
X_MOUSE_RESOLUTION = 400
X_MOUSE_BUTTONS = 3
USE_XFS = N
SCREEN_01 = startx
[ws001]
XSERVER = auto
X_MOUSE_PROTOCOL = "Microsoft"
X_MOUSE_DEVICE = "/dev/ttyS1"
X_MOUSE_RESOLUTION = 50
X_MOUSE_BUTTONS = 3
X_MOUSE_BAUD = 1200
[ws002]
XSERVER = XF86_Mach64
[ws003]
SCREEN_01 = shell
|
I commenti incominciano dal segno '#' e continuano fino alla fine della riga.
Questo parametro indica dove è collocato il filesystem principale di LTSP. Il valore di default (predefinito) per questo parametro è /opt/ltsp
Questo parametro indica il server che è usato al posto di XDM_SERVER, TELNET_HOST, XFS_SERVER e SYSLOG_HOST, quando uno o più di questi parametri non sono specificati esplicitamente. Se avete una macchina che funziona da server per tutti questi servizi allora basta che specificate l'indirizzo del server in questo parametro e omettete gli altri parametri. Se questo parametro non è specificato viene utilizzato il valore predefinito 192.168.0.254.
Se volete mandare i messaggi di log ad una macchina diversa dal server principale (quello definito dal parametro SERVER) potete specificare il server per i log con questo parametro. Se questo parametro non è specificato verrà, come descritto sopra, utilizzato il valore specificato come 'SERVER'.
Questo parametro specifica l'indirizzo IP del server NFS quando il filesystem /home viene montato. Se questo
