Quattro risate…

Una amica è solita inviarmi tramite email alcuni barzellette simpatiche. Ne riporto un paio ringraziandola, giusto per alleggerire le discussioni tecniche in vista del weekend.

Un’ insegnante spagnola stava spiegando alla classe che in spagnolo , contrariamente all’inglese, i nomi possono essere sia maschili che femminili. “casa, per esempio, è femminile: la casa”
“matita, invece, è maschile: el lapiz”
Uno studente chiese: “Di che genere è la parola computer?”
Anziché rispondere, l’insegnante divide la classe in due gruppi, maschi e femmine, e gli chiese di decidere tra loro se computer dovesse essere maschile o femminile. A ciascun gruppo chiese inoltre di motivare la scelta con 4 ragioni.
Il gruppo degli uomini decise che ” computer” dovesse essere decisamente femminile “la computadora” perchè:
1. Nessuno tranne il loro creatore capisce la loro logica interna.
2. Il linguaggio che usano per comunicare tra computer è incomprensibile.
3. Anche il più piccolo errore viene archiviato nella memoria a lungo termine per possibili recuperi futuri e…
4. Non appena decidi di comprarne uno, ti ritrovi a spendere metà del tuo salario in accessori.

Il gruppo delle donne, invece, concluse che i computer dovessero essere maschili (el computador) perchè:

  1. Per farci qualunque cosa, bisogna accenderli.
  2. Hanno un sacco di dati ma non riescono a pensare da soli.
  3. Si suppone che ti debbano aiutare a risolvere i problemi, ma per la metà delle volte, il problema sono LORO; e…
  4. Non appena ne compri uno, ti rendi conto che se avessi aspettato qualche tempo, avresti potuto avere un modello migliore.

Le donne vinsero.


Quando si vede uno Space Shuttle sulla rampa di lancio, si notano i due booster attaccati al serbatoio principale; questi due propulsori sono due razzi a combustibile solido o SRB. Gli SRB sono stati costruiti dalla Thiokol nei propri stabilimenti situati in Utah. Gli ingegneri che li hanno progettati avrebbero voluto farli un po’ piu’ grossi, ma gli SRB dovevano essere trasportati in treno dalla fabbrica alla rampa di lancio. Visto che la linea ferroviaria che collega lo Utah alla base di lancio attraversa nel suo percorso alcune gallerie, i razzi dovevano essere costruiti in modo da passarci dentro. I tunnel ferroviari sono poco piu’ larghi di una carrozza ferroviaria, la cui larghezza e’ a sua volta dettata dallo scartamento dei binari (distanza tra le due rotaie). Lo scartamento standard degli Stati Uniti e’ di 4 piedi e 8,5 pollici (è la stessa misura europea solo che noi la esprimiamo in millimetri).

A prima vista questa misura sembra alquanto strana. Perche’ e’ stata scelta?
Perche’ questa era la misura utilizzata in Inghilterra, e perche’ le ferrovie americane sono state costruite da progettisti inglesi.

Ma perche’ gli Inglesi le costruivano in questo modo?
Perche’ le prime ferrovie furono costruite dalle stesse persone che, prima dell’avvento delle strade ferrate, costruivano le linee tranviarie usando lo stesso scartamento.

Ma perche’ i costruttori inglesi usavano questo scartamento?
Perche’ quelli che costruivano le carrozze dei tram utilizzavano gli stessi componenti e gli stessi strumenti che venivano usati dai costruttori di carrozze stradali, e quindi gli assi avevano la stessa larghezza e lo stesso scartamento.

Bene! Ma allora perche’ le carrozze utilizzavano questa curiosa misura per la larghezza dell’asse?
Perche’, se avessero usato un’altra distanza, le ruote delle carrozze si sarebbero spezzate percorrendo alcune vecchie e consunte strade inglesi, in quanto questa era la misura dei solchi scavati dalle ruote sul fondo stradale.

Ma chi aveva provocato questi solchi sulle vecchie strade dell’Inghilterra?
Le prime strade di collegamento costruite in Europa (e Inghilterra) furono quelle costruite dall’Impero Romano per le proprie legioni. Prima di allora non vi erano strade che percorrevano lunghe distanze.

E i solchi sulle strade?
I carri da guerra romani produssero i primi solchi sulle strade, solchi a cui poi tutti gli altri veicoli dovettero adeguarsi per evitare di rompere le ruote. Essendo i carri da guerra costruiti tutti per conto dell’esercito dell’Impero Romano, essi avevano tutti la stessa distanza tra le ruote.

In conclusione, lo scartamento standard di 4 piedi e 8,5 pollici deriva dalle specifiche originarie dei carri da guerra dell’Impero Romano ed e’ la misura necessaria a contenere i sederi di due cavalli da guerra.

Morale
La prossima volta che ti capitano in mano delle specifiche tecniche e ti stupisci per il fatto che le misure sembrano stabilite con il culo, magari stai facendo proprio la giusta congettura.
La misura standard utilizzata nel piu’ avanzato mezzo di trasporto progettato in questo secolo (i booster dello Shuttle) e’ stata determinata oltre due millenni or sono prendendo a modello due culi di cavallo. [www.magnaromagna.it]

Report sicurezza browser dal Pwn2Own 2011

Pwn2Own è un meeting annuale a cui partecipano i migliori hacker del mondo. Le aziende “sfruttano” questo evento per provare la (non) sicurezza dei propri sistemi.

Vediamo cosa è emerso quest’anno da questo evento.

Apple Safari
Apple ha rilasciato una patch per correggere tutti i bug ed exploits conosciuti del proprio browser appena prima che venisse sottoposto al tentativo di hacking. Ebbene, il team VUPEN vincitore di questo contest è riuscito ad accedere ad Airport attraverso un precisa vulnerabilità del motore di rendering “WebKit” in soli 5 secondi. Avete letto bene, 5 secondi! Difatti l’hacker ha preso controllo del MacOS semplicemente andando a visitare una pagina Internet con codice maligno.

RIM Blackberry e Apple iPhone
Entrambi i browser di questi apparecchi utilizzano lo stesso motore di renderinf WebKit di Safari (RIM l’ha cambiato proprio di recente), quindi in entrambi i casi i sistemi sono stati compromessi semplicemente andando a visitare una pagina con codice maligno.

Internet Expolerer 8
E’ stata utilizzata la versione 8 a 32 bit del browser su un sistema Windows 7 a 64 bit. Il vincitore è stato Stephen Fewer del gruppo Harmony Security che è riuscito a superare la Sandbox e ad eseguire un programma attraverso il browser sfruttando tre diverse vulnerabilità del Browser. Microsoft, prima dell’evento, non ha nemmeno tentato di patchare il suo prodotto.

Google Chrome
Google ha rilasciato una patch di security appena prima del contest ed ha preteso di partecipare innalzando la posta in palio con un ulteriore premio di 20.000,00 $. Due le persone iscritte alla gara, ma entrambe si sono ritirate prima dell’evento per concentrarsi sul sistema RIM Blackberry; in realtà questo non vuol dire che Chrome sia esente da buchi, difatti lo stesso buco con cui è stato forzato Safari e Blackberry sarebbe stato presente anche in Chrome visto che anch’esso utilizza come motore di rendering WebKit; difatti l’azienda di Mountain View si è affrettata a rilasciare una ulteriore patch al termine del contest.
Assieme a Google Chrome, sono stati “graziati” anche Windows Mobile e Android.

Mozilla Firefox
Per la prima volta il browser più diffuso al mondo è riuscito a resistere agli attacchi ed arrivare alla fine del contest inviolato. In questo caso i tentativi ci sono stati e l’hacker Sam Thomas era quasi riuscito a trovare un exploit che però si è rilevato instabile.

Le 10 App di Android che preferisco

Il motivo più usato dagli amanti dell’IPhone per “denigrare” Android è la quantità di App presenti nello Store: iPhone ha una disponibilità ben superiore rispetto ad Android, però le App più conosciute sono diponibili per entrambe le piattaforme.

Ecco le mie 5 App preferite, quelle che più utilizzo e che immagino esistano anche per iPhone:

ConnectBot
Si tratta di un ottimo client SSH. Tra le funzionalità importanti, segnalo il salvataggio automatico delle sessioni in bookmark in modo da poterle riaprire con facilità, la possibilità di emulare il tasto CTRL con il pulsante del volume e la possibilità di aumentare e diminuire la dimensione dei caratteri. Se, come me, dovete essere certi di poter intervenire in qualsiasi momento sui vostri server, questa App non può mancare.

Opera Mini
Opera è diventato il mio browser di default su Android per un semplice motivo: Opera non scarica direttamente i contenuti da Internet, ma passsa per un proxy trasparente che è in grado di comprimere la pagina rendendola più veloce da visualizzare sul nostro smartphone

Pagine Gialle
Fantastica App per trovare sempre in qualsiasi momento un numero di telefono. Include anche l’elenco delle Pagine Bianche

Almanacco TV
Cosa c’è in TV questa sera? Include moltissimi canali del digitale terrestre, consigliatissima.

Wordpress
Un ottimo client per Wordpress per tenere aggiornato il proprio Blog con il telefonino. Può collegarsi sia a Blog su “wordpress.com” sia a blog ospitati sui propri server

ilmeteo.it
Si tratta di un Widget, cioè quelle App che rimangono aperte su una schermata del telefono. Ok, la grafica non è spettacolare, però le previsioni sono accurate ed è possibile scegliere il comune del quale visualizzare le previsioni meteo

SoundHound
Esiste in due versioni, free e a pagamento. Permette di risalire al titolo e all’autore di una canzione campionando qualche secondo di audio

Missing Sync
Ebbene si, ho un iMac e la sincronizzazione di Agenda/Rubrica/Note non è disponibile nell’iSync. Questa app (a pagamento) permette di sincronizzare un po’ tutti i dati del telefono con quelli del proprio Mac

FourSquare
All’inizio ero scettico, però essere Major (sindaco) dei miei posti preferiti mi inizia a piacere.

Quotidiani Italiani
Una raccolta dei link alle principali testate giornalistiche italiane. Utile per quando pranzo da solo…

Test comparativo di apache ed nginx

Riprendiamo il filone dei test di velocità con ab per capire la differenza che intercorre tra apache ed nginx per servire contenuti statici. Questo è per far capire quanto si migliorano le prestazioni di un sito utilizzando il sistema descritto in questo articolo. I parametri dell’ambiente di test sono gli stessi dell’articolo precedente.

Caso 1

Filesystem: ext3 locale
Contenuto servito tramite Apache
Richieste contemporanee: 10

Time taken for tests:   3.670543 seconds
Requests per second:    272.44 [#/sec] (mean)
Time per request:       36.705 [ms] (mean)
Time per request:       3.671 [ms] (mean, across all concurrent requests)
Transfer rate:          1368.73 [Kbytes/sec] received

Caso 2

Filesystem: ext3 locale
Contenuto servito tramite nginx
Richieste contemporanee: 10

Time taken for tests:   0.689000 seconds
Requests per second:    1451.38 [#/sec] (mean)
Time per request:       6.890 [ms] (mean)
Time per request:       0.689 [ms] (mean, across all concurrent requests)
Transfer rate:          7354.14 [Kbytes/sec] received

Caso 3

Filesystem: DRBD 8/OCFS2
Contenuto servito tramite nginx
Richieste contemporanee: 10

Time taken for tests:   4.439284 seconds
Requests per second:    225.26 [#/sec] (mean)
Time per request:       44.393 [ms] (mean)
Time per request:       4.439 [ms] (mean, across all concurrent requests)
Transfer rate:          1133.07 [Kbytes/sec] received

Da questi testi si evince che la velocità di nginx nel servire contenuti statici rispetto ad apache è notevole, però il filesystem DRBD/OCFS2 è comunque il “collo di bottiglia” della configurazione, cosa che nei test precendenti sui contenuti dinamici non appariva. Seppur da questi test non appaia evidente il beneficio che si ha adottando nginx rispetto ad apache per servire i contenuti statici, questo appare evidente se, durante i test, si lancia sul server il comando “top”: il carico di lavoro sul server prodotto da nginx rispetto ad apache è notevolemte inferiore, per cui visto che i nostri siti si compongono sia di parti statiche sia di parti dinamiche, serverndo i contenuti statici con il “caso 3” inceve che con il “caso 1” non si ha un aumento di prestazioni sui singoli contenuti statici, ma lo si ha sulla stabilità del webserver in quanto si lasciano libere più risorse.

Stress test di apache attraverso ab

Faccio seguito agli articoli sui diversi metodi di configurazione del web server per esporvi alcune statistiche realizzate attraverso il comando ab sulla home page di un sito Wordpress particolarmente pesante ed esoso di risorse, utilizzando i diversi metodi di esecuzione di php, diversi filesystem e diverse distibuzioni Linux.

Il comando ab permette di calcolare i tempi medi di download di una pagina web settando il numero di richieste totali e la contemporaneità delle stesse. L’ambiente di test prevede una macchina virtuale dedicata su VMWare esxi con assegnati 4 GB di Ram e 4 core CPU. L’hardware fisico è un server Dell PowerEdge R410 con due CPU Xeon E5520 QuadCore a 2.27 GHz. La macchina ospita localmente solo il server Web Apache/PHP, mentre il database MySQL è su un secondo server accessibile sempre in rete locale. Il PC su cui viene lanciato il comando ab è in rete locale e si richiedono 1000 pagine con una contemporaneità di 10 (tranne il caso 9).

(valore più basso, risultato migliore)

Caso 1: la situazione iniziale da migliorare

Distribuzione: CentOS 5.5
Posizione file PHP: SAN in rete locale 1 Gbit con FileSystem OCFS2
Metodo di esecuzione PHP: SuPHP
Plugin Wordpress attivi: moltissimi tra cui nextgen gallery e WassUp

Time taken for tests:   221.287876 seconds
Requests per second:    4.52 [#/sec] (mean)
Time per request:       2212.879 [ms] (mean)
Time per request:       221.288 [ms] (mean, across all concurrent requests)
Transfer rate:          2.15 [Kbytes/sec] received

Caso 2

Distribuzione: CentOS 5.5
Posizione file PHP: SAN in rete locale 1 Gbit con FileSystem OCFS2
Metodo di esecuzione PHP: mod_PHP
Plugin Wordpress attivi: moltissimi tra cui nextgen gallery e WassUp

Time taken for tests:   167.713406 second
Requests per second:    5.96 [#/sec] (mean)
Time per request:       1677.134 [ms] (mean)
Time per request:       167.713 [ms] (mean, across all concurrent requests)
Transfer rate:          2.84 [Kbytes/sec] received

Caso 3

Distribuzione: CentOS 5.5
Posizione file PHP: SAN in rete locale 1 Gbit con FileSystem OCFS2
Metodo di esecuzione PHP: mod_PHP
Plugin Wordpress attivi: nessuno

Time taken for tests:   78.987 seconds
Requests per second:    12.66 [#/sec] (mean)
Time per request:       789.875 [ms] (mean)
Time per request:       78.987 [ms] (mean, across all concurrent requests)
Transfer rate:          3.97 [Kbytes/sec] received

I primi 3 test riguardano esclusivamente un ambiente di test standard in cui modifichiamo prima il metodo di esecuzione di PHP passando dal “comodo” suPHP al più performante mod_PHP in modalità prefork (non multithreading, quindi). Il miglioramento di prestazioni si evidenzia, così come “predetto” nel precedente articolo: 6 decimi di secondo per ogni richiesta. Con il test 3, abbiamo disabilitato tutti gli esosi plugin di wordpress e si può notare come le prestazioni aumentino in maniera considerevole su scala di valori immensamente più grande (1,5 secondi a pagina), segno che comunque un buon sistemista non può fare miracoli se il codice da eseguire non è ottimizzato per la velocità.
Purtroppo non possiamo prescindere dall’utilizzo degli esosi plugin di Wordpress, per cui proviamo a vedere se cambiando distribuzione le cose migliorano.

Caso 4: come caso 1 con diversa distribuzione

Distribuzione: Gentoo Linux
Posizione file PHP: SAN in rete locale 1 Gbit con FileSystem OCFS2
Metodo di esecuzione PHP: SuPHP
Plugin Wordpress attivi: moltissimi tra cui nextgen gallery e WassUp

Time taken for tests:   198.396024 seconds
Requests per second:    5.04 [#/sec] (mean)
Time per request:       1983.960 [ms] (mean)
Time per request:       198.396 [ms] (mean, across all concurrent requests)
Transfer rate:          1.37 [Kbytes/sec] received

Bene, un ambiente “su misura” come quello creato da una distribuzione in cui si compila ogni singolo elemento porta i suoi frutti: circa 2 decimi di secondo in meno a richiesta per un totale di 20 secondi sullo svolgimento del test. Da notare che nel caso di Gentoo, abbiamo attivo anche il sistema Grsecurity che comunque rallenta leggermente i processi, mentre su CentOS abbiamo disabilitato SELinux.

Caso 5: come caso 4 ma con mmm_itk
Distribuzione: Gentoo Linux
Posizione file PHP: SAN in rete locale 1 Gbit con FileSystem OCFS2
Metodo di esecuzione PHP: Apache ITK
Plugin Wordpress attivi: moltissimi tra cui nextgen gallery e WassUp

Time taken for tests:   182.14380 seconds
Requests per second:    5.49 [#/sec] (mean)
Time per request:       1820.144 [ms] (mean)
Time per request:       182.014 [ms] (mean, across all concurrent requests)
Transfer rate:          1.49 [Kbytes/sec] received

Il passaggio da suPHP ad Apache compilato in modalità ITK permette di guadagnare altri 2 decimi a richiesta, mantenendo quindi un ambiente del tutto similare per l’utente a quello iniziale con CentOS/suPHP. Non si hanno le prestazioni del mod_php su CentOS (mancano ancora 2 decimi), però la situazione non è poi così diversa e… meglio perdere 2 decimi e guadagnare un cliente!
Abbimo preso per buono il fatto che i file php del sito stiano su una SAN accessibile via rete. Vediamo come si influenzano i tempi spostando i file php in locale ed utilizzando diversi filesystem.

Caso 6

Distribuzione: Gentoo Linux
Posizione file PHP: locale con filesystem ext3
Metodo di esecuzione PHP: Apache ITK
Plugin Wordpress attivi: moltissimi tra cui nextgen gallery e WassUp

Time taken for tests:   147.679954 seconds
Requests per second:    6.77 [#/sec] (mean)
Time per request:       1476.799 [ms] (mean)
Time per request:       147.680 [ms] (mean, across all concurrent requests)
Transfer rate:          1.84 [Kbytes/sec] received

Niente da dire, siamo sulla strada giusta. Seppure la SAN sia in rete locale a 1 Gbit, le prestazioni di un filesystem locale sono nettamente superiori guadagnando ben 4 decimi a pagina rispetto al test 5. Seppure questa soluzione rappresenti un buon passo in avanti è però impossibile da utilizzare in produzione in quanto non garantisce il funzionamento in caso di guasto del server; inoltre un sistema in alta affidabilità (acceso/spento) non ci garantisce nel caso di intenso traffico sul sito per cui vogliamo avere almeno due server web in load balancing. Dobbiamo quindi dotare il filesystem locale di un sistema di replica in modo che sia disponibile in due diversi server.

Caso 7

Distribuzione: Gentoo Linux
Posizione file PHP: locale con filesystem GlusterFS
Metodo di esecuzione PHP: Apache ITK
Plugin Wordpress attivi: moltissimi tra cui nextgen gallery e WassUp

Time taken for tests:   467.476497 seconds
Requests per second:    2.14 [#/sec] (mean)
Time per request:       4674.765 [ms] (mean)
Time per request:       467.477 [ms] (mean, across all concurrent requests)
Transfer rate:          0.58 [Kbytes/sec] received

Decisamente non ci siamo. Nonostante Gluster ci permetta di accedere localmente ai file e di replicarli tra di loro, il sistema impiega ad eseguire il test un tempo due volte maggiore rispetto alla situazione iniziale. Proviamo quindi ad usare un filesystem cluster come OCFS2 e DRBD 8 configurato in modalità attivo-attivo:


Caso 8

Distribuzione: Gentoo Linux
Posizione file PHP: locale con DRBD su filesystem OCFS2
Metodo di esecuzione PHP: Apache ITK
Plugin Wordpress attivi: moltissimi tra cui nextgen gallery e WassUp

Time taken for tests:   149.53515 seconds
Requests per second:    6.71 [#/sec] (mean)
Time per request:       1490.535 [ms] (mean)
Time per request:       149.054 [ms] (mean, across all concurrent requests)
Transfer rate:          1.82 [Kbytes/sec] received

Bene, DRBD 8 in modalità attivo-attivo e il filesystem OCFS2 utilizzato inizialmente sulla SAN iSCSI portano a delle velocità paragonabili a quelle del filesystem locale e alla fine migliori di circa 8 decimi di secondo rispetto alla situazione iniziale. Il sistema evidentemente è meno scalabile in quanto con un filesystem su SAN possiamo aggiungere infiniti nodi di calcolo in load balancing, mentre con DRBD siamo limitati a 2 nodi; questa mancanza di scalabilità migliora di 4 decimi l’output della pagina rispetto al caso 5: non si può dire se è meglio la soluzione 5 o la 8, ciascuno deve trarre le proprie conclusioni in base al tipo di servizio che deve offrire.
Inoltre c’è da dire che l’installazione di wordpress presa in esame è particolarmente pesante e lenta. Giusto a titolo comparatvo, per far felice il mio amico Maurizio del sito www.contaotutorial.com, ecco un test eseguito su un sito da lui realizzato con Contao.

Caso 9

Distribuzione: CentOS 5.5
Posizione file PHP: SAN in rete locale 1 Gbit con FileSystem OCFS2
Metodo di esecuzione PHP: mod_php
ATTENZIONE, in questo caso utilizziamo una contemporaneità di 100 richieste, non 10, quindi per avere un valore della stessa scala, nel grafico iniziale l’abbiamo diviso per 10!

Time taken for tests:   99.116 seconds
Requests per second:    10.09 [#/sec] (mean)
Time per request:       9911.572 [ms] (mean)
Time per request:       99.116 [ms] (mean, across all concurrent requests)
Transfer rate:          128.59 [Kbytes/sec] received

Ribadisco quanto già detto a commento del caso 3: un buon sistemista non può fare i miracoli se il codice è scritto senza alcuna ottimizzazione per la velocità.