venerdì 5 ottobre 2007

Ubuntu LTSP - Thin client per piccola azienda (3)

In questo terzo e ultimo post sui thin client cerco di spiegare alcuni dettagli di messa a punto e gestione della rete basata su server LTSP e thin client. La documentazione ufficiale su questi argomenti si trova invece qua.

Preparazione dei dischi per il boot dalla rete

Non tutti i pc sono in grado di fare il boot direttamente dalla scheda di rete. Anzi, normalmente solo macchine relativamente recenti, diciamo costruite grossomodo dal 2003 in avanti, sono in grado di farlo. Dal momento che uno dei vantaggi dei thin client è proprio quello di poter riciclare pc molti vecchi è assai probabile che sarà necessario preparare un cd o un floppy di avvio che permetta al pc di caricare il sistema operativo dal server ltsp.
Fortunatamente la procedura è molto semplice: grazie a rom-o-matic è possibile "fabbricarsi" una immagine di avvio per ogni scheda di rete. Per fare questo bisogna innanzitutto conoscere il tipo di scheda di rete presente nel thin client, e questo in qualche caso potrebbe non essere semplicissimo. In generale, su pc in grado di avviarsi da cd-rom è sufficiente avviare la macchina con una qualunque distribuzione linux live (io mi porto sempre dietro una Knoppix per ogni evenienza) e usare il comando

lspci

per identificare in maniera corretta la scheda presente sotto la voce "Ethernet controller". Una volta identificata la scheda, se non si conosce il nome del relativo modulo da caricare è sufficiente fare una rapida ricerca su google mettendo il nome e il modello della scheda trovata assieme alla stringa "linux module" ed in genere tra i primi risultati viene riportato il nome del modulo corretto. Mi sono anche capitati pc ancora più vecchi, dotati solo di unità floppy da 3.5", ma in quel caso erano dotati di una vecchia scheda a 10 Mbit, non idonea per un thin client, e ho quindi dovuto sostituirle con schede a 100Mbit che già conoscevo.
Una volta identificata la scheda e il relativo modulo su rom-o-matic si sceglie dal menu a tendina la voce corretta, il tipo di immagine ("Floppy bootable ROM image" per i floppy o "ISO bootable image without floppy legacy emulation" per i cdrom) e si scarica il file che viene prodotto. Per creare un floppy di avvio si può usare semplicemente il comando:

cat <nome_immagine_scaricata>.zdsk > /dev/fd0

mentre per il cd-rom basta masterizzare il file .iso.
Un'opzione interessante del rom-o-matic è che molti parametri di rete possono essere predefiniti nell'immagine che si sta creando. Posso per esempio fissare già un indirizzo ip, un gateway di default e parecchi altri parametri. In teoria tutto questo dovrebbe permettere l'avvio e l'utilizzo di un thin client senza aver bisogno di configurare un server dhcp nella rete.


Installazione di software per i thin client

I thin client prendono i file necessari al boot via tftp dal server, dopodichè montano le loro partizioni di lavoro via nfs sempre dal server. La partizione di root è rappresentata sul server da /opt/ltsp/i386, cioè dalla directory che è stata preparata all'inizio dell'installazione con il comando

ltsp-build-client

Anche in questa directory possiamo effettuare le normali operazioni di manutenzione, installazione/disinstallazione, aggiornamento di software etc. Per fare questo bisogna innanzitutto copiare il file /etc/apt/sources.list in /opt/ltsp/i386/apt/ in modo da avere gli stessi repository di software; successivamente con il comando:

chroot /opt/ltsp/i386

si entra in quella directory come se fosse la nostra root. Per finire si monta un filesystem proc con il comando:

mount -t proc none /proc

A questo punto siamo pronti a lavorare nell'ambiente chroot come se fosse un vero e proprio sistema indipendente. Possiamo usare i classici comandi apt, dpkg etc. per la manutenzione e l'aggiornamento del sistema. Possiamo modificare il file sources.list per gli upgrade di versione. Per uscire dall'ambiente chroot è sufficiente digitare exit o la classica combinazione di tasti Ctrl+d.
Per aggiornare invece il kernel dei thin client seguendo gli eventuali aggiornamenti di Ubuntu si usa il comando:

ltsp-update-kernels

che automaticamente si occupa di preparare le immagini del kernel aggiornate e di posizionarle al posto giusto nella directory servita da tftp.

Il file di configurazione lts.conf

Il file /opt/ltsp/i386/lts.conf è il file di configurazione dove è possibile definire delle impostazioni generali delle impostazioni particolari per singoli thin client.
La struttura generale del file comprende una sezione [default] nella quale vengono messe le impostazioni generali e delle sezioni particolari (facoltative) per i singoli thin client. Una esaustiva rassegna delle possibili configurazioni che si possono utilizzare è riportata qua. Rispetto a quanto riportato nella documentazione "ufficiale" ho verificato che qualche volta succede di dover forzare nella configurazione un particolare driver video (XSERVER=<nome_driver>) poichè il riconoscimento automatico non ha funzionato. Un'altra considerazione riguarda l'abilitazione del server di swap (NBD_SWAP): per parecchio tempo ho tenuto questa opzione abilitata e non ho osservato problemi anche se a dire il vero non ho notato nemmeno un utilizzo particolare dei file di swap che vengono creati sulla /tmp del server. Infatti qua riportavo uno spezzone di configurazione di lts.conf in cui NBD_SWAP era abilitato. Recentemente invece mi sono imbattuto in un thin client collegato da poco (un vecchio Pentium II a 300Mhz, una primizia), che ad un certo momento ha cominciato a perdere e ricreare la connessione con lo swap di rete provocando la creazione di decine di processi zombie sul server. Sinceramente non ho capito il motivo preciso di questo comportamento (oltretutto accaduto in piena giornata lavorativa, quindi senza la possibilità di stare con calma ad analizzare il problema ma con l'urgenza di ripristinare la piena funzionalità nel minor tempo possibile) ma è bastato mettere NBD_SWAP=False per quel client, far spegnere tutti i client e riavviare il server per riportare la situazione nella norma. Dopo questo episodio ho deciso di disabilitare questa opzione per tutti e non solo tutto funziona egregiamente ma ho l'impressione che il server sia meno impegnato rispetto a prima. Credo quindi che tale opzione vada lasciata disabilitata come da default, perchè in realtà non necessaria e, come ho potuto verificare, potenzialmente dannosa. E poi, parliamoci chiaro, perchè mai dovrebbe servire uno spazio di swap per ogni thin client quando la memoria usata per far girare le applicazioni è quella del server? Saranno ben affari suoi come e quando fare swap su disco.

Periferiche locali

E' possibile utilizzare alcuni tipi di periferiche collegate direttamente ai thin client. La maggior parte delle periferiche di archiviazione di massa (dischi fissi, lettori cd/dvd, chiavette usb etc.) possono essere utilizzate senza problemi. Per poter usare tali periferiche è necessario che siano installati i pacchetti ltspfs, libfuse2 e fuse-utils. Si pone poi LOCALDEV=True in lts.conf e si danno i permessi corretti agli utenti. Per fare questo si può utilizzare il pannello di amministrazione degli utenti di gnome, che nella sezione dei Privilegi Utente riporta una inequivocabile voce "Consentire l'uso di file system FUSE come i device a blocchi LTSP thin client", oppure si può aggiungere a mano l'utente prescelto nel gruppo "fuse" editando il file /etc/group. Anche numerose macchine fotografiche possono essere collegate in questo modo. La regola generale è che se una periferica si può presentare come "block device" allora probabilmente funzionerà. A meno di recenti novità delle quali non sono a conoscenza non è possibile invece masterizzare cd e dvd direttamente sui thin client, mentre in lettura funzionano normalmente. Non ho mai provato invece a collegare delle stampanti direttamente ai thin client poichè ho sempre avuto la possibilità di utilizzare stampanti di rete, ma pare sia possibile farlo.

Audio

La configurazione dell'audio è stata lunga e faticosa, cominciata quando ancora si era alla edgy usando queste istruzioni. A partire da Feisty la situazione è decisamente migliorata ed i pacchetti necessari sono tutti già presenti di default nei repository. Qua ci sono le istruzioni per Feisty. Come aggiunta personale posso dire che Skype, a dispetto di quanto riportato nei siti linkati prima, non funziona. Non c'è verso, il massimo del risultato che ho ottenuto sono alcuni secondi di funzionamento, dopodichè si pianta inesorabilmente. Se qualcuno dovesse riuscire a farlo funzionare con il demone pulseaudio (non necessariamente su un thin client, non va nemmeno in locale) lo prego anticipatamente di farmi sapere come, perchè sono mesi che ci provo senza successo. Comunque i programmi multimediali più usati (Listen, Rhytmnbox, mplayer, totem etc. etc.) funzionano senza problemi. Per permettere anche al plugin flash di funzionare a dovere in firefox si installa il pacchetto libflashsupport che si trova qua. Le cose cambiano invece riguardo all'utilizzo di microfoni. L'intenzione era quella di mettere a punto il sistema per permettere agli utenti l'utilizzo di software di voip direttamente dai thin client. Per il momento l'unico programma che ha parzialmente funzionato è stato kphone, ma il segnale in ambo le direzioni è risultato pessimo, di fatto non utilizzabile, almeno finchè non avrò la possibilitò di fare nuovi test e messe a punto.
Credo che con l'uscita di Gutsy, ormai prossima, alcuni di questi problemi potranno essere risolti.

Gestione e accesso da remoto ai terminali

Installando il pacchetto thin-client-manager-gnome e tutte le sue dipendenze è possibile utilizzare il pannello di gestione dei thin client. Da questo pannello è possibile fare molte cose, dal mandare messaggi a un utente fino a uccidere o far partire un processo su un thin client. Una delle funzionalità più divertenti è quella di poter visualizzare una miniatura dello schermo su cui stanno lavorando gli utenti. Se questa funzione è decisamente lesiva della privacy degli utenti, abilitandola si ottiene però qualcosa di molto utile: la possibilità di interagire da remoto con l'utente direttamente sul suo desktop. La cosa è assai comoda per fornire supporto agli utenti in caso di bisogno.

La procedura per abilitare il desktop remoto è questa:

chroot /opt/ltsp/i386

mount -t proc none /proc

apt-get install x11vnc

logout

Poi si edita il file /opt/ltsp/i386/etc/rc.local e si inserisce questa riga:

x11vnc -display :6 -forever -loop -shared &

prima di exit 0.

Poi ci si assicura che lo script rc.local venga eseguito all'avvio dei thin client, basta dare questi comandi:

cd /opt/ltsp/i386/etc/rc2.d
ln -s ../init.d/rc.local S99rc.local

se il link esiste già nessun problema, altrimenti viene creato. In questo modo ogni thin client all'avvio farà partire un demone x11vnc in ascolto sulla porta 5900, al quale sarà possibile collegarsi per la gestione remota del desktop.

Con la prossima versione di Ubuntu, la 7.10 denominata Gutsy Gibbon e la cui final release è prevista per il 18 Ottobre 2007, verranno introdotti alcuni cambiamenti nel sistema LTSP. Tanto per citarne alcuni tra i più importanti verrà abbandonato NFS in favore di un più efficiente demone nbdrootd, il root filesystem caricato all'avvio dai client sarà rappresentato da un singolo file immagine e cambierà di posizione il file lts.conf per non dover ricreare l'immagine di root ad ogni modifica. Senza dubbio il progetto è vivo e attivo e mi aspetto che vengano anche risolti alcuni dei problemi e delle limitazioni che ancora sono presenti.

12 commenti:

  1. Leonardo Paolino15 ottobre 2007 13:16

    ciao Enrico, è possibile contattarti in qualche modo (telefono, mail, skype etc)?

    RispondiElimina
  2. Sergio Dicandia23 ottobre 2007 03:10

    Ciao Enrico,
    grazie per gli utilissimi post su Edubuntu. Ho una domanda per te: sui thin client è possibile fare il boot da HD (una partizione separata), lasciando un'altra partizione con Windows (ME, ahimè ...) ? Vorrei lasciare la "scappatoia" agli irriducibili per scegliere in fase di boot (GRUB ?) quale sistema avviare: 1-Windows, 2-Edubuntu (thin client). Grazie mille!

    RispondiElimina
  3. Certamente sì!! Sul sito www.rom-o-matic.net quando crei il file di avvio dalla rete scegli il formato "LILO/GRUB/SYSLINUX loadable kernel format (.zlilo)".
    Il file ottenuto puoi usarlo direttamente con il boot loader. Copialo nella /boot del tuo pc (se è Ubuntu mettilo dove c'è il memtest86). Edita /boot/grub/menu.lst e aggiungi un'istanza di avvio del tutto simile a questa:

    title Ubuntu gutsy, Thin client
    root (hd0,0)
    kernel /eb-5.4.3-eepro100.zlilo
    quiet

    ovviamente modificando parametri e nome file se opportuno.
    Al prossimo avvio nel menu di Grub avrai la possibilità di selezionare l'avvio da rete.
    Provato con grub, funziona bene. Dovrebbe funzionare con qualsiasi altro boot loader.

    RispondiElimina
  4. Sergio Dicandia23 ottobre 2007 09:21

    Grandioso, grazie mille (anche per la tempestività !). Però ho un dubbio: io ho il pc con Win, e ho lasciato una parte di disco disponibile, ancora senza partizioni. Come faccio ? Non vorrei installare Edubuntu sulla partizione, solo lasciare all'utente le due possibilità ... (scusa, non sono praticissimo di Linux ...)

    RispondiElimina
  5. In questo caso credo tu debba lavorare sul file boot.ini. In pratica devi aggiungere una voce al boot.ini (dopo aver fatto ovviamente una copia di backup). Se il file che hai creato con rom-o-matic si chiama "eepro100.zlilo" e tu l'hai salvato in C:, in fondo al boot.ini aggiungi una riga simile a questa:
    c:\eepro100.zlilo="Ubuntu thin client"
    Dovrebbe funzionare, ma non posso provarlo. Forse hai da modificare qualcosa anche in "Proprietà del sistema" -> "Avanzate", ma non credo. Comunque sia non farai fatica a trovare informazioni su come modificare il boot.ini di windows.
    Fammi sapere.

    RispondiElimina
  6. Sergio Dicandia24 ottobre 2007 07:30

    Ottimo, grazie ancora, stasera provo e ti dico.

    RispondiElimina
  7. [...] inserito in un vecchio pc il cdrom per l’avvio dalla rete (preparato come descritto qua) e ho avviato: ha funzionato tutto al primo colpo senza batter ciglio. Tuttavia qualcosa è [...]

    RispondiElimina
  8. [...] * Per chi non avesse idea di che cosa è “l’ambiente chroot” rimando ad un precedente post su ltsp. [...]

    RispondiElimina
  9. Quando dici, in riferimento alle periferiche locali,
    ------
    >Per poter usare tali periferiche è necessario che >siano installati i pacchetti ltspfs, libfuse2 e >fuse-utils.
    ----
    Ti riferisce al sistema 'normale' o dopo aver fatto chroot .. etc.
    Ciao

    RispondiElimina
  10. Al sistema normale.

    RispondiElimina
  11. Ciao, non riesco a far funzionare la "Gestione e accesso da remoto ai terminali" ogni volta che nel chroot installo x11vnc tutti i client si bloccano in avvio ( maschera shell con initfs ), nei log non trovo nulla di anomalo, a quel punto non riesco più a ripristinare il server anche rieseguendo il client build, unica soluzione riinstallare tutto. Mi sapete dire cosa sbaglio, grazie.

    RispondiElimina
  12. Il precedente problema lo ho risolto, non avevo impostato bene i parametri del dns nel dnsmasq.conf , ora però non riesco far funzionare sulla mia ubuntu 7.10 il controllo remoto nel "thin client manager" ottengo sempre il messaggio che il servizio non è disponibile. Ho seguito la procedura esposta nella guida per effettuare l'installazione ma nulla da fare. Mi potete aiutare ?

    RispondiElimina