In Vista

Un’altro post di Russinovich: The Case of the System Process CPU Spikes.

’ste cose mi divertono!

Il tool Microsoft Assessment and Planning Solution Accelerator è definitivo. Questo tool vi permette di valutare se le macchine della rete possono far girare Windows Vista, Microsoft Office 2007, Microsoft Application Virtualization (SoftGrid) e Windows Server 2008.

Somiglia al tool che valuta se l’hardware di un PC è in grado di far girare Vista ma su una scala enterprise.

Come previsto è uscito il WSUS 3.0 SP1, una vecchia conoscenza per gli amministratori Windows. Questo service pack aggiunge una funzione estremamente importante: il supporto a Windows Server 2008. E’ un elemento fondamentale per completare la nostra migrazione (e dei clienti).

Normalmente i post di Mark Russinovich sono molto interessanti. Questo dedicato ai miglioramenti della copia di file in SP1 non sfugge alla regola. Da leggere. Dedicato soprattutto a chi pensa che la copia di file sia una cosa semplice.

Ieri mia sorella mi ha portato a casa il suo portatile Toshiba Satellite Pro. Si tratta di una macchinetta nata con XP Pro ma upgradata a Windows Vista Ultimate, con un processore Centrino (niente dual core a disposizione quella volta), un disco da 40 GB a 5400 giri/min, 1.2 GB di RAM, scheda video ATI, video 1200×800 Trubrite, audio  e un indice di prestazioni di 2.7. Il software più usato su questo PC è Office 2003. Questo per dire che non serve e non serviva una macchinona costosissima per far girare Vista decentemente.

La macchina in questione dopo mesi di funzionamento senza problemi improvvisamente ha deciso di non connettersi più alla rete. Con lo scarso tempo che mi ritrovo a disposizione in questi giorni non ero molto felice di dover mettermi a smanettare sul PC della sorella.

Dopo aver verificato il comportamento scopro che ha smesso di ottenere un indirizzo IP dal server DHCP (in questo caso un access point Linksys WRT54G, quello flashabile con Linux). Dal log degli eventi si vede che il servizio SYMTDI (è un device connesso con il Norton Antivirus) non partiva a causa del fatto che un dispositivo collegato al sistema non è funzionante. Dalla visualizzazione della configurazione di macchina ho notato che nessun dispositivo dava problemi (neppure quelli nascosti) escluso SYMTDI stesso. 

Dopo vari tentativi e la consultazione di alcuni articoli nelle knowledge base che non si applicavano al mio caso, ho deciso di disinstallare il Norton Antivirus e… sorpresa! Il PC ha ripreso a funzionare correttamente senza alcun problema. Nei prossimi giorni sentirò Symantec per capire se esiste qualche soluzione al problema. Nel frattempo installerò una trial di 3 mesi di Microsoft OneCare. Poi mia sorella deciderà quale dei due preferisce.

P.S.: mi stupisce sempre la differenza tra Symantec Antivirus e Norton Antivirus (il primo per le aziende, il secondo per i consumatori). Sembra che siano prodotti da due aziende diverse. Il Norton è forse la peggiore pubblicità al Symantec, molto diverso dal primo.

Il DEP (Data Execution Prevention) è un meccanismo hardware che impedisce l’esecuzione di codice in aree di memoria marcate come contenenti dati. Si tratta di un meccanismo di sicurezza interessante che è abilitato di default in Windows Vista.

Purtroppo alcuni programmi o perchè scritti male o per necessità non sono compatibili con il DEP. Il risultato è che il programma viene abortito (e la colpa del fatto spessa è data a Windows mentre, in ultima analisi, è delle applicazioni). In rete spesso si trova come consiglio quello di disabilitare il DEP completamente. Ovviamente non è una bella proposta visto che rende il sistema meno sicuro.

Windows Vista (e anche altre versioni) è però in grado di gestire delle eccezioni alla regola generale e questo è probabilmente il migliore modo per risolvere i problemi.

Ad esempio nel mio sistema ho disabilitato il DEP per alcuni programmi particolarmente rognosi.

L’emulatore della calcolatrice HP ha richiesto questa operazione. Anche l’utilizzo di alcuni programmi come Lotus Symphony su macchine doppio core lo richiede. Quindi quando vi capita un errore dovuto al DEP è bene cercare di capire che programma lo provoca, perchè, verificare se esiste una versione alternativa del programma e, come ultima possibilità, inserire il programma nella lista delle eccezioni.

Vista ha uno strumento che ne misura l’affidabilità (in inglese reliability). Lanciando il Reliability Monitor si può osservare un grafico che illustra l’andamento temporale del sistema evidenziando eventuali componenti che hanno avuto problemi, l’installazione di software (fix compresi) o di periferiche e altro ancora.

Nella schermata qui inserita si può vedere l’andamento del mio media center e si può notare che il giorno 14 ottobre ho avuto un disruptive shutdown. In altri termini non ho chiuso bene il PC, fatto probabilmente dovuto ad una mancanza di corrente visto che il PC in questione non viene mai chiuso. Questo ha fatto calare per quella giornata l’indice di affidabilità a 8.26. Oggi viaggia su 9.40.

Il Reliability Monitor è uno strumento molto interessante e utile che fornisce informazioni a livello diagnostico. La bellezza di questo strumento è che aiuta a identificare cosa dà problemi nel tempo.

Come già detto non sono un grande fan della virtualizzazione. Spesso noi abbiamo a che fare con sistemi complessi e la virtualizzazione in questi sistemi non risulta per nulla trasparente provocando cali di efficienza o, peggio, veri e propri malfunzionamenti. Mi è persino capitato di trovare casi in cui alcuni fornitori hanno consigliato al cliente l’acquisto di prodotti di virtualizzazione per scoprire poi che il loro stesso software non girava sulla virtualizzazione da loro stessi proposta! E comunque a volte proprio non serve visto che la piattaforma applicativa stessa fornisce le caratteristiche per cui la virtualizzazione viene scelta.

Però poco tempo fa BEA ha annunciato una nuova versione del loro application server WebLogic in grado di girare nell’ipervisore senza richiedere il sistema operativo. Per un application server J2EE questo ha molto senso visto che l’ambiente Java stesso maschera il sistema operativo sottostante: fornire quindi un ambiente minimale necessario alla JVM può essere efficiente. Quindi a maggior ragione si può eliminare il sistema operativo completo sostituendolo con uno strato molto meno complesso che fornisce le funzioni di base. E’ un modello molto interessante e che dimostra ancora una volta di più cosa si intende per piattaforma quando si parla di Java. In effetti noi utilizziamo spesso lo stack Java di IBM (WebSphere in parole povere) dove quasi sempre il resto (e soprattutto il sistema operativo) è irrilevante.

Tra parentesi di solito il cliente medio sceglie come sistema operativo Windows perchè non ha né voglia né tempo di gestire sistemi operativi alternativi. Questo fatto è stata uno delle motivazioni che mi ha convinto qualche anno fa a riproporre Windows in modo pesante nonostante la nostra grande esperienza su altri sistemi.

Tornando al discorso della virtualizzazione sarà interessante vedere come questa si inquadrerà in una architettura Windows.

Attualmente molte applicazioni Microsoft fanno uso di alcuni servizi comuni come Active Directory e SQL Server. AD è il cuore di una rete Windows ed è bene avere almento due server in azienda. Io penso che, per questioni di ridondanza e resistenza e sicurezza, è bene averli su macchine fisiche separate. Se si utilizza molto SQL Server, allora anche questo è bene averlo ridondato su macchine fisiche: in fondo un SQL Server è in grado di sfruttare memoria e thread in modo efficiente da solo. Con una organizzazione di questo tipo è possibile ospitare applicazioni IIS (che utilizzano la struttura SQL Server per i dati) su vari server: bilanciamento e ridondanza sono offerti dall’IIS stesso. I server di posta evoluti sono sistemi spesso critici e che oggi hanno un  bisogno di elevato I/O. Al momento attuale non ho esperienza di virtualizzazione di grossi sistemi questo tipo in quanto tutti i clienti li preferiscono su macchine dedicate (in cluster tra loro). I sistemi di messaggistica integrata con funzionalità VOIP richiedono molta CPU, molta banda, schede di rete veloci e poco disco. Anche questi probabilmente funzionano meglio su macchine fisiche. Aggiungo, poi, che il supporto al framework .NET è e sarà sempre più embeddato nel sistema operativo (in pratica “application server” .NET e Windows saranno sempre più la stessa cosa). A tutti questi fattori vanno aggiunti i cali dei costi delle SAN che permettono di centralizzare facilmente lo storage “fisico” delle varie macchine e la disponibilità di dispostivi blade. E, se proprio si vuole, esiste un Microsoft Virtual Server che permette di gestire bene e facilmente macchine virtuali per altri scenari.

E’ però vero che sul mercato oggi si trovano processori quadricore a prezzo basso e, pare, anche chipset e motherboard in grado di sfruttare queste caratteristiche in modo più efficiente. Potrebbe non essere lontano il momento in cui alcune delle applicazioni descritte potrebbero girare meglio su sistemi virtualizzati. Microsoft, oltre ai classici strumenti già esistenti per gestire sistemi e aggiornamenti, avrà Windows Server 2008 che è assai più modulare delle versioni precedenti, uscirà con un ipervisore incorporato nel server e ha oggi un sistema di management per i sistemi virtualizzati. E quindi sicuramente ben posizionata per sfruttare queste funzionalità.

Ma per il momento la maggior parte del software, di famosi e meno famosi produttori, a volte non è in grado di lavorare al massimo delle proprie capacità o è addirittura non pienamente supportato su macchine virtuali. E allora io continuo a preferire le macchine fisiche che danno meno problemi. 

Una delle cose che più mi affascina nel sistema Windows è la forte integrazione presente tra vari elementi. E questa una particolarità che lo rende più adatto di altri in molti scenari aziendali. E per sistema Windows intendo sia i sistemi desktop che i server che altro. Fulcro principale di questa integrazione è sicuramente Active Directory, un contenitore gerarchico che si occupa di gestire le informazioni relative alla maggior parte degli elementi come utenti, computer, certificati, stampanti, applicazioni e altro.

Uno di questi elementi, fornito con il server Windows, sono i Certification Services. La mia esperienza nelle aziende mi induce a pensare che siano inspiegabilmente poco conosciuti e quindi poco installati. Questi servizi, integrati con Active Directory, forniscono a Windows una completa struttura di Certification Authority (CA) per la gestione dei certificati digitali standard che permette operazioni come la richiesta, la revoca e la distribuzione di questi elementi oggi fondamentali. Alcune di queste operazioni su alcuni tipi di certificati sono automatiche e trasparenti per l’utilizzatore. I certificati sono assolutamente standard tanto è vero che noi li utilizziamo anche nei nostri server Domino, Apache e WebSphere.

Oltre ad autentificazione e crittografia una delle funzionalità fornite da una struttura di certificati è la firma digitale del codice. Questo è molto importante per aumentare il livello di sicurezza del codice che viene eseguito nella rete. Ad esempio io li utilizzo anche per firmare gli script PowerShell.

In pratica un mio PC dove sviluppo il codice ha un livello relativamente blando di sicurezza (RemoteSigned) ma i server, invece, richiedono codice firmato. Quindi io scrivo uno script sul PC e, una volta testato, lo copio nel server e lo firmo per autorizzarne l’esecuzione. L’utilizzo del certificato rilasciato dalla CA integrata fa sì che la firma sia conosciuta da tutti i computer del dominio. Questo dovrebbe impedire l’esecuzione di script malevoli scritti da persone che non possono firmare digitalmente lo script utilizzando la CA o dovrebbe contribuire all’individuazione dell’autore.

Per attivare questi meccanismi (che peraltro possono essere usati per la firma di altro tipo di codice) ho utilizzato i Certification Services (installati come una CA di livello Enterprise). In questo modo ho una CA “autocertificata” che certifica tutti i certificati rilasciati (e questo mi permette di utilizzare certificati dove voglio all’interno della mia rete) e che sono riconosciuti dalle macchine, dagli utenti e dai software che fanno parte del dominio. Fatto questo ho abilitato il template per il Code Signing usando la console sul server. Sul PC dove voglio firmare lo script richiedo il certificato usando l’apposito plugin per MMC (digitando certmgr.msc si lancia una console con il plugin già caricato per i certificati personali).

A questo punto è possibile firmare il codice. Il resto è storia e ben descritto nell’help della PowerShell (digitate help about_signing). Comunque per farla breve ho dovuto impostare il livello di esecuzione del codice nella shell:

Set-ExecutionPolicy AllSigned

In seguito ho firmato lo script:

$cert = @(dir cert:\\CurrentUser\\My -codesigning)[0]
Set-AuthenticodeSignature .\\mioscript.ps1 $cert

In questo modo ho potuto eseguirlo:

mioscript

Cosa succede se non firmo lo script? PowerShell si rifiuta di eseguirlo. Cosa succede se lo script è firmato con un certificato non noto (cioè un autocertificato o un certificato non facenti parte della stessa catena di autorizzazione)? Il sistema si rifiuta di eseguirlo.

Una nota sulla istruzione dir usata nel codice di cui sopra: utilizza l’accesso ai certificati attraverso un provider per gli store dei certificati.

Questa semplice linea di codice PS ha un pattern che mi è spesso utile: in questo caso particolare serve a cancellare tutti i file con estensione .bak nella directory c:\temp e che non sono stati modificati da 31 giorni:

Get-ChildItem c:\temp\*.bak
| Where-Object { $_.LastWriteTime -lt
($(Get-Date) - $(New-TimeSpan -day 31))}
| Remove-Item

Il nucleo di tutto è nella cmdlet Where-Object che filtra l’output della cmdlet Get-ChildItem (l’equivalente di DIR) prelevando solo ai file che soddisfano la condizione e mandando questi in pasto alla cmdlet Remove-Item (l’equivalente di DEL). Il comando Get-ChildItem ha diversi parametri interessanti come la visita ricorsiva dell’albero delle directory o inclusione ed esclusione di file.

La condizione del filtro Where-Object utilizza l’aritmetica delle date. Il comando $(New-TimeSpan -day 31) produce un TimeSpan di 31 giorni. TimeSpan è una vecchia conoscenza di chi lavora in .NET e rappresenta una differenza temporale. Quindi il comando ($(Get-Date) - $(New-TimeSpan -day 31)) produce la data precente di 31 giorni quella di oggi. Il resto è un semplice confronto con l’attributo che memorizza l’ultimo tempo di scrittura del file.

Il pattern citato all’inizio del post è il seguente

1. dammi una pipe di oggetti
2. seleziona gli oggetti nella per produrre un’altra pipe
3. fai qualcosa con gli oggetti selezionati

Direi che il 90% dei miei comandi di manipolazione “massiva” in PS seguono il pattern descritto. Ci sono poi eccezioni ma solitamente è così anche usando la shell in ambienti “ospiti” diversi dal sistema operativo. Il rimanente 10% si divide in comandi semplici e diretti e in file di script per operazioni più articolate.

Mi domando cosa fa il resto del mondo.