LTSP - Linux Terminal Server Project - Progetto per un sistema Server per Terminali con Linux v4.1 - Documentazione in Italiano James McQuillan
jam@LTSP.org
Andrea Fascilla
afascilla@mail.com
4.1.3-en  2004-06-20 jam 4.1.3-0-it  2005-03-09 af 4.1.3-0c-it  2005-03-21 eag 4.1.3-0d-it  2005-03-22 af 4.1.3-0e-it  2005-03-23 cp 4.1.3-0f-it  2005-04-18 af 2004 James A. McQuillan 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. Introduzione 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: Interfaccia Grafica con Sistema X Window 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. Sessioni tramite telnet ad interfaccia in modalità testo 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. Shell prompt (linea di comando) 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! Avvertenze <!-- ?? -->(Disclaimer) 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. Copyright e Licenza d'uso 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. Marchi registrati Tutti i marchi citati sono proprietà dei rispettivi proprietari. Schema teorico di funzionameno <!-- ??? o Spiegazione teorica del sistema di funzionnamento --> 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: DHCP TFTP NFS XDMCP 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. I vari passi per l'avvio della workstation Il kernel Linux viene caricato nella memoria della workstation. Questo può essere fatto in diversi modi, tra questi: Bootrom (Etherboot, PXE, MBA, Netboot) Dischetto floppy Disco fisso (Harddisk) CD-ROM Dispositivo di Memoria USB (USB Memory device) Ognuno dei suddetti metodi per l'avvio sarà spiegato di seguito in questo capitolo. Una volta che il kernel è stato caricato nella memoria, ne avverrà la sua esecuzione. Il kernel inizializzerà l'intero sistema e tutte le periferiche che verranno identificate. Qui entra in gioco una caratteristica interessante. Mentre viene caricato il kernel in memoria, viene anche creato un disco virtuale in memoria (RAM disk). Una linea di comando per il kernel del tipo root=/dev/ram0 informerà il kernel di utilizzare il dico ram come disco principale (il ramdisk viene montato come cartella principale - root directory). Normalmente, quando il kernel completa la fase di avvio, lancia il programma init. Invece in questo caso abbiamo istruito il kernel di caricare e di eseguire un piccolo script. Questo si ottiene passando alla linea di comando del kernel il parametro init=/linuxrc. Lo script /linuxrc inizia effettuando una scansione del bus PCI alla ricerca di una scheda di rete. Per ogni scheda PCI trovata, effettua una ricerca nel file /etc/niclist per vedere se è qui elencata assieme al nome del modulo del kernel necessario. Una volta trovata una corrispondenza, viene fornito al kernel il nome del modulo che serve come driver per la scheda di rete trovata, e ne avverrà il suo caricamento. Nel caso di schede ISA, il nome del modulo driver DEVE essere specificato come parametro nella riga di comando del kernel, insieme ai valori di IRQ ed indirizzo e qualunque altro parametro aggiuntivo eventualmente necessario per configurare la scheda. Un piccolo client DHCP chiamato dhclient entrerà successivamente in esecuzione per fare un'altra richiesta al server DHCP. C'è bisogno di questa ulteriore richiesta fatta in user-space perchè abbiamo bisogno di maggiori informazioni di quelle che sono state ottenute con la prima richiesta DHCP fatta dal chip ROM. Quando dhclient avrà ricevuto una risposta dal server, sarà eseguito il file /etc/dhclient-script , che leggerà le informazioni ricevute e configurerà la scheda ethernet (interfaccia di rete eth0). Quando dhclient avrà ricevuto una risposta dal server, eseguirà il file /etc/dhclient-script, che utilizzerà le informazioni precedentemente ottenute e configurerà l'interfaccia di rete eth0. Non è possibile fare il mount di questa directory direttamente come /. Bisogna prima fare il mount come /mnt e poi fare un pivot_root. Il pivot_root farà cambiare il root filesystem corrente con un nuovo filesystem. Quando questo comando sarà completato, il filesystem importato tramite NFS sarà montato come /, e il vecchi filesystem sarà montato come /oldroot. Fino a questo punto, il filesystem principale (il root filesystem) è stato nel disco RAM. Ora lo script /linuxrc farà il mount di un nuovo filesystem principale tramite NFS. La directory che viene esportata dal server è in genere /opt/ltsp/i386. Lo script non può fare il mount di questa directory direttamente come /. Deve prima fare il mount come /mnt. Poi eseguirà il comando pivot_root che scambierà il root filesystem corrente con quello nuovo. Una volta completata l'operazione, il filesystem NFS risulterà montato come /, ed il vecchio filesystem risulterà montato come /oldroot. Una volta completata la fase di mount e di pivot del nuovo filesystem principale, lo script /linuxrc ha completato il suo lavoro ed è ora necessario chiamare il vero programma /sbin/init. Il programma init leggerà il file /etc/inittab e comincerà a configurare l'ambiente della workstation. Uno dei primi elementi presenti in inittab è il comando rc.sysinit, che sarà eseguito mentre la workstation è nello stato di 'sysinit'. Lo script rc.sysinit creerà un disco ram di 1MB che conterrà tutti i file che per qualunque motivo necessitano essere scritti o modificati. Questo disco RAM sarà montato come directory /tmp. Ogni file che sarà necessario scrivere, esisterà nella directory /tmp e vi saranno link simbolici che punteranno a questi file. Virrà montato il filesystem /proc. Il file lts.conf verrà letto ed analizzato e tutti i parametri che appartengono a questa workstation verranno impostati come variabili d'ambiente per poter essere utilizzati dallo script rc.sysinit. Se la workstation è configurata in modo da utilizzare NFS per lo swap (dei file temporanei), allora la directory /var/opt/ltsp/swapfiles sarà montata come /tmp/swapfiles. A questo punto, se non c'è già un file di swap per questa workstation, ne viene creato uno automaticamente. La dimensione del file di swap è configurabile tramite il file lts.conf. Il file di swap verrà attivato utilizzando il comando swapon. L'interfaccia di rete di loopback viene configurata. Questa è l'interfaccia di rete che ha l'indirizzo IP 127.0.0.1. Se "Local apps" è abilitato, viene fatto il mount della directory /home, in modo che le applicazioni possano accedere alle home directory degli utenti. Alcune directory vengono create nel filesystem sotto /tmp per contenere alcuni file temporanei che sono necessari mentre il sistema è in funzione. Tra queste verrano create le seguenti directory: /tmp/compiled /tmp/var /tmp/var/run /tmp/var/log /tmp/var/lock /tmp/var/lock/subsys Il file /tmp/syslog.conf verrà creato. Questo file conterrà le informazioni che configureranno il demone syslogd, tra cui a quale host (computer) della rete devono essere inviate le informazioni che devono essere mantenute nei log. Quale debba essere l'host che riceve il log di syslogd è specificato nel file lts.conf. Verrà creato un link simbolico chiamato /etc/syslog.conf che punterà al file /tmp/syslog.conf. Il demone syslogd viene fatto partire utilizzando il file di configurazione creato al passo precedente. Una volta che lo script rc.sysinit è terminato, il controllo ritorna al programma /sbin/init, che cambierà il runlevel da sysinit a 5. Questo causerà l'esecuzione di alcune istruzioni elencate nel file /etc/inittab. Come impostazione predefinita (cioè se non vengono fornite istruzioni diverse), le istruzioni presenti in inittab faranno eseguire lo script /etc/screen_session sulla tty1, sulla tty2 e sulla tty3. Questo fa sì che ci saranno 3 sessioni contemporaneamente. Quale sia il tipo di ognuna delle sessioni viene controllato dai parametri SCREEN_01, SCREEN_02 e SCREEN_03 nel file lts.conf. Si possono inserire ulteriori sessioni nel file inittab, se lo si desidera. Se SCREEN_01 ha il valore startx, allora sarà mandato in esecuzione lo script /etc/screen.d/startx, che lancerà il sistema X Window, creando l'interfaccia grafica. 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. Se viene usanto Xorg, allora viene eseguito lo script /etc/build_x4_cfg per crere il file di configurazione XF86Config. Se viene usanto XFree86 3.3.6, allora viene eseguito /etc/build_x3_cfg per creare il file di configurazione XF86Config. Questi file vengono collocati nella directory /tmp, che come precedentemente detto è un disco RAM, visto solo dalla workstation. Il file di configurazione XF86Config sarà creato in base ai parametri presenti nel file /etc/lts.conf. Quando il file di configurazione XF86Config è stato completato, allora lo scipt startx lancerà il server X con la nuova configurazione. Il server X lancerà una richiesta XDMCP al server LTSP, che fornirà una finestra di login. A questo punto l'utente può effettuare il login ed otterrà una sessione sul server. 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 nella memoria Il caricamento del kernel Linux dentro la memoria della workstation può essere ottenuto in più modi. Boot da memoria ROM Boot da dispositivo locale Boot da memoria ROM Etherboot 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. PXE 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. MBA 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 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 Boot da dispositivo locale Disco Floppy 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. Hard disk (disco fisso) 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. CD-ROM 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. Dispositivo di Memoria USB (USB Memory device) 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. Installare LTSP sul server 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. Installazione delle utility LTSP (dei programmi di utilità di LTSP) Installazione dei pacchetti client di LTSP Configurazione dei servizi necessari a LTSP Installazione delle utility LTSP 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 . Installazione del pacchetto RPM 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 Questo comando installerà le utility sul server. Installazione del pacchetto TGZ 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 .. Questo comando installerà le utility sul server. Questo metodo è utile nel caso di sistemi che non supportano gli RPM. Installazione dei pacchetti client di LTSP 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:
Installazione di LTSP - Schermata principale
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.
Installazione di LTSP - Schermata di configurazione
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: Where to retrieve packages from (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 which directory would you like to place the LTSP client tree (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. HTTP Proxy (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". FTP Proxy (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.
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'.
LTSP installer - Finestra d'Aiuto
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.
LTSP installer - Package list
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. Configurazione dei servizi necessari a LTSP I servizi principali necessari per permettere l'avvio (il boot) delle workstation LTSP sono i quattro qui sotto elencati: DHCP TFTP NFS XDMCP 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:
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.
ltspcfg - Schermata dei servizi
1 - Runlevel 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à. 2 - Interface selection (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. 3 - DHCP configuration (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. 4 - TFTP configuration (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. 5 - Portmapper configuration (Configurazione della mappa delle porte) Il Portmapper è utilizzato dai servizi RPC, quali ad esempio NFS. 6 - NFS configuration (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. 7 - XDMCP configuration (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. 8 - Create /etc/hosts entries (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. 9 - Create /etc/hosts.allow entries (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. 10 - Create the /etc/exports 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. 11 - Create the lts.conf 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). Configurazione specifica delle workstation 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. /etc/dhcpd.conf /etc/hosts /opt/ltsp/i386/etc/lts.conf /etc/dhcpd.conf La workstation ha bisogno di un indirizzo IP e di altre informazioni. Riceverà le seguenti informazioni dal server DHCP: IP address hostname Server IP address Default gateway Pathname of kernel to load Server and directory path to be mounted as the root filesystem 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.
/etc/dhcpd.conf 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"; } }
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. /etc/hosts 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. /opt/ltsp/i386/etc/lts.conf 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: lts.conf file # # 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 La seguente è una lesta di alcune voci: XSERVER 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. RUNLEVEL 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. Visualizzazione dela configurazione corrente 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.
ltspcfg - Current Status
La Configurazione della workstation 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. Avviare il computer con PXE 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: Il bootrom PXE inizializza la scheda di rete e manda una richiesta DHCP. Il server DHCP risponde fornendo un indirizzo IP e il nome del NBP da caricare.. Il bootrom PXE prende lo NBP, lo mette in memoria e lo fa eseguire. Lo NBP usa tftp per far il download del file di configurazione dal server. Il file di configurazione contiene il nome del kernel, il nome del del file del disco ram iniziale e le opzioni da passare al kernel. 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 Lo NBP, a questo punto, usa tftp per fare il download del kernel Linux e del disco ram iniziale (initrd). Quindi il controllo viene passato al kernel Linux, avviene la fase di boot, viene montato il disco ram iniziale (initrd) e prosegue l'avvio della workstation. Avviare il computer con Etherboot
Ken Yap 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.
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. Scelta del driver Etherboot per la scheda di rete ISA 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). Scelta del driver Etherboot per la scheda di rete PCI 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) Nell'esempio qui sopra, si vede una linea per ogni scheda PCI presente nel sistema. Dovete guardare soltanto alle linee dei dispositivi con la classe Class 0200. Lanciando il comando in modo da guardare solo alle schede Ethernet la lista diventa più facile da leggere. [root@jamlap root]# lspci -n | grep "Class 0200" 0000:06:00.0 Class 0200: 8086:1229 (rev 09) In questo esempio i numeri PCI ID sono: 8086:1229. Il primo campo è il PCI Vendor ID in questo esempio 8086 corrispondente alla Intel Corporation. Il secondo campo è 1229, che è il PCI Device ID. Questo ci dice il modello della scheda di rete. In questo caso è una scheda EtherExpress 100. Creare un disco floppy di avvio 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 dove al posto di Etherboot_Image dovete mettere il nome del vostro file immagine. Creare un bootrom 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. La workstation in fuzione 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.
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. La Stampa 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. La parte della configurazione della workstation 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 Le righe qui sopra fanno sì che il programma lp_server sia eseguito come demone, ascolti le connessioni TCP/IP sulla porta 9100 in attesa di uno flusso di stampa proveniente dal server. I dati da stampare saranno reindirizzati alla stampante attaccata alla porta parallela /dev/lp0. Sono disponibili molte ozoioni. Maggiori informazioni per la configurazione delle stampanti sono disponibili nella sezione di spiegazione del file di configurazione lts.conf. La parte della configurazione del server 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.
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: "a-z" lettere minuscole "A-Z" lettere maiuscole "0-9" cifre numeriche "-"  trattino "_" :nbsp; segno di sottolineatura 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.
Dettagli Informazioni di Printconf-gui
Vi sono due campi da configurare necessariamente per poter comunicare con la stampante: L'indirizzo IP o il nome del computer (hostname) della workstation cui è attaccata. La porta TCP/IP su cui il demone lp_server è in ascolto. 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. Gli script per le sessioni dello schermo 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 Questa configurazione farà partire un server X (una sessione grafica) sul primo schermo e una sessione a caratteri (con un prompt di una shell) sul secondo schermo. Per passare al primo schermo si premono contemporaneamente i tasti Ctrl-Alt-F1 e per passare al secondo schermo si premono contemporaneamente i tasti Ctrl-Alt-F2. 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: startx 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. shell 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. telnet 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 Si può anche specificare una qualsiasi altra opzione che telnet sia in grado di comprendere. Però se si specifica una o più opzioni deve anche essere indicato il nome del server a cui connettersi. rdesktop 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 Con la configurazione di questo esempio verrà lanciato rdesktop in modalità tutto schermo. L'utente vedrà una finestra di login di Windows e avrà bisogno di loggarsi una volta sola. Questa cosa è molto utile quando avete bisogno soltanto di un finestra di login Windows senza avere la login Linux o il window manager. L'utente non saprà neppure di essere su una macchina Linux. 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. Risoluzione dei problemi (Troubleshooting) 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. Risoluzione dei problemi nel caso dell'immagine Etherboot su dischetto floppy 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. Risoluzione dei problemi con DHCP 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 vedete una linea che inizia per 'Me:' seguito da un indirizzo IP, allora potete considerare che il sistema DHCP funziona correttamente e potete passare a controllare la parte del TFTP. 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. Controllare le connessioni 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. Il sistema DHCP è in funzione? 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 " si dovrebbe vedere un output del tipo: udp 0 0 0.0.0.0:67 0.0.0.0:* La quarta colonna contiene l'indirizzo IP e la porta separata dal simbolo dei due punti (:). Un indirizzo composto da tutti zero ('0.0.0.0') indica che l'ascolto è effettuato su tutte le interfacce. Cioè se avete sia una interfaccia eth0 ed una eth1 vuol dire che dhcpd da ascoltando entrambe le interfacce.. 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 Dovreste vedere qualcosa del tipo: 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 La prima riga mostra che il programma dhcpd è in esecuzione. La seconda riga è semplicemente il comando grep che stiamo eseguendo adesso. 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 Prestate attenzione all'output, e controllate se sono evidenziati degli errori. Controllo incrociato della configurzzione dhcpd 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. La richiesta a ipchains o a iptables è stata fatta? Controllare ipchains Usate il seguente comando e guardate cosa vi dice: ipchains -L -v Se vedete qualcosa del tipo: Chain input (policy ACCEPT: 229714 packets, 115477216 bytes): Chain forward (policy ACCEPT: 10 packets, 1794 bytes): Chain output (policy ACCEPT: 188978 packets, 66087385 bytes): allora non è ipchains che è responsabile dei problemi. Controllare iptables Usate il seguente comando e guardate cosa vi dice: iptables -L -v Se vedete qualcosa del tipo: 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 allora non è iptables che è è responsabile dei problemi. La workstation sta spedendo la richiesta? Provate a guardare il file /var/log/messages mentre la workstaion si sta avviando. Potete utilizzar il seguente comando: tail -f /var/log/messages Questo comando continuerà a mostravi le nuove righe registrate nel file. 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 Se vedete dei messaggi come quelli qui sopra, la scritta 'no free leases', indica che dhcpd è in funzione, ma non sa nulla della workstation che sta richiedendo un indirizzo IP. Risoluzione dei problemi con TFTP 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......... Con dei puntini che compaiono sullo schermo abbastanza vleocemente significa che il TFTP sta funzionando correttamente e che sta avvenendo il downlodad il kernel. Se invece non compaiono i puntini, allora c'è qulache problema. Tra le possibilità da considerare ci sono: <command>tftpd</command> non è in esecuzione 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 Se non vedete nessun output dopo aver dato il comando allora è molto probabile che tftpd non è in esecuzione. 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 } Accertatevi che la linea disable NON sia posta a yes. Il Kernel non è dove tftpd pensa che sia 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 Risoluzione dei problemi con il filesystem principale NFS Ci sono parecchie motivi per cui potrebbero essere la causa per cui non riesca a montare il filesystem principale. Tra queste: Non viene trovato il file init (No init found) Se ricevete il seguente messaggio d'errore: Kernel panic: No init found. Try passing init= option to kernel. allora è molto probabile che state montando come filesystem principale una directory sbagliata o che la directory /opt/ltsp/i386 sia vuota. Il server ritorna error -13 Se ricevete il seguente messaggio d'errore: Root-NFS: Server returned error -13 while mounting /opt/ltsp/i386 questo significa che la direcory /opt/ltsp/i386 non è elencata nel file /etc/exports file. 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 confermerà il sospetto che la lista /etc/exports non è corretta. Problemi con il demone NFS (portmap, nfsd & mountd) 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. portmap 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 allora molto probabilmente questo è dovuto al fatto che portmap non è in esecuzione. Potete accertarvi della cosa utilizzando il comando ps, ad esempio: command: ps -e | grep portmap se portmap è in esecuzione dovrebbe esserci una linea del tipo: 30455 ? 00:00:00 portmap Un'altro test è quello di utilizzare il comando netstat. Le porte TCP ed UDP utilizzate da portmap sono le 111. Provate con il comando: netstat -an | grep ":111 " Dovreste vedere, come risultato, qualcosa di questo tipo: 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:* Se non vedete qualcosa di simile allora probabilmente portmap non è in esecuzione. Potete avviare portmap con il comando: /etc/rc.d/init.d/portmap start Quindi accertatevi che portmap sia correttamente configurato per essere avviato ogni volta che il server viene acceso. Utilizzate il comando ntsysv per accertarvi di ciò. I demoni NFS e MOUNT (nfsd & mountd) 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 se scoprite che uno o entrambi non sono in funzione dovete farli partire. 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 Non dovete preoccuparvi dei messaggi d'errore che ricevete nella fase di stop. Il comando start deve avere OK come risultato. 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 Dovreste ottenere qualcosa: 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 Questo indica che nfs (più propriamente nfsd) e mountd sono entrambi in funzione e si sono registrati al portmap. Risoluzione dei problemi con X 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 server X tenterà di avviarsi e non appena il tentativo fallisce per la prima volta ritornerà al prompt della shell bash. In questo modo potete vedere il motivo del fallimento. Risoluzione dei problemi con il Display manager 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: XDM - è in giro da moltissimo tempo ed è incluso nella distribuzione standard del sistema X window. standard X windows system. GDM - The 'Gnome Display Manager' (Il Display Manager di GNOME). Fa parte della distribuzione Gnome. KDM - The 'KDE Display Manager' (Il Display Manager di KDE). Fa parte di KDE, la distribuzione K Desktop. La maggior parte delle recenti distribuzioni GNU/Linux hanno tutti questi tre display manager. Una schermata grigia con soltanto una grande cursore a forma di X 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: Il display manager non è in esecuzione 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 Lo script prefdm si preoccupa di determinare quale display manager avviare. Quale sia il display manager di default dipende da quali pacchetti siano stati installati. Se è stato installato Gnome all