ATTENZIONE:

ABBIAMO RAPITO LA SCIARPA DI MARCO FORMENTO, LA SUA UNICA FONTE DI PRESTIGIO. PER RESTITUIRLA INCOLUME VOGLIAMO:

• UNA BORSETTA GRIFFATA DI MAFE.
• LA REFLEX DI SILVA.
• LE MUTANDE DI MANTELLINI.
• UN MAGLIONE SFERUZZATO PERSONALMENTE DA SOFI.
• TUTTI I CELLULARI DI SUZUKIMARUTI.
• SW4N FUORI DALLA TOP 100 DI BLOGBABEL.

INOLTRE VOGLIAMO 100.000 PAGEVIEW IN LINK DI PICCOLO TAGLIO, PROVENIENTI DA SITI CON ALTO PAGERANK.

IL TUTTO ENTRO IL 31 DICEMBRE A MEZZANOTTE, ALTRIMENTI RISPEDIREMO LA SCIARPA PER POSTA, UN PEZZETTO ALLA VOLTA.

I TERMINI NON SONO NEGOZIABILI. CI FAREMO VIVI NEI COMMENTI.

E’ già da un po’ di tempo che non mi imbatto più nei famigerati router “disco volante” forniti da Telekoma; ultimamente l’offerta che va per la maggiore è Alice Business, che prevede la fornitura di un altro tipo di apparato: Alice Gate 2 Plus.

Si tratta di un router ADSL dotato di due porte ethernet, una porta USB ed una porta RJ-11 per la linea telefonica. L’indirizzo IP di default dell’interfaccia LAN è 192.168.1.1, DHCP e NAT sono abilitati. Una caratteristica degna di nota è il fatto che il router si configura automagicamente una volta connesso alla linea telefonica. Dopo un paio di minuti dalla prima accensione l’apparato si resetta e il collegamento ad internet funziona perfettamente. Anche se può far storcere il naso a qualcuno, per uno studio professionale o una piccola azienda mi sembra una mossa azzeccata: non si è più costretti a mendicare dall’installatore un foglio scarabocchiato a mano con gli indirizzi IP ed i parametri di configurazione, spesso sbagliati.

Quelli incontrati finora hanno funzionato tutti molto bene fin da subito, e sembrano sufficientemente stabili. L’interfaccia di gestione è minimale e permette di modificare l’indirizzo IP LAN e i parametri del demone DHCP, ma soprattutto di configurare molto facilmente il NATP, cioè il port forwarding, sia per TCP che per UDP.

L’utilizzo di un firewall da installare tra il router e la propria rete è sempre consigliabile, e l’operazione è agevole perché finalmente è possibile impostare un default virtual server a cui inoltrare tutto il traffico in ingresso (la WAN del firewall).

L’unica cosa che mi lascia perplesso è l’assenza di autenticazione: per modificare le configurazione non viene richiesta alcuna password, e ciò non è affatto un bene. E’ consigliabile, pertanto, restringere l’accesso HTTP alla LAN del router tramite opportune regole sul firewall, in modo che la gestione possa essere effettuata solo dagli host decisi dall’amministratore di rete.

Update. A scanso di equivoci: della versione dotata di WiFi non parlo perché non ho avuto occasione di provarla. Il post si riferisce solo ed esclusivamente alla versione “base”, senza Aladino VoIP.

Definizione degli scopi.

Il presente documento è redatto nell’intento di creare un’infrastruttura adeguata alla fornitura di Auguri. Verranno definiti:

• Le finalità degli Auguri.
• L’infrastruttura necessaria a supportare le risorse destinate all’erogazione del servizio.
• L’integrazione dei nuovi elementi architetturali con l’infrastruttura esistente presso il Cliente.
• La definizione dei processi necessari all’erogazione del servizio Auguri tramite gli elementi qui sopra definiti.
• Verranno descritte le procedure operative atte alla implementazione e all’integrazione del sistema, nonché definiti i processi operativi e di formazione del personale di competenza del Cliente.
• Saranno accennati gli aspetti più critici relativi alla scalabilità della soluzione.
• Aspetti legali dell’erogazione del servizio di Auguri.
• Si fornirà una stima del materiale necessario e dei tempi necessari alla realizzazione del progetto, in modo da poter formulare una adeguata offerta economica.

Finalità degli Auguri.

Si definisce Augurio una espressione del desiderio o della speranza che ad altri accada qualcosa di positivo. Nell’accezione usata in questo progetto ci si riferirà alla variante della formula (augurale) usata in occasione di feste pubbliche o private. Nell’intento di soddisfare le esigenze del Cliente, particolare attenzione verrà posta alla implementazione degli Auguri erogati in determinate circostanze o periodi dell’anno (cfr: Natale)*.

Infrastruttura.

Nelle finalità perseguite dal presente progetto, si identificano alcuni tipi diversi di Auguri, ciascuno dei quali necessita di una piattaforma peculiare, e peculiari attività di implementazione, erogazione e fruizione. Gli Auguri presi in esame sono di tre tipi principali: orali, scritti e a mezzo email. Per ciascuno di essi il preliminare di progetto identifica le seguenti infrastrutture:

• Orali: per gli auguri a voce è necessaria l’emissione di fonemi tramite l’apparato vocale. La piattaforma necessaria al servizio necessita quindi di una infrastruttura fisiologica in grado di supportare le funzioni richieste. Inoltre particolare cura dovrà essere osservata nella installazione e configurazione del sistema neurologico e cognitivo preposto alla comprensione ad articolazione del linguaggio, limitatamente alle sezioni: “Tante care cose…” e “Se non ci vediamo più, Auguri eh…”. Un caso particolare di Auguri a voce implica l’utilizzo dei sistemi di telefonia fissa, mobile o su rete a commutazione di pacchetto (VoIP). Trattandosi di un ulteriore strato del protocollo che è trasparente per l’utente, l’implementazione di tale layer esula dagli scopi del presente progetto.
• Scritti: le piattaforme coinvolte nell’erogazione degli auguri scritti sono essenzialmente due. Il sistema neurologico e lessicale, che si sovrappone parzialmente al caso precedente, tranne che per le aree interessate, che prevedono l’utilizzo intensivo di alcune parole del tipo: “Sereno/i/e”, “Felici/e”, “Festa/e”, “Nuovo Anno”, ed il sistema grafologico a sua volta diviso nei due sottosistemi “a mano” o “stampato”. Entrambi i sottosistemi implicano il corretto funzionamento delle infrastrutture scheletriche e manuali necessarie per apporre (almeno) uno scarabocchio definito “Firma” dalle relative RFC. Il sottosistema “a mano” coinvolge tutte le risorse adeguate a miscelare una serie di locuzioni comuni che costituiscono le primitive per il messaggio di Auguri che sarà erogato.
• A mezzo email: si veda in tal senso il progetto sviluppato circa sei mesi fa e denominato “Invio di presentazioni PowerPoint a contenuto osceno”. Le uniche differenze riguardano i destinatari, che nel caso di Auguri possono comprendere anche persone di sesso femminile, e il contenuto, spesso rappresentato da una GIF animata in cui l’icona pop “Babbo Natale” è intenta a attività relative alla consegna di doni oppure ad agitare il bacino vestita in modo sommario.

Integrazione.

Trattandosi di sistemi che fanno ampio utilizzo di infrastrutture già utilizzate per altri (inutili) scopi, l’impatto sulla struttura del Cliente è ridotto al minimo. Gli unici elementi da acquisire saranno appositi biglietti nel caso degli auguri scritti e/o stampati.

Erogazione del servizio.

Come già accennato nei precedenti paragrafi, gli Auguri possono essere erogati con mezzi diversi, ciascuno dei quali implica un differente utilizzo delle infrastrutture. Nel caso di Auguri orali, è necessario un contatto fisico e/o telefonico con il destinatario. Nel caso degli Auguri a mezzo scritto e/o stampato, si rende necessario l’utilizzo di sistemi e servizi di terze parti che provvedano al corretto instradamento e recapito del payload augurale. Si consiglia di utilizzare a tale scopo l’operatore Poste Italiane, che malgrado la bassa qualità del servizio, esercita un regime di monopolio di fatto. Per gli auguri a mezzo email, si possono sfruttare le strutture preesistenti presso il cliente, che in tal modo vedrà anche aumentare il ROI del sistema in suo possesso.

Aspetti operativi.

Gli aspetti operativi sono la parte più delicata dell’erogazione del servizio e ne rappresentano la parte esposta all’esterno. Pertanto verranno prese in esame le questioni relative alla gestione della sicurezza perimetrale del sistema Auguri, ed il modo in cui l’augurante si interfaccia con l’augurato.

Gli Auguri a voce sono la parte più critica in termini di risorse di sistema: la caratteristica prettamente seriale e personale, la necessità della presenza fisica e/o telefonica, la ristrettezza della banda a disposizione conseguenza del fatto che l’erogazione degli Auguri è destinata a pochissime persone contemporaneamente, fa sì che sia la più onerosa dal punto di vista dei costi di esercizio. Lo svantaggio è controbilanciato dall’efficacia maggiore rispetto agli altri sistemi, che hanno meno impatto sul target. Tale efficacia è inversamente proporzionale all’aspettativa di Auguri del destinatario del servizio.

Gli Auguri scritti hanno una buona efficacia e godono di un canale a banda maggiore rispetto al caso precedente. Malgrado il confezionamento dell’augurio sia comunque seriale, la separazione della procedura di preparazione da quella dell’erogazione aumenta l’efficienza del sistema. L’erogazione è prettamente parallela, essendo possibile la “delivery” simultanea di parecchi Auguri a più target diversi.

L ‘ultimo caso, quello degli auguri via email, gode dell’ampiezza di banda maggiore, essendo il sistema definito da un protocollo completamente parallelo: sia il confezionamento che la “delivery” sono frutto di un singolo processo che scatena molti eventi contemporanei. Inoltre, l’aggiunta di un destinatario è un’operazione che pesa pochissimo in termini di risorse del sistema. Lo svantaggio è rappresentato dalla bassa efficienza: la maggior parte dei destinatari tende a cestinare il messaggio di Auguri senza neppure leggerlo, rendendo spesso vano l’intero processo. Alcune teorie, non ancora dimostrate, ritengono più efficaci verso i destinatari maschi i messaggi in cui l’icona pop “Babbo Natale” è impersonata da una giovane donna in abiti provocanti oppure vestita solo di orecchie da renna in feltro. In quest’ultimo caso, però, l’erogatore del servizio rischia di perdere visibilità a causa del basso rapporto segnale/rumore.

Formazione.

L’implementazione presso il Cliente del servizio in oggetto ha un basso impatto in termini di formazione del personale: si tratta solo di rimodulare gli skill già presenti in azienda, eventualmente integrati da un breve corso di cultura pop. Si consiglia di far visionare agli addetti i messaggi pubblicitari di televisione e carta stampata circa due mesi prima dell’inizio delle operazioni.

Scalabilità.

Come già evidenziato nel paragrafo relativo alle modalità operative, il metodo di erogazione del servizio più scalabile è quello degli Auguri via email. Va tenuto conto, però, che si tratta anche del metodo con il minore ritorno in termini di gratitudine da parte dei destinatari. Per questo si consiglia il Cliente di valutare caso per caso il protocollo migliore da adottare, eventualmente tramite la suddivisione in fasce dei destinatari e successiva assegnazione ad un protocollo piuttosto che ad un altro. In tal modo sarà sempre possibile coniugare il grado di scalabilità desiderata rapportato ai costi di implementazione della soluzione.

Aspetti Legali.

Per gli aspetti legali, si rimanda all’ufficio competente, che ha redatto una dichiarazione da allegare a ciascun Augurio emesso dal Cliente.

Tempi e Costi.

In considerazione del particolare periodo in cui ci troviamo, e considerata la quantità di sciocchezze scritte qui sopra, gli Auguri per coloro che sono arrivati a leggere fino a qui sono assolutamente sgravati da qualunque costo, e provengono direttamente dall’estensore del presente progetto che, evidentemente, oggi aveva poco da fare.

(*) De Mauro

Questo periodo di sciopero degli autori statunitensi è l’occasione per distrarsi un po’ dalle solite serie blockbuster e dedicarsi alla ricerca di nuovi stimoli. Consigliato egregiamente da Luca e Matteo, ho appena finito di vedere la prima stagione di Damages. Si tratta di un legal thriller in 13 puntate ben recitato, con un cast azzeccato ed una trama avvincente; per gli amanti del genere è un must see.

E’ un prodotto sofisticato, con un uso magistrale del flashback: si parte dalla fine per procedere a ritroso, con la storia che va continuamente avanti ed indietro, scoprendo di volta in volta nuovi particolari; praticamente ogni puntata termina con un cliffhanger. Malgrado le acrobazie del montaggio ed i continui spostamenti temporali, non si fatica a mantenere l’orientamento, grazie all’abilità degli sceneggiatori e ad un uso sapiente della fotografia, che fa capire immediatamente il contesto.

Tutta la storia è permeata di quella atmosfera (Hitchcock? De Palma?) nella quale nulla è mai come sembra ed i cambiamenti di prospettiva portano in continuazione a farsi delle domande sui personaggi. I contorni sono sempre molto sfumati; tanto che, malgrado la serie sia felicemente conclusa, mi rimangono dubbi su chi siano effettivamente i “buoni” e chi i “cattivi”.

La stagione è conclusa ed il finale è molto soddisfacente: il mistero viene risolto, lasciando nel contempo interessanti scenari per gli sviluppi di una eventuale seconda serie. Potete trovare tutti i 13 episodi nel bouquet di Teletorrent©.

Le esigenze di connessione tra le sedi remote di un’azienda e l’aumento costante del lavoro in mobilità sono cresciute di pari passo con la qualità e la velocità dei collegamenti a banda larga. La conseguenza logica dei questo scenario è l’utilizzo sempre più capillare dei collegamenti VPN. Questo acronimo significa: Virtual Private Network, rete privata virtuale. Generalizzando: l’utilizzo di infrastrutture “pubbliche” fuori dal proprio controllo (e gestione) per implementare un collegamento sicuro tra le diverse sedi di una azienda o tra un “road warrior” e la propria sede.

La trattazione tecnica dell’argomento è vasta e complessa, le voci di Wikipedia inglese ed italiana offrono estese spiegazioni e parecchi link di approfondimento. Cercherò qui di dare un quadro generale sulle VPN, con i concetti fondamentali e un accenno ai più comuni metodi di implementazione.

Una VPN permette di collegare in modo sicuro i due estremi della connessione tramite una rete non dedicata, tipicamente utilizzando internet, abbattendo i costi delle linee CDN, che un tempo erano l’unica opzione. Tutto ciò porta diversi benefici: i principali sono:

• Economicità: si abbatte il costo delle infrastrutture. La scelta dell’implementazione adeguata in fase di progetto permette di scegliere la soluzione più adeguata al miglior costo sostenibile.
• Semplicità: la tecnologia è molto matura e non richiede skill esoterici.
• Sicurezza: si basa su standard perlopiù aperti e universalmente riconosciuti come sicuri. Con pochi accorgimenti si riescono ad ottenere buoni compromessi tra semplicità di accesso e ragionevole sicurezza.

Il concetto è abbastanza semplice, e adotta il paradigma “hub and spoke“: una sede centrale dalla quale si dipanano i collegamenti verso le sedi remote. (E’ evidente come il modello “mesh” non sia sostenibile nel caso particolare delle VPN). Utilizzando regole opportune si può decidere che ciascuna sede remota acceda esclusivamente al nodo centrale, oppure di abilitare anche il traffico tra le periferie. Nel caso particolare del collegamento tra due sole sedi, il modello è semplificato.

Le soluzioni che si possono adottare sono molteplici e vanno dal semplice server equipaggiato con software open source, a costose appliance ridondate in HA: la scelta dipende dai costi, dall’integrazione con le infrastrutture esistenti, dalla banda necessaria, dal carico di lavoro e dalla criticità del collegamento, tanto per citare alcuni fattori che condizionano la scelta del sistema a cui affidarsi.

In alcuni casi la realizzazione di una VPN site-to-site può essere delegata interamente al fornitore di connettività. E’ una scelta fatta prevalentemente da aziende piccole e medie, spesso senza un reparto IT. In Italia ho incontrato prevalentemente soluzioni di Telecom, che usa le capacità VPN dei router Cisco (credo, correggetemi nei commenti), e di Fastweb, che implementa reti MPLS sulla propria infrastruttura in fibra.

Ci sono molti motivi per utilizzare una VPN, uno dei più comuni è l’accesso remoto ad applicazioni non adatte ad essere pubblicate nativamente. Ad esempio: condivisione di file e applicativi verticali, magari su piattaforme proprietarie. I candidati ideali per l’accesso VPN sono le risorse prive di strumenti nativi per garantire la sicurezza al di là del perimetro aziendale. A seconda del livello di protezione richiesto, sarà cura del sistemista perimetrale decidere, quando possibile, se le risorse vadano posizionate in DMZ oppure se l’accesso debba avvenire direttamente in LAN.

L’implementazione non è esente da problemi: spesso il traffico VPN è sensibile ai router che ne trattano i pacchetti con troppa disinvoltura, oppure va incontro a difficoltà dovute all’impostazione dell’MTU. LA diagnostica non è per nulla agevole: i messaggi syslog sono difficili da interpretare e spesso mostrano solo l’effetto ma non la causa. Per fortuna i casi complicati sono una frazione del totale: molto spesso l’installazione non presenta particolari problemi.

Nel caso di una connessione site-to-site oppure hub and spoke, non è necessario toccare gli host della rete locale, è sufficiente assicurarsi che le sedi distinte abbiano piani di indirizzamento che non si sovrappongano, per evitare problemi di routing e complicate manovre di subnetting. (Fatevi un grosso favore: reti diverse, sempre). La VPN è realizzata tramite software oppure appliance che dialogano con la loro controparte remota, rappresentando l’endpoint della VPN, cioè il luogo in cui i pacchetti in ingresso vengono decrittati ed instradati in chiaro verso l’host di destinazione, ed i pacchetti in uscita vengono criptati, incapsulati ed inviati al gateway remoto.

Nelle implementazioni più semplici, l’endpoint di una VPN è lo stesso firewall che controlla il traffico da e per l’esterno; se invece le due entità non coincidono si renderà necessaria la definizione di una rotta statica sul default gateway, in modo da instradare correttamente il traffico.

Nel caso di utenti mobili o uffici piccolissimi (uno o due host), si utilizza una componente client che connette il nodo direttamente alla rete remota. Generalmente si tratta di software proprietari forniti dai produttori di appliance, che creano una scheda di rete virtuale sulla quale far viaggiare il traffico VPN. In questi casi entrano in gioco meccanismi di ARP proxying e non più di routing. Nella maggior parte dei casi si potrebbero utilizzare gli strumenti nativi che i diversi sistemi operativi mettono a disposizione, ma l’operazione si rivela talmente complicata (almeno nel caso di Windows) che l’uso di questi driver virtuali è universalmente diffuso. In realtà per l’accesso a risorse limitate da parte di pochi client, si potrebbe prendere in considerazione un tunnel SSH, di implementazione ancora più semplice.

Io utilizzo OpenVPN da parecchio tempo e mi trovo molto bene. Non richiede risorse particolari e mi permette di accedere a tutta la mia rete pubblicando una sola porta TCP e senza disporre di un IP pubblico statico.

In linea di principio le diverse appliance sono interoperabili, ma spesso con qualche difficoltà. Scegliendo unità simili molto spesso ci si deve limitare a compilare una o due finestre con gli stessi dati in posizioni complementari.

Per utenti che devono poter lavorare da computer pubblici, chioschi e computer condivisi, le soluzioni basate su SSL-VPN offrono la comodità di poter accedere alla rete remota tramite un browser e un po’ di componenti java, e presentano il vantaggio di funzionare in ambienti fortemente controllati: è sufficiente che passi il traffico SSL su https (TCP/443). Lo svantaggio è la minore integrazione con il sistema e la necessità di dover comunque installare un componente “invasivo” qualora si volesse accedere in modo completo alla rete.

In definitiva le VPN offrono una quantità di vantaggi che le rendono sicuramente interessanti; in cambio è necessaria un po’ di cura nel progetto e un po’ di attenzione alla gestione della sicurezza: i meccanismi di one time password, i token, il controllo attento degli accessi e della gestione degli account (RADIUS), sono alcuni dei metodi da adottare per garantirsi sonni (abbastanza) tranquilli.

Ho appena traslocato un vecchio server di un ufficio che sta occupando alcuni locali di un cliente. Si tratta di un Compaq Netserver E60, di circa 8 anni fa. Pentium II 400 MHz, HD 9GB SCSI, 128 MB RAM, Windows NT4 SP5. Internet Explorer 2.0 non è in grado di visualizzare alcun sito, neppure Google o Microsoft. Se lo punto a questo blog mi dice che il dominio è scaduto (??!!).

Ehm, è veloce.

Molto.

Stacktrace. Aperiodico di resistenza informatica.
Robe geek scritte da geek. Hardcore. Bello.

Beatrice, 4,5 anni: “Papà è vero che noi abbiamo tutti i film del mondo e li guardiamo con la scatoletta con la luce blu?“

Disclaimer: i link sono pressoché a caso.

* La pizza con Matteo la sera prima. La serata con Matteo. La levataccia il sabato. Samu, Michela e la Grande Punto affittata. Il GPS di Samuele che ci vuole fuori dall’autostrada a tutti i costi. Il mio N80, fortunatamente, no. Poco traffico, due soste. Virgin Radio. Arrivo, la fame, il sonno. Il NetFuturismo ci ammazza, e si ritorna in albergo il pomeriggio, per un pisolino. Il ritorno alla base e all’aperitivo in un bar di simpaticoni. Gente, tanta. Facce nuove, facce vecchie, facce belle. Risate e Negroni. Poi pizza e manca sempre una sedia. Sì, ok, 21 euro per una fetta di pizza (io due), ma quante birre ho visto? Flash. Tanti flash. Di alcuni per tutta la sera si è visto solo metà faccia, l’altra metà coperta da reflex digitali dotate di appendici di ogni tipo e lunghezza. “Ma tu quante foto hai fatto? Io 135″. “Tze! Ho appena riempito una SD da 4 Giga.”. Gente ovunque. Camerieri esasperati e avventori sbigottiti.

“Ma voi siete una confraternita? Un club? Chi siete?”. Il candidato spieghi ad un profano del tavolo a fianco, in meno di 30 parole, il concetto di blogosfera e barcamp con relativa cena.

Risate. Passeggiata. La torta di riso finisce anche a Roma.

“Mantelliiiiniiiiiii….“

“Zorro fischiava e arrivava il cavallo, noi fischiamo e arriva Zoro.”

Ciao, a domani. Alle 3, in albergo, si dorme.

La mattina. Con calma. SuperMario husband. Un barcamp: no hay salette, no hay banda, no hay gadget, no hay cibo. WTF? Gli interstizi, quelli sì. Metto su una WiFi di fortuna col MacBook di Fabio Masetti. All’EUR la domenica è tutto chiuso, non c’è neppure l’IKEA per mangiare. Anche questo bar ha finito la torta di riso. La Taverna del Porno Porco Porto. Che fortuna. Commozione davanti all’amatriciana. Chiacchiere, conoscenze, amicizie; è l’ora. Piove. GRA. Virgin Radio. Fame. Cerca su Google: “Risorante uscita autostrada Prato” e clicca sul terzo risultato. E’ un blog. Il ristorante è pazzesco e non ha un sito. Cibo toscano. Buono. Economico. Mai più un viaggio senza connessione in macchina.

A casa alle 00:40. Baci, e guidate con prudenza.

(Sì, lo so mi sono dimenticato di linkarti. Scusami, chiunque tu sia.)

Lo strumento canonico di VMWare per la creazione di macchine virtuali senza dover reinstallare tutto da zero ogni volta, sarebbero i template.
Lavorare con i template presuppone di averli preparati prima e di usarli spesso, altrimenti potrebbe non valere la pena di utilizzare tempo e spazio sullo storage per gestirli.
La necessità di clonare una macchina virtuale mi si presenta raramente, e di solito procedo in questo modo:
Come prima cosa creo una snapshot della macchina tramite VC Backup. Al termine del processo ho ottenuto un backup della macchina virtuale su una cartella di uno storage esterno, ad esempio i dischi del server Virtual Center. Rinomino la cartella con il nome che desidero per il clone che andrò a creare, e utilizzando VMConverter (quello fornito con ESX server), provvedo a reimportare la macchina, avendo cura di non farla avviare automaticamente al temine del processo di importazione.

Nel frattempo mi procuro Sysrep, un’utility gratuita di Microsoft, scaricabile da qui. Malgrado la pagina parli solo di Windows 2000, WMWare dice che va bene anche per XP Pro e Windows Server 2003 (è vero, uso questa e funziona benissimo).
Con i files di Sysprep è necessario creare un file ISO che va copiato insieme alle altre immagini ISO sul datastore, nella cartella /vmimages/tools-isoimages dei server ESX, tramite WinSCP oppure Veeam FastSCP.
Al termine dell’importazione edito la configurazione del clone, impostando l’avvio con la scheda di rete scollegata e mappando il CD-ROM virtuale sulla ISO di Sysprep residente sui server ESX.

A questo punto posso finalmente avviare la macchina clonata. Alla partenza copio i files di Sysprep dal CD-ROM virtuale a c:\sysprep e lancio il programma; un wizard mi guida nelle operazioni di cambiamento dell’hostname della macchina, dell’impostazione dell’indirizzo IP e nell’eventuale join al dominio. Importante: subito prima di confermare le proprità del TCP/IP bisogna ricollegare la scheda di rete. Al termine del processo il pulsante “Seal” applica le impostazioni e fa ripartire la macchina. Al riavvio il sistema operativo si comporta come se fosse stato appena installato, ma con le impostazioni da voi definite poco prima. Se joinate lo stesso dominio, il profilo utente è bello pronto che vi aspetta e non dovete modificare una virgola rispetto alla macchina di partenza.

Risultato finale dell’operazione: due macchine identiche dal punto di vista del software e della configurazione, ma comunque distinte e funzionanti contemporaneamente. Perché è importante il processo di customizzazione tramite Sysprep appena descritto?

Ciascuna macchina in un dominio Active Directory possiede un SID che deve necessariamente essere univoco. Clonando brutalmente la macchina, il SID non viene modificato, neppure se cambia l’hostname. Due SID uguali su una rete pongono problemi di sicurezza e di funzionamento, e non sono in alcun modo supportati.

La procedura descritta va bene se non deve essere utilizzata con troppa frequenza, poiché le fasi di snapshot e importazione sono abbastanza lunghe. Nel caso si dovesse produrre parecchie macchine virtuali è sempre meglio utilizzare i template.