Cambridge in tre mesi

Il bagno più british è a EdimburgoTre mesi dopo, comincio ad ingranare col lavoro a Cambridge. Devo dire che ero piuttosto nervoso mentre accettavo la proposta: nonostante la chiacchierata con Alastair e Andy (aka, il colloquio) fosse stata più che piacevole, stavamo comunque parlando di una tra le prime cinque università al mondo per insegnamento e ricerca, senza considerare il fatto che da lì passa la futura élite del Regno Unito, il che può rendere l’aria tossica. Io, esattamente, cosa ci stavo a fare, a Cambridge? [1] Alla fine della fiera, io sono quello che la maestra di italiano lo chiamava dottore perché portava gli occhiali e le magliette col colletto. Quello che, dopo la laurea triennale, era contento di essere riuscito ad iscriversi alla specialistica nonostante la media. Quello che, prima di andare in Erasmus, al dottorato manco ci pensava – era roba da geni, mica da uno che “ottiene risultati se seguito e stimolato”. Ero anche un po’ preoccupato di entrare in un progetto che di musica aveva molto poco – praticamente niente – ma, mi sono detto, sicuramente qualcosa di figo si trova da fare, sulla musica posso sempre tenere un occhio, e poi Cambridge fa sicuro un figurone sul curriculum.

Edimburgo

Tre mesi dopo, qualcosa di figo da fare l’ho trovato [2], l’ambiente al Computer Lab è abbastanza rilassato, sto imparando un monte di cose nuove, e mi sto divertendo. Soprattutto, scrivo questo post mentre torno da Edimburgo dove sono stato a Learning@Scale, il che è molto bello perché, dopo essermi concentrato su tecnologie educative per singoli e piccoli gruppi, quindi molta ricerca etnografica e qualitativa, adesso sto lavorando su una piattaforma con più di 20000 studenti, con ampie opportunità di ricerca sia quantitativa che, se me la gioco bene, qualitativa, e di interazione uomo-macchina, che resta il mio interesse principale.

Mi resta anche l’interesse per le arti digitali, e la musica, per cui nei prossimi tempi mi dovrò concentrare sul condensare e pubblicare la tesi su qualche rivista scientifica, perché non mi aspetto che nessuno si legga veramente le mie 250 pagine più allegati. Avevo anche in mente un sacco di altre belle cose, più o meno correlate, che appariranno sul MorphLog quando sarà il momento.

Per ora, va bene così.

  1. Per la cronaca, i miei nonni sono appena passati a mollarmi quattro spettrali sberloni.
  2. Materiale per un altro post, promesso.

Il metallo (virtuale)

Spero non vi siate accorti di niente, e questo sarebbe un grande risultato. Da qualche giorno ho infatti fatto quello che pensavo di fare da un po’: prendermi un serverino tutto mio [1] e migrarci dentro i miei vari siti. Ci sono svariati ottimi motivi, tra cui il fatto che il mio vecchio hosting provider forniva una versione disperatamente antica di PHP [2] e mi dicono che le versioni nuove siano sufficientemente meglio in termini di prestazioni, API, e senso in generale, quindi volevo provare. Inoltre è un po’ che volevo usare cose che non sono in PHP, tipo roba in Ruby e via così. Quindi, complice il fatto che sto cominciando a gestire server di un certo livello per lavoro, ho fatto il grande balzo, ho scelto un provider affidabile e sufficientemente amico del portafogli, e ho cominciato al mia nuova avventura in Serverland.

Sicurezza: ridurre la superficie di attacco

Fino a poco tempo fa avrei scelto una distribuzione di Linux adeguata, avrei installato e configurato tutti i vari servizi al suo interno, e avrei passato notti insonni a chiedermi se avevo fatto tutto il necessario per mettere la macchina (virtuale) in sicurezza. Questo approccio ha una falla fondamentale: tutti i servizi pascolano felici nella macchina alla pari, vengono eseguiti con più o meno privilegi, e ciò significa che qualsiasi falla in qualsiasi dei servizi permetta ad un attaccante di scalare i privilegi fino a diventare root, porterebbe l’attaccante ad essere root nella macchina, con tutte le conseguenze del caso. Per fortuna, persone molto più intelligenti di me hanno già pensato ad una soluzione.

I container sono un meccanismo a livello kernel che permette di eseguire un qualsiasi processo in modo controllato ed isolato dal sistema operativo, così che solo lo stretto indispensabile gli sia accessibile [3]. In questo modo, un attaccante che riuscisse a bucare il servizio avrebbe accesso solo al piccolo mondo a disposizione di quel servizio, e se riuscisse a scalare i privilegi e diventare root, non sarebbe root nella macchina ma solo nel container, senza molte speranze di uscirne. Il problema è che configurare container è piuttosto complicato e macchinoso, ogni servizio o applicazione richiede configurazioni particolari e non sempre immediate. Sarebbe molto bello se esistesse un metodo per standardizzare il modo in cui il SO vede, tratta, e parla con questi container.

Docker

Docker è uno di questi metodi: adottando piuttosto letteralmente il concetto di container – quelli che si usano per trasportare merci, per intenderci – Docker fornisce un modo per creare, configurare, ed eseguire applicazioni in container offrendo al SO un’interfaccia uniforme e prevedibile, e all’applicazione che vive nel container tutto quello che le serve per fare il suo lavoro. In questo modo non ci si deve più preoccupare di come configurare container e SO perché si parlino senza rogne, ma ci basta descrivere di cosa il container ha bisogno – porte, file system, rete… – e Docker si farà carico di configurare tutto come si deve. Ulteriore vantaggio: possiamo avere lo stesso servizio – diciamo Apache – configurato in modi selvaggiamente diversi – diciamo con diverse versioni di PHP, a loro volta con diversi moduli caricati – per diverse applicazioni senza doverci preoccupare di eventuali conflitti ed effetti collaterali. Non ridete perché è proprio quello che mi è toccato fare.

Servizi

La prima necessità è stata di trasportare i miei vari siti nel modo più indolore possibile. In più, ho pensato che sarebbe stato carino replicare più fedelmente possibile una configurazione tipo shared hosting [4] in modo che se qualcuno di voi volesse dividere i costi del server si troverebbe un ambiente familiare (wink wink, nudge nudge). Quindi l’idea era preparare, per ogni dominio, un container HTTPD con vari Virtual Host e con supporto a PHP, un container *SQL con gli appositi utenti e database al bisogno, e un container SFTP generale con utenti nelle cui home vengono rese disponibili le varie directory htdocs dei rispettivi container HTTPD. Le scelte sono ricadute su

  • Apache HTTPD 2.4 con PHP 7
  • MariaDB 10.1
  • ProFTPD 1.3.5

che mi sono sembrate scelte sensate. A ProFTPD ci sono arrivato dopo un lungo, doloroso percorso in cui ho cercato inutilmente di piegare OpenSSH al mio volere. Ha vinto OpenSSH. In ogni caso sono contentissimo di ProFTPD.

Tanti piccoli container

Il sito più facile da trasportare è stato andreafranceschini.org, anche perché non abbisogna di database. Questo sito, tuttavia, ha una particolarità: ce l’ho sotto controllo di versione con git, e lo aggiornavo automaticamente usando git-ftp. Ora che ho un server tutto mio vorrei poter evitare tali abomini e fare il deployment interamente con git, ma per questo mi serve un container per git che ancora non ho.

Poi è venuta la volta di sbonk.it, che è stato relativamente facile da trasportare. Il sito gira su WordPress, e quindi l’immagine [5] basata su Apache e PHP 7 ha funzionato bene.

Quello che mi ha fatto penare è stato morpheu5.net. O meglio, Drupal 6 che tiene su il www. Tutti gli altri sottodomini, servizi, e altre cose hanno funzionato a meraviglia al primo tentativo – incluso il MorphLog, che gira su WordPress – ma Drupal 6 non supporta PHP oltre la versione 5. Ufficialmente non supporta niente oltre la 5.2, e considerando che la più recente versione della serie 5 è la 5.6, questo poteva essere una noia. Per fortuna PHP 5.6 non ha portato troppi stravolgimenti rispetto alla 5.2, quindi presto fatta un’immagine con Apache e PHP 5.6, et voilà – www è servito.

Non mi dilungherò sulle questioni di rete, ma sappiate che Docker crea una rete virtuale in modo che i container possano comunicare tra loro, e l’host (la macchina che ospita i container) con i container stessi. Il risultato è che ciascuno di quei container che ho descritto sopra ha un suo indirizzo IP, proprio come se fosse una vera macchina virtuale, e l’applicazione all’interno può mettersi in ascolto su tutte le porte che vuole. Fino a qui, però, i container non hanno alcun modo di entrare in contatto col mondo fuori dall’host [6]. Un’opzione è “pubblicare” le porte dei container attraverso le porte sull’host. Purtroppo, per come funzionano le cose, questo significherebbe che, una volta che uno dei container, per esempio uno degli HTTPD, si è impossessato di una porta sull’host, per esempio la 80, che è quella tipicamente usata per HTTPD, nessun altro container può mettersi in ascolto sulla stessa porta dell’host. Bisognerebbe quindi pubblicare un secondo container HTTPD sulla porta, diciamo, 81, ma a quel punto buona fortuna a spiegare ai visitatori che l’URL è http://www.morpheu5.net:81/ – perché 81 non è standard, e quindi i browser non la assumono implicitamente se manca. Un’altra soluzione è usare un reverse proxy, che è un modo carino per dire un servizio che si incarica di intercettare tutte le connessioni su una certa porta dell’host e re-indirizzarle al container appropriato. La mia scelta è ricaduta su NGINX, che è estremamente leggero, rapido, e indicato per fare il proxy. In questo modo, NGINX intercetta le connessioni sui tre domini e le gira ai tre container HTTPD appropriati, che si smazzano i sottodomini internamente via Virtual Host. Un ulteriore vantaggio di ciò è che i container HTTPD non hanno alcun canale diretto con il mondo esterno, ma tutte le comunicazioni passano esclusivamente attraverso NGINX, aggiungendo quindi un ulteriore strato di protezione, dato che NGINX gira a sua volta in un microscopico container dedicato al solo scopo di fare da reverse proxy.

Guardando oltre

Ci sono svariate cose che vorrei sperimentare, ora che ho un sistema flessibile per le mani. La prima cosa, come ho detto più su, è mettere in piedi un piccolo repository git privato perché quello attuale basato su Dropbox comincia a starmi stretto, e di pagare github non mi va. Sì, anche io a volte scrivo software non open source, e un po’ me ne vergogno, ma alla fine della giornata bisogna pure pagare le bollette.

Poi vorrei sperimentare un sistema per condividere preset per Circular Bells – no, non cCircular Bellsi sono ancora nella versione pubblicata – e le risorse che avevo col vecchio hosting provider erano un po’ limitate.

Se poi qualcuno volesse – seriamente – contribuire un po’ ai costi, sarei ben felice di tenergli su uno o più siti – sempre che non abbiate richieste di uptime del 99.99999%, che di questi tempi se riesco ad arrivare a 99% è già oro che cola. Ah, e non ho al momento in programma di fornire e-mail. Se vi va, possiamo parlarne – le cifre sono modiche e l’offerta non è necessariamente limitata al classico sito in shared hosting.

Insomma, per il momento è tutto molto bello. Devo mettermi di buona lena e implementare una politica di backup sensata, perché al momento sto facendo a mano, e ciò non è bello. Per tutto il resto, parliamone.

  1. Un VPS, che qua non siamo mica a crescere i soldi sugli alberi.
  2. Non che io sia un grande fan di PHP, ma WordPress, Drupal, e svariate altre cose lo usano.
  3. La questione è un po’ più complessa di così, lo so, e so anche che i container non sono un’invenzione di Linux.
  4. HTTPD, PHP, *SQL, (S)FTP, per intenderci…
  5. Non vi ho spiegato cos’è un’immagine: diciamo, semplificando, che un’immagine è l’idea platonica di cui i relativi container sono istanze nel mondo reale. In pratica, un’immagine è un prefabbricato – le pareti del container – a cui vanno aggiunti arredamento e decorazioni – i dati della specifica copia dell’applicazione che vogliamo mettere in un particolare container.
  6. L’host è la macchina che ospita i vari container, in questo caso è la macchina virtuale che ho acquistato.

Novitadi lavorative

Computer Laboratory, University of Cambridge

La novità del giorno è che sono stato assunto come Research Associate al Computer Laboratory dell’Università di Cambridge – che, per chi mi conosce, è una cosa abbastanza incredibile. Però oggi sono andato, mi hanno aperto la porta, e mi hanno dato perfino un badge!

Foto 18-01-16 20 38 31

La faccenda ha delle sfumature che non vale la pena raccontare, e il contratto è fino a settembre 2018, però non penso che starò qui a sindacare. Meglio rimboccarsi le maniche e fare del mio meglio.

Purtroppo non è un progetto legato alla musica, ma comunque gravita nell’ambito delle tecnologie educative, e si spera ci sarà una discreta componente di ricerca in HCI e user studies, il che sarebbe il mio campo.

Pendolarizzare da Londra è una tragedia, in termini di tempo e costi, quindi penso che a breve andrò ad aggiustarmi la macchina e me la riporterò su. Preferisco due ore di guida al giorno, coi miei tempi e tutto, piuttosto che tre ore sui mezzi pubblici inglesi. A conti fatti è pure più economico, considerando che ho appena speso 400 sterline (scontato!) per un abbonamento mensile al treno, senza contare il bus a Cambridge e la metro a Londra.

Per concludere la giornata, due settimane fa ho scritto un breve paper basato sulla tesi, e oggi mi è arrivata la notifica che è stato accettato a Sempre: Music, Education, Technology (MET2016).

A. Franceschini, R. Laney, C. Dobbyn, Sketching music: making music by exploring art.

Tutto sommato questo 2016 inizia bene.

Quest'anno ho fatto meglio

Puntuale come le tasse, anche quest’anno è arrivato WordPress a ricordarmi che non aggiorno il MorphLog da un po’. A parziale consolazione c’è che quest’anno ho fatto meglio dell’anno scorso:

Quest’anno però ho un po’ di scuse.

Tesi

Per chi fosse rimasto indietro, questo è stato l’anno in cui ho sistematicamente pianificato scadenze per terminare il dottorato, e le ho altrettanto sistematicamente sforate. Ci vogliono competenze anche per questo, eh. D’altro canto, l’unica scadenza che non potevo assolutamente sforare era quella del 30 settembre per la consegna della tesi, perché dopo avrei dovuto pagare tasse all’università, e considerando che i miei fondi finivano a giugno – per i più attenti, ho ottenuto un’estensione di tre mesi – sarebbe stato un problema. Alla fine, però, il nostro eroe c’è riuscito. Sono seguiti, nell’ordine: una settimana di totale svacco; svariate settimane di panico in cerca di lavoro; la realizzazione che, se voglio combinare qualcosa, devo rimboccarmi le maniche e fare. La ricerca del lavoro è una pagina che merita un post a parte, e con questo ho pronto almeno un post per il 2016.

Evviva!

Esame

Il 10 dicembre, la mia tesi è stata esaminata. In UK, la “viva” (da “viva voce”) funziona così: c’è una stanza, tipicamente angusta per problemi di fondi, e ci sono due esaminatori, un esterno e un interno, più un moderatore. Poi ci sei tu. Vi sedete tutti nella stanza, attorno ad un tavolo, e la fucilazione ha inizio. Può durare dalle due alle quattro ore, qualche volta di più. Il tuo lavoro è rispondere al meglio ai colpi, e il lavoro del moderatore è intervenire se i colpi iniziano ad essere sotto la cintura. A volte, nella stanza è ammesso anche il supervisore principale, ma non può aprire bocca.

Alle 9:30 del 10 dicembre, sono entrato in una grande e luminosa stanza dell’edificio in cui c’è l’ufficio del Vice-Chancellor (letteralmente, il CEO dell’università), mi sono seduto, ho estratto la mia copia della tesi su cui avevo pronte tutte le note in caso (leggi: certezza) il mio cervello fosse entrato in sciopero, e ho estratto anche l’iPad in caso (leggi: sarebbe carino ma non credo ci sarà tempo) gli esaminatori avessero voluto vedere una demo di questo.

L’esaminatrice interna, che avevo scelto personalmente per la sua fama di essere severa ma giusta, ha cominciato con il descrivere l’usanza svedese di inchiodare le tesi, difese con successo, al portone dell’università. Dopo questi simpatici convenevoli, l’esaminatore esterno mi ha chiesto da dove venivo, cioè quale fosse il percorso che mi ha portato a fare il lavoro che ho fatto. Da quel momento è andata tutta in discesa, talmente velocemente che due ore e mezza dopo io stavo cominciando a chiedermi quando sarebbero finiti i complimenti e quando sarebbe arrivato il primo colpo e invece l’esame è finito.

Sono uscito dalla stanza.

Sono rientrato nella stanza, dove mi hanno rovesciato addosso ulteriori complimenti, e mi hanno chiesto di aggiungere giusto un paio di pagine alla tesi, “to increase its archival value”. Ho ringraziato molto, specialmente la moderatrice che ha passato due ore e mezza a scrivere appunti su un foglio, e sono uscito dalla stanza.

Sto lavorando alle aggiunte, ma devo aspettare la comunicazione ufficiale dell’università prima di riconsegnare. Quando avrò consegnato, dovrò aspettare la comunicazione ufficiale prima di poter usare il titolo, ma vabè, gli esaminatori mi hanno salutato come Doctor al mio rientro nella stanza, quindi posso aspettare.

Nel frattempo

Non me ne sono stato a grattarmi la panza. Tra una ricerca di lavoro e un’altra ho lavorato alle mie “demonstrable skills”, perché succede che, agli occhi del mondo non accademico, quello che si fa durante un dottorato è praticamente grattarsi la panza, produrre niente, e prendersi indietro di tre anni sul progresso tecnologico — sorvolando sul fatto che quello che uno tipicamente fa in dottorato è quello che l’industria vedrà non prima di 4-5 anni, ma questo loro non lo sanno. Quindi, ho fatto un’app per iPhone e iPad, liberamente ispirata al lavoro di Jeanne Bamberger

È gratis, con le pubblicità — ma se mi volete bene potete versare un piccolo obolo in-app e rimuovere le pubblicità per sempre. Ci sto lavorando, quindi se vi sembra che manchi qualcosa, probabilmente è così. Se avete suggerimenti, ci sono i commenti apposta. Se poi volete lasciare una recensione sull’App Store, è sempre ben gradita.

Non contento, ho ripreso in mano la mia vecchia app che non so cosa fa, e l’ho rifatta da capo, usando Swift, il nuovo linguaggio di Apple che è recentemente diventato open source. Già che c’ero, l’ho anche fatta per Apple TV. Al momento è in review, se tutto va bene dovrebbe essere pubblicata all’inizio del mese prossimo. Se conoscete dei cardiologi, passate il link :)

Il sito

Non mi è chiarissimo ancora come gestire Morpheu5.net, e il MorphLog, ma per il momento mi sono fatto un altro sito, più ordinato e in inglese, che mi servirà soprattutto per gli aspetti professionali. Morpheu5.net rimarrà attivo, ma non so ancora cosa ci farò. Per ora resta tutto com’è.

Insomma

Cose sono successe, cose succederanno. Vediamo se l’anno prossimo riuscirò a fare almeno tre post sul MorphLog. Voi, intanto, beccatevi gli auguri.