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.

Farewell Ubuntu-it!

Era il gennaio 2007 quando, per la prima volta, lasciai un messaggio sul forum della Comunità Italiana di Ubuntu. Da lì l’evoluzione è stata rapida: cominciai a contribuire alla stesura delle guide della documentazione della comunità (il “wiki“), prima come autore, poi come editor e infine come amministratore. Parallelamente iniziai anche a partecipare ai lavori del Gruppo traduzione e infine approdai allo sviluppo vero e proprio, curando inizialmente i merge e sync dei pacchetti da Debian, per poi estendere successivamente il mio raggio d’azione anche alla risoluzione dei bug.

Sette anni fa dunque ebbi il mio primo contatto con la Comunità e i riscontri furono molto positivi, trovai un folto gruppo persone disposte a impiegare molto tempo delle proprie giornate a spargere il verbo di una distribuzione GNU/Linux libera, fondata sui valori universali di solidarietà e condivisione della conoscenza, in modo del tutto volontario. Tra me e il Codice di Condotta di Ubuntu è stato amore a prima vista e, come gli altri, fui felicissimo di abbracciare il progetto Ubuntu e impegnarmi per la sua crescita.

Ci sono stati tempi duri, l’evoluzione del rapporto fra la base comunitaria e l’azienda sponsor principale di Ubuntu ha indebolito molte delle promesse fatte alle origini, nonchè incrinato le certezze e ispirato dubbi a un buon numero di noi. Mentre qualcuno, profondamento deluso dalla scelta di Canonical di declassare i principi etici sui quali la Comunità di Ubuntu ha costruito il vero successo di quest’ultimo, se ne andava altri iniziavano a ridurre i propri contributi e a credere meno nel progetto, altri ancora hanno semplicemente trovato cose migliori da fare. Ecco, io faccio parte di quest’ultimo gruppo. Benchè sia l’unico amministratore ancora attivo della mailing list di supporto, sono passati anni ormai dall’ultima volta in cui ho revisionato una guida sul wiki o dato un consiglio a qualche nuovo utente in difficoltà sul forum o nel canale IRC, ciò mi fa sentire una specie di burocrate del nulla ed è assolutamente in contrasto con la mia idea di cosa una comunità di supporto deve fare: aiutare gli utenti.

Oggi dunque prendo finalmente coscienza e lascio la Comunità Italiana per evidente mancanza di interesse e tempo da dedicarvi.

In questi sei anni molte cose sono cambiate nella mia vita e una fetta della felicità raggiunta la devo a ciò che ho imparato da quelle persone che ho avuto modo di conoscere e frequentare proprio grazie a Ubuntu-it. Milo, Paolo, Leo, Fabio “thesaltydog”, Flavia, Luca (entrambi, “elle” e DktrKranz), Maurizio (Bugman! Dove sei finito?), Sergio, Volans: a loro va il mio pensiero e la memoria corre verso tutti quei momenti nei quali abbiamo condiviso un pezzetto di infinito.

Farewell everyone, it’s been great riding with you.

Ubuntu, il M5S e le occasioni mancate (di evitare brutte figure)

Non é facile per me scrivere questo articolo, ho poco tempo e un micro cosmo di cose da gestire, ma non posso lasciar correre. Ennò, non stavolta.

Premesso che cercherò di essere breve, ficcante e di non esagerare con le parolacce, quella che segue é la mia risposta ai bizzarri paragoni utilizzati dall’autore del sopra linkato articolo per giungere a conclusioni corrette ma talmente ovvie da coprire l’intero pezzo di ridicolo.

Proporrei di saltare a piè pari le analogie fra leader politici e capitani di ventura di industria così culturalmente, economicamente e geograficamente lontani (ehy Santiago, quante notti insonni sono state necessarie per partorire accostamenti deliranti come MacOSPDL, WindowsPD?) e andare al punto:

Ubuntu non è una democrazia

Non lo è mai stato, non lo sarà mai e nessuno, Shuttleworth incluso, ha mai sbandierato una governance democratica dove tutti potessero contare qualcosa. Da quel “tutti” i meri utenti sono sempre stati esclusi. Perfino in Debian, dove l’utente rappresenta la priorità massima, regna il principio di do-ocracy, e qui lo trovate scritto nero su sfondo bianco sperando che adesso tu, Santiago, non cominci a rompere il cazzo anche a proposito della governance di Debian solo perché é di fatto diversa da come hai sempre creduto che fosse.

Debian e Ubuntu si collocano su due universi tangenti e nei processi decisionali di entrambi, fatte salve rare eccezioni, le opinioni degli utenti contano poco. Fatevene una ragione.

Ubuntu non combatte alcuna Kasta del Kazzo

Rendere GNU/Linux usabile per utenti desktop e rubare spazio a Microsoft nel mercato desktop consumer non é la stessa cosa di sconfiggere la fame nel mondo, ma solo business. Vincere facendo buon marketing non riporta in vita Madre Teresa né rappresenta la soluzione al riscaldamento globale. Canonical non ha mai proposto rivoluzioni nè portato avanti battaglie per sani e giusti principi, ha sempre solo legittimamente cercato di farsi spazio nel mondo e se qualcuno, in passato, ha pensato di poter associare Canonical al Bene e credeva che Microsoft, Apple, Sun, Oracle, IBM e compagnia bella fossero evidenti manifestazioni del Maligno ora non deve rimanere deluso. Piuttosto cercasse un buon medico.

“Ubuntu e il M5S sono due prodotti aziendali”, “Apertura non è sinonimo di Comunità”, (e se nonno avesse avuto tre palle sarebbe stato un divertentissimo flipper)

Con questo diventa chiaro che in quanto a perspicacia sei a posto, ti tocca solo lavorare sulla prontezza di riflessi e poi sei a cavallo.

What about me?

Anni fa sostenevo che la Community aveva un peso, ora purtroppo conta come il due di quadri quando comanda denari, perciò non sono io ad aver cambiato opinione (benchè me ne riservi il diritto di farlo ogni tanto) ma le storia ad aver preso una piega totalmente diversa da quella che ci si aspettava.

Concludo con una non-conclusione: evito di rispondere con l’unico tono appropriato che conosco alla frase “considerando chi è che ha scritto tale critica ulteriori argomentazioni sarebbero sprecate”. Sempre considerando chi scrive, sarebbe come sparare sulla Croce Rossa.

Un, due, tre: puff! La community non c’è più

Non ho molto tempo e, a dir il vero, anche le motivazioni cominciano a mancare, ciononostante ho grande voglia di esprimere ciò che ho in testa e ho deciso di farlo con una breve, brevissima serie di commenti.

Ma vi avviso: trattandosi di fulminei giudizi lapidari, nati da pensierosi attimi di puro rancore misto a un sentimento di profonda e amarissima delusione, non vi aspettate alcun diritto di replica nè razionali e logici approfondimenti sul tema.

  1. Raring sarà la prima release ad essere stata sviluppata col paracadute. Questo perchè Canonical si fida poco di noi, cioè di chi non è pagato da Canonical e il messaggio appare chiaro: la community non è affidabile. Colpiti.
  2. Non si terrà più alcun Ubuntu Developer Summit. Poco male, in realtà gli ultimi due ai quali ho partecipato fisicamente (UDS-P Orlando, UDS-Q Oakland) erano già sembrati alquanto superflui: più che meeting di una comunità riunita per decidere, sembrava di stare a una première. Altro messaggio, non meno importante del precedente: la community pensasse a scrivere le app, al resto ci pensa Canonical. Affondati.

Naturale conclusione è la seguente: la community di Ubuntu, per come l’abbiamo conosciuta e apprezzata per tanti anni, è morta e sepolta. È ora di farsene una ragione.

UbuntuStudio abbandona GNOME e abbraccia XFCE

Il titolo é abbastanza self-explanatory, qui l’annuncio:

After various discussions, investigation and tinkering the Ubuntu
Studio team have decided to re-base the project on XFCE. The team
simple feel that Unity and GNOME-Shell do not fit our target audience
or intended workflow.

Shell non mi fa impazzire, Unity letteralmente cagare e, beh, se dai futuri setup verranno escluse tutte le possibili soluzioni che prevedono un minimo di supporto al vecchio stile grafico, aspettiamoci molti altri annunci simili.

Ubuntu, Unity e la coerenza

Io credo che non ci si possa lamentare della mancanza di vere e proprie scelte “comunitarie”, sono diversi anni che MOTU e Core-dev non affiliati a Canonical le forniscono forza lavoro a costo zero, rispondendo ai requisiti, orientando lo sviluppo verso precise direzioni e caricandosi sulle spalle le conseguenze di scelte se non imposte, quasi mai ampiamente discusse e condivise: questo é Ubuntu, bellezza! Conosciamo certi meccanismi da troppo tempo ormai per stupirci di fronte alle relazioni spesso difficili tra il main sponsor di Ubuntu e GNOME, per esempio, o al rapporto mai idilliaco con mamma Debian (a proposito, Debian ha lanciato il progetto DEX, per maggiori informazioni leggere qui).

Insomma, le regole del gioco sono chiare (perlomeno lo stanno diventando sempre più), la Comunità, gli sviluppatori volontari, Canonical e i suoi dipendenti hanno ruoli sempre più distanti gli uni dagli altri: da qualunque parte tu stia, o stai al gioco o lasci.

Io sono consapevole di questo e non mi lamento, mi limito a riflettere e a muovere le giuste critiche solo quando le situazioni appaiono così contradditorie da lasciare un alone di imbarazzo, come in questo caso (qui il bug su Launchpad e la risposta di BDFL).

Per quanto mi riguarda, mi chiedo seriamente se valga ancora la pena continuare su questa strada.