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

E allora ho pensato: perchè non raccontare come garantirsi una connettività ssh anche quando sembra impossibile?

Lo scopo di questo post è dare le indicazioni necessarie per permettere alla propria Linux-box di raggiungere in ssh qualsiasi server sparso nel pianeta, anche nella situazione più scomoda del mondo. Quando, cioè, la nostra connettività è sottomessa ad un cattivissimo proxy che ci lascia libere solo le porte HTTP e HTTPS in uscita. Per farlo eseguiremo un tunneling ssh attraverso il nostro maledettissimo proxy, e sfrutteremo un softwarino open piccolo piccolo ma potente potente: Corkscrew.

Un po’ di teoria (semplificata)

Probabilmente sappiamo tutti cos’è un proxy e come funziona. Se qualcuno avesse dei dubbi, può dare un’occhiata alla pagina relativa su Wikipedia. Molto spesso, essere dietro ad un proxy HTTP, vuol dire dover rinunciare a tutti i flussi comunicativi che non siano, appunto, flussi HTTP o HTTPS. Il che si traduce in una semplice affermazione:

qualsiasi tentantivo di connessione verso l’esterno diretto verso porte diverse dall’80 (HTTP) e dalla 443 (HTTPS) risulteranno bloccati dal proxy.

Come sappiamo, quando provo a loggarmi in ssh su un server remoto, sto provando ad istanziare una connessione sulla porta 22 di questo server. Ovviamente il proxy HTTP non mi farà passare. Come risolvere questo problema?

Diciamo che la soluzione che mi sono divertito a trovare non è proprio “a basso impatto”!! Nello specifico si tratta di utilizzare (e quindi di base di avere a disposizione…) un “server ponte”, sul quale settare SSH in listening sulla 443.

La 443 è la porta dell’HTTPS. L’HTTPS è consentito generalmente da un classico proxy HTTP. Di conseguenza, istanziando una connessione ssh sul nostro “server ponte”, stiamo materialmente chiedendo al nostro proxy di far passare un flusso dati destinato ad una porta che lui considera abilitata.

Questo è il nostro ambiente, questo è quello che spiegheremo di seguito.

Due parole su Corkscrew

Corkscrew è, banalmente e semplicemente, un software che permette la realizzazione di tunnels ssh attraverso proxies HTTP. La sua home page è questa: http://www.agroman.net/corkscrew. Se utilizzate Debian o Ubuntu (server o desktop non fa differenza) ve lo trovate già pacchettizzato. Altrimenti dovrete attrezzarvi e compilarlo, ma non è certo un lavorone. Nel nostro caso utilizzeremo come “distribuzione-esempio” Ubuntu Lucid Lynx 10.04 LTS.

La configurazione di Corkscrew è veramente semplice e consta di un file config che va posizionato all’interno della cartella .ssh che ogni utente linux dovrebbe avere nella sua $HOME.

Iniziamo a lavorare

Configuriamo il server ponte

Cominciamo dal nostro “server ponte” Qui dovremmo mettere SSH in ascolto sulla 443. Non lo togliamo, però, dalla porta 22 perchè può sempre tornare utile!

Per fare ciò è sufficiente aprire il file /etc/sshd/sshd_config ed aggiungere la seguente stringa:

sotto la dichiarazione (uguale peraltro) relativa alla porta 22. Restartate SSH

e il gioco è fatto. Con un piccolo netstat vedremo che SSH è correttamente in LISTENING sulla porta 443.

Come potete vedere nella terza riga, SSH aspetta la nostra connessione sulla porta 443. Perfetto! Ora procediamo a configurare il client.

Configuriamo il nostro client

Sul nostro client, anzitutto, scarichiamo corkscrew. Può bastare un colpetto di apt-get…

Una volta concluso download ed installazione del pacchetto entriamo nella nostra directory .ssh

e qui creiamo il nostro file “config”

che conterrà due righe due

Ovviamente sostituite “my.proxy.local” con l’indirizzo o il FQDN del vostro proxy e 8080 con la porta sulla quale esso è in listening. Una volta fatto ciò il gioco è fatto. Dalla vostra shell digitate

Una volta che siete lì…siete dappertutto!!!

E se il mio proxy necessita di credenziali???

A volte può accadere che sia necessario inserire delle credenziali per accedere al proxy. In quel caso è necessario scrivere quelle credenziali in un authfile. Creiamolo:

e scriviamo all’interno le nostre credenziali, prima la username, poi la password separate da un “:”. In questo modo

Per farlo leggere al file config è necessario aggiungere alla seconda riga del config la path (anche relativa) dell’authfile. Il config diventerà quindi:

Nel nostro caso, dato che l’authfile si trova esattamente allo stesso livello del file config può bastare inserire solo il nome del file.

Ok anche qui il gioco è fatto. Un colpetto di ssh sul serverponte e siete fuori!

ATTENZIONE!!!

Attenzione:  tutte le indicazioni date sopra potrebbero non essere valide (quindi non funzionare!) se il vostro è un proxy NTLM. In quel caso dovrete utilizzare corkscrew in combinazione con NTLMAPS. Ma questa è un’altra storia…che forse scriverò!

Enjoy!

Bookmark It

Dear Google Apps admin,

In order to continue to improve our products and deliver more sophisticated features and performance, we are harnessing some of the latest improvements in web browser technology.  This includes faster JavaScript processing and new standards like HTML5.  As a result, over the course of 2010, we will be phasing out support for Microsoft Internet Explorer 6.0 ​as well as other older browsers that are not supported by their own manufacturers.

E non è tutto: il messaggio continua con un ultimatum veramente incredibile!!!

We plan to begin phasing out support of these older browsers on the Google Docs suite and the Google Sites editor on March 1, 2010.  After that point, certain functionality within these applications may have higher latency and may not work correctly in these older browsers. Later in 2010, we will start to phase out support for these browsers for Google Mail and Google Calendar.

Amici, ce l’abbiamo fatta. Il browser più terrificante, inusabile, dittatoriale, scriteriato, brutto, vecchio, odiato da tutti i developers del globo terracquo, viene ufficialmente scaricato da Sua Maestà Google. Ci abbiamo messo PIU’ di otto anni. Otto anni nei quali il mondo di internet è cambiato perlomeno ottocento volte, presentando perlomeno ottomila novità. Ma lui era rimasto lì, saldo, sul trono, come un sovrano vecchio e tiranno di cui non ci si riesce a liberare. Una svolta, per tutti. Una svolta che viene, però, da lontano.

Circa un anno fa, il 23 febbraio 2009, in tempi assolutamente non sospetti, un grido rompeva la pace dell’era di Re Internet Explorer Sesto: Calling Time on IE6!!! E a lanciarlo erano proprio i suoi sudditi: l’appello appare sulle pagine di .net magazine! Il suo editore, Dan Oliver, è netto nel giudizio:

The premise is simple: Internet Explorer 6 is an antiquated browser, does not support web standards, and because of this should be phased out. [...]
So come on Microsoft, do us all a favour, and help us bury this horrible browser once and for all!

Una chiusura che non sembrava ammettere repliche. Microsoft non sembra aver ascoltato il nostro eroe, ma qualcun altro si! Sei mesi più tardi, è Youtube a fare il passo. Questo è ciò che leggemmo in un’articolo di “fuego” su TechRadar.com:

YouTube will no longer support Internet Explorer 6, TechRadar can confirm, with Google beginning to roll out warnings to those accessing the video site that they should update to a better browser. [...]
IE6 is a much maligned program in the modern environment, even sparking a campaign from .net magazine to ‘kill’ the browser.

Fu il colpo di grazia.

Oggi siamo qui, a commentare un funerale in diretta, come suggeriscono quei geni di IEFuneral.com. E il nostro commento, in queste ore di dolore e rammarico, ricordi e rimpianti può essere solo…

FINALMENTE!!!

Bookmark It

Fate un salto su questo sito

http://www.catswhothrowupgrass.com/kill.php

e date un’occhiata a tutti i pericoli che corriamo quotidianamente noi che ospitiamo un felino nelle nostre case!!

Ho fatto anche il test e…

Bookmark It

Di conseguenza CentOs (che segue pedissequamente i rilasci degli rpm-src RHEL), anche nella sua latest 5.4, ti propone PHP 5.1.6 come versione standard. Il che ti può creare problemi se hai una applicazione che utilizza versioni più elevate (cosa molto comune se hai sviluppato qualcosa con Zend Framework).

Al chè ho pensato potesse essere utile scrivere due righe di guida per capire come aggiornare il sistema CentOs a versioni più recenti della 5.1.6.

Per installare una versione più “alta” di PHP potete utilizzare l’RPM Repository gestito e mantenuto da Remi.

Innanzitutto scaricatevi e installate gli rpm di riferimento in questo modo:

Ora i repos sono installati sul vostro sistema ma non sono abilitati. Non c’è bisogno di farlo, potete gestirli direttamente da linea di comando. Ora aggiorniamo la nostra release di PHP.

se non avete ancora installato PHP al posto della parolina “update” scrivete “install”.
Ok il gioco è fatto, controllate la nuova versione in questo modo:

Ok. Fatto! Enjoy

Bookmark It

Ora wordpress è all’ultima versione rilasciata e per come è stato studiata la gestione dei moduli e del template sarà possibile tenerlo più o meno sempre aggiornato; Inoltre le parti di “codice” e “comandi” all’interno dei miei post si vedono meglio. Le foto hanno la funzionalità lightbox e spero di aggiungere presto nuovi moduli wordpressiani e (di conseguenza) nuove funzionalità.

Per non dimenticare il viso “passato” del mio amico, ad imperitura memoria, qui ci metto un “santino” del “com’era”…

Il vecchio blog buonanima...

Bookmark It