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

L’environment scelto, come detto, è una Centos, ma (a parte i posizionamenti dei files e delle directory che può cambiare, la configurazione di Bind9 è piuttosto generica e quindi, la guida, può essere “traslata” facilmente anche su sistemi “debian-based”.

Non è questo il luogo dove illustreremo le peculiarità e i vantaggi in termini di sicurezza che stanno dietro alla scelta di installare e configurare in modo che sia startato dal sistema in chroot. Googlando un po’ troverete molte guide e manuali che vi possono spiegare tutto ciò.

Come primo passo installeremo i pacchetti necessari utilizzando yum

Ad installazione conclusa spostiamoci nella directory /var/named/chroot/etc e cominciamo le configurazioni

Controllate che il file rndc.key appaia così:

Non vi occorre nient’altro, quindi potete anche rimuovere le altre righe che troverete nel file.
Date un’occhiata all’interno di /etc: dovreste avere un symlink all’rndc.key. E’ importante che questo symlink esista e dovrebbe essere correttamente creato da yum durante la fase di spacchettamento dell’rpm. Se, tuttavia, così non fosse preoccupatevi di crearlo, perchè poi il demone named si aspetta di trovarlo lì…è bene che non lo deludiate.

Ora configuriamo il file named.conf

Ok: ora configuriamo la nostra zona. Per farlo creiamo il file /var/named/chroot/var/named/data/example.com.zone. Sarà qualcosa che appare più o meno così:

Ovviamente la parte in fondo customizzatela a secondo dei record che volete propagare.
Ok abbiamo finito. Come avete visto è veramente semplice. Ora startiamo named e assicuriamoci che parta al boot

E ora controlliamo che tutto sia startato correttamente dando un colpetto di “rndc status”

Ok è tutto “folks!”. Per essere sicuri che tutto funziona fate qualche query con nslookup o con dig, sia dal server dns che dagli altri server.

Bookmark It

• Load balancing: le richieste degli utenti vengono processate da più server che si dividono il carico equamente.
• Server affinity (sticky session): Attraverso il sistema di “server affinity” le richieste di uno stesso utente vengono processate dallo stesso server.
• jsessionid: E’ un codice univoco che viene rilasciato dal Tomcat al browser dell’utente finale e che identifica univocamente la sessione dell’utente sull’applicazione deployata dal Tomcat.
• Worker name: E’ il nome che viene assegnato univocamente al Tomcat. Ogni Tomcat che compone il cluster ha un worker name differente.

Load Balancing con server affinity

Come detto Apache implementa server affinity attraverso la riscrittura del jsessionid inviato dal Tomcat al browser. Il Tomcat worker name viene aggiunto alla fine del jsessionid, prima che tale id venga inviato dal Tomcat al browser. Alla prossima richiesta che l’utente effettua con un determinato jsessionid, il Tomcat che la riceve legge il worker name e la richiesta viene delegata al Tomcat “proprietario” del worker name.

Ora andiamo alla configurazione. Ipotizziamo di avere una struttura simile a quella della figura qui sotto

Schema Load-Balancing

nella quale un Apache accetta le richieste destinate ad una webapp in cluster all’interno di due istanze di Tomcat.

Il primo step è controllare di aver abilitato i seguenti moduli Apache:

• mod_proxy
• mod_proxy_balancer
• mod_proxy_ajp
• mod_proxy_connect
• mod_proxy_ftp
• mod_proxy_http

Quindi apriamo il file di configurazione httpd.conf e inseriamo questa parte di codice

Abbiamo deciso di far dialogare Apache e Tomcat attraverso ajp, ma è possibile effettuare la medesima configurazione anche contattando tomcat via http. Ovviamente è necessario customizzare alcune parti:

• al posto di ”/apache-balancing” inserite il vostro context (che deve essere uguale a quello di Tomcat). Ovviamente può anche essere /.
• al posto di tomcat1_server e tomcat1_ajp_port inserite l’ip o il FQDN del server 1 e la porta AJP. Stessa cosa con tutti gli altri nodi (BalancerMember) che definite.
• al posto di worker_name1 inserite il worker name che volete identifichi univocamente il tomcat. Stessa cosa con tutti gli altri nodi che definite.
• il _loadfactor_ può essere un numero compreso fra 1 e 100.

Ora continuiamo la configurazione che interessa il file di configurazione dei Tomcat, server.xml aggiungendo il worker name, in questa maniera.

Stessa cosa facciamo col file server.xml del tomcat che corrisponde al worker_name2. Quindi abilitiamo sempre su ogni server.xml (se non fosse già abilitato) il Connector Ajp, decommentando queste righe

Dovrebbe bastare. Restartiamo i due Tomcat e l’Apache di frontend e proviamo a puntare l’indirizzo mod_proxato sull’Apache: dovremmo riuscire a navigare l’applicazione tranquillamente. Possiamo controllare la jsessionid attraverso Firefox o utilizzando l’add-on Firebug sempre per Firefox.

Bookmark It