Oggi tutti parliamo di cloud computing e, ad accezione degli addetti ai lavori (quanto mi piace questa espressione), ritengo che pochi abbiano compreso il tema. Faccio quindi un passo indietro rispetto al mio precedente post, probabilmente troppo tecnico, nel tentativo di raccontare il concetto di cloud agli esseri umani.

Il concetto standard di infrastruttura informatica prevede che un’azienda debba dotarsi di determinate componenti hardware (computer, monitor, apparati di rete, ecc.) e software (sistemi operativi, applicazioni, server gestionali, server di posta elettronica, ecc.) per informatizzarsi.

Queste componenti costituiscono un investimento di capitale e generano dei costi ricorrenti per la loro gestione e manutenzione: serviranno tecnici qualificati per far funzionare il tutto e serviranno nuovi investimenti per mantenere l’infrastruttura efficiente. Inoltre ogni nuovo investimento deve tener conto dei trend di crescita, si rischia quindi di dover investire sovradimensionando un’infrastruttura che sarà a regime di utilizzo sono per una parte della sua vita.

I servizi cloud mirano a minimizzare i costi d’infrastruttura astraendone il concetto stesso. Le aziende di settore si impegnano a pre-costruire e manutenere un’infrastruttura informatica di alto livello su cui le aziende clienti possono far risiedere i propri servizi pagando un canone per l’uso delle risorse e delle funzionalità. Avviene dunque che il responsabile ICT dell’azienda ABCDEF s.r.l. non sarà più vincolato ad acquistare un server e il software necessario per il server e per i client al fine di mettere a disposizione il servizio di posta elettronica, potrà invece rivolgersi ad un’azienda che eroga servizi cloud e dire:

voglio la posta elettronica con Exchange per 2000 utenti e con 10 GB di spazio mailbox ad utente, voglio pagare solo per lo spazio che uso, voglio che ci siano i backup granulari a livello mailbox con 1 mese di retention e che il sistema sia in H.A., voglio il monitoraggio del servizio ed un presidio 24×7 da contattare in caso di problemi

e finalmente qualcuno risponderà:

certo, il servizio sarà pronto tra due giorni e costerà € XX ad utente e € YY a GB di spazio utilizzato

Ho voluto ovviamente estremizzare con un ipotetico Software as a Service, ma la realtà, per le aziende che dispongono di questo tipo di servizi, non è distante da quanto ho scritto.

Dal punto di vista dell’utilizzatore dei servizi il passaggio al cloud potrebbe essere quasi trasparente in quanto, nell’esempio precedente, l’utente usava Exchange prima e continua ad usare Exchange dopo. Dal punto di vista dell’ICT manager la situazione cambia notevolmente in quanto si trova a gestire un servizio e non una “sala server interna” che eroga servizi. Cambiano gli oneri, cambiano le competenze, cambiano le responsabilità, cambiano i costi. Su questo versante è una piccola rivoluzione.

Il cloud risolve quindi tutti i problemi dell’ICT? Vi rimando al mio vecchio post :-)

Esiste un interessante documento di VMware che suggerisce cinque riflessioni utili a chi desidera virtualizzare il proprio Datacenter, grande o piccolo che sia. Il documento titola “Five steps to determine when to virtulize your servers” e di seguito ne espongo il sunto.

Step 1: comprendere i benefici della virtualizzazione
I quattro principali benefici della virtualizzazione sono il risparmio di tempo, il risparmio economico, la facilità di gestione e le potenzialità di recovery in caso di disastro. Questi quattro benefici sono ovviamente da rapportare al mondo fisico dove l’ottimizzazione delle risorse hardware è meno versatile e spesso presenta delle diseconomie in quanto ogni server può far girare un sistema operativo, quello installato.

In relazione al risparmio, sia esso di tempo o di moneta sonante, vale la legge dei numeri: gestire un cluster VMware di due nodi costa meno che gestire venti – o più – server fisici. Ovvio che se la nostra infrastruttura comprende un server che fa tre cose, le fa bene da anni, il sistema è solido ed il backup sono a regime… bhe, in questo caso potrebbe aver poco senso virtualizzare il quanto il rapporto costo/beneficio potrebbe risultare poco allettante.

Step 2: valutare la soluzione di virtualizzazione
Il mercato offre differenti soluzioni e modelli di virtualizzazione, i tre brand citati all’inizio offrono la loro interpretazione dei servizi di virtualizzazione e tutti e tre lo fanno molto bene. Io sono un dichiarato fun di VMware ma bisogna considerare il fatto che ogni brand offre qualcosa di unico. Un esempio banale: se il nostro Datacenter comprende e comprenderà sempre server con O.S. di casa Microsoft potrebbe seriamente aver senso utilizzare HyperV.

Al di la del brand va considerato il livello di funzionalità che si richiede alla nostra server farm virtuale. VMware, ad esempio, offre diverse modalità di licensing per diversi livelli di funzionalità, da quella base dove “basta virtualizzare” a quelle Enterprise con funzionalità evolute come l’alta affidabilità la Fault Tollerance ed il DRS.

Step 3: assicurarsi che le applicazioni funzioneranno bene in virtuale
Virtuale non è fisico, ficchiamocelo bene in testa. Aggiungere una stratificazione software porta inevitabilmente a dei costi che, per quanto trascurabili, esistono. Se virtualizziamo male questi costi diventano delle vere e proprie perdite di performance che possono compromettere il servizio.

Quando si valuta una soluzione di virtualizzazione è necessario investire del tempo in analisi per comprendere quali sistemi dovranno girare sullo stesso nodo, quali dovranno condividere lo storage, quali avranno bisogno di risorse garantite e quali invece potranno lavorare tranquillamente best-effort. Esempio: se posizioniamo nello stesso Datastore due sistemi che fanno molto I/O su disco è inevitabile generare una contesa di risorse, sin dall’inizio i due sistemi dovranno essere posizionati su dischi logici e fisici differenti.

Step 4: analisi dei costi
Quanto costa virtualizzare? Come detto poco fa molto dipende dal livello di funzionalità che si desidera, ad ogni modo virtualizzare bene non è gratis e non è affatto detto che tutte le aziende possano permetterselo. Esistono aziende che offrono servizi di virtualizzazione nei propri Datacenter (io lavoro per una di queste) con soluzioni a canone mensile, ma c’è anche chi preferisce (o è vincolato ad) investire in una propria infrastruttura di virtualizzazione.

In questo caso i costi lievitano notevolmente e basta poco per raggiungere i 10.000-15000 euro di infrastruttura. Quindi la questione è: ma mi conviene virtualizzare? Fatevi i conti in tasca, potreste trovare soluzioni meno belle ma altrettanto affini al vostro target.

Step 5: considerare le skills ed il tempo per migrare in virtuale
Per approcciare una migrazione da mondo fisico a mondo virtuale è necessario avere delle skills sul prodotto di virtualizzazione che si è scelto. Se queste skills non le si hanno in casa è ovviamente saggio rivolgersi ad un professionista (ci sono fior di aziende e liberi professionisti stra-certificati che potete contattare).

E’, inoltre, da tener presente che il lavoro di migrazione richiederà dell’operatività che potrebbe durare anche parecchi giorni a seconda della mole di dati. Spesso è utile fare un piano d’azione per effettuare le migrazioni in più step e minimizzare l’impatto sugli utenti dei servizi che si è deciso di virtualizzare.

La virtualizzazione è (IMHO) un grande strumento ma non va utilizzato “a caso”, bisogna ponderare bene ogni scelta prima di intraprendere la via del virtuale e trarne effettivi benefici.

In molti è ancora radicata la credenza che gli attacchi informatici siano opera di qualche furfante che dalla propria tana opera nella notte allo scopo di rubare denaro per via telematica. La verità è abbastanza diversa. Oggi buona parte degli attacchi sono condotti da bot che in mesi di lavoro collezionano decine di server compromessi con i mezzi più banali (spesso con semplici brute force). Questa modalità di attacco nelle sue prime fasi ha come unico obbiettivo il guadagnarsi l’accesso a quanti più sistemi possibili a prescindere da cosa vi sia sui server. I server compromessi vengono spesso utilizzati per altri attacchi o come base per attacchi DDoS. Si può quindi essere vittime di un attacco informati senza necessariamente essere il bersaglio primario.

Provate a spiegare quanto da me scritto ad un qualsiasi membro di una PMI italiana. Al di la del comprendere o meno gli aspetti tecnici del tema è lampante una completa mancanza di interesse, come se il problema non esistesse. C’è addirittura il rischio che passiate per paranoici.

Chi ha tanti anni di servizio alle spalle sa che “l’attacker” è dietro l’angolo e questa consapevolezza ci spinge, dovrebbe spingerci, a fare le cose per bene: password robuste, policy di firewalling stringenti, attenzione al livello di patching, hardening dei sistemi, fino ad arrivare agli IDS ed IPS laddove la situazione lo richiede.

La sicurezza informatica è, in Italia, ancora percepita come un qualcosa in più, non sempre necessaria, qualcosa di trascurabile salvo situazioni particolari come l’essere una banca. La sensibilizzazione sul tema sta di fatto a noi, forse dobbiamo indossare la tunica del “security evangelist” più spesso.

Il migliore amico del problem solver è il log file. Guardiamoci dentro e leggiamo attentamente, non necessariamente alla ricerca di un errore il quale non è detto che si manifesti esplicitamente. Riporto un esempio recentissimo:

*** NetworkManager[921]: <info> Starting VPN service 'pptp'...
*** NetworkManager[921]: <info> VPN service 'pptp' started (org.freedesktop.NetworkManager.pptp), PID 3877
*** NetworkManager[921]: <info> VPN service 'pptp' appeared; activating connections
*** NetworkManager[921]: <info> VPN plugin state changed: 1
*** NetworkManager[921]: <info> VPN plugin state changed: 3
*** NetworkManager[921]: <info> VPN connection 'TEST VPN' (Connect) reply received.
*** pppd[3878]: Plugin /usr/lib/pppd/2.4.5/nm-pptp-pppd-plugin.so loaded.
*** pppd[3878]: pppd 2.4.5 started by root, uid 0
*** pptp[3883]: nm-pptp-service-3877 log[main:pptp.c:314]: The synchronous pptp option is NOT activated
*** pptp[3889]: nm-pptp-service-3877 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
*** pptp[3889]: nm-pptp-service-3877 log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply
*** pptp[3889]: nm-pptp-service-3877 log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established.
*** pppd[3878]: Using interface ppp0
*** tuxicity pppd[3878]: Connect: ppp0 <--> /dev/pts/2
*** NetworkManager[921]:    SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/ppp0, iface: ppp0)
*** NetworkManager[921]:    SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/ppp0, iface: ppp0): no ifupdown configuration found.
*** pptp[3889]: nm-pptp-service-3877 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
*** pptp[3889]: nm-pptp-service-3877 log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply.
*** pptp[3889]: nm-pptp-service-3877 log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 43392).
*** pppd[3878]: CHAP authentication succeeded
*** kernel: [ 6154.097690] PPP BSD Compression module registered
*** kernel: [ 6154.135569] PPP Deflate Compression module registered
*** pppd[3878]: LCP terminated by peer (MPPE required but peer negotiation failed)
*** pptp[3889]: nm-pptp-service-3877 log[pptp_read_some:pptp_ctrl.c:544]: read returned zero, peer has closed
*** pptp[3889]: nm-pptp-service-3877 log[callmgr_main:pptp_callmgr.c:258]: Closing connection (shutdown)
*** pptp[3889]: nm-pptp-service-3877 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'
*** pptp[3889]: nm-pptp-service-3877 log[pptp_read_some:pptp_ctrl.c:544]: read returned zero, peer has closed
*** pptp[3889]: nm-pptp-service-3877 log[call_callback:pptp_callmgr.c:79]: Closing connection (call state)
*** pppd[3878]: Modem hangup
*** pppd[3878]: Connection terminated

Trovato il problema? Allora cerchiamo con Mr. Google e capiamo cosa è successo. Fortunatamente PPTP è ben documentato e alla pagina http://pptpclient.sourceforge.net/howto-diagnosis.phtml del sito troviamo buona parte degli errori e relativa diagnosi. Nonostante io non ami particolarmente PPTP bisogna apprezzare la quantità di documentazione a disposizione, ottimo ausilio alla diagnosi dei problemi.

Non limitiamoci a guardare i log del cliente, anche i logs dei server che erogano il servizio VPN possono contenere informazioni utili alla diagnosi di un problema (ammesso che il server sia in vostra gestione).

Ultima nota: incentivate l’uso di VPN per l’accesso ai servizi “delicati”, anche se il servizio prevede nativamente un sistema di autenticazione. Un esempio banale è la posta elettronica aziendale: limitarsi ad esporla in IMAP o in POP3 è una pratica poco sicura. Un buon livello di “blindatura” è l’esposizione della sola porta 25 per la ricezione della posta dall’esterno e l’accesso ai servizi del mail server solo tramite sessione VPN. Paranoia? Noi la chiamiamo sicurezza ;-)

La scelta dell’interfaccia grafica della propria linux-box è sempre molto soggettiva, ciò che mi è sempre piaciuto di Gnome era la semplicità e la reattività, due qualità che con la crescita delle funzionalità sono andati via via scemando. Guardo oggi KDE e vedo quello che dieci anni fa vedero in Gnome, qualcosa di davvero innovativo e al contempo semplice, usabile e personalizzabile.

Oggi la scelta cade su KDE.

Fortunatamente c’è un modo migliore di agire. Dalla admin CLI di TSM (o dall’interfaccia della ISC se preferite) potete modificare il nodename del nodo:

rename node <ATTUALE_NOME> <NUOVO_NOME>

Successivamente accedere al sistema oggetto di backup ove dovrete rimuovere il servizio (o il processo) di scheduler in quanto questo fu avviato con un nodename ormai inesistente. Nel file di configurazione del Backup Archive Client (dms.opt) modificare il nodename del server ed avviare il cliente in modo da eseguire una prima sessione di comunicazione con il server TSM. Verificate le credenziali del nodo si potrà creare il nuovo servizio (o processo) di scheduler.

Questa procedura garantisce il corretto funzionamento delle schedulazioni di backup dopo aver modificato il nodename. La maggior parte degli amministratori alle prime armi con TSM spesso si limita a modificare il nodename sul server e nel file dsm.opt senza rigenerare i servizi di scheduler, cosa che fa inevitabilmente fallire i backup successivi alla modifica.

Chiudere per la crisi è una cosa, chiudere per fare più utili è un’altra.

Il prodotto resta valido, finché funziona. La versione 2.1.7, attualmente rilasciata nei repository di Ubuntu 11.10, porta con se un bug che impedisce il funzionamento delle VPNs verso apparati Cisco (e forse non solo Cisco). Nessuna patch al momento, solo uno scomodo workaround: eseguire il downgrade alla versione 2.1.5 (disponibile sul sito del produttore).

Addio Unity, bentornato Gnome!

Transitare per un proxy aiuta, di per se, a rendere anonimo l’utente in quanto l’IP che verrà intercettato dai sistemi di tracciamento sarà quello del proxy e non quello dell’utente. Grazie alla rete Tor gli utenti navigano dietro un discreto numero di proxy ed il percorso varia randomicamente, in questo modo l’IP con cui l’utente si presenta varia ad ogni sessione di navigazione sul web.

Il progetto ha come unico scopo la protezione della privacy e si basa sul contributo degli utenti che mettono a disposizione i propri sistemi per espandere la rete Tor. Non è un caso che le prestazioni di rete siano molto basse: i nodi della rete Tor utilizzano una percentuale della banda che il provider mette a disposizione del server.

Sito ufficiale del progetto: https://www.torproject.org.