Gestire le identità nelle istanze cloud distribuite

Ho molte istanze in diversi cloud, anche approfittando di alcune offerte gratuite per sviluppatori: Amazon Web Services (AWS), Digital Ocean, HP Cloud, ma anche cloud regionali come Moresi.Com, Enter o le mie istanze virtuali sui miei sistemi in housing.

Insomma, un bel po’ di sistemi Linux distribuiti nel mondo, forse come molti informatici.  E su questo si incastra il problema di avere la mia identità e quella dei miei utenti/sviluppatori distribuita in questi sistemi. Mentre in una intranet avrei usato LDAP senza esitazioni, creare un LDAP esposto ad Internet potrebbe non essere una buona idea.

Allora come fare a risolvere questo problema e contemporaneamente avere un ottimo livello di sicurezza? La risposta potrebbe essere quella di usare il nuovo modulo NSS per SecurePass.

Fino ad adesso SecurePass è stato sempre usato come un “two factor authentication” nel cloud, soltanto sfruttando la parte di autenticazione nel sistema operativo. Ma la nuova versione beta è in grado di ospitare gli “extended attributes”, che sono informazioni arbitrarie che un amministratore o una applicazione puo’ usare per ogni utente di SecurePass.

Useremo SecurePass per autenticare l’utente e tenere le informazioni Unix atttraverso questa nuova funzionalità. In particolare, useremo:

  • il sottosistema PAM per autenticare gli utenti via RADIUS
  • il nuvo modulo NSS di SecurePass per ottenere informazioni di UID/GID/….

SecurePass e gli extended attributes

La prossima generazione del servizio SecurePass (attualmente in beta) è in grado di ospitare informazioni arbitrarie per ogni profilo utenti. Questa funzionalità è chiamata “Extended Attributes” (o xattrs) e -come potete immaginare- sono organizzate in modalità chiave/valore.

Dovete avere i SecurePass tools per modificare gli extended attributes di un utente. Le nuove release di Debian Jessie and Ubuntu Vivid Vervet, avranno un pacchetto per questo, quindi potrete fare:

# apt-get install securepass-tools

Per altre distribuzioni Linux (o Unix), potete usare il python package installer (PIP) per installare i tools. Installate come pre-requisito pycurl e poi:

# pip install securepass-tools

Anche se i SecurePass tools hanno la possibilità di avere un file di configurazione locale, per questo tutorial raccomandiamo di creare un file /etc/securepass.conf, in modo da essere usato anche dal modulo NSS. Il file di configurazione e’ simile a quanto sotto:

[default]
app_id = xxxxx
app_secret = xxxx

Dove app_id e app_secrets sono API keys valide per accedere a SecurePass beta.

Attraverso la riga di comando, saremo in grado di impostare UID, GID e tutti gli attributi Unix per ogni utente:

# sp-user-xattrs user@domain.net set posixuid 1000

Mentre  posixuid e’ l’attributo minimo per avere un login su Unix con il modulo NSS, i seguenti attributi sono validi:

  • posixuid → UID dell’utente
  • posixgid → GID dell’utente
  • posixhomedir → Home directory
  • posixshell → Shell preferita
  • posixgecos → Gecos (il default è lo username)

Installazione e configurazione del modulo NSS SecurePass

Similmente a quanto avviene per i tools, Debian Jessie e Ubuntu Vivid Vervet hanno un pacchetto nativo per SecurePass

# apt-get install libnss-securepass

Per le precedenti releases di Debian e Ubuntu, ma anche per CentOS e RHEL, è sempre possibile installare il modulo. I sorgenti sono disponibili su:

https://github.com/garlsecurity/nss_securepass

Poi:

./configure
make
make install (solo Debian/Ubuntu)

Per CentOS/RHEL/Fedora bisogna installare il modulo NSS nel posto giusto:

/usr/bin/install -c -o root -g root libnss_sp.so.2 /usr/lib64/libnss_sp.so.2
ln -sf libnss_sp.so.2 /usr/lib64/libnss_sp.so.2

Il file di configurazione /etc/securepass.conf va esteso per avere le informazioni di default per il modulo NSS. Bisogna creare una sezione [nss] come da basso:

[nss]
realm = mydomain.com
default_gid = 100
default_home = "/home"
default_shell = "/bin/bash"

Il realm va impostato come quello registrato su SecurePass, il modulo NSS farà append del dominio/realm corrispondente all’utente Unix. Io preferisco impostare il GID corrispondente al gruppo “users”, che di solito su Linux è il gruppo 100. Fate in modo che questo gruppo esista a livello di sistema operativo. Se non si impostano i default su home e shell, i default dei default sono “/home” e “/bin/false”

Dobbiamo ora configurare il Name Service Switch (NSS) per usare SecurePass. Cambiamo il file  /etc/nsswitch.conf aggiungendo “sp” alla riga passwd come segue:

$ grep sp /etc/nsswitch.conf
passwd:     files sp

Controllate che il sottosistema NSS stia funzionando con il modulo SecurePass facendo una query alla tabella passwd come segue:

$ getent passwd user
user:x:1000:100:My User:/home/user:/bin/bash
$ id user
uid=1000(user)  gid=100(users) groups=100(users)

A questo punto abbiamo configurato gli utenti a sistema operativo, ma gli stessi non potranno collegarsi perche’ manca una password corrispondente. Useremo SecurePass per autenticare gli utenti.

Configurare PAM per SecurePass

Se stai usando CentOS o RHEL, bisogna avere EPEL configurato. Per attivare EPEL, seguite le istruzioni su http://fedoraproject.org/wiki/EPEL

La configurazione seguente non è stata provata con SE-Linux abilitato (controllate che sia disabilitato o in modalita’ permissive).

Su CentOS/RHEL, installate il modulo PAM RADIUS con:

# yum -y install pam_radius

Su Debian/Ubuntu, installate il modulo PAM RADIUS con:

# apt-get install libpam-radius-auth

Nota: al momento della scrittura del presente articolo, EPEL 7 è ancora in beta e non contiene il modulo PAM RADIUS. E’ stata fatta una richiesta attraverso il Bugzilla di RedHat per includere questo pacchetto in EPEL 7

Accediamo all’interfaccia di amministrazione SecurePass e aggiungiamo un nuovo device RADIUS. Dobbiamo solo settare l’IP Pubblico del server, un fully qualified domanin name (FQDN) e la secret pass per l’autenticazione Radius. Se siete sotto NAT, questo corrisponde all’IP pubblico di uscita dei pacchetti. Dopo l’aggiunta avremo un piccolo riassunto con i dati del device appena aggiunto. Per questo esempio, useremo “secret”.

Configurate il modulo PAM RADIUS attraverso il file /etc/pam_radius.conf e aggiungete le seguenti righe:

radius1.secure-pass.net secret 3
radius2.secure-pass.net secret 3

Ovviamente “secret” è la stessa che abbiamo impostato attraverso l’interfaccia di amministrazione di SecurePass administration interface. A questo punto bisogna modificare il file di configurazione di PAM.

In CentOS, modificate il file /etc/pam.d/password-auth-ac; in Debian/Ubuntu modificate il file /etc/pam.d/common-auth ed assicuratevi che il modulo pam_radius_auth.so sia nella lista.

auth required pam_env.so
auth sufficient    pam_radius_auth.so try_first_pass
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so

Conclusioni

E’ difficile avere a che fare con tante istanze Linux distribuite; ci sono problemi che spaziano dal mantenere il software sempre aggiornato, al logging centralizato fino alla gestione delle utenze. Nel cloud, infatti, non è sempre possibile usare i software che tradizionalmente venivano usati nelle intranet. Alcuni tools, come SecurePass, possono aiutare nella gestione quotidiana.

Per poter accedere alla Beta di SecurePass, bisogna attivare SecurePass su: http://www.secure-pass.net/open

E successivamente mandare una mail a support@secure-pass.net richiedendo l’accesso alla beta.

Ubuntu-it meeting, 7 giorni dopo

Così, dopo diversi tentativi, questo sviluppatore autoreferenzialista pluridecorato (secondo alcuni anche un po’ stronzo) finalmente é riuscito a partecipare a un meeting della Comunità Italiana!

Devo ringraziare infinitamente Leo Iannacone per la splendida ospitalità, se non fosse stato per lui avrei saltato anche questo incontro 🙂

Ma basta parlare del passato, piuttosto pensiamo al futuro! Stiamo già lavorando all’organizzazione del prossimo meeting e abbiamo ristretto la scelta delle possibili location a quelle presenti in questa pagina (link funzionante).

Fatemi sapere qual è la vostra preferita!

Also sprach Zarathustra

Perché gli uomini non sono uguali: così parla la giustizia. E ciò che io voglio essi non possono volerlo!

Professare l’uguaglianza: che ipocrisia!

Accettare la diversità é il primo vero passo contro ogni discriminazione.

Non siamo tutti uguali e ognuno ha gli stessi diritti dell’altro, ma questo non significa che tutti possano prendere decisioni.

Ubuntu, il caos intorno al nuovo look

Il look della Ubuntu che sarà ha dato vita a una bagarre senza precedenti, in breve ecco le principali fazioni che, da qualche settimana ormai si fronteggiano su forum e blog, e le loro opinioni:

  • partito del +1: “Che figo! In quanto a bellezza grafica, Leopard a Lucid glie fa na ‘pippa!”
  • partito del -1: “Che schifo! Chi cazzo é stato a spostare i pulsanti lì a sinistra?”

Chiariamo subito: io appoggio la tesi del primo partito, al di là della posizione dei pulsanti, Lucid rappresenterà davvero un salto di qualità e con ciò non intendo sostenere che non sia migliorabile, dico solo che, per la prima volta, avremo fra le mani qualcosa che sarà insieme usabile e graficamente accattivante.

Insomma, ecco la dimostrazione (mai fornita prima) del teorema:

usabile != bello_da_vedere

Non dimentichiamo che tutte le possibilità di personalizzazione dell’ambiente grafico resteranno immutate (per chi non l’avesse capito prima, mi riferisco a GNOME), ognuno sarà ancora libero di scegliere quale sfondo utilizzare, modificare il tema, {aggiungere,eliminare,modificare,spostare} i pannelli e, ebbene sì, ri-posizionare i famosi controlli delle finestre nella posizione originale.

A proposito di tali maledetti controlli: si tratta di un tentativo di cambiare qualcosa che obbligherà gli utenti decisi a mantenere il tema di default a adattarsi a cercare i pulsanti non più a destra, ma a sinistra. Ok, il primo impatto potrebbe provocare disorientamento ma, insomma, stiamo parlando dei pulsanti di massimizzazione&minimizzazione&chiusura delle finestre e mi vien da chiedere agli accaniti sostenitori del partito avverso cosa farebbero se un giorno fossero costrettti a traslocare di casa.

Ora, a tutto quello di cui sopra, aggiungiamo il re-branding e qui sarò breve: a me piace e, soprattutto, non riesco a vederlo come un rischio per la struttura della nostra Comunità nè per i meccanismi che ne regolano l’esistenza. Insomma, ci sono team che badano a raggiungere gli scopi prefissati, c’è un Development Team, un Security Team, un Artwork Team, un Design Team e molti altri, se si vuole partecipare ai processi decisionali non si può farlo scrivendo attraverso il proprio blog o postando messaggi sui forum, per farlo é necessario entrare a far parte della parte attiva della Comunità, quella parte composta da persone che, nel pieno rispetto delle regole, intraprendono dei percorsi all’interno della stessa.

Da ciò deriva che bisogna accettare che attribuire al mero utente la definizione di parte passiva non significa svilire il suo ruolo, i feedback sono sempre richiesti ma, appunto, l’utente non può pretendere di decidere con la propria opinione, anche se largamente condivisa. Se davvero l’utente vuole partecipare al team di sviluppo, può chiedere aiuto a qualche sviluppatore, proporre delle patch, iniziare a fare il triaging dei bug, oppure se preferisce entrare a far parte del Documentation team, dovrebbe cominciare leggendo tutta la pagina del wiki e iscriversi alla mailing list, etc.

Per concludere, sono d’accordo con Mark, questa non é una democrazia, forse questo sistema non é ancora perfettamente meritocratico ma mi sento di assicurare che chi si impegna viene sempre premiato.

Italians do artwork better!

Ho poco tempo, perciò bando alle ciance, ecco l’annuncio e il regolamento:

Indicazioni base per partecipare alla prima edizione del concorso “Italians do artwork better”

  • Divertirsi nel realizzare lo sfondo.
  • Ogni partecipante può proporre quanti sfondi desidera.
  • Ogni sfondo con cui si partecipa al concorso deve essere inviato separatamente dagli eventuali altri.
  • La risoluzione richiesta è di 72 DPI. Trattandosi di sfondi, si consiglia di fornire immagini di dimensioni regolari (1024×768, 1280×1024, 1600×1200, etc).
  • Il nome di file dello sfondo inviato per il concorso deve contenere l’indicazione sulle dimensioni in pixel, per esempio titolo-1920×1080.png oppure sfondo-1280×1024.png e così via.
  • Il formato del file può essere a scelta JPEG, PNG o SVG
  • Sono inoltre ammessi gli “sfondi animati” supportati dallo GNOME Desktop (cfr http://anotherubuntu.blogspot.com/2009/11/dawn-of-ubuntu-returns.html); in tale caso dovrà essere fornito anche il file XML che regola i cambi di immagine.
  • Il soggetto dello sfondo è a scelta del partecipante: fotografie, pixmap, vettoriale, 3D, frattali…
  • Ogni sfondo con cui si partecipa al concorso può essere inviato in diverse dimensioni. In questo caso si deve inviare lo sfondo alle varie dimensioni sotto forma di archivio zip/tar.
  • Per inviare lo sfondo o gli sfondi con cui partecipare al concorso, inviare una email all’indirizzo <gruppo-documentazione@ubuntu-it.org> allegando il file e indicando nel corpo del messaggio i seguenti dati:
    • Nome del partecipante – la persona che partecipa al concorso e a cui accreditare la “vittoria”
    • Licenza – la licenza con cui lo sfondo è rilasciato (cfr dopo per licenze ammissibili)
    • Riconoscimenti – eventuali riconoscimenti a terzi che hanno collaborato alla realizzazione (per es. fornendo immagini e/o foto)
  • Gli sfondi dovranno pervenire entro il 31/03/2010.
  • La proclamazione dei vincitori avverrà il giorno precedente al rilascio della versione di Ubuntu 10.04 sui vari canali della comunità Ubuntu-it (Forum, Planet, …)
  • Gli sfondi vincitori verranno rilasciati al pubblico sotto forma di pacchetto DEB installabile.

Criteri di scelta ed eventuale esclusione

  • Le opere devono essere originali, ovvero prive di elementi (come immagini e campioni) di terze parti, di origine incerta o, in ogni caso, prive di informazioni riguardanti la licenza e gli autori originali; fanno eccezione i loghi ufficiali di Ubuntu e della Comunità Italiana
  • I vincitori del concorso verranno scelti in base a criteri oggettivi e soggettivi della commissione valutante (Magnifica Commissione Giudicante)
  • Tra i criteri oggettivi il fatto che l’opera non violi copyright, che sia aderente a quanto indicato poco sopra, che sia rilasciato con licenza adeguata…
  • Tra i criteri soggettivi il gusto estetico della commissione valutante, la maggiore o minore conformità allo stile grafico di Ubuntu (in particolare 10.04 e 9.10), essere uno sfondo “well behaving”
  • Per le qualità che dovrebbe possedere uno sfondo “well behaving”, cfr queste pagina web: http://designinginterfaces.com/Deep_Background e http://designinginterfaces.com/Few_Hues_Many_Values
  • Verranno automaticamente escluse le immagini che verranno pubblicate prima del termine del concorso stesso
  • Il giudizio della commissione è insindacabile e inappellabile
  • L’uso delle opere non vincitrici verrà “liberato” a conclusione del concorso stesso. La commissione valutante si riserva però la possibilità, qualora le opere proposte valide fossero numerose, di rilasciare successivi pacchetti con altre proposte valide non vincitrici in un secondo momento

Note legali

  • Ogni partecipante si assume la piena responsabilità del materiale inviato; la Comunità Italiana di Ubuntu e la commissione valutante declina ogni responsabilità su eventuali dichiarazioni fallaci o violazioni di copyright
  • Licenze ammesse per gli sfondi sono tutte quelle GPL compatibili (cfr http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses ) adeguate ad opere come sfondi (es. Artistic License 2.0, GPL, WTFPL 2.0…)
  • È consentito il “dual licensing”, a patto che sia tra quelle consentite indicate sopra
  • Indirizzi email e dati personali dei partecipanti non verranno usati per finalità diverse da quelle relative alla partecipazione al concorso

Un vestito per la Lince

Come avrete saputo attraverso i canali ufficiali della Comunità Italiana di Ubuntu, è stato annunciato il concorso Italians do artworks better.

In realtà il progetto é ben più ambizioso: c’è l’intenzione  di creare una personalizzazione grafica completa del desktop firmata Ubuntu-it, ma mancano 15 giorni al Feature Freeze, Lucid verrà rilasciata fra tre mesi e, insomma, di tempo a disposizione ne è rimasto davvero poco, perciò si é scelto di intraprendere la via più breve (verranno presi in esame solo sfondi per il desktop, quindi niente temi) ma che, comunque, per la prima volta, ci porterà a fornire agli utenti la possibilità di vestire una release di Ubuntu con un abito italiano (si sa, in quanto a gusto non ci batte nessuno¹)

Le regole del gioco le trovate qui, lunedì prossimo saranno resi noti maggiori dettagli riguardanti i formati e le modalità per candidare i propri lavori.

[1] A dirla tutta, mi è capitato di incontrare qualche caso eccezionale: ma, per fortuna nostra e della nostra reputazione, pare che, a causa di enormi difficoltà di adattamento ai rapidi cambiamenti climatici occorsi in questi anni, anche gli ultimi esemplari rimasti della razza della foto si siano estinti.

Noi, i buoni

Sì, é il 2010 e sono tornato dall’UDS e so di non aver raccontato nulla, in realtà non sono neanche sicuro di farlo attraverso le pagine di questo blog.

Anzi, un paio di foto ve le concedo:

Jane Silber, Mark Shuttleworth, Paolo Sammicheli e io

Io, Paolo, Simone e Milo

Sì, so anche di avere diversi discorsi in sospeso: li riprenderemo quando ne avrò voglia.

Ho poco tempo, molto da studiare e altro su cui lavorare, perciò sarò sintetico: hanno chiuso il Bar Sport e per questo voglio congratularmi con i ragazzi del Gruppo Forum (i buoni, appunto), i quali, secondo me, hanno preso la decisione giusta.