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, 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.

Procedura di rooting per Toshiba Folio 100

Aggiornamenti:

  • 2011-05-12: Ho aggiornato la guida con le istruzioni necessarie al rooting permanente. Inoltre, ho messo a disposizione un archivio compresso contenente tutto il necessario.

Dopo aver effettuato l’aggiornamento all’ultima versione del software Toshiba vi sarà capitato di notare che il buon vecchio SuperOneClick non é più una soluzione valida per ottenere i privilegi di root.

Sul forum di xda-developers é prontamente comparso un thread che guida l’utente al ripristino di un’immagine precedente all’aggiornamento upstream al fine di aggirare il problema. Ma io, da buon malfidato, ho preferito lasciar andare e cercare una soluzione per conto mio.

Beh, eccola qui, semplice e efficace.

Si comincia installando l’Android SDK e configurando correttamente ADB per il corretto riconoscimento del Toshiba Folio 100 (una buona procedura testata su Ubuntu si trova qui). Poi si passa a scaricare e scompattare questo file.

Dopo aver smontato ogni SD dal Folio, collegato il device e abilitato la modalità di debug, bisogna spostarsi nella cartella contenente l’SDK, copiare psneuter o rageagainstthecage e tutte le utility necessarie dell’archivio compresso nella memoria interna, dunque entrare nella ADB shell. In breve:

cd ~/android-sdk-linux_86/platform-tools
./adb push rageagainstthecage /data/local/tmp
./adb push busybox /data/local/tmp/
./adb push su /data/local/tmp/
./adb push Superuser.apk /data/local/tmp/
./adb shell

Ora siamo nel device, lasciamo compiere all’exploit il suo dovere:

$ cd /data/local/tmp
$ chmod 4755 rageagainstthecage
$ ./rageagainstthecage

Riavviamo adb, montiamo il filesystem in modalità di scrittura e entriamo nuovamente nella shell:

./adb kill-server
./adb start-server
./adb remount
./adb shell

Infine, non resta che installare a manina tutti i tool che ci permetteranno di ottenere nuovamente i privilegi di root dopo il riavvio del device (la presenza del carattere cancelletto ‘#’ indica i nuovi privilegi ottenuti):

# cd /data/local/tmp
# ./busybox cp busybox /system/bin
# chmod 4755 /system/bin/busybox
# busybox cp Superuser.apk /system/app
# busybox cp su /system/bin
# chmod 4755 /system/bin/su

Se tutto é andato a buon fine, root é abilitato e funzionante.
Altrimenti, ripetere la procedura con psneuter.

Riferimenti

Gestire i caratteri con Font Manager

Già disponibile in Debian sid da qualche giorno, é entrato da poche ore in Maverick e fornisce delle funzionalità davvero interessanti per quanto riguarda la gestione dei font.

Sto parlando di Font Manager, sviluppato in C e Python da Jerry Casiano, vera e propria chicca per chi vuole installare, rimuovere e confrontare i caratteri installati sul proprio sistema.

Seguono un paio di schermate:

Per installarlo basta un

sudo apt-get install font-manager

Fatemi sapere cosa ne pensate 😉

Link

Lucid e la ventola dell’AspireOne

Questa piccola procedura é stata testata su un AcerAspire One AO150 e si riferisce alla nuova Ubuntu 10.04.

La gestione della ventola é sempre stata problematica per i primi modelli dei netbook AspireOne dell’Acer, in modo particolare ne sono affetti i modelli AO110x e AO150x, in parole povere la ventola, una volta partita, viene spenta solo nel caso in cui la temperatura scenda sotto i 30° (cioè: mai), e tale comportamento causa una sensibile riduzione della durata e della vita della batteria, nonché la costante presenza di un fastidioso rumore.

Con il modulo acerhdf, integrato nel kernel fin da Karmic, é possibile impostare una policy di gestione per ridurne la velocità quando possibile.

Come prima cosa, prendiamo i privilegi di amministrazione:

sudo -s

Ora aggiungiamo acerhdf fra i moduli caricati all’avvio:

echo 'acerhdf' >> /etc/modules

Attenti al doppio ‘>‘, non é un errore, serve per aggiungere la stringa acerhdf in fondo al file senza modificare il contenuto già presente.

Al prossimo riavvio il modulo verrà caricato automaticamente con le impostazioni di default, per personalizzare la configurazione é necessario creare un nuovo file /etc/modprobe.d/acerhdf.conf che conterrà le opzioni che verranno passate al modulo durante il suo caricamento.

Digitate:

echo 'options interval=5 fanon=60000 fanoff=55000 verbose=1' >> /etc/modprobe.d/acerhdf.conf

Il comando può essere personalizzato:

  • interval: intervallo di tempo (in secondi) dei check della temperatura da parte del kernel
  • fanoff: temperatura in gradi centigradi * 1000, al di sotto della quale la ventola viene spenta
  • fanon: stessa unità di misura della precedente opzione, una volta raggiunta tale temperatura la ventola, se spenta, viene nuovamente attivata.
  • verbose: stampa messaggi di log nel kernel ring buffer

Per testare il modulo basta far ripartire il sistema con:

reboot

Badate bene che questo trucco deve essere usato in modo coscienzioso e impostare una temperatura di ri-accensione troppo elevata può causare seri danni all’hardware: insomma, la ventola sarà anche rumorosa ma se ce l’hanno messa un motivo c’è 😉

In risposta a ……..

(Siate gentili, aiutatemi a sostituire adeguatamente i puntini del titolo, a questo indirizzo trovate tutte le informazioni sul mio coraggioso interlocutore): Dario, credo che tu abbia esperienza in fatto di utenti anonimi, nevvè?

Caro GM,

sei davvero simpatico, mentre te mi chiami per cognome io non ho neanche la più pallida idea di chi tu sia, ma si sa, questa è una delle comodità offerte dall’anonimato.

Ma facciamo un po’ di chiarezza: nel campo Depends presente nel file debian/contol di un pacchetto sorgente sono elencati tutti i pacchetti necessari all’esecuzione del relativo pacchetto binario (a n pacchetti binari nel source package corrispondono dunque n campi Depends) (+ macro come ${shlibs:Depends}, ${misc:Depends}, etc che vengono lette e convertire in nomi di pacchetti a tempo di building); vale un discorso simile anche per i campi Suggests e Recommends, con la differenza che i pacchetti elencati nei campi Suggests non vengono installati di default.

Quando si installa un pacchetto $p con apt-get (o aptitude) vengono installati e configurati $p + $pacchetti_dai_quali_dipende_p.

Successivamente, se si disinstalla lo stesso pacchetto $p con l’opzione autoremove, vengono disinstallati $p + $pacchetti_dai_quali_dipende_p + $pacchetti_precedentemente_installati_come_dipendenze_ora_non_più_necessari$pacchetti_marcati_per_l_installazione_manuale.

Se si disinstallasse $p senza l’opzione autoremove, i $pacchetti_dai_quali_dipende_p rimarrebbero installati e marcati come $pacchetti_precedentemente_installati_come_dipendenze_ora_non_più_necessari.

Il concetto di pacchetti orfani in sé é una supercazzora (also known as bosif) e ora ti do la dimostrazione (su Jaunty) della validità delle mie affermazioni:

sudo apt-get install meld

meld si tira dietro diverse dipendenze (queste sono quelle che compaiono a me):

I seguenti pacchetti NUOVI (NEW) saranno installati:
libgda3-3 libgda3-bin libgda3-common libgdl-1-0 libgdl-1-common meld
python-gnome2-extras
0 aggiornati, 7 installati, 0 da rimuovere e 8 non aggiornati.
È necessario prendere 0B/1867kB di archivi.
Dopo quest'operazione, verranno occupati 11,7MB di spazio su disco.

Una volta installato, prova a dare:

sudo apt-get autoremove meld

Il risultato é il seguente:
Lettura della lista dei pacchetti in corso... Fatto
Generazione dell'albero delle dipendenze in corso
Lettura informazioni sullo stato... Fatto
I seguenti pacchetti erano stati automaticamente installati e non sono più richiesti:
python-gnome2-extras libgdl-1-common libgda3-common libgda3-bin libgda3-3
libgdl-1-0
I seguenti pacchetti saranno RIMOSSI:
libgda3-3 libgda3-bin libgda3-common libgdl-1-0 libgdl-1-common meld
python-gnome2-extras
0 aggiornati, 0 installati, 7 da rimuovere e 8 non aggiornati.
Dopo quest'operazione, verranno liberati 11,7MB di spazio su disco.

Come puoi vedere, le dipendenze sono correttamente calcolate. Ma cosa succede se dai un comando come il seguente?

sudo apt-get install meld && sudo apt-get install libgda3-bin

Lettura della lista dei pacchetti in corso... Fatto
Generazione dell'albero delle dipendenze in corso
Lettura informazioni sullo stato... Fatto
I seguenti pacchetti verranno inoltre installati:
libgda3-3 libgda3-bin libgda3-common libgdl-1-0 libgdl-1-common
python-gnome2-extras
Pacchetti suggeriti:
libgda3-mysql libgda3-postgres libgda3-odbc libgda3-sqlite
python-gnome2-extras-doc python-gnome2-extras-dbg
I seguenti pacchetti NUOVI (NEW) saranno installati:
libgda3-3 libgda3-bin libgda3-common libgdl-1-0 libgdl-1-common meld
python-gnome2-extras
0 aggiornati, 7 installati, 0 da rimuovere e 8 non aggiornati.
È necessario prendere 0B/1867kB di archivi.
Dopo quest'operazione, verranno occupati 11,7MB di spazio su disco.
Continuare [S/n]?
Selezionato il pacchetto libgda3-common, che non lo era.
(Lettura del database ... 204085 file e directory attualmente installati.)
Spacchetto libgda3-common (da .../libgda3-common_3.0.2-5ubuntu1_all.deb) ...
Selezionato il pacchetto libgda3-3, che non lo era.
Spacchetto libgda3-3 (da .../libgda3-3_3.0.2-5ubuntu1_amd64.deb) ...
Selezionato il pacchetto libgda3-bin, che non lo era.
Spacchetto libgda3-bin (da .../libgda3-bin_3.0.2-5ubuntu1_amd64.deb) ...
Selezionato il pacchetto libgdl-1-common, che non lo era.
Spacchetto libgdl-1-common (da .../libgdl-1-common_2.26.0-0ubuntu1_all.deb) ...
Selezionato il pacchetto libgdl-1-0, che non lo era.
Spacchetto libgdl-1-0 (da .../libgdl-1-0_2.26.0-0ubuntu1_amd64.deb) ...
Selezionato il pacchetto meld, che non lo era.
Spacchetto meld (da .../meld_1.2-0ubuntu1_all.deb) ...
Selezionato il pacchetto python-gnome2-extras, che non lo era.
Spacchetto python-gnome2-extras (da .../python-gnome2-extras_2.19.1-0ubuntu14_amd64.deb) ...
Processing triggers for man-db ...
Processing triggers for menu ...
Configuro libgda3-common (3.0.2-5ubuntu1) ...
Configuro libgda3-3 (3.0.2-5ubuntu1) ...
Configuro libgda3-bin (3.0.2-5ubuntu1) ...
Configuro libgdl-1-common (2.26.0-0ubuntu1) ...
Configuro libgdl-1-0 (2.26.0-0ubuntu1) ...
Configuro meld (1.2-0ubuntu1) ...
Configuro python-gnome2-extras (2.19.1-0ubuntu14) ...
Processing triggers for libc6 ...
ldconfig deferred processing now taking place
Processing triggers for menu ...
Processing triggers for python-support ...
Lettura della lista dei pacchetti in corso... Fatto
Generazione dell'albero delle dipendenze in corso
Lettura informazioni sullo stato... Fatto
libgda3-bin è già alla versione più recente.
libgda3-bin impostato per installazione manuale.
0 aggiornati, 0 installati, 0 da rimuovere e 8 non aggiornati.

La penultima riga è quella di nostro interesse: apt-get, dopo aver installato meld + dipendenze, ti dice che il pacchetto libgda3-bin é già installato ed é stato impostato come manuale.

Ora, proviamo a digitare di nuovo sudo apt-get autoremove meld:

Lettura della lista dei pacchetti in corso... Fatto
Generazione dell'albero delle dipendenze in corso
Lettura informazioni sullo stato... Fatto
I seguenti pacchetti erano stati automaticamente installati e non sono più richiesti:
python-gnome2-extras libgdl-1-common libgdl-1-0
I seguenti pacchetti saranno RIMOSSI:
libgdl-1-0 libgdl-1-common meld python-gnome2-extras
0 aggiornati, 0 installati, 4 da rimuovere e 8 non aggiornati.
Dopo quest'operazione, verranno liberati 5579kB di spazio su disco.
Continuare [S/n]?

È facile notare come libgda3-bin (e le relative dipendenze) non vengano più citati, perchè precedentemente marcati come installati manualmente.

Ora, come vedi, invece che rispondere alle tue battute scontate con altre che, sono sicuro, riscuoterebbero molto più successo (già, perchè devi sapere che, oltre che autorefenzialista sviluppatore pluridecorato, sono anche simpatico, intelligente e, beh, mettici anche sessualmente molto attivo), preferisco venirti incontro, illuminando quei lati a te oscuri del sistema che probabilmente usi.

Per concludere: l’unica cosa di cui davvero vado fiero, è quello di far parte di una Comunità meravigliosa formata da persone vere, corrette e competenti e che non hanno bisogno di celarsi dietro misteriosi acronimi.

Si chiama Comunità Italiana di Ubuntu: puoi passarci a trovare quando vuoi, la nostra porta è sempre aperta.

In risposta a Guido “Guiodic” Iodice

Questo articolo è la mia risposta al commento lasciato da Guido Guiodic Iodice sul suo blog:

Guido,

ogni volta che capita di trovarsi in una situazione del genere provo dispiacere.

L’effettiva utilità delle guide alle quali hai contribuito in passato è almeno pari a quella di tante altre presenti sul wiki italiano. Aiutare le persone in difficoltà, scrivere buone guide, tradurre stringhe dei programmi o della documentazione, {creare,mantenere} pacchetti, risolvere bug, sono modi diversi di contribuire allo sviluppo del sistema e della Comunità, Ubuntu significa proprio questo, nessun ruolo ha più dignità degli altri e da ciò deriva che nessuno ha il diritto di ricevere un trattamento speciale.

Non ho mai goduto nell’assistere ad atti di martirio (in tutta sincerità, sul forum non mi è mai capitato nulla di simile) né aspiro a diventare un martire, e in generale odio le scenate drammatiche ispirate a quel senso del tragico che fu elemento caratterizzante della tradizione magnogreca. Anche io ho scritto e revisionato numerose guide, entrai nella Comunità italiana come semplice contributor della Documentazione, dopo essere diventato Editore del wiki, quindi Amministratore (ruolo che ancora oggi ricopro) e infine traduttore decisi di dedicarmi allo sviluppo: ciononostante, puoi stare certo che se avessi infranto le regole del gioco, avrei pagato anche io, proprio come chiunque altro.

Per motivi spesso molto diversi, in alcuni casi per scelta e in altri per necessità, ho visto tante altre persone, prima di te, prendere altre strade, me ne sono sempre dispiaciuto ma la vita è questa, la Comunità Italiana di Ubuntu, come quella internazionale, sopravvivono alle perdite: voglio ripeterlo, sono dispiaciuto ma non vedo neanche un solo motivo per farne una tragedia. Perciò, ti auguro tutta la fortuna di cui potrai avere bisogno.

See you 😉

Di ritorno in ritorno

Ri-eccomi al lavoro su tutti i fronti ed ecco il mio rapporto, stilato secondo il modello Milo:

  • Tanta puzza (tipica di Barcellona)
  • Tanto il mal di stomaco
  • Tante le risate
  • Due le buste rimorchiate da Ciccio (per l’occasione ribattezzato el puerco Olimpico)
  • Pochi i giorni di vacanza
  • Troppi gli esami

Tornando seri, prima di partire avevo annunciato delle novità e ora vi presento la prima: ho rilasciato la nuova versione dell’autenticatore per la rete della mia università, la quale risolve il bug segnalato da Luca. Il nuovo pacchetto, reperibile dal mio Personal Package Archive (altra novità), è disponibile solo per Ubuntu 8.10 «Intrepid Ibex», per maggiori informazioni consultate la pagina dedicata.

L’ultima novità riguarda… mmmno… preferisco mostrarvela:

Ebbene sì, ho cominciato a contribuire allo sviluppo del sistema e nella pagina su Launchpad potete trovare tutti i miei lavori.