Marco Dorigo DA RIFIUTO A RISORSA. (come utilizzare il Software Libero per recuperare vecchi PC e vivere felici)

Transcript

1 Marco Dorigo DA RIFIUTO A RISORSA (come utilizzare il Software Libero per recuperare vecchi PC e vivere felici)

2

3 Premessa Il software libero (o freesoftware) in generale e Linux Terminal Server Project (LTSP) in particolare sono interessanti, oltre che per la loro validità tecnica, anche per le opportunità che offrono di riduzione della quantità di rifiuti e di riutilizzo efficace di computer altrimenti destinati alla rottamazione, ancorché funzionanti. Possiamo fare le seguenti osservazioni: 1) una quantità enorme di hardware ancora funzionante viene destinata alla rottamazione Questo fatto, oltre ad essere una forma di spreco favorita dalla naturale evoluzione tecnologica e dalle politiche commerciali di obsolescenza programmata praticate dalle aziende produttrici di hardware, costituisce un problema e un costo per la collettività che deve dotarsi delle necessarie strutture di smaltimento, ed è fonte di inefficienza anche per le aziende che devono pagare la tassa di smaltimento anche su materiale ancora funzionante. Scuole, enti ed associazioni possono però utilizzare il materiale informatico dismesso da privati ed aziende sollevando queste ultime dal pagamento della tassa di smaltimento e contribuendo a ridurre la quantità di rifiuti prodotta. 2) è possibile ottenere tecnologia valida a costo zero (o quasi) LTSP ed il software libero consentono di riutilizzare proficuamente hardware vecchio ma ancora funzionante, a costo zero o comunque estremamente più basso rispetto alle soluzioni basate su hardware nuovo e magari software con licenze proprietarie. Bassi costi non significa automaticamente bassa qualità; il freesoftware ha un livello tecnico del tutto confrontabile, in molti casi superiore, al software proprietario, e in questo caso consente di evitare l'acquisto di hardware inutilmente potente senza compromettere il servizio offerto agli utenti. In tempi in cui s'impone, per così dire, una razionalizzazione delle risorse economiche in molti settori, scuola compresa, avere a disposizione strumenti e conoscenze che permettono di fare scelte oculate e che vanno in direzione del risparmio, non è cosa di poco conto. Definizioni e considerazioni introduttive LTSP è un insieme di programmi e protocolli nato per agevolare l'implementazione di una rete di computer che si connettono ad un server, e ne sfruttano la potenza di elaborazione. Un ambiente di rete di questo tipo è detto thin client server computing. L'installazione di reti di tipo thin client server computing è una pratica abbastanza diffusa all'estero, ma ancora relativamente poco conosciuta nella realtà italiana. Con riferimento particolare al mondo della scuola, l'argomento è trattato in un documento dell'osservatorio tecnologico del ministero della pubblica istruzione, e viene evidenziato per la possibilità che offre sia di abbattere decisamente i costi di manutenzione hw e sw, sia di potere riutilizzare PC obsoleti (ForTIC Piano nazionale di Formazione degli Insegnanti sulle Tecnologie dell'informazione e della Comunicazione Percorso formativo C Materiali didattici 2002/2004 pag. 37). Perché una rete di computer in un'aula scolastica informatica o per uso didattico e non semplicemente un insieme di PC standalone anche se attrezzati con software libero?

4 Non sempre la soluzione dei PC stand alone è ottimale in questi casi, per queste motivazioni: - necessità di installare il software e di intervenire per la manutenzione tante volte quanti sono i PC, con conseguente dispendio di tempo e possibilità di errori; - necessità di evitare installazione di applicazioni non autorizzate (sopratutto nel caso di macchine equipaggiate con Windows) - risorse economiche limitate e quindi impossibilità di avere un parco hardware sempre aggiornato; non tutti i PC disponibili possono essere all'altezza del software che si desidera installare. L'hardware: componenti e requisiti La soluzione LTSP comprende un server su cui vengono concentrate l'installazione delle applicazioni, la manutenzione del sistema, la gestione degli utenti ed il salvataggio dei dati, un certo numero di terminali realizzabili utilizzando anche computer con caratteristiche minimali, ed uno switch di rete.

5 Requisiti del server I requisiti hardware del server sono abbastanza contenuti, una macchina moderna con normali prestazioni può fungere adeguatamente allo scopo. Una CPU dual core con 3 GB di RAM può gestire 15 client. Ovviamente le caratteristiche devono essere proporzionate al numero di client da gestire. Requisiti dei client I client sono costituiti da terminali privi di disco e di sistema operativo, e possono essere utilizzati sia computer obsoleti riciclati, con caratteristiche hardware davvero modeste, oppure, se si desidera una soluzione più professionale, thin client nativi ovvero computer molto leggeri appositamente progettati. Dall'esame delle richieste hardware elencate, emerge che le risorse fondamentali per un buon funzionamento di una rete LTSP sono la disponibilità di RAM e la velocità delle schede di rete e degli switch; in particolare quest'ultima è importante dal momento che le applicazioni disponibili sui terminali non vengono eseguite localmente, e le informazioni devono quindi necessariamente transitare in rete. Una volta installato e configurato opportunamente il sistema, i singoli terminali hanno a disposizione le stesse funzionalità e programmi installati sul server.

6 Il software: componenti, installazione e funzionamento Componenti software Un server LTSP è una vera e propria distribuzione completa, che viene ospitata all'interno di quella già esistente, e si basa su una serie di servizi: 1) un server DHCP (Dynamic Host Configuration Protocol). E' il protocollo per la configurazione automatica delle interfacce di rete, e viene utilizzato da LTSP per distribuire gli indirizzi IP ai terminali; 2) un server TFTP (Trivial File Transfer Protcol. E' un protocollo di trasferimento file molto semplice, poiché non prevede l'autenticazione dell'utente, è utilizzato da LTSP per trasferire il kernel ai terminali; 3) un server NFS (Network File System); è il protocollo che consente l'accesso ad un hard disk remoto attraverso la rete, permettendo la condivisione di file, directory o dell'intero filesystem. Il client richiede al server la condivisione di una risorsa, dichiarando un punto di mount. Una volta effettutata la mount, l'utente accede alla risorsa remota condivisa come se si trattasse di una risorsa locale. E' utilizzato da ltsp per condividere con i thin client la directory contenente l'installazione ospite. Nelle ultime versioni di Ubuntu la configurazione di LTSP non prevede più l'uso di NFS, essendo stato sostituito con NBD (Network Block Device), che consente di montare un filesystem di rete come se fosse un block device locale. Il servizio viene lanciato dal server inetd 4) Un server XDMCP (X Display Manager Control Protocol); è il protocollo che consente il login grafico dei terminali. Il server X fa una una richiesta XDMCP al display manager del server LTSP per ottenere una schermata di login. I display manager più comunemente usati sono XDM, GDM e KDM, quello usato da LTSP è LDM. Per ragioni di sicurezza il display manager è configurato di default per rifiutare le connessioni remote. 5) Un server SSH per esportare la sessione grafica dal server ai client; 6) un server LTSPFS per permettere ai client la gestione dei device locali (floppy, CD, chiavette USB). Installazione dei componenti LTSP 5 è l'ultima versione stabile di LTSP e presenta queste caratteristiche fondamentali: - Utilizza comunicazioni di rete tramite SSH, e quindi sicure; - Auto-configura i terminali all'avvio; - Gestisce l'audio locale dei terminali; - Gestisce le periferiche locali USB e CD; - Permette anche l'esecuzione locale sui terminali delle applicazioni grafiche, al fine di ridurre il carico sul server. (Fat client) Alcune distribuzioni pensate per la didattica, quale ad esempio Edubuntu, prevedono addirittura l'installazione di default di un ambiente LTSP; nel caso di una distribuzione generale, è necessario invece installare separatamente il software; in questa sede

7 consideriamo l'installazione e la configurazione relativa ad una distribuzione generica Ubuntu In questa distribuzione, è sufficiente installare il pacchetto ltsp-server-standalone ed eseguire come root lo script ltsp-build-client, che provvede a scaricare ed installare tutto il software. Questo script, lanciato senza opzioni, esegue l'installazione del filesystem per la stessa architettura del sistema ospitante, ma l'opzione arch <architettura> consente di implementare il supporto anche per altre architetture dei client. Al termine dell'installazione verranno creati seguenti file e directory: 1) /opt/ltsp/i386 (o, più genericamente nella directory /opt/ltsp/<architettura> ) che contiene un filesystem completo GNU/Linux. Questa directory contiene il filesystem di rete che verrà utilizzato come un disco remoto dai thin client, ed è a tutti gli effetti la root del filesystem dei client; 2) /var/lib/tftpboot/ltsp/i386/, contenente i file inviati ai client durante la prima fase del processo di boot. 3) Una immagine /opt/ltsp/images/i386.img, di tipo squashfs, contenente il sistema operativo minimale che verrà esportato ai client dopo la fase iniziale del boot. Root di LTSP E' possibile lavorare all'interno del sistema operativo generato in /opt/ltsp/i386 al termine dell'installazione, ma per farlo è necessario impostare questa directory come root del filesystem. Il tool chroot consente di cambiare la directory radice e di conseguenza il sistema su cui stiamo lavorando; una volta entrati nel sistema operativo ospite, possiamo eseguire qualsiasi operazione. sudo chroot /opt/ltsp/i386 Il comando permette di ottenere una shell con privilegi di root all'interno del sistema operativo che si trova in /opt/ltsp/i386, che diviene la radice che su u sistema normale di solito è /. Il cambio è naturalmente attivo solo all'interno di questo ambiente chroot. Per uscire dall'ambiente è sufficiente digitare il comando exit. All'interno di questo sistema operativo destinato ai thin client, è possibile installare software aggiuntivo. Questo ha lo scopo di utilizzare il terminale come fat-client, ovvero sutilizzare la RAM ed il processore di quest'ultimo per eseguire i programmi così installati, liberando parzialmente le risorse del server. Per potere installare software nell'ambiente chroot, prima di impostarlo come tale è necessario eseguire alcuni comandi, per montare le directory /dev, /sys e /proc del server all'interno del sistema chroot: mount --bind mount --bind mount --bind /dev /opt/ltsp/i386/dev /proc /opt/ltsp/i386/proc /sys /opt/ltsp/i386/sy

8 Il funzionamento Quando si avvia un terminale nella rete LTSP, il server riceve da queste le richieste di connessione, fornisce i parametri per la configurazione delle schede di rete e successivamente un intero sistema operativo che, mantenuto nella RAM della macchina ospite permette di fare funzionare localmente il server grafico (X-Window); le applicazioni (cioè i client grafici) vengono invece eseguite sul server LTSP. E' possibile anche eseguire alcune applicazioni sul terminale, sfruttandone il processore e diminuendo di conseguenza il carico di quello del server. Semplificando molto, durante il boot con LTSP avviene quanto descritto di seguito: 1) Il terminale carica dalla rom della scheda, dal floppy o dal CD il software (circa 16 kb) che gli permette di contattare il server dal quale, tramite il prorocollo TFTP, vengono scaricato un kernel e una immagine di filesystem; 2) Dopo il boot, il terminale carica via NFS l'immagine /opt/ltsp/images/i386.img del sistema operativo minimale che utilizzerà. Viene caricato solo quanto basta per eseguire X ed il programma di login grafico sul terminale. Il filesystem (circa 4 MB) viene montato temporaneamente in RAM (ramdisk). 3) Partito X, il terminale fa la richiesta al server di fare partire il desktop manager (normalmente LDM) e compare la schermata di login; 4) A questo punto è possibile effettuare l'autenticazione e dopo questa è possibile lanciare le applicazioni come se ci si trovasse direttamente sul server LTSP. 5) al termine della sessione dopo il logout il terminale può rimanere acceso in attesa di altro login, e può essere direttamente spento senza la procedura di shutdown, dal momento che non è possibile danneggiare alcun flilesystem. Confronto con il processo normale di boot In un processo di boot normale di Linux, vengono caricati il kernel in /boot/vmlinuz2.6.xxx e l'init ramdisk in /boot/initrd.img-2.6-xxx L'init ramdisk contiene un file system temporaneo con i moduli necessari a gestire l'hard disk ed il filesystem della partizione di root effettiva del disco. Una volta che il kernel è in grado di montare il filesystem di root effettivo, può leggere /etc/fstab e montare le altre partizioni Conclusa la propria inizializzazione il kernel lancia /sbin/init che esegue quella del sistema sulla base di /etc/inittab Il processo di boot con LTSP si differenzia per il fatto che il kernel e l'init ram disk vengono caricati tramite tftp, e l'init ram disk contiene, oltre al modulo per gestire la rete, un modulo per gestire non un disco fisso locale, ma un disco e un filesystem remoto, tramite NFS o NBD Una volta montato il filesystem di root effettivo, analogamente al boot normale può essere avviata la procedura di inizializzazione finale del sistema.

9 Boot dalla scheda di rete Se il client dispone di una scheda di rete in grado di eseguire direttamente il boot dalla rete, si parla di ambiente PXE (Preboot Execution Environment). PXE è un aambiente in grado di eseguire un pre-boot, cioè di inizializzare i computer indipendentemente dalla presenza di un hard disk e sistemi operativi installati Se il BIOS del PC supporta questo tipo di boot, è sufficiente indicare network come primo dispositivo di boot nel BIOS stesso. Boot da floppy con Etherboot o gpxe Se non è disponibile un ambiente PXE, è possibile creare un floppy contenente un'immagine di boot del network bootloader Etherboot o gpxe. Le immagini di boot sono scaricabili da Vi sono immagini specifiche per ogni scheda di rete, ed è quindi necessario identificarla preventivamente con il comando lspci. Il floppy può essere creato con il comando: dd if=<nomefile>.zdsk of=/dev/fd0 Boot da CD generico Se non si desidera utilizzare immagini di boot specifiche, si può utilizzare un CD generico denominato DRBL (Diskless Remote Boot in Linux), scaricabile da dalla sezione Si masterizza il CD e al menu si sceglie Network boot. Il processo di boot nel dettaglio 1. Il client viene acceso e non essendoci disco il BIOS passa il controllo al software di boot, che può essere contenuto nella ROM della scheda di rete, in un floppy o in un CD. Nel caso di boot da ROM, è necessario che lo stesso BIOS preveda il supporto del boot da rete. Le schede di rete che consentono il boot supportano l'ambiente PXE (Preboot Execution Environment). In alternativa è possibile utilizzare Etherboot, progetto open di bootrom che dispone dei driver per le più comuni schede di rete. Si posson utilizzare immagini ROM utilizzabili per il boot da floppy, da CD, da supporto USB, o installabili direttamente sulla EPROM della scheda di rete. 2. Il software di boot, qualunque esso sia, inizializza la scheda di rete (indirizzo IP ) ed esegue una richiesta DHCP broadcast sulla rete locale, alla ricerca di un server DHCP che possa fornire un indirizzo valido. Nella richiesta è incluso il MAC address della scheda di rete. 3. il processo dhcpd in funzione sul server LTSP riceve la richiesta e, in base al

10 proprio file di configurazione /etc/ltsp/dhcpd.conf invia la risposta con le informazioni necessarie: a) indirizzo IP e netmask; b) directory e nome del'immagine del filesystem di boot da scaricare (parametro filename ; var/lib/tftpboot/ltsp/i386/<nomefile> c) percorso del filesystem remoto NFS che verrà montato come root: /opt/ltsp/i386. Viene poi configurata l'interfaccia ethernet del client. 4. A seconda del tipo di software di boot della scheda (Etherboot o PXE) il server DHCP comunica quale file scaricare. Se il client è di tipo PXE, non può essere scaricato direttamente il kernel Linux, ltsp/i386/vmlinuz ma occorre prima scaricare un loader. Il sistema PXE ha infatti la limitazione di non potere caricare file di dimensione superiore a 32 kb, ed un kernel linux supera di molto questa dimensione. Il loader che carica il kernel si chiama pxelinux.0 5. Le informazioni ottenute dal serve DHCP vengono utilizzate dal software di boot per inviare una richiesta TFTP al server. Questo è un protocollo FTP semplificato, che non richiede la gestione utenti ed è quindi implementabile anche nel firmware di una scheda di rete. Se il client è di tipo PXE, il software di boot della scheda scarica il bootloader pxelinux.0 ed il relativo file di configurazione, che contiene le informazioni: a) posizione e nome del kernel da caricare; b) nome dell'init ramdisk; c) opzioni da passere al server; Il bootloader PXE viene eseguito e, in base alle informazioni contenute nel proprio file di configurazione e sempre tramite il protocollo TFTP scarica il kernel e immagine dell'init ram disk da /var/lib/tftpboot/ltsp/. Se il client è di tipo Etherboot, vengono scaricati direttamente kernel e immagine dell'init ram disk. 6. Una volta scaricati completamente il kernel e il file immagine dell'init ram disk, vengono rispettivamente caricati in memoria e decompressi dal software di boot. L'immagine decompressa del disco ram iniziale viene temporaneamente montata come filesystem di root. 7. Il controllo passa al kernel che inizializza il sistema e le periferiche e carica i moduli necessari; in un processo di boot normale verrebbe eseguito /sbin/init che procederebbe con la inizializzazione finale del sistema. In questo caso viene invece eseguito lo script /linit che monta i filesystem /proc e /sys, carica i driver delle schede di rete e passa l'informazione, come parametro del kernel, di utilizzare il ram disk come filesystem di root provvisorio (ommagine nbi.img) 8. Viene eseguita una seconda query DHCP. Questa iulteriore richiesta viene fatta in user space ed è necessaria poiché la prima non contiene tutte le informazioni necessarie che sono contenute nel file dhcpd.conf, quali percorso della directory radice, nome e percorso dell'immagine del filesystem remoto NFS, default gateway.

11 Le informazioni ricevute sono usate oer configurare l'interfaccia ethernet e determinare da quale server montare via NFS (NBD) la root. 9. Fino ad ora, il filesystem di root è stato l'immagine del ramdisk; ora /init monterà il filesystem di root via NFS. La directory esporta è /opt/ltsp/i386. Non è possibile montare il nuovo filesystem direttamente su /, ma è necessario montarlo prima su /mnt e poi eseguire il comando pivot_root che scambia il filesystem corrente con quello nuovo. 10. Completato il montaggio del nuovo filesystem di root, lo script /init ha terminato il suo lavoro e viene richiamato il vero programma /sbin/init. Viene letto il file /etc/inittab e inizia la configurazione della workstation 11. Viene letto il file di configurazione lts.conf con i parametri generali e specifici delle singole workstation. Se è abilitato il parametro LOCAL_APPS per l'esecuzione locale delle applicazioni, viene fatto il mount della directory /home in modo che le appplicazioni possano accedere alle home directory degli utenti. 12. Se non è specificato nulla in lts.conf, viene avviato getty sullo schermo 1 del terminale (corrispondente alla direttiva SCREEN_01 nel file di configurazione e ad Alt + F1 ), ed avviato il desktop manager predefinito LDM LTSP Display Manager (corrispondente alla direttiva SCREEN_07 le file di configurazione ed al Alt + F7). 13. Viene avviato X Window fornendo l'interfaccia grafica. Il server grafico rileva la scheda video e crea un file di configurazione xorg.conf sul ramdisk del terminale. 14. Il server X avvia un tunnel SSH sul server LTSP nel caso di avvio del desktop predefinito LDM, e viene presentata la schermata di login grafico sul terminale. 15. Da questo momento l'utente può effettuare l'accesso ottenendo una sessione sul server. La sessione è eseguita sul server, tutti i comandi sono eseguiti sul server, l'output è mostrato sul terminale. Configurazione del server Configurazione del server DHCP Prendiamo in considerazione il caso di un server che disponga di due interfacce di rete;una collegata verso la rete LTSP, su cui verrà configurato il server DHCP, e un'altra verso il resto della rete. Entrambe sono state configurate con un indirizzo IP fisso. Il file di configurazione utilizzato da LTSP è /etc/ltsp/dhcpd.conf 1) Editare il file /etc/default/dhcp3-server inserendo la direttiva INTERFACES= eth1. Questo serve per determinare l'interfaccia di rete su cui funziona il server DHCP 2) Editare il file /etc/ltsp/dhcpd.conf adattandolo alla propria rete:

12 authoritative; subnet netmask { range ; option domain-name "aula_ltsp"; option domain-name-servers ; option broadcast-address ; option routers ; next-server ; # get-lease-hostnames true; option subnet-mask ; option root-path "/opt/ltsp/i386"; if substring( option vendor-class-identifier, 0,9 ) = "PXEClient" { filename "/ltsp/i386/pxelinux.0"; } else { filename "/ltsp/i386/nbi.img"; } } - option-root-path: definisce il percorso della directory root per i client; - option-domain-name-servers: indirizzo del server LSTP; - filename: percorso e nome del file immagine per i client; - if substring...: indica l'immagine da caricare al boot, pxelinux.0 nel caso di client PXE o l'immagine di un filesystem bootabile via rete e creata dal tool mknbi (make network bootable image) E' possibile configurare caratteristiche specifiche per i client, inserendo per ciascun terminale una sezione definita dal prefisso host e da un identificativo. In questo modo è possibile: - specificare un indirizzo IP fisso per quella macchina, identificandola con il MAC address della scheda di rete (direttive hardware ethernet e fixed-address) - specificare con la direttiva filename l'immagine del filesystem da utilizzare. - che identifica una macchina specifica tramite il proprio MAC address: host <nomehost> { hardware ethernet<mac address>; fixed-address ; filename /ltsp/i386/nbi.img ; } Confermate le modifiche nel file di configurazione, occorre eseguire i comandi che rigenerano le chiavi SSH che identificano il server, l'immagine del filesystem montato dai client con la nuova chiave, e in seguito riavviare il server DHCP. sudo ltsp-update-sskeys sudo ltsp-update-image sudo /etc/init.d/dhcp3-server restart

13 NOTA Il server DHCP parte automaticamente all'avvio del pc, solo se le interfacce di rete sono state configurate editando manualmente il file /etc/network/interfaces. Se invece vengono create tramite network manager, il server DHCP non si avvia automaticamente. Configurazione del server TFTP Il file di configurazione del server TFTP installato con LTSP è /etc/default/tftpd-hpa. In esso viene definita la directory root del server tftp; normalmente non vi è necessità di modifica. TFTP_DIRECTORY= /var/lib/tftpboot" La directory /var/lib/tftpboot/ltsp/i386 contiene i file che vengono inviati ai client durante la fase del boot: - loader pxelinux.0 e relativo file di configurazione pxelinux.cfg; - immagine del filesystem di root; nbi.img immagine del ramdisk iniziale: initrd.img immagine del del kernel: vmlinuz file di configurazione del kernel di boot: config System.map Per default il server TFTP è avviato tramite il superserver inetd; volendo configurarlo come demone a sé stante, occorre inseire la direttiva RUN_DAEMON= yes nel file di configurazione tftpd-hpa Configurazione del server NFS Il serveizio NFS nelle ultime release di Ubuntu, a differenza di Debian Lenny, è stato rimpiazzato da NBD. Anche in questo caso l'avvio del servizio avviene tramite il superserver inetd. L'immagine creata a partire dalla chroot verrà passata ai client tramite il servizio nbdrootd. Nel file di configurazione di inetd, inetd.conf, la seguente direttiva abilita il servizio e stabilisce l'immagine del filesystem che viene utilizzata dai client: 2000 stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/nbdrootd /opt/ltsp/images/i386.img Se è abilitato il parametro LOCAL_APPS per l'esecuzione locale delle applicazioni, viene fatto il mount della directory /home/<utenti> in modo che le applicazioni possano accedere alle home directory degli utenti.

14 Possono anche essere configurate altre immagini da esportare (da utilizzare ad esempio per i fat client con architettura diversa da quella del sistema) inserendo un'altra direttiva con il nome dell'immagine. In precedenza dovrà essere stata generato l'ambiente per l'architettura specifica con il comando sudo ltsp-build-client --<architettura> Nel caso invece di utilizzo del server NFS, Occorre editare il file di confgurazione /etc/exports per consentire ai terminali di accedere al filesystem di root /opt/ltsp/i386, aggiungendo la direttiva: /opt/ltsp/ *(ro,no_root_squash,async,no_subtree_check Per l'esecuzione locale delle applicazioni locali, è inoltre necessario prevedere anche l'esportazione delle home directory degli utenti, con apposita direttiva in /etc/exports Aggiornamento dell'immagine del filesystem dei client e delle chiavi SSH l'aggiornamento consiste nella rigenerazione dell'immagine del filesystem dei client e di nuove chiavi SSH. Deve essere eseguito ogni volta che viene modificato il file dhcpd.conf, e dopo ogni modifica apportata all'interno del filesystem chroot. sudo ltsp-update-sskeys sudo ltsp-update-image Configurazione dei client Locazione del file di configurazione La configurazione dei client riguarda la personalizzazione dell'interfaccia e delle caratteristiche dei terminali: della risoluzione dello schermo, configurazione della tastiera ee del mouse, gestione delsuono, gestione dei device rimovibili locali, delle stampanti collegate al terminale e al server. Il file di configurazione è lts.conf. Ne esistono due in due posizioni diverse; il primo si trova in /opt/ltsp/i386/etc/ e al suo interno una riga di commento ricorda che con la introduzione di NBD in luogo di NFS questo deve essere creato in /var/lib/tftpboot/ltsp/i386/etc e da qui modificato, in caso contrario è necessario aggiornare l'immagine del fileystem di root con il comando : sudo ltsp-update-image Per maggiore sicurezza si assume che le modifiche debbano essere riportate in entrambi, e debba essere comunque lanciato il comando di aggiornament dell'immagine del filesystem

15 Struttura del file E' diviso in sezioni; costituite da un identificativo racchiuso fra parentesi quadre. La prima sezione si chiama [default] e contiene le impostazioni valide per tutti i client (o meglio, per tutti i client che utilizzano quel tipo di chroot, in questo caso /opt/ltsp/i386, legato appunto all'achitettura i386) Possono poi seguire altre sezioni specifiche per ogni thin client, il cui identificativo può essere costituito da: - MAC address del client; - indirizzo IP del client; - un nome host, che deve però essere risolvibile nel corrispondente indirizzo IP. NOTA L'identificativo della sezione deve essere identico nei file di configurazione: - dhcpd.conf (dove identifica il nome host a cui ad esempio è assegnato un certo indirizzo IP); - /etc/hosts (risoluizione dei nomi host) - lts.conf Ecco un elenco di alcune direttive: SCREEN_01 fino a SCREEN_012 E' possibile imostare fino a 12 valori per ogni thin client, per altrettante sessioni di terminale, da CTRL-ALT-F1 a CTRL-ALT-F12, specificando il tipo per ciascuna SCREEN_07 = ldm SCREEN_02 = shell Alcuni valori che può assumere la variabile: - ldm: è il gestore delle sessioni terminale predefinito, archivia nome utente e password e stabilisce un collegamente al server tramite SSH. Se si dispone di client o server non moolto potenti, la cifratura potrebbe rallentare le sessioni. - startx: utile negli ambienti meno potenti che non possono supportare la cifratura via ssh. E' necessario abiltiare anche XDMCP per il gestore di accesso gdm. Per fare questo, sul server scegliereil menu Sistema Amministrazione finestra di accesso e nella scheda. Utilizzando questo metodo, tutto il traffico di X attraverso la rete non sarà cifrato: - shell: avvia una shell sul terminale MODULE_01 fino a MODULE_012 Con questa voce è possibile caricare fino a 10 moduli kernel per ciascuna workstation

16 SOUND Abilita l'audio per i thin coient X_MOUSE_DEVICE I device a cui è collegato il mouse. Per un mouse seriale il valore è /dev/ttys0 ad esempio. Non deve essere impostato per i mouse PS/2 o USB perchè rilevati automaticamente. XKBLAYOUT paramryto per configurare il layout della tastiera PRINTER_0_DEVICE Nome del device della prima stampante. La stampante può essere collegata al server o ad una wokstation, a seconda del caso si dovrà indicarne i parametri nella sezione generale o in quella specifica del client. Per una stampante USB il valore è /dev/usblp<n>, per una seriale è /dev/ttys<n>, per uina parallela è /dev/lp<n> Se la stampante è collegata direttamente al server LTSP, è immediatamente disponibile a tutti i client senza alcuna configurazione aggiuntiva. PRINTER_0_TYPE Tipo della prima stampante: P per stampantei parallele, S per seriali e U per USB PRINTER_0_PORT numero dela porta TCP7IP da utilizzare per la prima stampante. Il valore predefinito è 9600 LOCAL_APPS LOCAL_APPS = True Abilita l'utilizzo delle applicazioni da parte dei client LOCAL_DEVICES = True LOCAL_DEVICES = True Abilita l'utilizzo dei device locali nelle workstation, ed è l'impostazione di default per Ubuntu. Per consentire l'utilizzo dei device locali inoltre devono ricorrere le seguenti condizioni: - deve essere installato ltspfs - deve essere caricato il modulo fuse (file system in user space) - l'utente deve essere membro del gruppo fuse

17 MODULE_01 = <nomemodulo> In questo modo quando un utente connette un dispositivo USB ad un client, viene mostrata sul desktop la corrispondente icona. Se gli utenti appartengono però ad uno stesso gruppo primario, su tutti i desktop di quegli utenti verrà mostrata l'icona del dispositivo. E' possibile comunque ovviare all'inconveniente: Se si tenta di smontare il device sul client, si ottiene un errore collegato ai permessi e all'assenza dlla voce collegata al device nel file /etc/fstab. Non sembra necessario eseguire l'umount esplicito del device (da root con umount <puntodimount> o come utente normale con fusermount -u <puntodimount>, poiché fuse realizza la sincronizzazione del filesystem dopo qualche secondo da completamento delle operazioni di scrittura. Per rimuovere una chiavetta è pertanto sufficiente attendere qualche secondo dal completamento dell'operazione di scrittura. Per disabilitare una certa workstation all'utilizzo dei device locali, è sufficiente inserire nel file lts.conf, nella sezione specifica per la wokstation, la direttiva LOCAL_DEVICES = False, per disabilitarne l'uso ad un certo utente, è sufficiente non inserirlo come membro del gruppo fuse [Default] XSERVER = auto X_MOUSE_PROTOCOL = "PS/2" X_MOUSE_DEVICE = "/dev/psaux" X_MOUSE_RESOLUTION = 400 X_MOUSE_BUTTONS = 3 USE_XFS = N SCREEN_01 = startx SCREEN_02 = shell XkbLayout = it XkbModel = pc105 Le direttive precedute dalla etichetta [default] sono valide per tutte le workstation; configurazioni specifiche vanno inserite dopo l'etichetta con il nome identificativo della workstation. [ws001] USE_NFS_SWAP = Y SWAPFILE_SIZE = 48m RUNLEVEL = 5 [ws002] XSERVER = XF86_SVGA LOCAL_APPS = True USE_NFS_SWAP = Y SWAPFILE_SIZE = 64m RUNLEVEL = 3

18 Configurazioni particolari Fat client Come si è già visto, la configurazione standard LTSP prevede l'esecuzione dei programmi sul server. Gli applicativi sono eseguiti sul server e ne utilizzano la CPU e la RAM, mentre l'output è mostrato sullo schermo delle workstation In questo caso la workstation esegue solo il kernel passato al boot e il server grafico X Window, e funziona come un normale terminale X Window. In linea generale non vi è necessità di eseguire le applicazioni localmente a meno di particolari esigenze, quali ridurre il carico del server o utilizzare applicazioni multimediali che necessitano di funzionare accedendo direttamente all'hardware dei terminali. Se i client dispongono di una CPU sufficientemente performante e buona quantità di RAM, è possibile spostare su questi ultimi l'esecuzione di alcuni programmi. Per fare questo, è necessario: 1. abilitare l'esecuzione di applicazioni sul client, inserendo nel file lts.conf, per tutte o determinate workstaton, le direttive: a) LOCAL_APPS = True b) LOCAL_APPS_MENU = True c) LOCAL_APPS_MENU_ITEM = <applicazione1>, <applicazione2 2. installare i programmi nella root del filesystem dei terminali, montando prima i filesystem /proc, /dev e /sys del filesystem del server, con le modalità esaminate nel paragrafo Root di LTSP L'esportazione della home directory degli utenti, necessaria per permettere alle applicazioni locali la scrittura delle proprie impostazioni, viene effettuata automaticamente se è configurato il parametro LOCAL_APPS = True. Il vantaggio dell'esecuzione locale delle applicazioni è sostanzialmente quello di ottenere una riduzione del carico del server; gli svantaggi sono così riassumibili: - La workstation deve fare un lavoro maggiore ed è quindi necessaria una CPU più potente e maggiore memoria RAM; - l'avvio delle applicazioni è più lento; l'applicazione deve essere letta tramite NFS e questo causa maggiore attività di rete. Accesso a internet delle applicazioni locali Se LTSP viene configurato nella sua modalità standard, non è necessaria alcuna configurazione aggiuntiva per consentire alle applicazioni (es: browser) l'accesso a internet. In caso contrario, occorre che il server LTSP svolga la funzione di router per instradare le richieste dei terminali al gateway verso internet (router ADSL).

19 1) Editare il file /etc/ltsp/dhcpd.conf, modifcando la direttiva option-routers indicando l'indirizzo IP del server LTSP, e la direttiva option domain-name-server indicando l'indirizzo IP del DNS principale della rete 2) Abilitare il parametro del kernel che controlla le funzionalità di instadamento tra le interfacce di rete. Il parametro è net.ipv4.ip_forward, per rendere permanente la modifica occorre editare il file /etc/sysctl.conf decommentando o inserendo la riga: net.ipv4.ip_forward=1 3) Oltre ad abilitare l'instradamento, è necessario attivare anche il mascheramento del traffico uscente dalla rete dei terminali. Questo permette ai pacchetti di essere gestiti dalla rete destinataria come provenienti direttamente dal router. E' necessario agire sul firewall del kernel con iptables (ipotizzando che la rete interna LTSP sia /255) sudo iptables --table nat append POSTROUTING jump MASQUERADE source /24 4) Per rendere permanente la modifica: sudo sh -c 'iptables-save > /etc/ltsp/nat' 5) Modificare il file /etc/network/interfaces aggiungendo, per l'interfaccia di rete interna della rete LTSP la direttiva: up iptables-restore < /etc/ltsp/nat Questo consente allo script /etc/ltsp/nat di ripristinare la funzionalità NAT ogni volta che viene attivata l'interfaccia di rete interna a LTSP. 6) Riavviare il server DHCP: sudo /etc/init.d/dhcp3-server restart Controllo remoto dei client tramite SSH Occorre installare openssh-server sui thin client, con la procedura di installazione vista per le altre applicazioni Supporto di architetture diverse Il supporto per architetture diverse da quella del pc su cui è installato ltsp, si ottiene lanciando lo script sudo ltsp-build-client con l'opzione --<architettura> sudo ltsp-build-client --<architettura> Questo comando provvede a creare: - /opt/ltsp/<architettura> che contiene il filesystem completo GNU/Linux. utilizzato come un disco remoto dai thin client; - /var/lib/tftpboot/ltsp/<architettura>/; - l'immagine /opt/ltsp/images/<architettura>.img, di tipo squashfs, contenente il sistema operativo minimale che verrà esportato ai client dopo la fase iniziale del boot.

20 Viene inoltre aggiornato il file di configurazione inetd.conf contenente la direttiva per l'esportazione via NBD della immagine del filesystem per la nuova architettura. Vantaggi e ambiti di applicazione favorevoli Vantaggi e svantaggi di LTSP dipendono in gran parte dalle specificità e dalle esigenze dell'ambiente in cui si prevede di adottarlo; con particolare riferimento al mondo della scuola, possiamo dire che lo scenario è costituito da questi elementi: 1) Vi è la necessità di un gran numero di postazioni; la conseguente attività di manutenzione è quindi un onere piuttosto pesante; 2) I costi per l'acquisto o l'aggiornamento dell'hardware sono relativamente elevati; 3) I fondi a disposizione sono insufficienti La soluzione LTSP/freesoftware consente di affrontare efficacemente questo tipo di problemi: 1) I costi sono estremamente ridotti: il software è gratuito, tutti i client possono essere ricavati dal riutilizzo di PC dismessi, con requisiti veramente minimi, a costo nullo o irrisorio. Solo il server deve essere un buon computer recente, reperibile comunque ormai ad un prezzo moderato. L'hardware eventualmente mancante, come schede di rete e switch, non comporta esborsi significativi. 2) Le operazioni di amministrazione del sistema sono concentrate sul server e non devono essere ripetute su ogni posto di lavoro; l'installazione e la configurazione per esigenze di base e le attività di routine è semplice e può essere svolta anche da personale mediamente competente. Il salvataggio dei dati degli utenti/allievi è centralizzato sul server. 3) l'amministrazione e la manutenzione dei terminali è ridotta al minimo e riguarda quasi esclusivamente la parte hardware; non è necessario installare alcun software né vi è pericolo che ciò accada. In caso di guasto il client è sostituibile immediatamente, non contenendo software o dati degli utenti. Le postazioni dispongono tutte delle stesse applicazioni e le eseguono con la velocità del server. 4) Semplicità di integrazione di una rete LTSP in reti più estese. L'aula informatica si integra facilmente nella rete di istituto, è sufficiente collegare a quest'ultima una interfaccia di rete del server LTSP. 5) Riduzione dei consumi energetici e della produzione di rifiuti.. Anche se i thin client sono ricavati da PC obsoleti, consumano meno energia elettrica rispetto ad un PC moderno normale, non disponendo di hard disk da alimentare. L'unico svantaggio degno di nota risiede nella non banalità della logica di funzionamento di LTSP, cosa che può rendere difficoltosa da parte di un normale utente la configurazione in caso di esigenze particolarmente avanzate di personalizzazione dei servizi. In ogni caso, come già rilevato, le configurazioni basilari e l'amministrazione ordinaria sono ampiamente alla portata di una persona normalmente competente, informaticamente parlando.