LTSP¶
Cos’è ltsp ?¶
Parafrasando la presentazione del sito ufficiale di LTSP_
“LTSP è un pacchetto aggiuntivo per linux che permette di collegare molti LTSPTerminal poco-potenti (terminali thin client) ad un server Linux. Tutte le applicazioni lanciate girano tipicamente sul server, in questo modo i vecchi pc avranno solo il compito di visualizzare a video le applicazioni e controllare mouse e tastiera.”
Installazione¶
L’installazione, molto semplice, si limita all’esecuzione di
apt-get install ltsp-server-standalone
Avendo di recente adottato dnsmasq come server dns e dhcp, prima di continuare, disinstalliamo l’eventuale dhcp3-server presente
apt-get remove dhcp3-server
e lo sostituiamo con dnsmasq.
Ora abbiamo tutti gli strumenti per configurare al meglio il nostro sistema LTSP.
Analisi ed installazione delle componenti di un sistema LTSP ISI¶
Cosa permette di fare LTSP
Immaginiamo di avere un laboratorio con tanti pc (client) datati abilitati al boot da rete ed un server LTSP prestante. Immaginiamo ora di accendere ora tutti i nostri client e scoprire che stanno avviando un sistema operativo che non avevano installato da nessuna parte, magari un sistema ubuntu ultima versione... Immaginiamo anche di autenticarci, lanciare openoffice, usare applicativi didadattici, il tutto con performance degne di un pc ultimo modello. Questo e solo uno dei vantaggi che un sistema LTSP può offrire. Non volete rinunciare al sistema operativo attualmente installato sui vostri client e preferite risparmiarvi un partizionamento? LTSP fa per voi. Avete un laboratorio con hardware nuovo? LTSP cambierà modalità di funzionamento e vi permetterà di sfruttare al 100% le potenzialità del client!
Durante l’avvio via rete(netboot), ogni client scarica dal server una immagine minimale del sistema operativo da utilizzare. Questa immagine, di tipo squashfs, è il frutto della compressione di una directory(chroot) contenente tutti i file del sistema operativo(noi useremo ubuntu) da passare ai client.
chroot¶
Le chroot dei thinclient/fatclient, le immagini cioè che vengono compresse e poi rese disponibili ai client, una volta create con il comando ltsp-build-client, si troveranno in /opt/ltsp/<nome-chroot>. E` a questi sistemi che dovremo apportare tutte le nostre modifiche per personalizzare i nostri client.
| .: | |
|---|---|
| .: |
Immagine squashfs della chroot¶
E’ l’immagine squashfs creata a partire dalla chroot che verrà concretamente passata ai client tramite il servizio nbdrootd. Tutte le immagini squashfs generate con il comando ltsp-update-image, a partire dalle varie chroot, verranno create, di default, in /opt/ltsp/images/ e avranno nome nella forma <nome-chroot>.img.
inetd¶
La configurazione del superdemone inetd consente di lanciare istanze di nbdrootd solo quando necessario. Il file di configurazione del servizio è /etc/inetd.conf, che andrà modificato definendo su che dovrà rendere disponibile una determinata immagine squashfs. Nella configurazione seguente si fa uso di due immagini (thinclient e fatclient)
2000 stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/nbdrootd /opt/ltsp/images/i386.img
2001 stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/nbdrootd /opt/ltsp/images/fati386.img
Nota
dopo ogni modifica di inetd.conf
dopo ogni modifica apportata al file inetd.conf, non si dimentichi di riavviare inetd con
killall -HUP inetd
od, in alternativa, si restarti il servizio con
/etc/init.d/openbsd-inetd restart
dnsmasq¶
La configurazione ISI prevede di utilizzare /etc/isi/dnsmasq/boot come unico file in cui definire quali informazioni verranno passate ai client via dhcp. Si potrà approfondire le modifiche alla configurazione standard di dnsmasq per sistemi ISI nella sezione relativa. Affinchè i client si avviino via rete correttamente, dnsmasq dovrà essere configurato per fornire ai PXE nativi( od eventuali gPXE) delle stazioni thinclient alcune informazioni :
il percorso completo in cui trovare l’immagine pxelinux.0 omettendo la root del server tftp /var/lib/tftpboot/
/ltsp/i386/pxelinux.0
Il server ltsp al quale puntare (passato via tag dhcp tag next-server).
es.
192.168.0.251
Ipotizzando di voler avviare i client aventi tag ns1_thin con l’immagine fornita dal server avente ip 192.168.0.251 e hostname SRV-SEDE, usando l’immagine pxelinux.0 /ltsp/i386/pxelinux.0, si potrà usare la linea seguente
dhcp-boot=net:ns1_thin,/ltsp/i386/pxelinux.0,SRV-SEDE,192.168.0.251
Nota
Non ci si dimentichi di effettuare il reload della configurazione di dnsmasq dopo aver modificato /etc/isi/dnsmasq/boot
/etc/init.d/dnsmasq force-reload
definizione kernel da usare: il file default
In /var/lib/tftpboot/ltsp/<nome-chroot>/pxelinux.cfg/default troveremo il file default relativo alla chroot in uso. Questo file, scaricato da pxelinux.0 durante la fase di netboot, definisce quale kernel e initrd scaricare via tftp e quali parametri passare al kernel in fase di boot.
Esempio di /var/lib/tftpboot/ltsp/<nome-chroot>/pxelinux.cfg/default
DEFAULT vmlinuz ro initrd=initrd.img quiet splash nbdport=2000
Analizzandone le direttive usate:
- quiet silenzia l’output prodotto durante l’esecuzione dell’initrd.
- splash nasconde il normale output del terminale sostituendolo con la splash screen di ubuntu( la barra di caricamento).
- nbdport è il parametro forse più importante e determina su quale porta del server cercheremo l’immagine squashfs da usare per il nostro thin-client. Ad ogni porta corrisponde una determinata immagine. Come già accennato in precedenza, le associazioni porta-immagine vengono definite in /etc/inetd.conf.
Server TFTP¶
Con l’installazione dei pacchetti LTSP, viene installato di default anche il server tftpd-hpa. Non dovrebbe quasi mai servire metter mano alla sua configurazione ma in caso contrario il file di riferimento è /etc/default/tftpd-hpa. In questo file possiamo ridefinire la root del tftp server
OPTIONS="-l -s /var/lib/tftpboot"
Od aggiungere ulteriori opzioni, magari per abilitarne la verbosità, aggiungendo “-v”, “-vv”, etc... . Per tutte le opzioni si faccia riferimento alla manpage.
Dopo aver parlato della tftp-root, forniamo qualche informazione in più circa la sua ramificazione interna ed i suoi contenuti, facendo sempre riferimento al nostro contesto reale con due chroot: fati386 e i386.
/var/lib/tftpboot/ltsp/
|-- fati386
| |-- System.map-2.6.24-16-generic
| |-- abi-2.6.24-16-generic
| |-- config-2.6.24-16-generic
| |-- initrd.img
| |-- initrd.img-2.6.24-16-generic
| |-- nbi.img
| |-- nbi.img-2.6.24-16-generic
| |-- pxelinux.0
| |-- pxelinux.cfg
| | `-- default
| |-- vmlinuz
| `-- vmlinuz-2.6.24-16-generic
|-- i386
| |-- System.map-2.6.24-16-generic
| |-- abi-2.6.24-16-generic
| |-- config-2.6.24-16-generic
| |-- initrd.img -> initrd.img-2.6.24-16-generic
| |-- initrd.img-2.6.24-16-generic
| |-- nbi.img -> nbi.img-2.6.24-16-generic
| |-- nbi.img-2.6.24-16-generic
| |-- pxelinux.0
| |-- pxelinux.cfg
| | `-- default
| |-- vmlinuz -> vmlinuz-2.6.24-16-generic
| `-- vmlinuz-2.6.24-16-generic
`-- lts.conf
Gestione della chroot : thinclient¶
Creazione di una nuova chroot¶
Per creare una chroot ltsp thin basta lanciare
ltsp-build-client
Il comando**ltsp-build-client** esegue le seguenti operazioni :
- crea in /opt/ltsp/i386 un ambiente chroot minimale.
- crea l’immagine squashfs /opt/ltsp/images/chroot-name.img.
- aggiorna di conseguenza /etc/inetd.conf assicurandosi che l’immagine squashfs venga esportata correttamente, via nbdrootd, su una data porta (definendone una nuova se già in uso o assente).
- aggiorna il contenuto di /var/lib/tftboot/<nome-chroot> creando una struttura come quella mostrata a titolo d’esempio nella struttura.
Scelta di un’architettura differente¶
Lanciando ltsp-build-client senza usare l’opzione “-arch <architettura>”, la chroot generata dal comando avrà architettura uguale a quella di sistema.
Se si stesse usando quindi un server con architettura amd64 ma si ma volesse generare una chroot i386, si dovrà lanciare
ltsp-build-client --arch i386
Un’altra opzione che si vorrà probabilmente utilizzare in fase di creazione della chroot è -prompt-rootpass. Questa opzione fa sì che al termine della creazione della chroot venga richiesto di impostare una password per l’account del suo utente root( l’account di root in chroot è disabilitato di default). Non ricorrendo alla spracita opzione, per utilizzare l’utente root in chroot bisognerà prima abilitarma manualmente chrootandovisi.
Installazione di nuovo software nella chroot¶
Prima di poterci chrootare nel sistema appena generato, dovremo innestarvi alcuni filesystem del sistema reale
mount /proc -t proc /opt/ltsp/<nome-chroot>/proc
mount /sys -t sysfs /opt/ltsp/<nome-chroot>/sys
mount -o bind /dev /opt/ltsp/<nome-chroot>/dev
Una volta montato il necessario, potremo chrootarci lanciando
chroot /opt/ltsp/<nome-chroot>
Da questo momento in poi saremo in grado di installare pacchetti e modificare la configurazione a piacimento. Terminate le modifiche, si potrà uscire dalla chroot con il comando exit o premendo control+D.
Nota
Ci si ricordi di smontare, in ultimo, le risorse montate in precedenza
umount /opt/ltsp/<nome-chroot>/*
od eventualmente ricorrendo all’opzione -l (lazy) in caso non si riesca a smontare il filesystem perchè misteriosamente occupato e si sa cosa si sta facendo
umount -l /opt/ltsp/<nome-chroot>/*
Aggiornamento¶
Il processo di aggiornamento consiste nella rigenerazione dell’immagine squashfs. L’operazione, che dev’essere eseguita dopo ogni modifica apportata alla chroot, si effettua lanciando il comando
ltsp-update-image -a <nome-chroot>
Nota
E` possibile specificare anche la porta su cui rendere disponibile l’immagine via nbdrootd con l’opzione -p od il nome della chroot con -a.
Gestione della chroot : fatclient¶
Cos’è in breve¶
Una chroot di tipo fat altro non è che una chroot di tipo thin con le seguenti varianti :
- non usa LDM ma GDM (o KDM).
- non usando LDM, effettua connessione al server X locale anzichè al server LTSP remoto.
- tutti i programmi voluti vanno installati direttamente nella chroot e non più sul server.
- anche gli aggiornamenti vanno effettuati in chroot
- la rigenerazione dell’immagine fat impiega molto più tempo rispetto alla rigenerazione della thin.
Creare una nuova chroot fat¶
Prima di cominciare, attiviamo tutti i repository utilizzati(quelli voluti) dal server nella chroot, sostituendo il file /opt/ltsp/<nome-chroot>/etc/apt/sources.list con /etc/apt/sources.list
cp /etc/apt/sources.list /opt/ltsp/<nome-chroot>/etc/apt/sources.list
Aggiorniamo quindi le lista dei repository eseguendo apt-get update all’interno della chroot.
Per creare una chroot di tipo fat si crea una chroot di tipo thin e si continua installando i pacchetti aggiuntivi gdm (il default per i thinclient è di usare LDM), gnome ed altri pacchetti base
gdm gnome gnome-mount ubufox ubuntu-artwork bluez-cups cups-pdf cupsddk \
cupsddk-drivers cupsys cupsys-bsd cupsys-client cupsys-common \
cupsys-driver-gutenprint hal-cups-utils libcupsimage2 libcupsys2 \
libgnomecups1.0-1 python-cups system-config-printer-gnome \
system-config-printer-common
Nota
Abbiamo incontrato problemi con l’avvio di gdm. Tale problema e’ stato aggirato sostituendo GDM con KDM. Abbiamo dunque installato kdm
apt-get install kdm
e, quando richiesto, l’abbiamo impostato default.
Installiamo poi ulteriori pacchetti:
per accedere al dominio
ldap-auth-client libpam-ldap libnss-ldap ldap-utils nfs-common
di localizzazione
language-pack-gnome-it language-pack-gnome-it-base language-pack-it \ language-pack-it-base language-pack-kde-it language-pack-kde-it-base \ language-support-it language-support-translations-it \ language-support-writing-it
Nota
Durante l’installazione dei pacchetti, solitamente si incappa nel seguente errore
Processing triggers for libc6 ...
ldconfig deferred processing now taking place
Sono occorsi degli errori processando:
policykit
hal
policykit-gnome
gnome-mount
E: Sub-process /usr/bin/dpkg returned an error code (1)
Per porvi rimedio, si lanci
dpkg --configure -a
L’output risultante dovrebbe cambiare in
root@srv-ubuntu:~# sudo chroot /opt/ltsp/fati386 dpkg --configure -a
Configuro hal (0.5.11~rc2-1ubuntu7) ...
* Reloading system message bus config... [ OK ]
* Can't start Hardware abstraction layer - detected chrooted session
Configuro gnome-mount (0.8~svn20080225-0ubuntu4) ...
Passiamo ora alla configurazione del sistema. La prima cosa da fare è assicurarci che il sistema sia in grado di risolvere correttamente i nomi host. Per fare ciò, impostiamo in /etc/resolv.conf l’ip del nostro server dns. Continuiamo quindi con la configurazione del sistema affinchè possa accedere al dominio.
Non resta che configurare il fatclient affinchè possa montare automaticamente la /home esportata via nfs dal server come :file`/home` locale. Facciamo un piccolo hack della script /etc/init.d/ltsp-client-setup sostituendo
configure_fstab() {
if [ -z "$CONFIGURE_FSTAB" ] || boolean_is_true "$CONFIGURE_FSTAB" ; then
echo "/dev/root / unionfs defaults 0 0" > /etc/fstab
echo "tmpfs /tmp tmpfs defaults,nosuid,nodev 0 0" >> /etc/fstab
mount /tmp
fi
}
con
configure_fstab() {
if [ -z "$CONFIGURE_FSTAB" ] || boolean_is_true "$CONFIGURE_FSTAB" ; then
echo "/dev/root / unionfs defaults 0 0" > /etc/fstab
echo "tmpfs /tmp tmpfs defaults,nosuid,nodev 0 0" >> /etc/fstab
mount /tmp
echo "srv:/home /home nfs defaults,rw 0 0" >> /etc/fstab
mount /tmp
mount /home
fi
}
Nota
Il server dns impostato in /etc/resolv.conf deve poter risolvere srv nell’ip del server che esporta la /home.
Aggiornamento¶
Il processo di aggiornamento della chroot fat è identico a quello già visto con la chroot del thinclient.
Rendere i client controllabili da remoto grazie a openssh¶
Per installare il demone ssh sui thin/fat client e fare in modo che l’utente root possa accedervi direttamente senza password, previa creazione delle necessarie chiavi dsa per l’utente root, si potrà procedere come indicato di seguito.
Impostiamo in due variabili d’ambiente il percorso completo della chroot e la password che vogliamo venga assegnata all’utente root della chroot
chroot_ltsp=/opt/ltsp/i386
root_pw=passwordsegretissima
Facciamo poi copia-incolla dei seguenti comandi
umount $chroot_ltsp/*
mount --bind /dev $chroot_ltsp/dev
mount --bind /proc $chroot_ltsp/proc
mount --bind /sys $chroot_ltsp/sys
chroot $chroot_ltsp apt-get -y install openssh-server
[ ! -z "$root_pw" ] && chroot $chroot_ltsp echo "root:$root_pw"|chpasswd
mkdir -p $chroot_ltsp/root/.ssh
cat /root/.ssh/*.pub >> $chroot_ltsp/root/.ssh/authorized_keys
chmod 644 $chroot_ltsp/root/.ssh/authorized_keys
umount $chroot_ltsp/*
E, quando richiesto, inseriamo la password di root.