Guacamole è un viewer  VNC scritto in HTML5 e Javascript, che fa uso di piccolo proxy, server side scritto in Java. Per questo avrete necessità di deployarla all’interno di un qualsiasi servlet container. Io ho sempre utilizzato Apache Tomcat.

Utilizzandola avrete la possibilità di accedere al server sul quale è installata da un comunissimo browser compliant con gli standard HTML5; da lì, avrete il “possesso” completo della vostra macchina, come se foste in console e…beh,  al diavolo il proxy HTTP che vi blocca le connessioni SSH (tanto per fare un piccolo riferimento al mio post precedente)!

Cmq, mi sembra superfluo continuare le spiegazioni (anche perchè non c’è molto altro da dire). Io proporrei di vederlo all’opera…voi che dite?

Il contesto

Due righe per spiegare dove e come proveremo Guacamole. Anzitutto l’OS: trattasi di una fantastica GNU/Linux Ubuntu Lucid Lynx 10.04 LTS; direi il capolavoro di Canonical. Quindi il servlet container scelto che, come detto, è Apache Tomcat in versione 6.0.24. In ultimo la versione della jdk: una 1.60_20 per piattaforma 64bit. Ok ora sappiamo tutto. Andiamo a provare Guacamole!

Installare Guacamole su Ubuntu 10.04

Anzitutto ci occorrerà installare un VNC server. Guacamole, come detto, utilizza un proxettino che si metterà in contatto con il questo VNC server e otterrà la view della vostra console che poi verrà ri-renderizzata in HTML5 e Javascript.

Io come VNC server ho utilizzato X11VNC. Perchè è semplice da installare (basta un apt-get install); perchè il deamon lo gestisci via xinetd (che comunque installeremo) e a me questa cosa piace; ma soprattutto perchè è consigliato dagli stessi creatori di Guacamole! Vediamo come installarlo:

e configuriamo xinetd per gestire X11VNC: creiamo il file /etc/xinetd.d/x11vnc che contenga:

Delle stringhe inserite qua sopra, la più rilevante è quella relativa ai server_args. Su Ubuntu questa è la configurazione ottimale, tuttavia ho già verificato che su altre distro c’è qualcosa da modificare (tipo Debian Lenny…). Ovviamente le modifiche dipendono direttamente da come viene configurato e gestito l’X server dalle varie distro. Diciamo che anche nella situazione peggiore, una googlata e un po’ di dimestichezza con l’X server dovrebbe risolvervi il problema.

Notate inoltre che il server VNC sarà in listening solo su localhost (istruzione “only_from”). Ovviamente, dato che il traffico VNC serve solo a guacamole che, nel nostro caso perlomeno, risiederà sulla stessa macchina server, non occorre esporre troppo il servizio.

Diciamo che le altre voci dovrebbero essere semplici da capire. Come semplice da capire è che il server VNC andrà in listening sulla porta 5900 e utilizzeremo il display :0.

In ogni modo ora X11VNC e xinetd sono installati e configurati. Un piccolo restart

e siamo apposto. Ora occupiamoci di Guacamole.

Chi non è nuovo di questo blog, sa che quando voglio installare un’applicativo che andrà in run da utente non privilegiato, io anzitutto creo un utente apposito e sfrutto la sua $HOME per installare l’applicazione che dovrà gestire. Apache Tomcat è un classico software che gira da utente non privilegiato. Di conseguenza creo l’utente “tomcat” che lo gestirà

e divento utente tomcat.

Tutto quello che accadrà da ora in poi sarà completamente “responsabilità” del nuovo utente

Siamo pronti per procurarci (prima di tutto) il software che ci serve. Quindi, prima di continuare la vostra lettura, assicurative di scaricare:

• la JDK a questo indirizzo: http://java.sun.com/javase/downloads/widget/jdk6.jsp
• Apache Tomcat a questo: http://tomcat.apache.org/download-60.cgi
• Guacamole sulla sua pagina Sourceforge: http://sourceforge.net/projects/guacamole/

Mettiamo tutto in una directory di proprietà dell’utente “tomcat” che chiameremo “pkg” e diamo i giusti permessi.

Come prima cosa installiamo la JDK e mettiamola nel $PATH dell’utente tomcat. Anzitutto diamo al .bin appena scaricato i permessi di eseguibilità

e quindi runniamo l’eseguibile

Creiamo un link simbolico per la dir della jdk. Questo ci darà due vantaggi:

• semplificare la path
• effettuare tutti i settings relativi alla messa in PATH della JavaVM utilizzando un percorso che non cambierà mai a prescindere le versioni della JDK che cambierete nel tempo.

Quindi modifichiamo il .bashrc dell’utente inserendo queste due righe:

e ricarichiamo le impostazioni utente

Se ora diamo un colpetto di which dovremo vedere che java viene correttamente identificato

A questo punto passiamo a Tomcat. Spacchettiamo il .tar.gz che abbiamo scaricato (ricordo che stiamo provando con la versione 6.0.24) e spostiamolo nella home dell’utente.

Ora, sempre nella dir ~/pkg spacchettiamo anche Guacamole:

All’interno della directory spacchettata troverete i seguenti files:

• guacamole.war: è il compilato dell’applicazione che deployeremo più tardi all’interno di Tomcat
• guacamole.xml: l’xml del contesto. Poche modifiche ed è già bello e pronto
• guacamole-users.xml: è il file xml che definisce l’autenticazione HTTP per accedere a guacamole. Anche questo provvederemo a modificarlo
• guacamole-src.tar: per chiunque ne senta il bisogno…ecco il sorgente!
• LICENSE.txt: la tua copia della licenza con cui è rilasciato Guacamole. Che è la GPL3.

Cominciamo l’installazione. Anzitutto copiamo il file guacamole.war all’interno della folder “webapps” del vostro tomcat.

Quindi copiamo il file guacamole-users.xml nella folder di conf di tomcat. Se aprite questo file, inoltre, vi accorgerete che la password è settata a “changeme”. Beh lo dice la parola stessa…modificatela!

Ora tocca al file di contesto. Apriamolo e modifichiamo la docBase del Context, specificando la path assoluta di dove si trova il nostro file .war. In poche parole sostituiamo questa riga qui:

con questa qui

Richiudetelo e spostatelo nella folder Catalina/localhost da creare all’interno della directory “conf”. Così

Ok signori. Abbiamo finito. Startiamo tomcat

e visitiamo la paginetta http://localhost:8080/guacamole. Inseriamo user e password specificati nel file guacamole-users.xml e… UALA’! Il VNC via HTTP è servito!

Bookmark It

Glassfish è l’Application Server OpenSource di Sun (da poco acquisita Oracle…con tutto quello che si potrebbe dire al riguardo e che non dirò), un prodotto che esiste ormai da più di due anni e ha raggiunto un discreto grado di maturazione, pur mancando ancora di quella “integrazione”, di quell’essere “suite” che ormai (sotto il controllo-spinta di RedHat) JBoss riesce maggiormente ad assicurare. Non è certamente questa la sede per avere maggiori indicazioni tecniche al riguardo, per questo potete chiedere a Google.

Noi cerchiamo solo di capire come effettuare una installazione del prodotto su un sistema operativo Ubuntu (per il test è stata utilizzata la versione server 8.10) pulita e con un sistema di start/stop automatico al boot.

Java

Prima di tutto sarà necessario installare la JDK Sun sulla nostra macchina. Per farlo, su un sistema debian-based come Ubuntu, è possibile aggiungere o semplicemente abilitare (solitamente già sono presenti, vanno solo decommentate) queste sorgenti al file sources.list che gestisce l’apt.

La nostra scelta cade sul pacchetto sun-java6-jdk contenente la versione 1.6.x del prodotto. A secondo del livello di upgrade di Intrepid, cambierà la minor release della JDK. Al momento in cui scrivo, l’ultima disponibile è la 1.6.0_10.

Tornando a noi: una volta abilitati i repositories, con un colpetto di apt (magie di debian), scarichiamo, installiamo e abilitiamo la JDK. Ovviamente da utente root.

Accettiamo tutte le dipendenze e lasciamo fare lo sporco lavoro al nostro sistema operativo. Alla fine basterà dare un colpetto di java -version da command line per avere qualcosa tipo:

Frasi che ci informano che tutto è andato a buon fine.

GlassFish

Ok, ora concentriamoci sull’installazione dell’AS vero e proprio. Scarichiamone il jar dell’ultima versione stable dal sito ufficiale. Al momento è la 2.1 b60e. Diciamo che un wget dovrebbe fare sufficientemente al caso nostro:

e ora scompattiamola in questo modo

Una volta accettata la licenza e scompattati i files, nella directory dove stiamo lavorando avremo una dir chiamata glassfish contenente tutti i files che ci occorrono per continuare.

E’ importante, a questo punto, individuare una directory dove far lavorare glassfish. Io tendenzialmente sono uso non utilizzare /opt per installare software di terze parti, ma preferisco sempre ragionare utilizzando l’associazione mentale “1 software >> 1 utente/gruppo >> 1 home directory”.
Volendo utilizzare questa strada procediamo con la creazione del gruppo e dell’utenza, copiamo la dir di glassfish all’interno della home directory del nuovo utente e cominciamo a lavorare direttamente da lì, dimenticandoci (il più possibile) l’utenza di root.

Credo sia praticamente inutile (e quindi utilissimo…) che io aggiunga che questa fase può essere tranquillamente saltata, tralasciando quella che è solo una mia abitudine. Ognuno ha i suoi standard. Ciò che, però è più importante, è evitare che l’application server “salga” da utente root. Ecco questo io lo eviterei come la peste.

A questo punto (con l’ultimo comando dato nel precedente blocco di codice) siamo utente “glassfish” e come tale operiamo all’interno della nostra home directory come preferiamo. Sfruttiamo ant contenuto in bundle a glassfish per lanciare il setup, ma prima di farlo ricordiamoci di dare all’eseguibile di ant i permessi di eseguibilità di cui è sprovvisto in default.

Il build durerà qualche secondo, e alla fine si completerà con successo (se così non fosse ricontrollate i passi precedenti perchè c’è qualcosa che non va…).

Ora facciamo una finezza con un po’ di forza bruta: per permetterci di aggiornare l’AS senza toccare ciò che deployeremo all’interno del default domain di glassfish, mi esternalizzo la directory relativa e con un symlink la lego comunque all’AS.

In questo modo ogni qualvolta voglio procedere ad un upgrade, non vado a toccare il contenuto del domain1 e con un nuovo symlink post-upgrade non perdo l’applicazione.

Ok ora possiamo startare l’AS:

Al termine dell’esecuzione aprite il browser e digitate http://indirizzo_server:8080. Vedrete la pagina di default di glassfish.

Il prossimo passo è modificare la password di amministrazione per accedere al pannello di controllo il porta 4848; ricordiamoci che la password deve avere perlomeno 8 caratteri di lunghezza. Anche in questa occasione usiamo il potentissimo binario asadmin.

Considerate che nel “code” qui sopra ho scritto in chiaro le password (sia quella vecchia che quella nuova): nella realtà esse sono nascoste, come se cambiaste password ad un qualsiasi utente unix.

Ok, anche questa è fatta: andiamo su http://indirizzo_server:4848 e proviamo a loggarci con le nuove credenziali admin/newpassword. Avremo così accesso al pannello di controllo di glassfish.

Fatto ciò il nostro esperimento potrebbe definirsi concluso. Ma c’è una cosa che ancora possiamo fare per completare meglio la nostra installazione: creare un init-script per fare in modo che l’AS parta al boot.

Init Script

L’init script che segue è relativo all’installazione che io ho fatto nella guida. Ovviamente è ampiamente suscettibile di customizzazione e soprattutto miglioramenti. Ma funziona e non è poco . Ringrazio Cay Horstmann (http://weblogs.java.net/blog/cayhorstmann/archive/2006/07/installing_glas.html) per il template dello script e per la guida ufficiale in lingua inglese alla quale mi sono “liberamente ispirato” per scrivere la mia.

Per aggiungere il nuovo init script all’interno dei runlevel di ubuntu è sufficiente scrivere da root

Ora è davvero tutto. Enjoy with glassfish!

Bookmark It