giovedì 22 novembre 2007

Ltsp su architettura X86_64

In alcuni commenti ad un post precedente si era parlato di LTSP server su architettura a 64 bit. Io, non avendolo mai provato e presumendo complicazioni, sconsigliavo di farlo. Avendo adesso a disposizione una macchina a 64bit ho deciso invece di provare.
Ho installato una versione di Ubuntu Gutsy per AMD64, poi ho creato l'ambiente server per ltsp usando i comandi già descritti in questo post. Dal momento che il server dhcp risiedeva su un'altra macchina della rete ho dovuto semplicemente modificare qualche parametro per indirizzare le richieste di tftp al server giusto. L'unica piccola (ma sostanziale) differenza in tutto il processo è stato il comando per creare l'ambiente chroot dei client: ho infatti usato "sudo ltsp-build-client --arch i386".
Con questa opzione attivata viene infatti costruito un ambiente chroot in grado di far partire i pc con architettura uguale o superiore a i386 (cioè tutti i cosiddetti x86). La scelta è logica poichè i thin client per definizione sono macchine poco potenti e difficilmente vengono costruiti su architetture diverse dalla x86, e comunque all'occorrenza anche un pc con processore X86_64 gira tranquillamente con sistema operativo a 32 bit per i386.
Nella pratica succede che i thin client fanno il boot e avviano i processi di sistema di base a 32 bit nell'ambiente chroot, dopodichè in ambiente grafico (e a questo punto siamo sul server) le applicazioni che vengono lanciate sono a 64 bit. I vantaggi sono evidenti: se vogliamo gestire un numero molto elevato di thin client l'architettura X86_64 è in grado di usare in modo molto più efficiente quantità di memoria ram superiore ai 4Gb. Per una esaustiva discussione sulle differenze tra sistemi a 32 e 64 bit suggerisco di dare un'occhiata qua.


Tuttavia non ci sono solo vantaggi, ci sono anche alcuni svantaggi. Attualmente la disponibilità di software per l'architettura a 64 bit si sta ampliando sempre di più ma mancano ancora alcuni applicativi "bloccanti" che scoraggiano l'utilizzatore comune. Ad esempio manca un plugin java per i browser a 64 bit, o meglio, ce ne sono alcuni non rilasciati da Sun, che a volte funzionano e a volte no, stessa situazione per il plugin flash di Adobe che, essendo closed source, viene distribuito in forma compilata a 32 bit. Su Ubuntu 64 bit si riesce comunque a far girare attraverso nspluginwrapper. Esistono in realtà alcuni plugin flash Open source e di uno di questi -swfdec- scriverò alla fine del post. Altre cose non funzionano bene: ad esempio i bookmark della Goggle Toolbar (una delle cose che uso di più) non vanno. Quindi firefox compilato nativamente per piattaforma a 64 bit può essere usato solo a condizione di poter fare a meno di alcune funzionalità. Sinceramente io non lo userei volentieri. Altrimenti si usa un firefox a 32 bit, che è in grado di far funzionare tutti i plugin e le estensioni senza problemi e con una perdita di prestazioni davvero minima, anzi, direi impercettibile. Istruzioni dettagliate su come installare firefox a 32 bit e relativi plugin si possono trovare qua. Per inciso la procedura descritta qua sopra funziona benissimo anche per Thunderbird, tranne che ovviamente per la parte di aggiunta dei plugin. In effetti anche thunderbird sembra soffrire di alcuni problemi nella versione a 64 bit: quello che mi ha spinto a provare la versione a 32 bit è stato il non perfetto funzionamento dell'estensione lightning, che uso tantissimo interfacciata al Calendario di Google.

Ma dal momento che si sta lavorando per preparare un ambiente terminal server queste istruzioni non sono sufficienti. Vogliamo anche avere l'audio sui thin client quando guardiamo un filmato su youtube, o no? Per fare questo occorre far parlare il plugin flash a 32 bit del browser con il sistema pulseaudio a 64 bit del server che poi ritrasmetterà il flusso audio al pulseaudio del thin client.
Per permettere all'audio di funzionare correttamente questi sono i pacchetti che occorre installare sul server:

ia32-libs libc6-i386 lib32asound2 libesd-alsa0

(questi sono tutti pacchetti di librerie di supporto a software a 32 bit), cui seguono i pacchetti del sistema pulseaudio:

libao-pulse libpulse-mainloop-glib0 libpulse0 pulseaudio pulseaudio-esound-compat pulseaudio-module-gconf pulseaudio-module-hal pulseaudio-module-x11 pulseaudio-module-zeroconf pulseaudio-utils paman padevchooser paprefs

Sarà utile creare un file /etc/asound.conf fatto in questo modo:

pcm.!default {
type pulse
}


ctl.!default {
type pulse
}


in modo da impostare pulseaudio come motore sonoro di default per tutto il sistema. Oppure per ogni utente lanciare da linea di comando asoundconf set-pulseaudio.

Dopodichè si modifica il file /usr/local/bin/firefox32 in modo che risulti così (l'aggiunta è nella penultima riga):
#!/bin/sh
export GTK_PATH=/usr/lib32/gtk-2.0
export PANGO_RC_FILE=/etc/pango32/pangorc
export GDK_PIXBUF_MODULE_FILE=/etc/gtk-2.0/gdk-pixbuf.loaders.32
export FIREFOX_DSP=esd
linux32 /usr/local/firefox32/firefox $@


E poi, tocco finale senza il quale non va nulla, scaricate la libreria libflashsupport che ho ricompilato con alcune modifiche per permettergli di funzionare in questa configurazione, e salvatela in /usr/lib32 dove il plugin flash andrà a cercare le librerie di supporto. Fatto questo il suono delle applicazioni flash che girano in firefox32 si sentiranno anche sui thin client.

Per chi volesse ricompilarsi (o anche pacchettizare) libflashsupport spiego la procedura.
Innanzitutto per poterlo compilare correttamente ci vogliono alcune librerie a 32 bit. Per evitare lunghe e penose installazioni di software a 32 bit su una macchina X86_64 ho raccolto queste librerie in questo file, sarà sufficiente scompattare l'archivio e copiare i files in /usr/lib32.

I sorgenti più recenti di libflashsupport si scaricano qua. Una volta scompattato l'archivio vanno modificate le righe CFLAGS e LIBDIR del Makefile in questo modo:

CFLAGS=-fPIC -shared -O2 -Wall -m32
LIBDIR=/usr/lib32


a questo punto si può compilare.

Se invece per semplicità si dovesse decidere di lasciare installato il browser a 64 bit così come viene dalla distribuzione e si fosse disposti a rinunciare a qualche funzionalità, esiste comunque un modo per usare sui thin client il plugin flash opensource swfdec che, a partire dalla versione 0.5.4 ha aggiunto il supporto a pulseaudio. L'opzione di configurazione però non è documentata e ho un po' fatto fatica a trovarla: quando si lancia il comando ../configure l'opzione per abilitare pulseaudio è --with-audio=pa. Bisogna anche avere installato il pacchetto libpulse-dev. Per chi non vuole cimentarsi con la compilazione metto a disposizione i pacchetti già pronti per Ubuntu Gutsy AMD64 con pulseaudio già abilitato: swfdec, swfdec-gnome, swfdec-mozilla (su richiesta in breve tempo potrei anche fabbricare dei pacchetti per ubuntu 32bit). Inutile dire che declino qualsiasi responsabilità sul fatto che vadano, non vadano o addirittura facciano dei danni. L'unica cosa che ho testato è che l'audio in uscita dai filmati di youtube funziona bene usando il plugin swfdec-mozilla con pulseaudio. Quindi non accetto reclami, semmai suggerimenti :-)

23 commenti:

  1. Ciao... lavoro in un comune dove stiamo cercando di portare il più possibile verso l'open source, anche seguendo i tuoi preziosi consigli.

    Stiamo cercando di impostare un server ltsp su uno xeon a 64 bit... dopo alcuni tentativi abbiamo messo una ubuntu 7.10 desktop a 32bit, con risultati discutibili: un solo client va e non c'è verso di avviare qualunque altro tipo di computer ...

    Quindi ti chiedo un consiglio. Ora rifaremo il server, come distribuzione per avere una certa solidità cosa ci consigli? ubuntu server 7.10, server 6.06 (le innovazioni della 7.10 sono belle, ma che siano immature?)... o che possa essere meglio una debian?

    Che possa valere la pena di avere un server a 64 bit...?
    Dedicare uno swicth solo per i thin client può risolvere qualche problema?
    ho la sensazione che i tempi siano ancora un po' immaturi ma abbiamo moltissimi computer obsoleti che per la gioia (e il risparmio) dei contribuenti potrebbero rinascere a nuova vita.

    Un tuo consiglio è prezioso, grazie mille, ciao.

    RispondiElimina
  2. Ciao dax, in che comune lavori? Giusto per curiosità: mi fa piacere sapere che ci sono amministrazioni pubbliche che (finalmente) fanno qualcosa di furbo.
    Comunque la risposta alle tue domande non è semplice. Se hai del tempo a disposizione (cioè non devi far andare le cose dall'oggi al domani) io metterei una Gutsy desktop a 64 bit. Sicuramente uno switch recente dedicato al server e ai thin client non sarebbe male, soprattutto se quello che avete adesso è vecchio. Non si direbbe ma a volte switch e altri apparecchi di rete fanno la differenza (nel bene e nel male). Ovviamente i client devono avere schede fast ethernet a 100 Mbit. Fai conto che con un server con cpu recente e 2 Gb di ram e che fa solo da ltsp server dovresti reggere secondo me tra i 10 e i 20 client, a seconda di quello che gli fai fare. Considera anche Xubuntu che ha un'interfaccia molto leggera. Comunque a parte qualche residuo baco, soprattutto su come funzionano i local device, Ubuntu 7.10 Gutsy va benissimo e mi pare che per LTSP abbia portato un bel guadagno di prestazioni. Fammi sapere.
    ciao

    RispondiElimina
  3. ora come ora siamo riusciti a far andare abbastanza bene la 7.04 server (con gnome desktop)... avvia praticamente di tutto tranne macchine molto vecchie... (p 1)

    I client volano, soprattutto quelli con un giga di scheda (ovviamente)... abbiamo fatto una sottorete e il server ha fatto da solo il nat (anche se i client hanno una maschera diversa dal router vengono reindirizzati perfettamente)...

    Io sto seguendo oltre la guida ubuntu anche i tuoi consigli e va un po' tutto... siamo abbastanza presi per la gola con i progetti da avviare... ma quello che stiamo cercando ora è un discorso di stabilità... che la 7.10 non possa essere troppo giovane? Anche la 7.04 va benone ma c'è qualche intoppo ad esempio sullo gnome del server che ogni tanto fa le bizze nella disconnessione dell'utente...

    Si pensava tra di noi di provare la Debian... che possa essere più rocciosa e stabile (sullo xeon con 4 giga di ram vorremmo portare un 30, 40 client)... Non possiamo iniziare a portare client agli uffici finché non siamo certi che ci sia stabilità... ma volevamo farlo nei prossimi giorni.

    Ogni opinione in merito è preziosa :)

    (siamo al comune di Negrar (Vr)... :))

    Grazie mille!

    RispondiElimina
  4. Ma i vostri utenti cosa devono fare sul pc? Sapere questo cambia molto. Se poteste far usare xfce ai vostri utenti al posto di gnome o kde credo che ne guadagnereste in performance e in stabilità, e poi è carino, a me piace.
    Per me Gutsy è stabile, dove ho i thin client in produzione finora non ha fatto una piega (a parte un baco sui local device, non risolto ma con un workaround). Debian (stabile) credo che abbia una versione piuttosto vecchia di ltsp, equivalente forse a quella che c'era su Edgy, che comunque già non era male, ed in ogni caso l'attuale mantainer è lo stesso di Ubuntu. In fondo dipende da quanto cattivi sono i tuoi utenti e i tuoi capi, a me in fondo, anche a costo di prendermi inizialmente qualche insulto, piace rischiare ;-)

    RispondiElimina
  5. uff mi si è mangiato il commento...

    xfce a me piace molto, ma testandola ci siamo accorti che openoffice veniva fuori senza menù grafico... quindi è stata scartata...

    ho messo su fuse (sempre seguendo i tuoi consigli)... monta benissimo tutto, ma non lo fa smontare, è normale?

    certo è sabato sera e sono qua che penso al ltsp server, considerato che sono pure l'ultima ruota del carro :)

    7.04 cmq sembra funzionare... mi affascina partire subito dalla 7.10, ma mi fa un po' paura perché è diversa in molte cose e c'è poca documentazione, e si dovrebbe partire subito operativi e stabili... non saprei proprio.

    Visto lo stato di decine di p2 e p3 arrancanti con licenze ehm... discutibili, terminal server è una possibilità ben vista dai capi a occhio.

    grazie mille, ciau

    RispondiElimina
  6. Ti ripeto, per mia esperienza 7.10 va bene. L'unico problema con cui mi sono scontrato è questo: https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/160420 attualmente risolvibile (in parte) con un workaround.
    Comunque se tu imposti un server dhcp esterno diverso dal server su cui gira ltsp nel giro di pochissimo tempo sei in grado di installare, cancellare, reinstallare il server ltsp senza doverti riscrivere ogni volta la configurazione. Può venirti utile per fare le prove.

    RispondiElimina
  7. :) ti ringrazio...

    continua così

    RispondiElimina
  8. Is there any chance to translate this article to english ? It seems intresting, and I have some problems with flash under amd64 gusty. Unfortunatly I don't speak your language at all. I am not even sure what your english is ? If you that, It would be very aprreciated ! Thanks.

    RispondiElimina
  9. Not enough time now to translate the whole article, but I feel this could be interesting for a lot of people so .... why not, but I don't know when. Anyway if you tell me exactly what problems do you have I can try to summarize the relevant parts.

    RispondiElimina
  10. Thank you for your reply. My problem concerns using libflashsupport on 64-bit macine in order to get sound in flash objects on ltsp terminal. I tried to copy all necessary (I found a "home made" ubuntu 64bit package with libflashsupport) to /usr/lib32 but the only effect was that flash is not playing anymore. Firefox started from cmd line fives me this message: *** NSPlugin Wrapper *** ERROR: NPP_SetWindow() wait for reply: Connection closed
    *** NSPlugin Wrapper *** ERROR: NPP_SetWindow() invoke: Connection closed
    *** NSPlugin Wrapper *** ERROR: NPP_New() invoke: Connection closed
    *** NSPlugin Wrapper *** ERROR: NPP_New() invoke: Connection closed
    *** NSPlugin Wrapper *** ERROR: NPP_NewStream() invoke: Connection closed
    *** NSPlugin Wrapper *** ERROR: NPP_GetValue() invoke: Connection closed
    *** NSPlugin Wrapper *** WARNING: unhandled variable 11 in NPP_GetValue(). When I removed libcap.so flash started again, but also without sound. If I start firefox from cmd line i get following message : ALSA lib ../../../src/pcm/pcm.c:2105:(snd_pcm_open_conf) Cannot open shared library /usr/lib/alsa-lib/libasound_module_pcm_pulse.so. The same message I get without 64-bit package installed.

    RispondiElimina
  11. Forget firefox X86_64. Install a a 32 bit version following this instructions: https://help.ubuntu.com/community/AMD64/FirefoxAndPlugins?action=show&redirect=FirefoxAMD64FlashJava
    Be sure you have this packages: ia32-libs libc6-i386 lib32asound2 libesd-alsa0.
    Install and configure the pulseaudio system using the list of packages provided in the article and the asound.conf example file.
    Add the line "export FIREFOX_DSP=esd" to the file /usr/local/bin/firefox32 as shown above.
    Download this http://www.zaffa.org/wp-content/uploads/2007/11/libflashsupport.so and copy it in /usr/lib32. It's a version I compiled from original sources modifying the makefile in order to make it working for this particular case.
    If audio is working on thin clients also flash on firefox should work now.
    Let me know.

    RispondiElimina
  12. ... of course be sure you launch the right 32bit firefox version ;-)

    RispondiElimina
  13. Thank you for your help. I thought it can be done on 64-bit version of Firefox. It's possible to run java plugin, is should be also with flash. Thanks you anyway.

    RispondiElimina
  14. By the way, Gnash can also be used on 64-bit machnes with 64-bit version of firefox but it is to buggy yet to run in in production enviroment.

    RispondiElimina
  15. This is exactly why I definitely put a 32 bit firefox, with all addons and plugins working, in a 64 bit environment.

    RispondiElimina
  16. abbiamo provato un upgrade di distribuzione da 7.04 a 7.10... e sono iniziati un po' di problemini, soprattutto nel riconoscimento della grafica...

    ciao!

    RispondiElimina
  17. Spero risolti o risolvibili.

    RispondiElimina
  18. Ciao Enrico...
    ti lascio un commento per chiedere una tua opinione.
    Dopo interminabili test e discussioni col mio collega stiamo per iniziare a distribuire terminali ltsp fra i dipendenti.
    La scelta di distro pare sia ormai ricaduta su ubuntu 6.06 desktop lts.
    Motivi: maggiore leggerezza, apparentemente maggiore stabilità, lungo supporto, desktop più semplice ma mi pare più affidabile.
    Che ne dici?
    Nel frattempo abbiamo la biblioteca comunale con 4 client su ubuntu 7.10, diciamo in fase di test per le novità. Anche se ho notato che sulla 7.10 c'è qualche imperfezione: a volte il processore schizza a mille senza apparente motivo, il processo nautilus di un client va in crisi. E la cosa è successa in due installazioni diverse su due macchine diverse.

    Ho la sensazione che nella pubblica amministrazione siamo un po' all'avanguardia... c'è poco che non riguardi le scuole e la situazione è diversa da un laboratorio informatico. Le sedi amministrative sono due e abbastanza grandi, abbiamo bisogno di avere tutto che va.
    Abbiamo individuato come server uno Xeon biprocessore montato su rack, con 4 gigi di ram e raid 1... e abbiamo già 20 postazione individuate per i primi client.

    Ubuntu 6.06... che ne dici? Alla fine ci limiteremo al kernel 686 col supporto multiprocessore. Anche se la macchina è a 64 bit. Ci sono dei dipendenti che devono usare siti con java... non voglio rischiare (altro grande problema i siti ministeriali solo per explorer, stiamo cercando di aggirare i problemi)

    Ci dai la tua benedizione per l'avvio del progetto?

    Intanto grazie, se la cosa va in porto sarà anche per i tuoi consigli. Se ti va scrivimi pure, ti terrò aggiornato.

    Ciao!

    RispondiElimina
  19. LOL ... la mia benedizione ... manco fossi chissà chi :-)
    Comunque la verità è che ltsp su Ubuntu 6.06 non l'ho mai fatto girare. Però nel complesso è certamente una buonissima versione. Ho un paio di server con quella versione che vanno benissimo. Se hai già fatto le prove e se l'hardware dei thin client non da problemi è sicuramente una buona scelta. L'unica cosa è che il supporto lts non durerà ancora molto. Se aspettate aprile magari potete installare la nuova versione lts (Hardy), in modo da avere il supporto per altri 3 anni. Se volete risolvere problemi di pesantezza (e di stabilità) usate il desktop xfce (xubuntu desktop) invece di gnome, per gli utenti una volta prese le misure cambia poco.
    A parte questo sono d'accordo con te sulla scelta del kernel 686. L'architettura x86_64 secondo me non è del tutto pronta per essere usata sui desktop .... anche se .....
    Tienimi aggiornato se hai voglia, mi interessa.
    ciao

    RispondiElimina
  20. Terza volta che scrivo il commento e wp se lo pappa..
    riassumo... Contrordine... mettiamo la Xubuntu 7.10!

    RispondiElimina
  21. Ciao a tutti! Ho provato ltsp su xubuntu e gira che è una meraviglia. Avrei però una domanda da porvi: ho un server xen in cui vorrei far girare una macchina virtuale (debian etch) che faccia da ltsp. Vorrei però che i client "girassero" su kubuntu 7.10. E' possibile creare un immagine della distro differente dal server? Grazie in anticipo

    RispondiElimina
  22. Appena lanciato su P4 Em64T 2Gbyte installazione Ltsp su Ubuntu 8.04 con client x86 funziona tutto fino ad ora tutto, i client sono una decina di vectra VL e Ve 256Mb, mga G200Video card, no audio, network boot da 3com59x stò carrozando i clinet con un po di tutto per lavoro aziendale.

    RispondiElimina
  23. Maybe you could make changes to the webpage name title Ltsp su architettura X86_64 | zaffa.org to more generic for your webpage you write. I enjoyed the post even sononetheless.

    RispondiElimina