Sono passati quasi 2 anni dal mio primo tentativo di corsa all’aperto (5 km @ 8:00/km, cinque pause a giudicare dal tracciato del cardio) e, contrariamente a ogni mia previsione, continuo a correre e soprattutto continua a piacermi farlo.

Visto il tipo di lavoro che faccio (sedentario) devo fare attività fisica, e la corsa rappresenta la soluzione ideale in termini di tempi (1-2 ore al massimo) e forma (esci all’aperto, staccati dalla tecnologia, libera la testa).

Dal mio ultimo post sull’argomento sono anche riuscito a togliermi qualche soddisfazione.

Mi sono reso conto di aver raggiunto un punto di stasi a inizio 2016, in cui faticavo a raggiungere 10 km di corsa, per cui ho iniziato a seguire un piano di allenamento su Strava per la mezza maratona per darmi uno stimolo. L’obiettivo è di correre la distanza sotto le 2 ore, poi magari penserò anche a iscrivermi a qualche gara (se riesco a decifrare il delirio tutto italiano su certificati agonistici, iscrizione ad associazioni sportive, ecc.).  Il record attuale in allenamento è 2:02:06.

Ho anche avuto la fortuna di correre in giro per il mondo durante le trasferte di lavoro:

• Portland: mi sono limitato a correre sul lungo fiume, freddo becco in dicembre. Voto: 6,5
• Bucarest: ero abbastanza terrorizzato dalle letture sui cani randagi, non ne ho praticamente visti. Voto: 6 (guidano come pazzi, marciapiedi non sempre percorribili)
• Vilnius: città molto bella, verde, una marea di piste ciclabili, bellissimo percorso lungo il fiume per correre immersi nella natura. Voto: 7
• Whistler: ho il rimpianto di non aver esplorato più sentieri e percorsi. Ambiente assolutamente favoloso. Voto: 7,5
• Corvara (Trentino, vacanze): bella lei, peccato che o da una parte o dall’altra la salita assassina te la becchi. Voto: 7
• Istanbul: pessima la parte Sultanahmet, dopo aver schivato pedoni e traffico in centro ti ritrovi sul lungo mare, su una strada dove passano auto a 90 km/h, con cani randagi e il marciapiede che finisce improvvisamente. Decisamente meglio Kadıköy, peccato per i branchi di cani (uno ha cercato di assaggiarmi una chiappa). Voto: 5 Sultanahmet, 7 Kadıköy.
• Orlando: monotona. Non riesci a fare un percorso oltre i 5 km senza girare come una trottola. Nota a margine: per la prima volta ho visto l’America che vediamo in televisione, con orde di trasportini elettrici e persone enormi. Voto: 6
• Singapore: ho “corso” 5 km solo per giustificare il fatto di essermi portato scarpe e abbigliamento. A oggi sono convinto che conti più come nuoto che corsa. Voto: 5
• Dublino: bellissima, magari un filo meno vento, e meno clima da pinguini la prossima volta? Voto: 6,5

Ho anche fatto le mie prime ripetute. Meglio non aggiungere commenti su questo strumento del demonio 🙂

Durante l’ultima workweek Mozilla a Orlando ho assistito a una breve presentazione di Let’s Encrypt da parte di Eric Rescorla (:ekr). Mi ero ripromesso di fare qualche prova al ritorno e, complice il passaggio da dedicato+debian+apache a vps+ubuntu+nginx, mi sono finalmente deciso a farlo.

Che cos’è “Let’s Encrypt”: un’autorità di certificazione indipendente e aperta che permette al proprietario di un sito web di ottenere gratuitamente dei certificati. Per ulteriori dettagli consiglio la lettura del post inaugurale del blog.

Veniamo al dunque: come ottenere un certificato per il dominio che ospita questo blog e configurare nginx per utilizzarlo.

Per prima cosa bisogna clonare il repository (non esiste ancora un pacchetto per Ubuntu):

git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt

Come spiegato nella documentazione: letsencrypt-auto è un wrapper che si occupa di installare le dipendenze e creare un ambiente virtuale per Python, e il plugin per nginx è ancora altamente sperimentale (al contrario di Apache).

Nel mio caso voglio:

• ottenere solamente il certificato senza modificare alcuna configurazione;
• utilizzare il webserver “standalone” per recuperare il certificato. Siccome il plugin occupa la porta 80 o la 443, potrebbe essere necessario bloccare temporaneamente il server nginx.

Questo è il contenuto del file di configurazione per evitare una linea di comando infinita (modificare l’indirizzo email)

# Use a 4096 bit RSA key instead of 2048
rsa-key-size = 4096
email = YOUREMAIL@EXAMPLE.COM

# Standalone authenticator on port 443
authenticator = standalone
standalone-supported-challenges = tls-sni-01

E questo il comando da lanciare (modificare il dominio e il percorso al file di configurazione)

./letsencrypt-auto certonly --config /root/cli.ini -d EXAMPLE.COM

La prima volta verrà chiesto di accettare le condizioni di servizio. Dopo pochi istanti il certificato verrà salvato in una sottocartella di /etc/letsencrypt/live/.

A questo punto bisogna aggiornare la configurazione del dominio in nginx. Personalmente ho utilizzato il generatore messo a disposizione da Mozilla, modificando

    ssl_dhparam /etc/nginx/dhparam.pem;
    ssl_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem;

E rimuovendo la linea ssl_session_tickets off; (non compatibile con la mia versione di nginx).

Per utilizzare questa configurazione, la prima volta bisogna generare una chiave Diffie-Hellman:

cd /etc/nginx
openssl dhparam -out dhparam.pem 2048

Se riuscite a leggere questo post, significa che non è esploso nulla.

Normalmente utilizzo Debian stable e Apache su tutte le mie VM. In questi giorni sto facendo qualche prova in locale con Ubuntu Server LTS (14.04) e NGINX, giusto per capire come funzionano le cose.

La prova è semplice: prendi una VM con risorse limitate (1 core, 2GB di RAM), installaci sopra WordPress (per la precisione un backup di questo blog), e prova a vedere come gira.

$ siege -c 100 -r 10 -b http://localvm/blog

Transactions:               2000 hits
Availability:             100.00 %
Elapsed time:               3.24 secs
Data transferred:          14.23 MB
Response time:              0.16 secs
Transaction rate:         617.28 trans/sec
Throughput:             4.39 MB/sec
Concurrency:               96.03
Successful transactions:        2000
Failed transactions:               0
Longest transaction:            0.69
Shortest transaction:           0.00

Poi mi è venuto in mente di provare a disattivare WP Super Cache.

$ siege -c 100 -r 10 -b http://localvm/blog

Transactions:               2000 hits
Availability:             100.00 %
Elapsed time:             138.59 secs
Data transferred:          14.15 MB
Response time:              6.61 secs
Transaction rate:          14.43 trans/sec
Throughput:             0.10 MB/sec
Concurrency:               95.39
Successful transactions:        2000
Failed transactions:               0
Longest transaction:           14.90
Shortest transaction:           0.00

Mentre nel primo caso il load era intorno a 0.2, nel secondo ha raggiunto piuttosto rapidamente 5. Morale della favola: utilizzate un plugin per la cache, c’è l’imbarazzo della scelta.

Sono da sempre un fan dei GPS+cardio Garmin: da anni possiedo un Edge 500 per la mountain bike e un Forerunner 210w per corsa ed escursioni. Quando in primavera ho visto l’annuncio del Forerunner 225, ho capito che era arrivata l’ora di un upgrade: finalmente niente più fascia per il cardiofrequenzimetro!

Da quando ho iniziato a correre la fascia è sempre stata un punto dolente, specialmente durante i mesi estivi: durante l’inverno l’intimo funzionale contribuisce a tenerla ferma, in estate “saltella” insieme a te. Il risultato sono dolorose abrasioni sul torace, specialmente nella zona centrale in cui si concentra il peso del sensore. In parte avevo risolto il problema passando dalla fascia originale Garmin Premium a una della Polar (il collegamento del sensore è uguale, per cui è sufficiente trasferire il sensore), ma il fastidio rimaneva. Anche quando viaggi è sempre un oggetto in più da portarsi appresso, a meno di rinunciare ai dati del cardio.

Tornando al Forerunner 225: ormai lo sto utilizzando da quattro mesi e ne sono veramente soddisfatto. La velocità con cui allinea i satelliti è favolosa rispetto al precedente, niente più “pinza” per scaricare i dati o caricarlo (credo sia l’interfaccia più assurda mai creata), contapassi incluso. Ottenere buoni risultati dal sensore ottico è stato un po’ più complicato, per cui ecco qualche suggerimento banale ma pratico se riscontri letture ballerine:

• Stringi il cinturino. Si tratta di un sensore ottico: se passa luce tra la guarnizione alla base e il tuo polso la lettura sarà meno affidabile.
• Se il tuo braccio sembra la zampa dell’orso Yoghi, oppure hai il polso pesantemente tatuato, potresti riscontrare qualche problema di lettura.
• Non allacciarlo esattamente al polso, posizionalo leggermente più in alto dove l’osso non intralcia.
• Se continui ad avere letture strane, prova a indossarlo al contrario (sul lato interno del polso).

Nel mio caso ho optato per tenerlo interno sul braccio destro: i pulsanti sono orientati verso il gomito, meno rischi di premerli muovendo la mano, e lo sento meno strano rispetto al braccio sinistro.

Ecco un esempio di scarsa e buona lettura (in blu il passo, in rosso la frequenza cardiaca).

P.S. Nel caso abbiate qualche dubbio, non è un post sponsorizzato. Non solo il dispositivo è stato pagato, ma è stato acquistato a prezzo pieno visto che non volevo aspettare i primi sconti.

Oggi un’installazione di WordPress ospitata su Aruba ha iniziato a dare errori in area di amministrazione: impossibile accedere alla pagina degli aggiornamenti e alla gestione dei plugin, errori salvando nuove bozze.

Provato nell’ordine a:

• Rinominare la cartella wp-content/plugins, nel dubbio disattivati anche i plugin via database.
• Ripristinare i permessi in Aruba da Pannello di controllo hosting Linux → Strumenti e impostazioni → Riparazione Permissions [sigh].
• Sostituire tutti i file del core di WordPress con quelli di un pacchetto pulito.

Il log di errori, accessibile via Pannello di controllo hosting Linux → Strumenti e impostazioni → Mostra log degli errori, riporta “End of script output before headers” per ogni pagina di errore visualizzata.

A questo punto ho aperto un ticket di assistenza con scarse speranze di soluzione.

Nel frattempo l’illuminazione è arrivata via Twitter da San Beggi: controlla la versione di PHP.

L’ho trovata impostata a 5.2.x, e visto che il tutto ha sempre funzionato dubito sia mai stata impostata a quel valore, considerato anche questo post di “solo” 4 anni fa.

Morale della favola: controllate la versione di PHP, anche a prescindere da eventuali errori.

È arrivato il tempo di cambiare uno dei notebook di casa, ormai lento oltre ogni limite di umana sopportazione (ha ancora Windows Vista). Girando un po’ in rete ho trovato un HP abbastanza interessante: HP 250 G3, monitor 15.6″, Intel Core i5-4210U, 4 GB di RAM, hard-disk 500 GB, DVD±RW, 1xUSB 3.0, Free DOS. Insieme al notebook ho ordinato un SSD da 240 GB, visto che è il componente che influisce maggiormente sulla velocità finale.

Il computer è “onesto”, l’area della tastiera sembra un po’ troppo flessibile ma in generale ha un buon rapporto qualità/prezzo. Tutto bene, finché non scopri cosa tocca fare per sostituire l’hard-disk (non esiste un cassetto estraibile con l’hard-disk o uno scomparto per la RAM):

• Togliere tutte le viti del fondo. Tocca anche scollare i due piedini posteriori, visto che due viti sono nascoste lì sotto.
• Sfilare il masterizzatore DVD.
• Sganciare la tastiera e scollegarla. Non lo si capisce bene da alcuni video, ma la piattina non è “incastrata” nel connettore (non bisogna tirarla), bisogna ruotare di 90° il connettore grigio verso l’alto sbloccando la piattina.
• Sganciare i connettori (piattine) di touchpad e pulsante di alimentazione.
• Togliere altre 4 viti e sganciare il coperchio superiore.

Personalmente credo di non aver mai visto un notebook progettato in modo più assurdo. Come detto il computer è onesto per il prezzo, ma decisamente sconsigliato se vi spaventate di fronte a questo tipo di operazione, soprattutto su una macchina nuova.