Internet Point Seamen's Club/Relazione tecnica implementazione rete
Da Faber Libertatis.
Questo documento è una relazione!
Indice della pagina |
Problemi dell'installazione Kubuntu+LTSP
Stampare da (K)ubuntu su una una stampante condivisa in Windows XP
(K)Ubuntu installa automaticamente il pacchetto samba-common che contiene alcuni applicativi per collegarsi alle condivisioni di Windows. Nel nostro caso ho modificato il file /etc/samba/smb.conf associando a workgroup il valore del workgroup configurato nei computer Windows (nel nostro caso stellamaris), e quindi tentato si effettuare un list delle condivisioni nell'host che condivide la stampante con il comando:
$ smbclient -l stellaXXX
Non ho ricevuto una risposta corretta fino a quando non ho inserito la seguente riga nel file /etc/hosts
192.168.x.XXX stellaXXX.stellamarisfriends.org stellaXXX
Mi sono infatti accorto che nel tentativo di risolvere l'hostname con NetBIOS (come avviene comunemente in Windows quando si accede alle risorse di rete della rete locale) mi veniva restituito un indirizzo di rete sbagliato, per esempio effettuando un ping all'host Windows:
$ ping stellaXXX
A quel punto il comando smbclient mi dava il corretto indirizzo e potevo anche navigare con Konqueror tra le cartelle condivise di stellaXXX.
A questo punto ho tentato di configurare la stampante con System Settings di KDE, ma, ottenendo errori a riguardo di una assenza di permessi, ho provato anche ad abilitare la modalità di amministrazione (che richiede di inserire la password dell'amministratore), ma senza risultato.
Ho poi scoperto che era una causa di una configurazione parziale dell'utente cupsys con cui viene eseguito CUPS, il sistema di stampa predefinito di (K)Ubuntu. Ho aggiunto dunque l'utente al gruppo shadow con il comando
# adduser cupsys shadow
riavviato il sistema CUPS con
# /etc/init.d/cupsys restart
e poi mi sono assicurato che l'utente amministratore facesse parte del gruppo lpadmin con il comando
# adduser manichen lpadmin
Ho dunque proceduto alla configurazione della stampante per mezzo dell'interfaccia web di CUPS. Per accedervi avviare un browser (Firefox), aprire l'indirizzo http://localhost/631 e seguire la seguente traccia di operazioni:
- clicca su "Add Printer";
- Inserisci almeno il nome della stampante, senza gli spazi, tipo HPLaserJet1000, ed eventualmente gli altri campi e cliccare su "Continue";
- Selezionare il Device "Windows Printer via SAMBA" e cliccare su "Continue";
- Inserire il Device URI tipo smb://stellaXXX/hpLaserJ dove stellaXXX è il nome NetBIOS del computer Windows che condivide la stampante e hpLaserJ è il nome della stampante condivisa (lo si vede anche con il comando smbclient -l stellaXXX), e cliccare su "Continue";
- Scegliere il produttore, nel nostro caso HP, e cliccare su "Continue";
- Selezionare il modello di stampante, nel nostro caso HP LaserJet 1000, preferendo il driver raccomandato, nel nostro caso foo2zjs e premere su "Add printer";
- A questo punto inserire nome utente e password dell'utente amministratore;
- Effettuare un test di stampa dall'interfaccia Web e dagli utenti.
GDM, KDM e XDM
Il Desktop Manager è un componente fondamentale di una qualsiasi installazione di una rete di Thin-Client. È generalmente installato sullo stesso computer in cui è esecuzione il server e svolge la funzione di fornire l'accesso al server X da parte dei client e di autentificare gli utenti che generalmente sono utenti locali, quindi elencati nel file /etc/passwd e autentificati con password contenute nello stesso file oppure nel file /etc/shadow.
Definito quindi SERVER come l'hostname o l'indirizzo IP del server X dove è in esecuzione il Desktop Manager, alla conclusione della fase di boot e inizializzazione del client, questo avvierà il server X locale con un comando di questo tipo:
$ X -query $SERVER
e stabilirà una connessione XDMCP tra il client ed il server, se questo naturalmente sarà configurato per accettare la connessione.
I Desktop Manager più importanti sono tre:
- XDM, fornito dagli stessi sviluppatori del server X, sia esso XFree86 o X.org, ha una richiesta minimale di risorse e offre il minimo indispensabile di feature, ma è estremamente stabile;
- KDM, si integra con le librerie grafiche di KDE e viene installato automaticamente in Kubuntu e nelle altre distribuzione che adottano prevalentemente questo ambiente grafico, la sua configurazione è simile a quella di XDM;
- GDM, è il corrispettivo per Gnome ed ha una configurazione completamente diversa da quella dei concorrenti.
Gli ultimi due dispongono di programmi grafici di configurazione.
Abilitare le connessioni XDMCP in XDM
Installare il pacchetto xdm con tutte le sue dipendenze con il comando
# apt-get install xdm
Nel caso siano installati più Desktop Manager verrà chiesto a prompt di indicare quale abilitare.
- Commentare la riga "DisplayManager.requestPort: 0" presente nel file /etc/X11/xdm/xdm-config. Questo permetterà di accettare le connessioni XDMCP in generale.
- Assicurarsi che in /etc/X11/xdm/Xaccess (fare attenzione a rispettare le maiuscole) vi sia una riga contente come primo carattere un asterisco (*) e senza altre impostazioni a seguire, non influenzano eventuali commenti sulla stessa linea preceduti da un cancelletto (#). Generalmente basta eliminare il segno di commento da una riga del file di configurazione. Questo consente di accettare tutte le connessioni da qualsiasi host della rete.
- Valutare se sia il caso di attivare un X Font Server, in alternativa è necessario che nella configurazione di X nei client sia contenuta una lista di percorsi dove trovare delle collezioni di caratteri da usare per visualizzare a video le scritte.
Per attivare un XFS in Ubuntu installare il pacchetto xfs con
# apt-get install xfs
e commentare nel file /etx/X11/fs/config la riga
no-listen = tcp
quindi riavviare XFS con
# /etc/init.d/xfs restart
Per migliorare la sicurezza si consiglia di intervenire sul firewall del server per limitare l'accesso alla porta UDP 177, dove vengono accettate le connessioni XDMCP, e, nel caso del server XFS, alla porta TCP 7100, con dei comandi del tipo:
# iptables -I INPUT -i eth0 -s ! $NETWORK/$NETMASK -p udp --dport 177 -j DROP # iptables -I INPUT -i eth0 -s ! $NETWORK/$NETMASK -p tcp --dport 7100 -j DROP
Per cambiare l'aspetto grafico della schermata, come colori, immagini e scritte, intervenire sul file /etc/X11/xdm/Xresources.
Abilitare le connessioni XDMCP con KDM
Le impostazioni sono quasi le stesse di XDM, in Ubuntu corrispondono alle seguenti operazioni:
- in /etc/kde3/kdm/kdmrc, dopo la sezione [Xdmcp] impostare "Enable" a "true";
- come in XDM ma il file Xaccess si trova in /etc/kde3/kdm/.
Abilitare le connessioni XDMCP con GDM
Si modifica il valore di "Enable" a "true" nel file /etc/gdm/gdm.conf.
Problemi riscontrati
Sono stati presentati questi tre diversi Desktop Manager perché nel corso dell'installazione si sono incontrati dei problemi.
KDM, installato assieme a Kubuntu, ha un comportamento insolito: quando un terminale si disconnette, il processo X sul client si riavvia realizzando una nuova connessione con il server X, questo provoca un passaggio brusco ed improvviso dell'immagine sullo schermo del server dal terminale virtuale attivo, generalmente il settimo dove si trova il display grafico, alla modalità framebuffer del boot di Kubuntu, con tanto di logo su sfondo nero.
Il comportamento si ripete uguale che su un Pentium III dove ho testato la configurazione quindi non è da imputare al fatto che l'architettura del server sotto sotto sia una AMD64.
In quanto si prevedeva che un utente si potesse sedere anche sulla postazione del server, e potesse essere infastidito dal fatto di vedersi sparire a tratti il monitor, si è tentato GDM, ma anche questo presenta un problema forse più grosso ancora: semplicemente GDM crasha e dopo il logout gli utenti remoti non riescono più a ottenere un'interfaccia di login e l'utente loggato sul server si ritrova su un terminale testuale dopo il logout. Questo problema si è verificato anche sul mio computer di test dopo un aggiornamento quindi è da imputare alla particolare versione di GDM.
Come ultima soluzione si è dunque ricorso a XDM, seppure si presenti la necessità di abilitare il login automatico di un utente distinto per ogni postazione, cosa non facile con questo Desktop Manager.
HotSpot Wireless Zyxel G-4100
Il SeaMen's Club utilizza un dispositivo particolare che integra un access point, uno switch con 4 porte ethernet, collegamento WAN assieme ad un sistema di accounting e billing per la vendita di accessi ad internet di qualche ora agli utenti dell'internet point.
L'hotspot è stato collegato con l'interfaccia WAN alla rete 10.x.y.0/24 che comprende un router/firewall/DNS basato su IPCop che fa da default gateway e che e' il 10.x.y.z. Nella stessa rete si trovano il server e i client del sistema precedente di autentificazione cioè il CyberCafè Pro (TM). Un'interfaccia LAN è collegata invece agli hub che connettono i thin-client, i server LTSP e altri PC Windows alla rete 192.168.x.0/24. L'hotspot amplia la rete LAN anche ai dispositivi wireless fornendo la funzione di DHCP server ed una rete non criptata con ESSID "SEAMENS CLUB"
Un utente che voglia collegarsi ad internet sia con una postazione che con un laptop personale deve registrarsi con il proprio documento personale, quindi acquistare del traffico, viene allora stampato uno scontrino contenente il login e la password. Una volta avviato un browser appena si tenta di aprire una pagina nel Web la connessione viene rediretta verso una sito fasullo http://1.1.1.1 dove viene richiesto l'inserimento del login e della password. Appena l'utente si autentifica l'hotspot concede che l'utente navighi per un tempo fissato sulla base del valore dell'account sottoscritto. Nel caso si voglia interrompere la navigazione, per non perdere la quota di tempo di navigazione acquistata si deve essettuare il logout alla pagina http://1.1.1.1/info. Dalle prove effettuate e dalla lettura del manuale dell'apparato risulta che l'hotspot agisce bloccando o inoltrando il traffico di rete identificandolo sulla base del MAC Address. Il MAC Address identifica univocamente la scheda di rete ed è contenuto all'interno del frame di livello due nelle reti Ethernet. Quindi tutto il traffico diretto dalla rete di thin-client verso Internet viene prodotto dal solo server ed è associato al solo MAC Address della scheda di rete del server. Nonostante sia possibile associare più indirizzi IP virtuali ad una interfaccia di rete e trasmettere le comunicazioni a livello rete modificando l'indirizzo IP sorgente, non è possibile fare altrettando con i MAC Address: è possibile cambiare l'indirizzo hardware di un'interfaccia e gestire il routing a livello di collegamento dati attraverso un bridge ed il comando ebtables, ma affinché il traffico esca è necessario che il MAC Address appartenga ad una delle interfacce reali esistenti nel sistema. L'idea di installare più interfacce di rete è stata scartata per vari motivi pratici.
E' necessario dunque che il traffico di rete dei singoli utenti seduti alle postazioni si origini dai terminali stessi. Questo si può fare in due modi...
- eseguire le applicazioni di rete (Firefox, Gaim etc.) sui client;
- recuperare le informazioni in rete attraverso un proxy (Squid) in esecuzione sui client che serva le applicazioni di rete (Firefox, Gaim (?)) in esecuzione sul server...
Nel primo e nel secondo caso il primo problema da affrontare è installare l'applicazione o il proxy all'interno della chroot dei client LTSP. Se si ricorre ai pacchetti forniti da LTSP bisogna compilare l'applicazione e tutte le dipendenze attraverso LBE, l'LTSP Building Environment. Altra possibilità è ricorrere ad una installazione di LTSP basata sui pacchetti di una normale distribuzione, generalmente la stessa che si è installata sul server. Questo è realizzato in Ubuntu attraverso alcuni script contenuti in alcuni dei pacchetti dell'installazione standard di Edubuntu. Si predilige dunque questa opzione. Premettiamo comunque che è possibile impostare le ultime versioni di Gaim per utilizzare un proxy opportunamente impostato, ma alcuni protocolli come Yahoo (TM) hanno recentemente cambiato il sistema di autentificazione e reso impossibile l'utilizzo del proxy in Gaim con questo protocollo. Si prevede dunque di installare e avviare un proxy Squid sui client, e impostare Firefox per utilizzare come proxy quello in esecuzione sul client che ha l'hostname uguale al nome dell'utente. Anche Gaim viene installato sui client e avviato come applicazione locale e la scelta è caduta su Gaim perchè richiede di meno dipendenze rispetto a Kopete.
Installare LTSP con i pacchetti di Ubuntu
Innanzitutto assicurarsi di disporre delle ltsp-utils attraverso la repository oppure dal sito di LTSP. Per esempio dare i comandi:
$ wget http://ltsp.mirrors.tds.net/pub/ltsp/utils/ltsp-utils_0.25_all.deb # dpkg -i ltsp_0.25_all.deb
Prima di eseguire il programma ltspadmin è necessario installare anche il pacchetto libwww-perl:
# apt-get install libwww-perl
Installare dunque i pacchetti ltsp-server e ltsp-server-standalone (con le relative numerose dipendenze)
# apt-get install ltsp-server ltsp-server-standalone
Il primo problema che si incontra è che con questi pacchetti si installa un file /etc/ltsp/dhcpd.conf che ha la precedenza su /etc/dhcp3/dhcpd.conf, e naturalmente il nuovo file di configurazione non è compatibile con la nostra configurazione, per cui rinominiamo quel file per non farlo rilevare e riavviamo il servizo:
# mv /etc/ltsp/dhcpd.conf /etc/ltsp/dhcpd.conf~ # /etc/init.d/dhcp3-server restart
Se si vuole ottenere un immagine del kernel e dell'Init Ram Disk che sia avviabile in Ether-Boot bisogna installare il pacchetto mknbi che contiene il comando mkelf-linux per generare un unico file che contenga l'immagine compressa del kernel, l'initramfs e le impostazioni di avvio del kernel stesso.
# apt-get install mknbi
La chroot viene generata dal comando ltsp-build-client che scarica i pacchetti necessari dalle repository ufficiali di Ubuntu. Nel nostro caso la ridotta banda della connessione ci ha condotti ad installare una repository locale in un PC Linux della rete interna, abbiamo dunque avviato l'installazione con il seguente comando:
# build-ltsp-client --root /opt/ltsp/i386 --mirror http://192.168.x.y/ubuntu/dapper --dist dapper --arch i386
Si noti che ho dato l'indirizzo di rete della repository locale in quanto l'operazione di download dei pacchetti si divide in due parti, di cui la seconda viene eseguita all'interno della chroot, che non dispone di una file /etc/hosts con l'associazione degli indirizzi di rete e degli hostname.
È necessario poi cambiare le impostazioni dei file di configurazione di alcuni dei servizi precedentemente installati.
In /etc/dhcp3/dhcpd.conf sostituire "filename" e "option root-path" con le nuove impostazioni ottenendo qualcosa di questo tipo:
subnet 192.168.x.0 netmask 255.255.255.0 {
filename "ltsp/nbi.img";
option root-path "/opt/ltsp/i386";
host stellaXXX {
hardware ethernet 00:01:02:03:04:05;
fixed-address 192.168.x.XXX;
}
}
Si noti che all'inizio dell'opzione "root-path" non troviamo più l'indirizzo del server NFS, in quanto questo viene automaticamente inserito dagli script di inizializzazione di LTSP/Ubuntu. Poi riavviare il servizio DHCP:
# /etc/init.d/dhcp3-server restart
In /etc/exports aggiungere la riga
/opt/ltsp 192.168.x.0/255.255.255.0 (ro,no_root_squash,sync)
e riavviare NFS con il comando
# /etc/init.d/nfs-kernel-server restart
Non resta che copiare il file lts.conf nella nuova chroot
# cp /opt/ltsp-4.2/i386/etc/lts.conf /opt/ltsp/i386/etc
Ma una volta avviato il client con il metodo consueto ci si accorgerà che alla schermata di login del Desktop Manager la tastiera non risponde. Questo problema è dovuto al fatto che in un avvio standard di LTSP il desktop grafico di X occupa il terminale virtuale 1 (vt1) per via della riga
SCREEN_01 = startx
nel file di configurazione /opt/ltsp/i386/etc/lts.conf. Invece in LTSP/Ubuntu si avviano i consueti 6 terminali testuali che occupano i primi 6 terminali virtuali (vt1-6) ed il server grafico si trova in vt7. Si consiglia di disabilitare i terminali testuali, inutili in una configurazione simile, che inoltre occupano memoria andando a commentare le seguenti righe nel file /opt/ltsp/i386/etc/inittab
#1:2345:respawn:/sbin/getty 38400 tty1 #2:23:respawn:/sbin/getty 38400 tty2 #3:23:respawn:/sbin/getty 38400 tty3 #4:23:respawn:/sbin/getty 38400 tty4 #5:23:respawn:/sbin/getty 38400 tty5 #6:23:respawn:/sbin/getty 38400 tty6
e mantenere nel file di configurazione lts.conf la riga precedentemente citata.
Applicazioni locali in LTSP+Ubuntu
Installazione di SSHD sui client
Per prima cosa è necessario fare in modo che all'avvio i client dispongano di un server sshd per connettersi al sistema in esecuzioni su queste macchine, abbiamo infatti rimosso i terminali testuali che avrebbero permesso di eseguire dei comandi sulle macchine, cosa che non volevamo succedesse in un terminale destinato al solo utilizzato grafico. Il server sshd ci tornerà utile sia per controllare lo stato dei client che per eseguirvi dei comandi, come per esempio Gaim. Per installare il pacchetto contenente sshd, cioe' il pacchetto openssh-server dovremo effettuare un chroot all'interno della root che viene montata via NFS dai client LTSP e installarvi il pacchetto, prima pero' assicuriamoci che il sistema APT sia opportunamente configurato controllando che il file /opt/ltsp/i386/etc/apt/source.list contenga una configurazione adatta, nel nostro caso
deb http://192.168.x.y/ubuntu/dapper dapper main restricted
Quindi assicurarsi che anche il nostro sistema LTSP server sia dotato del pacchetto. Il motivo sta nel fatto che all'atto dell'installazione del pacchetto nella chroot questo dopo essere configurato effettua l'avvio del server, il quale va in esecuzione sul server, quindi è meglio averlo già in esecuzione. Si dia dunque il comando
$ dpkg -l openssh-server
dovesse informarci che il pacchetto non è installato, eseguiamo
# apt-get install openssh-server
e poi installiamolo anche nella chroot
# chroot /opt/ltsp/i386 (chroot)# apt-get install openssh-server (chroot)# passwd (chroot)# exit
Dopo il comando passwd ci sarà chiesta una password per autentificare l'utente root, infatti root non ha una password in una installazione vergine di Ubuntu, e nel caso dell'installazione di LTSP, non ci sono nemmeno altri utenti che dispongano di una shell, per cui se vogliamo accedere al client e ottenere una shell dobbiamo digitare la password di root e preventivamente fornirla. Attenzione perchè questa password sarà condivisa da tutti i client. Nel corso dell'installazione del pacchetto verranno mostrati a terminale una serie di errore a riguardo di una cattiva configurazione delle variabili di ambiente, non ve ne preoccupate a meno di volere che le interfacce dei programmi utilizzino una lingua diversa dall'Inglese. Notare inoltre che nella fase di configurazione del pacchetto vengono generate le chiavi RSA1, RSA e DSA che poi ci saranno necessarie.
Installare il proxy Squid
Installare Squid è una facile operazione, alla stregua di quanto già fatto per sshd
# chroot /opt/ltsp/i386 (chroot)# apt-get install squid (chroot)# exit
All'avvio automatico del servizio otterremo un errore, poco male dato che non era nostra intenzione avviare il servizio in questo momento, ma l'errore segnalato si verifica anche se tentiamo di avviare il servizio su un client. Squid non riesce infatti a determinare l'hostname "fully qualified" nella macchina in cui stiamo cercando di eseguirlo, i client infatti si ritrovano con l'hostname a "(none)" e naturalmente questo non è associato all'indirizzo di rete del computer né nel file /etc/hosts né attraverso un'interrogazione ad un server DNS. Per risolvere questo problema si può procedere in due modi, di cui uno lo scartiamo subito ed è quello di andare a modificare il file di configurazione di Squid /etc/squid/squid.conf dichiarando l'hostname con il parametro visible_hostname, in quanto dovremo generare un file di configurazione diverso per ogni client. Preferibile invece far riconoscere l'hostname a Squid automaticamente. Ciò è possibile copiando il file /etc/hosts nella chroot fornendo dunque la corrispondenza tra indirizzo di rete e hostname di tutti gli host della nostra rete di thin-client. Il comando è:
# cp /etc/hosts /opt/ltsp/i386/etc
C'e' poi da risolvere il problema che il client viene avviato senza che gli venga inizializzato opportunamente l'hostname. Ciò viene effettuato in fase di inizializzazione dallo script /opt/ltsp/i386/etc/init.d/hostname.sh, che dovrebbe utilizzare l'hostname fornito dal server DHCP durante la configurazione della rete, ma questo non avviene. Ho dunque deciso di impostare l'hostname sulla base dell'indirizzo di rete, aggiungento cioè al prefisso stella- l'ultimo byte dell'indirizzo IP, con un comando come questo tipo da inserire in maniera opportuna nel file /opt/ltsp/i386/etc/init.d/hostname.sh:
HOSTNAME = stella`ifconfig eth0 | grep "inet addr:" | grep -v "127.0.0.1" | cut -d: -f2 | awk '{ print $1 } | cut -d. -f4'`
[ -z "$HOSTNAME"] && hostname "$HOSTNAME"
Infine è necessario configurare le ACL di Squid per permettere al solo server LTSP di usufruire del servizio di proxy. Per farlo decommentare e modificare le seguenti righe nel file di configurazione /opt/ltsp/i386/etc/squid/squid.conf:
acl our_network src 192.168.x.y http_access allow our_network
Dove 192.168.x.y è l'indirizzo di rete del server LTSP. Una volta riavviati i client, oppure dopo aver eseguiro un comando del genere
$ ssh root@stellaXXX -c /etc/init.d/squid start
per i singoli client, potremo configurare il browser dell'utente ad usare il proxy in esecuzione sul suo client, per fare questo un singolo utente deve sempre loggarsi alla stessa macchina, possibile se non si prevede di creare un id per ogni cliente del servizio di internet point.
Autentificare l'accesso ssh ai client con NIS
Abbiamo un server sshd in esecuzione sui client e digitando da un terminale sia sul server che sui client (ma solo dentro alla modalità grafica) il seguente comando:
$ ssh root@stellaXXX
dove stellaXXX è l'hostname di un client, ci verrà chiesto di accettare la chiave pubblica del client e poi di inserire la password dell'utente root che abbiamo precedentemente inserito. L'utente root in questione è locale al client, ma se noi vogliamo permettere ai normali utenti loggati sui client di eseguire dei programmi sul client stesso dobbiamo fare in modo che anche questi utenti si possano autentificare sui client. Il client deve quindi vedere la stessa lista di utenti e parametri associati che si trovano sul server e accedere alla home dell'utente per ritrovare variabili di ambiente e file di configurazioni personalizzati. Prima risolviamo il secondo problema: si può montare la directory home del server, esportata con NFS, sui client, facendo ritrovare ai client quando si loggano la loro home directory. Per farlo modifichiamo in un altro file di inizializzazione nella chroot di LTSP, il file /opt/ltsp/i386/etc/init.d/ltsp-client-setup, la funzione configure_fstab:
configure_fstab() {
echo "/dev/root / unionfs defaults 0 0" > /etc/fstab
echo "tmpfs /tmp tmpfs defaults,nosuid,nodev 0 0" >> /etc/fstab
echo "192.168.x.y:/home /home nfs defaults,nolock 0 0" >> /etc/fstab
mount /tmp
mount /home
}
Dove 192.168.x.y è l'indirizzo di rete del server. Dobbiamo poi aggiungere la seguente riga a /etc/exports
/home 192.168.x.0/255.255.255.0(rw,root_squash,async)
e riavviare NFS con
# /etc/init.d/nfs-kernel-server
Bene, questa era la parte facile, ora viene il bello!
Ci sono diversi modi per autentificare l'accessi ad un host, ma tutti si basano sul confrontare i dati foniti dall'utente per autentificarsi con quelli riconosciuti dall'host. Questi dati si possono trovare anche in rete e forniti da dei server opportuni. Un servizio pensato per condividere dei dati di autentificazione in rete è il NIS, sviluppato da Sun per funzionare su sistemi Unix. Questo è il servizio che anche LTSP consiglia per eseguire delle applicazioni locali sui client.
Per prima cosa installiamo il pacchetto nis sul server:
# apt-get install nis
Durante la post-configurazione del pacchetto ci verrà chiesto di indicare un dominio NIS e generalmente si immette un nome di dominio uguale a quello usato per gli hostname o come dominio DNS. Poi tenterà di avviarsi il servizio ypbind che cercerà un server NIS in rete a cui collegarsi ma senza riuscirci, per cui possiamo aspettare che si interrompi oppure bloccarlo digitando Ctrl-C. Seguendo l'howto ( zless /usr/share/doc/nis/nis.debian.howto.gz ) installato assieme al pacchetto dovrebbe essere facile configurare il nostro server NIS master. Prima di tutto assicuriamoci che tutti gli host della nostra rete LTSP siano opportunamente listati nel file /etc/hosts dato che NIS non usa DNS. Fate attenzione anche che nel file /etc/hosts l'hostname del server non sia associato a 127.0.0.1, insomma si deve leggere:
127.0.0.1 localhost.localdomain localhost
Assicurarsi poi che in /etc/defaultdomain sia contenuto il dominio NIS prescelto, per impostarlo dare:
# echo "stellamarisfriends.org" > /etc/defaultdomain
oppure se si vuole usare sudo
$ echo "stellamarisfriends.org" | sudo tee /etc/defaultdomain
modificare il file /etc/default/nis in modo da leggere
NISSERVER=master
Modificare poi il file /etc/ypserver.securenets in modo da leggere
255.0.0.0 127.0.0.0 255.255.255.0 192.168.x.0 #0.0.0.0 0.0.0.0
la prima riga permette l'accesso al NIS server agli utenti che si loggano sul server stesso, la seconda limita l'accesso ai soli client della rete 192.168.x.0/24, la terza riga era prima decommentata e permetteva l'accesso da qualsiasi server al server NIS. Configuriamo ora il client ypbind sul server indicando come server NIS l'host locale, modificando il file /etc/yp.conf:
ypserver localhost
Avviamo dunque il server NIS (cioè i servizi ypserv, yppasswdd e ypbind):
# /etc/init.d/nis start
E' arrivato il momento di generare l'archivio degli utenti di NIS, sulla base degli attuali utenti definiti nei consueti file di Linux (/etc/passwd, /etc/group, /etc/shadow etc.):
# /usr/lib/yp/ypinit -m
ciò significa che dopo ogni cambiamento negli utenti del server, perchè questo sia trasmesso ai client attraverso NIS, bisogna effettuare un aggiornamento con il comando:
# cd /var/yp && make
Per testare che il server funzioni diamo il comando:
$ ypcat passwd.byname
e se tutto va a buon fine dovremmo ottenere una lista degli utenti con accesso ad una shell del nostro sistema server. Ora configuriamo i client ad autentificare gli accessi con NIS. Installiamo dunque il solito pacchetto nis nella chroot di LTSP:
# chroot /opt/ltsp/i386 (chroot) # apt-get install nis (chroot) # exit
ci verrà chiesto il solito dominio, poi andremo a modificare il file /opt/ltsp/i386/etc/yp.conf per avere la seguente riga:
ypserver stellaXXX
dove stellaXXX è l'hostname del nostro server. Non basta però, è necessario dire al programma "login" dei client che si autentichi usando il NIS server. Per questo aggiungiamo in fondo al file /opt/ltsp/i386/etc/passwd la riga:
+::::::
e al file /opt/ltsp/i386/etc/group
+:::
e modificate il file /opt/ltsp/i386/etc/nsswitch.conf con qualcosa del genere (questo è il file di una installazione di LTSP 4.2):
passwd: files nisplus nis shadow: files nisplus nis group: files nisplus nis hosts: files nisplus nis dns services: nisplus [NOTFOUND=return] files networks: nisplus [NOTFOUND=return] files protocols: nisplus [NOTFOUND=return] files rpc: nisplus [NOTFOUND=return] files ethers: nisplus [NOTFOUND=return] files netmasks: nisplus [NOTFOUND=return] files bootparams: nisplus [NOTFOUND=return] files netgroup: nisplus publickey: nisplus automount: files nisplus aliases: files nisplus
Soprattutto cambiate le righe passwd: e group:. Ora riavviando i client dovreste potervi loggare su un client tramite ssh con l'account di un qualsiasi utente:
$ ssh stellaXXX@stellaXXX
Una volta entrati dovreste poter vedere i file della directory di home dell'utente con cui vi siete loggati, in tal caso siamo ad un buon punto. Ma non è ancora finita. Prima installiamo un programma leggero ma molto utile...
SWAP su hard disk
I terminali di questa installazione sono dei Pentium III ma hanno quasi tutti solo 64 MByte di RAM, a parte uno che è stato potenziato per tentarvi l'installazione di Xubuntu e ne ha 128. Con l'avvio di LTSP basato su pacchetti di Ubuntu sui client si ha una occupazione di oltre 50 MByte dato che vengono avviati alcuni servizi aggiuntivi, come Squid, sshd e ypbind, questo nonostante si sia impedito l'avvio dei sei terminali virtuali con le conseguenti sei istanze di Bash. Per eseguire dunque le applicazioni locali, nel caso specifico Gaim, necessitiamo di ulteriore memoria. Per fare questo, dato che molta della memoria allocata dal sistema operativo sui client non viene particamente più utilizzata dopo l'avvio, ho pensato di ricorrere all'abilitazione dello swap, cosa che si puo' fare in tre modi:
- swap sull'hard disk, creando una partizione di swap, oppure un file di swap sempre sull'harddisk dei computer;
- swap su NFS, i file di swap vengono creati in una directory esportata da un server NFS, generalmente il server LTSP, il client vi accede via rete;
- swap su NBD, un block device è sostanzialmente uno spazio su disco, un NDB è un Network Block Device, cioè uno spazio su disco in rete, accessibile per il client attraverso un dispositivo del tipo /dev/nd0.
Ognuno di questi metodi ha i suoi pro e i suoi contro ma nel nostro caso sono stato costretto ad adottare lo swap su hard disk perché:
- lo swap su NFS non si può abilitare con il kernel 2.6.x e Ubuntu non ha versioni con il kernel 2.4 o precedenti;
- lo swap su NDB è stato introdotto nella versione 4.2 di LTSP per sopperire a questa limitazione del kernel 2.6 stabilmente adottato in questa versione, ma gli stessi autori di LTSP hanno implementato un particolare servizio per automatizzare questo sistema (ltspswapd), e poiché già ho avuto grossi problemi con i servizi creati ex-novo per LTSP ho preferito evitare di ingolfarmi in un nuovo rompicapo.
Sui client è montato un disco da 10 GByte con una unica partizione FAT32 (Windows 98), ho dunque riavviato i computer su cui creare la partizione di swap con un cd-rom live fornito di comandi opportuni (fdisk, cfdisk, parted, mkswap) ma che non facesse partire una interfaccia grafica, per esempio una vecchia versione del live-cd di Gentoo. Arrivato alla riga di comando ho effettuato il resize, la creazione della partizione e la sua formattazione con il seguente comando:
# parted /dev/hda resize 1 0 -256MB mkpartfs logical linux-swap -256MB -1s
Ho quindi riavviato il client prima con Windows per controllare che tutto fosse a posto (Windows non se ne è manco accorto di essere stato ridimensionato), poi con LTSP, mi sono collegato al client in ssh:
$ ssh root@stellaXXX
ed ho attivato lo swap con
# swapon /dev/hda5
In un secondo momento andrò a modificare i file di inizializzazione dei client aggiungendo la riga seguente al file /etc/fstab che viene generato in fase di inizializzazion:
/dev/hda5 none swap sw 0 0
e venga dato il comando swapon in automatico. Questo si ottiene con una nuova modifica alla funzione configure_fstab dello script /opt/ltsp/i386/etc/init.d/ltspd-client-setup:
configure_fstab() {
echo "/dev/root / unionfs defaults 0 0" > /etc/fstab
echo "tmpfs /tmp tmpfs defaults,nosuid,nodev 0 0" >> /etc/fstab
echo "192.168.x.y:/home /home nfs defaults,nolock 0 0" >> /etc/fstab
echo "/dev/hda5 none swap sw 0 0" >> /etc/fstab
mount /tmp
mount /home
swapon /dev/hda5
}
Autentificazione di SSH
Giunti a questo punto possiamo collegarci ai client in SSH con le credenziali degli utenti presenti sul server, ma siamo costretti ad inserire la password dell'utente per ottenere l'accesso. Affinchè sia possibile eseguire le applicazioni locali senza che queste si blocchino chiedendo all'utente una password, dobbiamo configurare opportunamente ssh per effettuare l'autentificazione attrverso una chiave DSA. LTSP fornisce nel suo Wiki un breve script che si occupa di gestire la cosa. Consiglio di analizzare questo script e adattarlo alle proprio esigenze, lo trovate all'indirizzo http://wiki.ltsp.org/twiki/pub/Ltsp/LocalApps/runremote Personalmente ho preferito creare uno script ad-hoc, per eseguirlo come ogni singolo utente in modo da creare i file necessari nella sua cartella home. Eccovi il testo:
#!/bin/sh
WRKDIR=${HOME}/.localapps
TMPDIR=${HOME}/.tmp
SSHCONFIG=${WRKDIR}/ssh_config
SSHDSAKEY=${WRKDIR}/ssh_id_dsa
KNOWNHOSTS=${WRKDIR}/ssh_known_hosts
XHOST=`echo $DISPLAY | cut -d: -f1`
LTSP_DIR=/opt/ltsp
SSHDIR=${HOME}.ssh
AUTHKEYS=${SSHDIR}/authorized_keys
[ -d $WRKDIR ] && rmdir -rf $WRKDIR
[ -d $TMPDIR ] && rmdir -rf $TMPDIR
mkdir $WRKDIR $TMPDIR
chmod 0700 $WRKDIR
ssh-keygen -q -t dsa -f "$SSHDSAKEY" -N '' -C 'Thin-Client-local execution key'
echo "$XHOST `cat ${LTSP_DIR}/i386/etc/ssh/ssh_host_rsa_key.pub`" > $KNOWNHOSTS
echo > $SSHCONFIG << EOF
# Auto-generated ssh configuration -- do not edit
# This file is used for thin-client-local execution
Protocol 2
PubkeyAuthentication yes
CheckHostIP no
ForwardX11 no
UserKnownHostsFile ${KNOWNHOSTS}
IdentityFile ${SSHDSAKEY}
EOF
mkdir $SSHDIR && chmod 0700 $SSHDIR
cat ${SSHDSAKEY}.pub > $AUTHKEYS
#rm -f $SSHDSAKEY
Per utilizzare questo script bisogna avere l'accortezza di controllare il valore assegnato alla variabile LTSP_DIR, deve coincidere con la radice dove si trova installata la radice della chroot dei client LTSP. Inoltre ho lasciata decommentato il comando finale in quanto la prassi vorrebbe che si cancellino le chiavi pubbliche per impedire un uso malevole di questa informazioni da parte di malintenzionati. Comunque non ha molto senso dato che le informazioni restano all'interno del file ~/.ssh/authorized_keys.
A questo punto dovremmo essere in grado di eseguire un comando di questo tipo dal desktop di un terminale:
$ ssh -F "${HOME}/.localapps/ssh_config" TMPDIR=${HOME}/.tmpdir DISPLAY=$DISPLAY xterm &
a patto di aver installato il programma xterm nella chroot dei client LTSP. Il risultato sarà lo spuntare di una finestra con una shell bash.
Eseguire Gaim in locale nei client
Realizziamo ora uno script che chiameremo gaim-xremote e salviamolo in /etc/local/bin/ con il seguente contenuto:
#!/bin/sh
XHOST=`echo $DISPLAY | cut -d: -f1`
if [ -z $XHOST ]; then
gaim-remote quit
gaim &
else
ssh -F "${HOME}/.localapps/ssh_config" TMPDIR=${HOME}/.tmpdir gaim-remote quit
ssh -F "${HOME}/.localapps/ssh_config" TMPDIR=${HOME}/.tmpdir DISPLAY=$DISPLAY gaim &
fi
Lo script controlla che il terminale video non sia in esecuzione sul server, in tal caso esegue Gaim, non prima di aver chiuso eventuali istanze di Gaim in esecuzione. Gaim infatti non controlla che vi siano più copie di sè in esecuzione. Bisogna avere dunque l'accortezza di chiuderle con il comando gaim-remote quit, a patto che abbiammo abilitato il plug-in nella configurazione di Gaim. Ora possiamo creare un icona sul desktop o sul pannello dell'intrefaccia degli utenti e associargli l'esecuzione del comando gaim-xremote.
