giovedì 7 giugno 2007

Ubuntu LTSP - Thin client per piccola azienda (2)

Installare un server LTSP per thin client con le ultime release di Ubuntu è diventato veramente semplice. In particolare l'immagine iso di Edubuntu denominata "Edubuntu 7.04 Classroom Server CD" prevede già l'installazione di default di tutto ciò che serve a far partire i thin client. Chi decide di effettuare una installazione pulita partendo da questa iso può tranquillamente passare alla descrizione dell'impostazione del server dhcp.
Se invece si vuole installare LTSP partendo da una versione Ubuntu normale o aggiungerla ad un sistema già funzionante è sufficiente digitare:

sudo apt-get install ltsp-server ltspfs

Automaticamente verranno risolte tutte le dipendenze e verrà proposta l'installazione di una serie di pacchetti, questo, ad esempio, è quello che è stato installato automaticamente sul pc che uso normalmente come workstation:

I seguenti pacchetti verranno inoltre installati:
debconf-utils debootstrap libevent1 libgssapi2 librpcsecgss3 nbd-server
nfs-common nfs-kernel-server openbsd-inetd tftpd-hpa


Vengono inoltre suggeriti alcuni pacchetti da installare

Pacchetti suggeriti:
dhcp3-server sdm audiooss


ma in questo momento, come si vedrà in seguito, è meglio non farlo.


A seconda di cosa è già installato sul sistema potrà essere richiesta la rimozione di alcuni pacchetti, nel mio caso ad esempio è stato rimosso in automatico il pacchetto netkit-inetd sostituito da openbsd-inetd.
Il pacchetto ltspfs, sebbene non strettamente necessario al funzionamento dei thin client, è bene installarlo poichè consente l'utilizzo di periferiche di archiviazione (dischi, chiavette usb etc., lettori cd e dvd) direttamente sui thin client tramite filesystem fuse.

Durante l'installazione dei pacchetti comparirà a video il seguente messaggio:

NOTE: you will probably want to add to /etc/exports:
/opt/ltsp *(ro,no_root_squash,async)
and then run:
invoke-rc.d nfs-kernel-server reload


L'aggiunta di questa riga in /etc/exports è praticamente l'unico intervento manuale su un file di configurazione da compiere in questa prima fase.

A questo punto si è pronti per configurare l'ambiente di sistema per i client. E' sufficiente digitare il comando:

sudo ltsp-build-client

Questo comando crea in /opt/ltsp/i386 l'ambiente necessario all'avvio dei thin client. In pratica viene ricreato un sistema operativo in miniatura, completo di kernel, librerie, eseguibili e repository dei pacchetti da cui i thin client effettueranno il boot e l'avvio del sistema grafico. A seconda della velocità di connessione dopo qualche minuto il processo terminerà con questo messaggio:

informazione: installazione client LTSP completata con successo

Il sistema è pronto per passare all'installazione di una delle parti più critiche: il server dhcp. Il dhcp infatti si dovrà occupare non solo di rilasciare gli indirizzi ma di dire ai thin client dove prendere l'immagine di boot via tftp.
La documentazione ufficiale di LTSP suggerisce di usare il buon vecchio server dhcp di isc.org, che è senz'altro il più diffuso in ambiente *nix. Ma io ho preferito usare dnsmasq, sicuramente meno conosciuto ma che a mio avviso presenta alcuni vantaggi. Innanzitutto la sintassi del suo file di configurazione è "civile", e già non è poco. Fa da "dns forwarder", in pratica una sorta di proxy dns. Poi all'avvio legge il file /etc/hosts e risponde alle query dns sugli indirizzi trovati. Ma la cosa che mi è sempre particolarmente piaciuta di questo software è che, mentre rilascia gli indirizzi dinamici ai client, automaticamente li inserisce nella sua cache dns e risponde alle query dns dirette e inverse. Questo risultato è ovviamente ottenibile anche accoppiando il dhcp di isc.org con bind, ma a costo di una configurazione macchinosa e di un funzionamento che, per quanto ho potuto osservare, non è proprio ineccepibile. Da qui la mia netta preferenza per dnsmasq.

Dnsmasq è già presente nei repository di Ubuntu e quindi si installa semplicemente con

sudo apt-get install dnsmasq

se necessario dopo aver disinstallato dhcp3-server.

Un esempio funzionante (e ampiamente commentato) di configurazione di dnsmasq (/etc/dnsmasq.conf) è questo:

# non inoltrare mai ai server dns esterni
# query senza nome dominio
domain-needed

# Tutti i reverse lookup per la subnet privata
# non presenti in /etc/hosts o nei lease dhcp
# ottengono "host not found"
# invece di essere inoltrati ai dns esterni
bogus-priv


# Filtra le ricorrenti richieste SOA, SRV e altre,
# provenienti da macchine windows
# serve in particolare a non attivare
# per sbaglio il link quando si
# hanno connessioni "on demand"
filterwin2k

# server dns esterni di riferimento
# inserire i server dns uno per riga
# usati in questo caso i server di opendns.org
server=208.67.222.222
server=208.67.220.220

# aggiunge sempre il nome dominio al nome host
expand-hosts

# nome del mio dominio
domain=mydomain.net

# range dei lease dhcp: indirizzo iniziale, indirizzo finale, netmask, durata del lease
dhcp-range=192.168.35.50,192.168.35.100,255.255.255.0,8h

# esempio di reservation per un client
# MAC address, indirizzo, nome host
dhcp-host=00:18:f8:83:d8:f4,192.168.35.190,LinksysPAP

#Opzioni del dhcp
# dnsmasq supporta la maggior parte delle
# opzioni dhcp e bootp specificate in
# http://www.faqs.org/rfcs/rfc2132.html
# la sintassi e':
# dhcp-option=[numero relativo all'opzione],parametro

# default gateway (3)
dhcp-option=3,192.168.35.1

# dns da passare ai client (6)
dhcp-option=6,192.168.35.10

# le prossime sono quelle che servono
# in particolare ai thin client
# root-path (17)
# percorso dove montare la partizione root
dhcp-option=17,"/opt/ltsp/i386"

# file di boot (percorso relativo alla root del server tftp),
# nome tftp server, ip tftp server
# l'indirizzo e il nome del server
# devono essere inseriti in /etc/hosts
dhcp-boot=/ltsp/i386/pxelinux.0,ltsp-server,192.168.35.10

dhcp-authoritative
cache-size=1024

# da usare per debug
log-queries


In questo esempio il server 192.168.35.10 è quello su cui girano dnsmasq, il server tftp con l'immagine di boot e su cui è presente il root file system (/opt/ltsp/i386) per i thin client. E' interessante notare come dnsmasq, grazie alla occupazione di risorse veramente ridotta, sia spesso installato di default su device di rete casalinghi ed economici, come ad esempio router wireless. E' sufficiente in questo caso aggiungere alla configurazione del dhcp (di solito in un campo chiamato "opzioni dhcp" o "opzioni dnsmasq") le due righe:

dhcp-option=17,"/opt/ltsp/i386"
dhcp-boot=/ltsp/i386/pxelinux.0,ltsp-server,192.168.35.10

per permettere ai thin client di fare il boot dal server corretto. In effetti il trucchetto ha funzionato egregiamente sul mio router Linksys wrt54gl con firmware Tomato.

Successivamente si edita il file /etc/resolv.conf inserendo queste righe:

#mydomain.net va sostituito col nome del proprio dominio
search mydomain.net
nameserver 192.168.35.10


Come ultimo tocco si edita il file /opt/ltsp/i386/etc/lts.conf in questo modo:

# This is the default lts.conf file for ltsp 5.
# For more information about valid options please see:
# /usr/share/doc/ltsp-client/examples/lts-parameters.txt.gz
# in the client environment


[default]
SOUND=True
LOCALDEV=True
NBD_SWAP=True
SYSLOG=server
SOUND_DAEMON="pulse"
NETWORK_COMPRESSION=True
XKBLAYOUT="it"


Questa è solo una configurazione generica, in particolare ciò che interessa adesso è il layout della tastiera italiana. La configurazione del server grafico per ogni thin client in genere avviene grazie al riconoscimento automatico dell'hardware, solo in rari casi bisogna creare delle sezioni apposta "per client" specificando il server grafico da utilizzare.

Completata questa fase un qualunque pc in grado di fare il boot direttamente dalla scheda di rete è già in grado di diventare un thin client.

Qua sotto i link ad alcune immagini della fase di avvio di un thin client.

Fase iniziale del boot di un thin client

Login grafico di un thin client

Schermata iniziale Gnome di un thin client

In un prossimo post illustrerò la preparazione dei dischi di boot per i thin client non in grado di avviarsi direttamente dalla scheda di rete e di altri aspetti relativi alla configurazione e al "fine tuning" del sistema ltsp, di problemi legati all'audio e alle periferiche collegate ai terminali.

79 commenti:

  1. Complimenti per l'articolo, spero di poterlo seguire al piu' presto. Avevo fatto delle prove partendo direttamente dai pacchetti di LTSP due anni fa ed era stato un bagno di sangue!!!
    Marco

    RispondiElimina
  2. Molto interessante, complimenti per la quantità di dettagli.

    RispondiElimina
  3. Non c'è verso di far trovare il pxe al client. Continuo a ottenere PXE-T01 file not found. Ho cercato per lungo e per largo qualche spiegazione ho cambiato decine e decine di volte il percorso nel dnsmasq.conf ma non c'è modo e maniera di far trovare il kernel al thin client

    RispondiElimina
  4. Il client ottiene un indirizzo dal dhcp all'inizio? Così alla cieca uno dei problemi potrebbe essere relativo alla risoluzione dei nomi, comunque se vuoi posta qua il tuo dnsmasq.conf e lo vediamo assieme.
    Tieni conto che stasera vado via e sarò offline tutta la settimana.

    RispondiElimina
  5. Cambia la riga del tftp in /etc/inetd.conf in questo modo:
    tftp dgram udp wait root /usr/sbin/in.tftpd /usr/sbin/in.tftpd -vvv -s /var/lib/tftpboot
    Così avrai dei log più dettagliati di quello che succede e magari già dai log capisci il problema.

    RispondiElimina
  6. Ciao vorrei sapere se è possibile fare un boot dei thin client verso un server che è su internet con un ip fisso ovviamente.

    Grazie

    RispondiElimina
  7. Domanda di riserva???? Come risposta veloce a pelle ti direi che avere un unico server che fa da dhcp e tftp su internet la vedo durissima, se non impossibile. Se invece nella tua rete hai un server dhcp che indirizza il tuo client verso un server tftp su internet la cosa diventa già più fattibile, almeno per la fase iniziale, per il resto poi è da vedere e provare. Ti dico anche però che non lo farei mai per mille motivi (sicurezza innanzitutto). Se hai voglia di dirmi che cosa hai in mente potrebbe essere interessante discuterne.

    RispondiElimina
  8. 1 grosso problema :-(
    1) sul server ho creato N account (utenti).
    2) il client fa il boot regolarmente.
    3) Sul client arrivo al login grafico LDM
    a questo punto non c'è verso di fare la login :-o
    inserisco una qualsiase delle coppie user/pass creati sul
    server , macina un pochino e poi mi ributta alla login (LDM).
    Nel log /var/log/syslog , vedo che viene autenticato
    con successo l'utente inserito dal client in ssh.
    Ho analizzato anche il log del dhcpd ma non trovo nessun errore :-o
    Qualcuno da dirmi cosa sbaglio?
    Grazie.

    RispondiElimina
  9. Un comportamento del genere si manifesta quando non sono state create le home directory degli utenti. Fai una verifica. Se non si tratta di questo su due piedi non saprei, ma fammi sapere che indaghiamo.

    RispondiElimina
  10. Grazie Enrico :-)
    Solo 1 cosa non mi è chiara:
    -) Io creo gli utenti a lato server
    amministrazione->utentigruppi
    -) vedo che nella /home del server , vengono creati i vari utenti
    -) loggando nel server (da locale e NON da client) non ho nessun problema :-o
    -) loggando da client non parte il gnome-desktop :-(

    RispondiElimina
  11. Un particolare :-o
    quando creo gli utenti , vedo che di fatto nelle /home/newutente vengono creati SOLO i files:
    .bash_logout
    .bashrc
    .profile
    e non tutti i file/cartelle (tipo Desktop) che trovo per esempio nella home dell'utente
    che ho creato in fase di installazione...
    Che sia già questo un problema?
    Grazie ancora per l'aiuto..

    RispondiElimina
  12. Pare, dico pare, che lanciando sul server il comando "ltsp-update-sshkeys" (come root o con sudo) qualcuno abbia risolto problemi simili al tuo. In questo momento non ho molto tempo per poter verificare, ma ti sarei grato se riesci a confermare/smentire.

    RispondiElimina
  13. OK!
    entro stasera/stanotte :-\ dovrei saperti dare delle risposte.
    Grazie ancora ;-)

    RispondiElimina
  14. Un dettaglio: il comando di cui sopra funziona se per caso è stato cambiato l'ip del server o qualche altro parametro di rete. "ltsp-update-sshkeys" ripristina le chiavi corrette per l'ssh e fa funzionare tutto di nuovo. Se invece il problema non era quello comunque non fa danni, lancialo senza problemi.

    RispondiElimina
  15. :-P
    allora già credo che quel comando non sortirà effetti :-\
    l'ip del server è rimasto sempre lo stesso (192.168.20.1) con
    range di assegnazione .100 -> .200
    C'è da dire però che appena dopo aver installato il server e
    fatto l'aggiornamento , sono riuscito a connettermi da client con
    stessa user/psw dell'utente creato durante l'installazione
    (l'unico nel server fra l'altro)
    Mha! (mi sa che faccio la "notte bianca" ma a CASA :-) :-)
    Sriverò dei risultati non appena ho qualcosa..
    Ciao!

    RispondiElimina
  16. Ma allora eri già a buon punto!!

    RispondiElimina
  17. Reinstallo che comincio ad essere pallido :-(
    Ho eliminato tutti i nuovi utenti, ho inserito 1 nuovo utente (paperino/paperino) ma nulla da fare :-(
    Mo reinstallo!
    speriamo...

    RispondiElimina
  18. Ore 03:00 di mattina :-P
    Finalmente ho terminato la re-installazione del server!
    Premesso che avevo già a bordo le 2 schede di rete LAN di cui ho specificato quale usare per il DHCP-server , mi sono
    ritrovato a fine installazione ad avere il server perfettamente configurato :-)
    Lancio quindi il client e TAK! parte immediatamente , e
    come per incanto arrivo alla login LDM.
    Creo l'utente "mammolo" sul server (i 7 nani ;-) )
    inserisco sul client user/passw "mammolo" e voilà!
    Funziona tutto egreggiamente :-)
    Creo quindi anche gli altri 6 "nani" e li provo tutti sul client
    a login successive.
    Funziona TUTTO! Ma ecco che sia sul server che sul client mi compare il dialogo di "aggiornamenti disponibili" :-P
    A questo punto:
    SERVER: Eseguo laggiornamento? o è meglio lasciarlo così che funziona...
    CLIENT: anche qui... che faccio? aggiorno? e se aggiorno mi aggiorna la "/opt/ltsp/i386"? o...
    Ultima cosa:
    Con il tool client-manager , vedo la lista dei client in esecuzione.. ma se tento di visualizzare il desktop di 1 dei clien connessi , mi scrive che devo installare x11vnc
    ok.. ma da che parte? (sul client suppongo...)
    Se sul client.. posso fare "sudo apt-get install x11vnc" in un terminale sul client?
    Queste dovrebbero essere le ultime "dritte" che chiedo a voi luminari ;-)
    Poi se la cosa si sistema , direi che i "kinder" della scuola per la quale stò preparando le macchine , saranno felicissimi di iniziare a giocarci :-)
    Grazie ancora per l'aiuto!

    RispondiElimina
  19. Beh, innanzitutto complimenti per la costanza, di aiuto in realtà non ne hai avuto molto. Ma soprattutto chissà cos'era che ti bloccava i client.
    Le risposte alle tue domande dovevano essere argomento della parte terza dell'articolo, che non ho ancora avuto tempo di finire (è in bozza da un po'). Ma non posso chiederti di aspettare ;-) quindi eccoci qua.
    Tutte le volte che ti viene proposto un aggiornamento tieni a mente che tu, anche se sei su un thin client, stai lavorando a tutti gli effetti sul server, quindi è il server che stai aggiornando. Per quanto ho visto finora se stai usando una versione stabile (come credo) puoi fare aggiornamenti in tutta tranquillità che di problemi non dovrebbero essercene.
    Se vuoi che vengano fatti aggiornamenti anche nell'ambiente virtuale di avvio dei client (/opt/ltsp/i386) devi fare così:
    "cp /etc/apt/sources.list /opt/ltsp/i386/etc/apt/"
    "chroot /opt/ltsp/i386"
    "mount -t proc none /proc"
    "apt-get update"
    "apt-get upgrade"
    "logout"
    Poi se lo fai sul server puoi anche aggiornare le immagini del kernel con cui partono i thin client:
    "ltsp-update-kernels".
    (tieni conto che tutti questi comandi io li do come utente root, potresti dovere usare sudo se parti invece da utente normale).

    Per quanto riguarda x11vnc le istruzioni circa ufficiali sono queste:
    Rifai chroot nell'ambiente virtuale ("chroot /opt/ltsp/i386"), rimonta il proc come prima.
    Installa il pacchetto x11vnc con apt-get.
    Esci pure dal chroot.
    Edita il file /opt/ltsp/i386/etc/rc.local in modo che le ultime due righe siano così:
    "x11vnc -display :6 -forever -loop -shared &"
    "exit 0"
    Salva e chiudi. D'ora in avanti tutti i client in avvio dovrebbero avviare un x11vnc in ascolto.
    Questa parte però l'ho testata una sola volta molto tempo fa e non posso garantire che funzioni.
    Ma semmai si può continuare a provarla e nel caso metterla a punto meglio.
    Ciao e buona continuazione.

    RispondiElimina
  20. Dimenticavo: assicurati che esista il link di avvio "/opt/ltsp/i386/etc/rc2.d/S99rc.local" che punta a "/opt/ltsp/i386/etc/rc.local" per far partire rc.local all'avvio.
    In pratica fai: "ln -s /opt/ltsp/i386/etc/rc.local /opt/ltsp/i386/etc/rc2.d/S99rc.local".

    RispondiElimina
  21. Che dire... :-o
    Ce ne fossero in rete di utenti come te/voi :-)
    Stasera proverò quindi a fare l'aggio server/client e ad installare il vnc
    sul client.
    Se tutto fila liscio (come auspico.. non vorrei andare a letto dopo le 03 di mattina :-\) direi che la questione sia chiusa (felicemente ;-) )
    Grazie ancora!!!!!!

    RispondiElimina
  22. Buongiorno..
    Aggiornamento eseguito con successo :-)
    i client fungono alla grande (anche se il server poverino è un po preso per il collo ma vedo di arrivare almeno a 1Gb di ram che per 6 client spero bastino)
    Ora mi cimenterò nell'installazione di un mail-server per posta interna/esterna.
    Già ho trovato un articolo sull'uso di postfix..
    Speriamo..
    PS:
    Se qualcuno ha link utili , sarò lieto di visitarli!
    Ciao!

    RispondiElimina
  23. Ciao e complimenti per il tuo blog, ricco di informazioni utili.
    Premesso che sono un newbie, volevo chiederti consiglio per l'installazione di una rete con thin client in un'aula informatica.
    L'aula è in un complesso universitario, in cui la rete è gestita da un apparato "superiore" che non gradisce i dhcp server. Posso assegnare ai thin client un ip statico senza utilizzare il server dhcp?
    Come va effettuata in questo caso la prima installazine per i thin server?
    Grazie per l'aiuto

    RispondiElimina
  24. Sì, teoricamente la possibilità esiste, anche se non l'ho mai provata. Se vai sul sito http://www.rom-o-matic.net hai la possibilità di crearti e scaricarti le immagini (per floppy o per cd) per far fare il boot da rete a pc non predisposti. Nella fase di creazione dell'immagine se lasci i default viene cercato un dhcp/bootp altrimenti hai la possibilità di fissare alcuni parametri (IP, netmask, gateway, bootfile, server tftp e moltissimo altro). Questo dovrebbe permetterti di fare a meno completamente di un server dhcp. L'unica è sperimentare un po'.
    A questo punto, viste le domande, mi sa che sarò costretto a finire la terza parte del post sui thin client :-)

    RispondiElimina
  25. Grazie, la prossima settimana vedo se riesco.

    RispondiElimina
  26. Scusami se ti disturbo ancora (se sei disponibile a darmi una mano posso contattarti via mail se preferisci), ma sto incontrando alcuni problemi.
    1) Secondo te posso usare come server un AMD64 e come client pc con Intel?
    2) Con rom-o-matic devo specificare il percorso del boot file. Io ho messo più soluzioni (/opt/ltsp/amd64;/opt/ltsp/amd64/boot/;/opt/ltsp/amd64/boot/vmlinuz) ma nessuna funziona, dice che non può caricare il file.
    Secondo te dove starei sbagliando?
    Grazie mille e scusami ancora per il disturbo

    RispondiElimina
  27. 1) sicuramente il modo c'è, ma io non l'ho mai fatto. L'importante credo che sia non fare confusione tra le cose che devono essere fatte girare dal thin client su architettettura Intel 32bit (kernel e file in /opt/ltsp/i386) e le cose che girano sul server a 64bit e che vengono solo visualizzate sul thin client (da X in avanti, tutte le altre applicazioni).
    2) Devono essere specificate due cose: chi è il server tftpd e dove si trova il file in tale server. Ovviamente il percorso è relativo alla root del server tftp. Esempio: sul file system il file di boot è "/var/lib/tftpboot/ltsp/i386/pxelinux.0", il server tftp gira usando come root "/var/lib/tftpboot", allora il mio file di boot da specificare sarà "/ltsp/i386/pxelinux.0". Se guardi qua sopra la parte relativa alla configurazione di dnsmasq forse ti è più chiaro.
    Come ultima cosa credo che se cerchi di avviare i client Intel con file di avvio e sistema operativo thin client di AMD64, come mi pare di capire dalla tua domanda) non ne otterrai nulla.
    Per essere sincero fino in fondo: per fare un terminal server affidabile e non farla troppo difficile se possibile installerei un sistema operativo per vecchie architetture (386/586/686) anche su una macchina a 64bit.

    RispondiElimina
  28. Grazie dei consigli, ora ho capito.
    In effetti avevo il dubbio che fosse una stupidaggine mettere il server su un amd64.
    Tanto più che continua a dare dei problemi, ovvero quando gli faccio caricare il kerner /ltsp/i386/vmlinuz va in kernel panic.
    Credo che installerò ubuntu server su una macchina i386...
    Comunque grazie ancora per la tua gentilezza

    RispondiElimina
  29. Guarda che puoi mettere Ubuntu per i386 anche su un AMD64. Va benissimo. L'unica cosa è che ci perde un pochino in prestazioni rispetto ad un sistema operativo nativo a 64bit. Il vantaggio invece è che in generale hai più software a disposizione ed è più testato. Per quanto mi riguarda i server in produzione, anche se l'hardware supporta i 64bit, continuo a farli con versioni a 32bit.

    RispondiElimina
  30. Infatti l'ho già installato senza problemi; ora devo capire questo problema del kernel da dove deriva

    RispondiElimina
  31. Ciao,

    sono mesi che rincorro ltsp sul web, piu' per la mia fissa di non volermi sbarazzare dei vecchi pc che per reale necessità.
    In garage ho un P4 che fa da "server" casalingo e ci vorrei collegare un portatile "obsoleto" per la moglie.
    Il problema grosso che mi ha bloccato è che entrambi i notebook che potrei usare NON hanno la rete integrata e il netboot dalla pcmcia non pare possibile.
    Non essendo un esperto di kernel e di boot, non sono riuscito a creare un'immagine che mi consentisse di partire in locale e mi sono fermato.
    Ogni tanto frugo ancora su google e ho trovato il tuo articolo veramente chiaro e dettagliato: complimenti!
    Non che questo abbia risolto il mio problema ma le ultime righe ("In un prossimo post illustrerò la preparazione dei dischi di boot per i thin client non in grado di avviarsi direttamente dalla scheda di rete") mi danno qualche speranza.
    Se dovessi trovare il tempo per abbozzare questa soluzione te ne saro' davvero grato.
    Credo proprio che sarebbe qualcosa di utile per molti visto che nel mio girovagare in internet ho trovato molte domande al riguardo ma veramente poche risposte.

    Grazie ancora per la tua disponibilità !

    RispondiElimina
  32. Ahimè io intendevo i pc che nel bios non hanno l'opzione di avviarsi dalla rete ma solo da floppy e/o cdrom, pcmcia purtroppo è tutta un'altra storia.
    Non credo sia una cosa facilissima da fare ma di sicuro non è impossibile. Il giochetto dovrebbe essere quello di fare partire il laptop con un kernel in locale (da cd o floppy) che gli attivi la pcmcia (ma potrebbe essere anche una nic su usb) e che poi gli consenta di usare l'interfaccia grafica e le applicazioni come client lstp.
    Per cominciare quarda qua:
    http://wiki.ltsp.org/twiki/bin/view/Ltsp/WirelessLtsp
    Pare che una volta il pacchetto ltsp_wireless supportasse anche alcune schede pcmcia.
    Se riesci o scopri qualcosa di interessante mi farebbe piacere saperlo, e, tempo permettendo, posso anche darti una mano se ne hai bisogno.
    Ciao.

    RispondiElimina
  33. Ho lo stesso problema di brancher, i thin-client mi mostrano la schermata di login ma non riesco ad accedere con alcun utente!
    Sul server gli utenti accedono correttamente, hanno la home directory e ho dato anche il comando ltsp-update-sshkeys...

    RispondiElimina
  34. Nei log sul server compare nulla? I log di quello che accade sui thin client dovrebbero essere visualizzati di default nei log del server. Nel dubbio (tanto male non fa) modifica /etc/default/sysklogd in modo che contenga questa riga: SYSLOGD="-r", poi fai ripartire i log di sistema. Guarda nei log se compare qualcosa. Altre idee al momento non ne ho.

    RispondiElimina
  35. Interessante l'opzione "-r" del syslogd, ora vedo effettivamente i log dei client sul server!
    Però non sono molto d'aiuto...
    Quando provo ad accedere su un thin-client non invia messaggi di log, e l'unica informazione che ricavo dal /var/log/syslog server è:
    [code]
    Nov 6 22:26:56 ltsp ldminfod[20246]: connect from 192.168.21.200 (192.168.21.200)
    [/code]
    mentre su /var/log/auth.log
    [code]
    Nov 6 22:26:54 ltsp sshd[20237]: Accepted password for heruan from 192.168.21.200 port 52144 ssh2
    Nov 6 22:26:54 ltsp sshd[20239]: pam_unix(ssh:session): session opened for user heruan by (uid=0)
    [/code]
    ma sul thin-client il server X si riavvia e non mi lascia accedere. Forse può essere d'aiuto il fatto che se inserisco una password sbagliata me lo segnala, mentre con la password giusta sembra accedere e crashare subito dopo!

    RispondiElimina
  36. Risolto. Facevo un errore madornale: sul server avevo un'installazione minimale (solo ubuntu-minimal e ltsp-server) e quindi non c'era Gnome! Ho installato ubuntu-desktop ed ora tutto funziona a meraviglia!

    RispondiElimina
  37. Finalmente la strada maestra...
    Avevo intrapreso la via dei terminal client da quasi 1 anno, ma per strani motivi un bel giorno il server si piantò con relativa perdita di dati ed impostazioni...
    Da allora, fino ad oggi non sono più riuscito a far "ripartire" i client con ltps, di acquistare pc nuovi ed indipendenti non se ne parla, e poi, funzionava tutto così bene...

    comunque; grazie a questa guida sintetica ma dettagliata quanto basta, sono di nuovo "on-line" :)

    ps: solo una precisazione, dopo aver modificato le impostazioni del server dhcp (dnsmasq) è stato necessario (credo lo sia per tutti) riavviarlo, con il seguente comando:

    /etc/init.d/dnsmasq restart

    Grazie ancora!

    RispondiElimina
  38. [...] alcuni commenti ad un post precedente si era parlato di LTSP server su architettura a 64 bit. Io, non avendolo mai provato e presumendo [...]

    RispondiElimina
  39. Ciao a tutti!
    Sono alle prime armi con ltsp, e stò
    finendo dei test di funzionalità sul server e sui client.
    Mi stò mordicchiando le unghie da un po' di tempo, perchè non riesco a trovare soluzioni o alternative su alcuni problemetti che mi sono capitati:
    - Noi possiamo entrare con un utente "pippo" su più un thin client contemporaneamente, ma questo non va bene (almeno nel mio caso) perchè ad esempio se provo ad aprire firefox , sull'ultimo client da un errore di accesso al file che credo sia dovuto dal fatto che sia già in uso dal primo client. E' possibile limitare una sessione per utente?
    - VNC: se provo a collegarmi sul server (edubuntu 7.10) da un pc in rete locale tutto ok;
    ma se provo (anche dal server) a collegarmi su un thin-client mi viene visualizzato un messggio del tipo
    unable to connectto host: Connection refused (111).

    Ho fatto già le seguenti prove:
    1) Dal Thin-client sono andato nel pannello "Preferenze > Desktop Remoto"
    ed impostato la condivisione del Desktop.

    2) Ho seguito la guida InstallX11VncOnLtspclients a questo link:
    https://wiki.edubuntu.org/InstallX11VncOnLtspClients
    devo dire che la guida che ho seguito sul link soprastante è leggermente diversa da come è stato indicato in precedenza, in particolare non dice di montare /proc. Può dipendere da questo?

    Per il resto mi sembra una bella soluzione per riutilizzare i vecchi pc.

    Grazie per ora

    RispondiElimina
  40. Sulla limitazioni degli accessi contemporanei allo stesso account se non ricordo male qualcuno aveva già avanzato la tua stessa richiesta direttamente agli sviluppatori di ltsp. Non saprei però se la proposta avrà un seguito.
    Per quanto riguarda vnc il punto 1) non serve a nulla, rimettilo come era prima, quella è la condivisione di gnome, che gira sul server e non sul client. Per il punto 2) segui quello che ho scritto qua http://www.zaffa.org/2007/10/05/ubuntu-ltsp-thin-client-per-piccola-azienda-3/, forse ho messo qualche dettaglio in più.

    RispondiElimina
  41. Grazie, ottimo Enrico, provo e poi ti dico com'è andata intanto per VNC

    RispondiElimina
  42. Ho provato, ma non è cambiato niente:
    - Ho provato a reinstallare x11vnc come dalla guida, ma sul Thin client manager mi continua a segnalare l'installazione di x11vnc, ho provato anche a lanciare il comando:
    x11vnc -display :6 -forever -loop &
    direttamente sul thinclient tramite la console, ma non va...

    RispondiElimina
  43. Ciao Enrico, ho risolto on vnc:
    a seguito di un aggiornamento fatto sul server,
    ho dato anche come comandi:
    ltsp-update-sshkey, e anche ltsp-update-image.

    Riavviato il thinclient e miracolosamente è nato.

    Grazie

    RispondiElimina
  44. Già ... soprattutto il secondo.... Ci si dimentica sempre il dettaglio (anche io non me lo ricordo mai) che a partire da Gutsy ogni cambiamento sul file system in chroot ha bisogno dell'aggiornamento dell'immagine.
    Grazie per avermi aggiornato :-)

    RispondiElimina
  45. Pensavo una cosa per quanto riguarda la gestione degli utenti come ho accennato qualche post fa:
    quando un utente fa il login, viene eseguito ciò che è definito nel file /etc/passwd per tale utente, giusto?
    Quindi, se nel passwd dove c'è /bin/sh, io creo uno scrippettino che controlla se c'è già loggato un utente con lo stesso nome, quindi se esiste, killa se stesso, tenento sempre attivo quello che era già connesso. Se po fa?
    Ciao

    RispondiElimina
  46. Potrebbe essere un'idea, ma prima di provare quello cercherei un po' di documentazione.
    Qua, ad esempio, c'è qualcosa: http://www.mail-archive.com/ltsp-discuss@lists.sourceforge.net/msg32828.html

    RispondiElimina
  47. Prova a installare questo: http://ppa.launchpad.net/moquist/ubuntu/pool/main/x/xterminator/
    Io ho messo la versione 2 e sembra funzionare abbastanza bene. Non ha bisogno di configurazione, installi il pacchetto e basta.

    RispondiElimina
  48. Grazie Enrico,
    ti faccio sapere appena ho provato

    RispondiElimina
  49. Ho provato xterminator
    (xterminator_0.1-4_i386.deb),
    ma riavviato il eserver, e poi riavviato il thinclient, con qualsiasi utente voglia entrare,
    mi oscura lo schermo e fa vedere sul il puntatore del mouse. Se entro direttamente dal server tutto ok.

    RispondiElimina
  50. Scusa Enrico, non avevo provato la versione 2, comunque fa uguale, o provato a smanettare un po' anche sul gdm.conf, ma per il momento niente da fare...

    RispondiElimina
  51. Scusa il ritardo nella risposta. E' vero, è come se se ne fregasse delle impostazioni del desktop di default per l'utente, se scegli il desktop ogni volta dalle opzioni di ldm funziona bene. Appena ho tempo faccio qualche prova per sistemarlo.

    RispondiElimina
  52. Grazie Enrico, anch'io faccio lo stesso.
    ...Se tante le volte trovassi qualche soluzione ti faccio sapere...

    RispondiElimina
  53. Vorrei utilizzare un unico utente per tutti i thinkclient. Se effettuo il login dai think client con lo stesso utente entro tranquillamente. Il problema sorge quando da uno dei client avvio un'applicazione; può capitare infatti che l'applicazione venga visualizzata in un altro think client. ome posso fare?

    RispondiElimina
  54. Pensa che alcuni segnalano la possibilità di fare login con lo stesso utente su macchine diverse come un baco .... e io sono abbastanza d'accordo.
    No, con ltsp non puoi fare una cosa del genere, o meglio: il sistema te lo permette ma sono i singoli applicativi a rifiutarsi di andare. Così su due piedi non ho soluzioni da suggerirti in mente, tranne quella (banale, me ne rendo conto) di creare più utenti. Ovviamente se tu dovessi trovare una soluzione mi farebbe piacere sentirla. ciao

    RispondiElimina
  55. Chiedo scusa in anticipo, ma non sono riuscito a trovare la sezione giusta.
    Su un server con edubuntu 7.10, ho configurato il protocollo xdmcp che servire per potersi collegare in terminal server da altri thin-client Windows o Linux.
    Ho notato che se mi collego su questo server da un client linux tramite "terminal server client" funziona alla grande;
    ma se provo da MS Windows (provato con XP SP2 e Vista), inizialmente sembra fuinzionare bene, ciè manda il login di gnome grafico, ed entro e per qualche minuto riesco a lavorare decisamente bene; ma dopo un pò, inizia a rallentarsi il tutto, fino al punto che io posso cliccare da qualsiasi parte, ma senza alcun effetto.
    Il programma usato è Cygwin con il batch configurato startxdmcp.bat. Non sò proprio come risolvere. Provando invece a collegarmi con X-Win32, tutto ok. Potete aiutarmi?

    RispondiElimina
  56. Questo che hai fatto tu non l'ho mai usato, quindi non ti posso aiutare. Ma per usare in finestra un desktop linux da un terminale win32 ti suggerisco di usare freenx (segui le istruzioni che trovi qua http://ubuntuforums.org/showthread.php?t=620057&highlight=freenx) ed il client nx free per windows che trovi su http://www.nomachine.com.
    Non va benissimo, di più ;-)

    RispondiElimina
  57. Grazie Enrico, freenx come dice il nome dovrebbe essere completamente free, l'avevo già provato in passato, funziona bene garantito, ma con la versione free, ho la limitazione sul numero di client che possono collegarsi contemporaneamente sul server, di conseguenza l'ho la sciato da parte come X-Win32. Al momento che conosca come soluzione free è ricorrere a cygwin, ma con problemi descritti. Se riesco a risolvere ti faccio sapere.
    Grazie per ora.

    RispondiElimina
  58. Non confondere: nomachine-nx versione free ha la limitazione sul numero di client e di connessioni, ma in più ha il supporto per l'audio via rete e altre cose. Freenx (quello del link qua sopra) è completamente free, non ha alcuna limitazione su client e connessioni. Quello che usi di nomachine è solo la parte client. In pratica rinunciando ad alcune cose (audio per es.) hai un terminal server che va benissimo anche su connessioni lente e non ha limiti di connessioni, sessioni etc.

    RispondiElimina
  59. Ah, questa proprio non la sapevo...
    Ero proprio convinto che in realtà si installasse il solito programma!
    Provo e ti faccio sapere

    RispondiElimina
  60. Sembra molto buono, inoltre a quanto son riuscito a capire i dati vengono cifrati con protocollo ssh, e quindi la possibilità di gestire anche le chiavi rsa per le connessioni!
    Domani provo a collegarmi contemporaneamente sul server se ci riesco da una decina di client...

    RispondiElimina
  61. Ri-eccomi!
    Ho provato in modo abbastanza assiduo freenx, e in contemporanea anche ltsp sullo stesso server. lavorano tutti e 2 alla grande.

    Avrei però alcune domande da fare su cose che non mi sono chiare abbastanza sia su freenx che su ltsp:
    FREENX:
    - E' possibile in qualche modo abilitare un qualcosa per trasferire i file, audio, stampa in locale? (Da quanto ho capito si può fare qualcosa del genere solo su NX a pago).
    - Ho provato a cambiare porta al servizio ssh diversa dalla 22. Collegandomi nuovamente con il client NX, si rifiuta totalmente a collegarsi sulla nuova porta impostata. Ma perche?

    LTSP:
    - Su alcuni pc specie i vecchi compaq Celeron 466 e 500, non si avviano:
    il boot via lan viene eseguito alla perfezione, (viene anche la scritta "Ubuntu" in modalità grafica), sembra che quando infine prova a tirare su la sessione X, li si blocca ritornando con il cursore in alto a sinistra che lampeggia.
    - Su alcuni pc LTSP si avvia, ma non funziona ad esempio l'audio, e/o non monta gli HD integrati.

    Per il resto è soddisfacente veramente!

    RispondiElimina
  62. In breve:
    freenx: hai capito bene, per il momento se vuoi le funzionalità aggiuntive devi pagarti nomachine-nx.
    ssh: mai provato a cambiare porta, comunque ho visto che sul server in /etc/nxserver/node.conf c'è l'opzione "#SSHD_PORT=22" (quotata di default). L'avevi già vista?
    ltsp: da come lo descrivi sembra un problema di corretta identificazione della scheda grafica, a volte succede. Dovresti provare a far partire quei pc con un cd live di ubuntu, verificare che driver grafico usano (ammesso che partano correttamente) e poi forzarglielo nell'lts.conf. Ci sono alcuni bachi noti di questo genere (per esempio uno con le schede grafiche AMD recenti) che saranno fissati con Hardy.
    periferiche esterne: è probabilmente un baco noto per il quale c'è un fix: https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/160420
    Anche in questo caso credo che sarà tutto fissato con Hardy.
    Per l'audio non ho idea, quello non mi ha mai dato problemi, tranne che per il microfono, dove però era proprio una scheda difettosa.

    RispondiElimina
  63. Grazie Enrico, il file di configurazione non lo avevo visto, modificherò la porta anche su di esso.
    Per ltsp i vecchi pc da una live di ubuntu bootano tranquillamente, anche se moooolto lentamente.
    Proverò a prendere la sezione di Xorg.conf relativa alla grafica e la inserirsco in ltsp.conf.
    Giusto?

    RispondiElimina
  64. Evabbè ... qua ormai siamo in tempo reale :-)
    Più che inserire tutto il xorg.conf penso che potresti provare modificando questi parametri in lts.conf:
    [mac address del pc che da problemi]
    XSERVER = nome del modulo giusto della scheda video
    X_HORZSYNC = 30-96 #solo un esempio
    X_VERTREFRESH = 50-160 #esempio

    I parametri di esempio riguardano marca e modello del monitor, devi ricavarli dalla documentazione, si trovano facilmente anche googlando. Il primo ovviamente è il driver della scheda che usi.
    Mi è successo che problemi simili al tuo siano andati a posto mettendo correttamente questi parametri, proprio perchè l'auto configurazione di X non funzionava bene.
    ciao

    RispondiElimina
  65. E diciamo proprio di sì... Cosa non si fa per ltsp... oggi il server mi ha fatto impazzire,
    ad un certo punto non andava neanche più in rete: la ventola del processore non fungeva più!
    Lasciamo stare ormai acqua passata.
    Ma se io, anche le variabili X_HORZSYNC e X_VERTREFRESH le prelevo dalla live ad ubuntu avviato da CD?

    RispondiElimina
  66. Se le trovi e se x funziona bene perchè no?

    RispondiElimina
  67. [...] quanto riguarda la configurazione del dhcp rimando alla descrizione che ho fatto qua. Sotto questo aspetto non è cambiato nulla. Alla fine della preparazione dell’ambiente [...]

    RispondiElimina
  68. Ciao, sto provando a mettere in piedi una rete con ltsp, ho installato il server seguendo la guida e quì tutto ok. I 2 pc che vorrei usare come client fanno il boot iniziano il caricamento appare lo splashscreen di unbuntu e poi si blocca tutto. Nei log trovo : tftp: client does not accept options

    Questo accade su enttrambi i pc il primo un portatile toshiba il secondo un asemblato .
    Su internet ho trovato poco tutti dicono che è un problem generico, mi potete aiutare.

    Complimneti per la guida è fatta davvero bene.

    RispondiElimina
  69. Confermo che si tratta di un problema generico. Anche in sistemi perfettamente funzionanti compare quella riga nei log. E comunque il tftp se arrivi a quel punto ha già fatto il suo lavoro, cioè ti ha trasmesso l'initrd e il vmlinuz. Quello che non funziona è nbdrootd, oppure l'immagine del root filesystem servita da nbdrootd è corrotta.
    Prova a ricreare l'immagine con ltsp-update-image.

    RispondiElimina
  70. Ciao, ho utilizzato dnsmasq come server ma quando il client parte non utilizza il proprio hostname ma quello della macchina, l'unica soluzione e creare reservation per tutte le macchine o si riesce in un'altra maniera?
    grazie
    ciao

    RispondiElimina
  71. [...] A questo punto c’è da installare il server DHCP. Ho provato e riprovato con i vari HowTo trovati in rete, ma alla fine ho optato per la soluzione proposta su www.zaffa.org (cui va il mio più sentito ringraziamento), che trovate qui. [...]

    RispondiElimina
  72. Ho installato Ubuntu Server 10.04 in modalità LTSP.
    Collego un client con boot da rete e lo faccio partire.
    Arrivo fino alla finestra di login,inserisco le credenziali di un utente di prova inserito nel server e faccio invio.
    Inizialmente viene fuori un messaggio con scritto "creating new authoriting file" poi,per uno motivo che ignoro,il client si blocca visualizzando solamente lo sfondo di ubuntu.
    Cosa significa?Devo modificare qualche file di configurazione?

    RispondiElimina
  73. Ciao sto provando a mettere su una rete ltsp ho installato edubuntu 10.10 che dovrebbe contenere già tutti i pacchetti necessari per l'implementazione.
    Ma quando provo ad avviare il thin client mi da questo errore "no DHCP or proxyDHCP offers were received" qualche aiuto???

    RispondiElimina
  74. Evidentemente non sta girando nessun server dhcp, o comunque non è disponibile per i client della rete. Se hai seguito le istruzioni del mio articolo (non so nemmeno se vadano ancora bene per ubuntu 10.10, ma penso di sì) controlla che stia girando "dnsmasq" e che sia ben configurato.

    RispondiElimina
  75. ok allora ho risolto il problema del DHCP poi seguend la tua guida quando arrivo al passaggio "sudo ltsp-build-client" mi dice che l'installazione del client è terminata in modo anomalo e infatti il client quando faccio il login mi dice "no respons from server" e si riavvia. sapresti dirmi qual'è il problema ora???

    RispondiElimina
  76. Ciao Enrico, ho seguito la tua guida passo passo, ho installato ltsp su ubuntu 10.10 e funziona il boot da rete con un client arrivo al boot grafico LDM inserisco utente e password, ma mi risponde dicendo "nessuna risposta dal server" e mi si riavvia.... Domanda (scusa l'ignoranza) ma devo avere, per caso, un sistema server di ubuntu?
    grazie per l'eventuale risposta e perdonami di nuovo l'ignoranza

    RispondiElimina
  77. No, non ci vuole nessun sistema server. Per scrupolo controlla che sia attivo il servizio sshd. D'altra parte è parecchio che non installo più un sistema ltsp quindi non saprei dire che cosa può essere cambiato nella 10.10 e, di conseguenza, che problema potrebbe essere.
    Se trovo un po' di tempo (difficile) nei prossimi giorni provo a fare un'installazione di prova, così mi tengo aggiornato.

    RispondiElimina
  78. Intanto grazie per le nozioni.
    Ho seguito le istruzioni, ma il boot sul client rimane con il puntatore e lo schermo nero.
    Sarei grato dell'aiuto perchè qui a scuola pc li vederemo col binocolo, con questo sitema forse riesco a recuperare dei pc per i ragazzi.

    RispondiElimina
  79. Ciao. Ho aggiornato il s.o. da ubuntu 8 a 10.04 in un server di una scuola che permette il boot ai client connessi attraverso la rete. Dopo l'aggiornamento i client non si avviano più. Per favore aiutami!!!

    RispondiElimina