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

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

In ogni modo l’obiettivo di questo piccolo post/piccolissimo how-to è quello di dare le indicazioni corrette per implementare una autenticazione HTTP via ldap su delle vostre pagine web.

Il contesto è semplice: avete una pubblicazione web (un sito, delle info, una attività di un vostro sviluppo che vi occorre online ma che non deve essere accessibile da tutti e indicizzabile da google neanche per sbaglio). E oltre a questo, avete anche un server OpenLdap che potete sfruttare per le autenticazioni.

Vediamo come si fa

Una autenticazione classica HTTP richiede solitamente la creazione di un file di password (che generalmente viene creato attraverso l’utilizzo del binario htpasswd di Apache). All’interno di esso, Apache, si preoccupa di creare una associazione uno ad uno tra il nome utente scelto e la cifratura della password scelta. Sarà lo stesso Apache ad interpretare poi quel file per consentire o meno l’autenticazione, quando se lo troverà nella configurazione del suo virtualhost o nell’.htaccess del proprio contenuto web.

Demandare l’autenticazione ad Ldap sicuramente è una soluzione molto più pratica (l’utente ha già una coppia di credenziali e usa sempre quella per loggarsi a qualsiasi cosa) ma si fa i conti con una piccola differenza logica rispetto allo scenario descritto sopra. Nel file di accesso creato con htpasswd, c’è una associazione uno ad uno scritta più o meno così:

miousername:hashdellamiapassword

In questo modo, con “una sola fava” si vanno a prendere “due piccioni”, perchè ad Apache dai due tipi di informazioni: quali sono gli username abilitati ad accedere all’area riservata e quale è la loro password.

Mentre se demandi su ldap l’autenticazione HTTP, hai il problema di dire ad Apache quali sono gli utenti che ne debbono giovare.

Ok andiamo al dunque. Per implementare una HTTP Basic Authentication via Ldap in Apache, è sufficiente aggiungere il seguente blocco di configurazione all’interno di una direttiva del proprio virtualhost, oppure (più semplicemente) all’interno del proprio file .htaccess.

Commentiamo stringa per stringa.

AuthName: Label per la vostra area riservata. Qui potete scrivere veramente quello che vi pare!
AuthType: il tipo di autenticazione scelta. La nostra è Basic.
AuthBasicProvider: rappresenta il provider dal quale vogliamo ottenere una autenticazione “basic”. Nel nostro caso è, appunto, ldap.
AuthzLDAPAuthoritative: è un sistema di fallback. Se è settato su “off” il sistema prova in cascata altri sistemi di autenticazione se fallisce quello su ldap. Nel nostro caso, non essendoci altri sistemi di autenticazione, lo abbiamo settato su “on”.
AuthLDAPURL: è la stringa di connessione. Non basta passargli solo l’indirizzo del server, ma è necessario dargli anche (dopo lo /) la path dell’alberatura ldap dalla quale volete che Apache permetta l’autenticazione. Nel nostro caso siamo stati molto generici: tutte le utenze sotto la radice vengono prese in considerazione. Dopo il punto interrogativo è necessario aggiungere quale è l’attributo ldap per il quale fare la ricerca. Nel nostro caso è “uid”, cioè lo userid dell’utente.
AuthLDAPBinDN: non è un parametro obbligatorio. Dipende da come è stato configurato il vostro ldap. Se il vostro Ldap non è accessibile in sola lettura da utente “anonymous” è necessario specificare quale è l’utente che ha accesso al server ldap. Se vi trovate in quest’ultimo caso è necessario specificare anche la password (AuthLDAPBindPassword).

In ultimo diciamo al nostro apache che è obbligatorio un utente valido (require valid-user) per permettere l’accesso.

Questa configurazione è il primo livello di complessità: manca un file che gestisce la profilazione sugli accessi (in questo modo, infatti, tutti gli utenti di ldap possono loggarsi con successo), manca un sistema di fallback, eccetera. Però spesso è la cosa più utile che ci serve

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

Prima di procedere rispondiamo innanzitutto ad alcune domande come ad esempio “Cos’è CentOs, in cosa si differenzia dall’enterprise Red Hat e soprattutto perchè dovremo trovarci di fronte ad una tale necessità.

Cos’è CentOs

Come leggo pari pari dal sito alla pagina Purpose, CentOs esiste per mettere a disposizione una piattaforma enterprise free a chiunque voglia usarla. Le sue release sono compilate a partire dai sorgenti SRPMS opensource pubblici di un prominent North American Enterprise Linux vendor (come lo chiamano loro), che in altre parole è RedHat.

In cosa si differenzia da Red Hat

CentOs è completamente conforme e compatibile con il prodotto Red Hat e tendenzialmente modifica il sorgente originale solo con lo scopo di rimuovere e/o modificare le customizzazioni grafiche e gli artworks di RedHat. Essa è disegnata per tutti coloro che vogliono una distribuzione enterprise senza dover sostenere i costi di una licenza RedHat. Nè il CentOs Project nè qualsiasi versione di CentOs sono in qualche modo collegate con Red Hat.

Perchè trasformare una RHEL (Red Hat Enterprise Linux) in una CentOs

Mah…per vari motivi. Chiaro che si potrebbe obiettare: se voglio una CentOs me la installo direttamente, non compro una licenza Red Hat e poi cambio distro! E tuttavia a volte le vie dell’amministratore di sistema possono essere tendenti all’infinito. Personalmente l’ho fatto sia per test personale, sia per utilità lavorativa. Ma diciamo che, da accaniti compratori di Red Hat, ci potremmo trovare nella situazione di non voler più pagare licenza e supporto e non voler cmq reinstallare il server o condannarci ad una distro obsoleta in poco tempo. Ecco mi sembra che questo sia un ottimo motivo. Ma andiamo presto al dunque.

Trasformare una RHEL5 in una CentOs5: how-to

Importante premessa: comprendendo le istruzioni e con un pizzichino di intelligenza e malizia, questo breve how-to può trasformare qualsiasi versione di Rhel in una CentOs. Il test è stato fatto a partire da una Red Hat Enterprise Linux 5, verso una CentOs 5.1. E possiamo seguire due metodi:

Metodo 1 – switch parziale

Create il file /etc/yum.repos.d/CentOs.repo e inseriteci quello che vedete qui sotto:

quindi abilitate i repo con un yum –enablerepo, girate un fantastico yum upgrade e preparatevi ad avere un sistema misto.

Metodo 2 – switch totale

E’ il metodo che onestamente vi consiglio. Recatevi in /etc/yum.repos.d e spostate altrove il contenuto della directory.
Quindi importiamoci il file gpg di CentOs in questo modo

Ora con un paio di colpetti di wget, tiriamo giù i pacchetti: centos-release-5-1.0 e centos-release-notes-5.1.0-2 dai seguenti indirizzi:

http://isoredirect.centos.org/centos/5.1/os/i386/CentOS/centos-release-5-1.0.el5.centos.1.i386.rpm
http://isoredirect.centos.org/centos/5.1/os/i386/CentOS/centos-release-notes-5.1.0-2.i386.rpm

Se non vi tornano gli address (perchè magari i pacchetti sono stati aggiornati), fatevi una capatina sul sito isoredirect.centos.org e sicuramente troverete il bandolo della matassa.

Adesso è necessario installarli. Innanzitutto io darei una controllatina che sulla vostra macchina non creino problemi di sorta, in questo modo:

quindi, se in output non trovate nulla di preoccupante, procedete all’installazione, senza assolutamente dimenticare di farlo in modo da rimuovere i rispettivi pacchetti RedHat. In poche parole lanciate questo comando:

L’installazione dei due pacchetti creerà nella directory /etc/yum.repos.d/ i due files .repo che vi occorrono: CentOS-Base.repo e CentOS-Media.repo.

A questo punto il gioco è fatto. Lanciate un bel yum upgrade, riavviate (probabilmente) e buona fortuna con il vostro nuovo server CentOs.

Bookmark It