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

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.