Durante l’installazione di VMware server, gli oltre 2 GB risultanti solo per l’installazione di CentOS sono un pò eccessivi per i requisiti di funzionamento del sistema. Dei tanti applicativi installati, ben pochi sono effettivamente necessari per il corretto funzionamento di VMware Server 2.0.

Dopo qualche prova, sono riuscito a trovare una configurazione di installazione minima che permette di ridurre l’installazione di Linux a poco più di 650 MB.

1. Installazione CentOS minimum
Effettuando l’installazione da DVD, dopo aver impostato partizioni, grub, ip, password, etc., scegliere la configurazione custom in modo da selezionare (deselezionare in questo caso!) i packages non necessari:

Da Customize now -> disabilitare tutto e procedere con l’installazione.

Terminata l’operazione, aggiornare l’OS tramite il comando yum:

# yum update

2.  Installazione packages
Aggiungere ora i packages necessari per il corretto funzionamento di VMware Server:

# yum install kernel-devel xinetd libXtst-devel libXrender-devel perl make httpd

3.  Configurazione di CentOS 
Per evitare problemi di funzionamento, disabilitare SELinux tramite il comando:

# system-config-securitylevel-tui

 Abilitare il servizio httpd poichè è necessario per poter accedere via browser al server vmware:

# chkconfig httpd on
# service httpd start

Per snellire ulteriormente il sistema, è opportuno disabilitare i servizi non necessari. La lista è molto breve poichè grazie all’installazione minima, i servizi installati sono notevolmente ridotti.

Disabilitare quindi ciò che non serve.

# chkconfig netfs off

Se non fosse necessario avere 6 virtual terminals, è possibile disabilitarli editando il file /etc/inittab e marcando quelli che non si vogliono eseguire:

# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
#3:2345:respawn:/sbin/mingetty tty3
#4:2345:respawn:/sbin/mingetty tty4
#5:2345:respawn:/sbin/mingetty tty5
#6:2345:respawn:/sbin/mingetty tty6

In questo caso saranno disponibili 2 sessioni virtual terminals.

 4.  Installazione VMware Server
Effettuare il download del modulo rpm dal sito vmware e procedere alla sua installazione:

# rpm -Uvh VMware-server-2.0.1-156745.i386.rpm

Terminata l’installazione, effettuare la configurazione dell’ambiente Vmware Server tramite il comando:

# /usr/bin/vmware-config.pl

Impostare i parametri in base alle esigenze operative.

VMware è adesso operativo.

- p@olo

Il dover controllare quotidianamente che tutti i sistemi siano perfettamente operativi è uno dei compiti più importanti per un sistemista. Il trascurare un’anomalia può portare a dei risvolti a volte drammatici… morto un disco del server in RAID5, il sistema continua a funzionare ma ovviamente il disco deve essere sostituito al più presto per evitare problemi. Ma se non verifichiamo lo stato degli array dei nostri server… cosa succede se oltre al primo, anche un secondo disco del RAID smette di funzionare?… vi consiglio di non sfidare la sorte…

In reti piccole o con pochi apparati, il controllo periodico si può fare “manualmente” ma se la rete presenta un numero importante di dispositivi “in produzione”, è opportuno utilizzare un qualche sistema di controllo automatico.

Uno strumento molto funzionale è Nagios, un software che permette il monitoraggio completo della rete.
Essendo uno strumento non semplicissimo come setup, sono nati alcuni tools per rendere la sua configurazione un po’ più accessibile… uno di questi che ho trovato utile è NagiosQL, un’interfaccia web che facilita l’impostazione dei parametri di Nagios.

Poichè l’installazione è un po’ lunga, ricordarsi tutti i passaggi necessari per il corretto funzionamento del sistema potrebbe non essere immediato, ecco la procedura che ho adottato per le mie installazioni utilizzando come OS Linux CentOS 5.3.

1. Aggiornamento del sistema
Prima di procedere con l’installazione di Nagios, verifichiamo di avere il nostro Linux aggiornato tramite il comando yum.

# yum update

2. Aggiunta del repository RPMForge
RPMForge è una collaborazione dei più noti packagers (Dag, Dries, etc.) che implementano i moduli rpm delle più note distribuzioni Linux. L’aggiunta di questo repository, ci permette di effettuare l’installazione di Nagios tramite yum.

Verifichiamo innanzitutto quale sia l’ultima release di rpmforge-release all’indirizzo http://dag.wieers.com/rpm/packages/rpmforge-release/ e poi procediamo con la sua installazione.

In una cartella precedentemente creata (/install nell’esempio), scarichiamo l’ultima versione:

# wget http://dag.wieers.com/packages/rpmforge-release/rpmforge-release-0.3.6-1.el5.rf.i386.rpm

Installiamo il modulo rpm appena scaricato:

# rpm -Uvh rpmforge-release-0.3.6-1.el5.rf.i386.rpm

3. Installazione dei componenti richiesti da Nagios + NagiosQL
I componenti richiesti per il corretto funzionamento sono Linux Apache + MySQL + PHP (acronimo LAMP) che installeremo tramite yum:

# yum install httpd mod_ssl php mysql mysql-server php-mysql php-pear

Attiviamo i servizi:

# chkconfig httpd on
# service httpd start
# chkconfig mysqld on
# service mysqld start

4. Installazione Nagios
Installiamo i componenti di Nagios richiesti per il suo funzionamento:

# yum install nagios nagios-devel nagios-plugins nagios-plugins-nrpe

Una volta installato, i componenti di Nagios risiedono in:

• cfg files: /etc/nagios
• web interface files: /usr/share/nagios
• log files: /var/log
• CGI files: /usr/lib/nagios/cgi
• plugins: /usr/lib/nagios/plugins

Per l’utilizzo di plugins che utilizzano il protocollo SNMP (tipo check_hpjd), è necessario installare ed abilitare il daemon net-snmp:

# yum install net-snmp net-snmp-utils
# chkconfig snmpd on
# service snmpd start

5. Configurazione di Apache
Modifichiamo il file di configurazione di Apache impostando come ServerName il nome del nostro host, supponiamo “monitor”:

# vi /etc/httpd/config/httpd.conf

Impostiamo la password per Nagios:

# htpasswd -bcm /etc/nagios/htpasswd.users nagiosadmin password

Digitiamo nel nostro browser l’indirizzo IP del nostro server Nagios per verificare che la pagina sia visualizzata.

6. Installazione componenti NagiosQL
I componenti richiesti da NagiosQL sono i seguenti:

1. Webserver (Apache 1.x o superiore)
2. PHP 5 o superiore
3. MySQL 4.1 o superiore
4. Nagios 2 o superiore
5. PEAR Module: HTML_Template_IT 1.1 o superiore
6. PHP Extension: mysql
7. Javascript enabled nel browser

Installazione template PEAR
L’installazione del template viene effettuata con il comando pear:

# pear install HTML_Template_IT

Installazione NagiosQL
Il file di installazione lo preleviamo tramite il comando e lo copiamo nella directory di appoggio (/install):

# wget https://sourceforge.net/project/platformdownload.php?group_id=134390

Scompattiamo e copiamo i files in /var/www/html:

# tar zxfv nagiosql303.tar.gz
# cp nagiosql3/ /var/www/html/ -R

Directory Structure
Come riportato dal sito di NagiosQL, deve essere creata una struttura di directories come riportato nello schema:

• /etc/nagios

• /etc/nagiosql/hosts
• /etc/nagiosql/services
• /etc/nagiosql/backup
  • /etc/nagiosql/backup/hosts
  • /etc/nagiosql/backup/services

nagios.cfg
Il file /etc/nagios/nagios.cfg deve essere corretto per riflettere la directory structure appena creata.

Creiamo i files a cui facciamo riferimento in nagios.cfg:

# touch /etc/nagiosql/contacttemplates.cfg
# touch /etc/nagiosql/contactgroups.cfg
# touch /etc/nagiosql/contacts.cfg
# touch /etc/nagiosql/timeperiods.cfg
# touch /etc/nagiosql/commands.cfg
# touch /etc/nagiosql/hostgroups.cfg
# touch /etc/nagiosql/servicegroups.cfg

Permessi
Per permettere a NagiosQL di leggere e scrivere i files di configurazione di Nagios, bisogna impostare i permessi di accesso:

- Nagios Main Configuration Files

• # chgrp apache /etc/nagios
• # chgrp apache /etc/nagios/nagios.cfg
• # chgrp apache /etc/nagios/cgi.cfg
• # chmod 775 /etc/nagios
• # chmod 664 /etc/nagios/nagios.cfg
• # chmod 664 /etc/nagios/cgi.cfg

- NagiosQL Configuration

• # chmod 6755 /etc/nagiosql
• # chown apache.nagios /etc/nagiosql
• # chmod 6755 /etc/nagiosql/hosts
• # chown apache.nagios /etc/nagiosql/hosts
• # chmod 6755 /etc/nagiosql/services
• # chown apache.nagios /etc/nagiosql/services

- NagiosQL Backup Configuration

• # chmod 6755 /etc/nagiosql/backup
• # chown apache.nagios /etc/nagiosql/backup
• # chmod 6755 /etc/nagiosql/backup/hosts
• # chown apache.nagios /etc/nagiosql/backup/hosts
• # chmod 6755 /etc/nagiosql/backup/services
• # chown apache.nagios /etc/nagiosql/backup/services

- Impostare i permessi sui files già esistenti

• # chmod 644 /etc/nagiosql/*.cfg
• # chown apache.nagios /etc/nagiosql/*.cfg

- Il file binario Nagios deve essere eseguibile dall’utente di Apache:

# chown nagios.apache /usr/bin/nagios
# chmod 750 /usr/bin/nagios

- l’utente Apache deve poter accedere alla directory /var/www/html/nagiosql3/:

# chown apache:apache /var/www/html/nagiosql3/ -R

L’utente Nagios deve poter scrivere il file di comando nagios.cmd (verificare che in /etc/nagios/nagios.cfgi il parametro check_external_commands sia impostato a 1):

# chown nagios.apache /var/log/nagios/rw/ -R            # se la directory rw non esiste, crearla manualmente.
# chmod 750 /var/log/nagios/rw/ -R

Per verificare se sono necessari ulteriori permessi, eseguire il comando:

# nagios -v /etc/nagios/nagios.cfg

Creazione file ENABLE_INSTALLER
L’installatione wizard di NagiosQL richiede l’esistenza del file ENABLE_INSTALLER in /var/www/html/nagiosql3/install/:

# touch /var/www/html/nagiosql3/install/ENABLE_INSTALLER

4. Installazione NagiosQL tramite Installation Wizard
Nel browser digitare l’indirizzo http://IP_ADDRESS/nagiosql3 per accedere all’installazione guidata:

Dopo aver verificato che la pagina non presenta nessun errore, specificare la password solo del campo “Initial NagiosQL Password“.

Nella pagina successiva viene visualizzato il riepilogo.

Per procedere ulteriormente è necessario rimuovere il file precedentemente creato in /var/www/html/nagiosql3/install/ENABLE_INSTALLER:

# rm /var/www/html/nagiosql3/install/ENABLE_INSTALLER

Cliccando su Finish, si presenta finalmente la pagina di login:

A questo punto l’installazione è terminata. Prima di procedere con la configurazione di Nagios, è necessario effettuare alcune modifiche configurazione di NagiosQL per farlo funzionare correttamente con Linux CentOS. Procediamo in questo modo:

1. effettuare il login a NagiosQL
2. andare su Administration -> Domains
3. editare (Modify) la voce localhost
4. il parametro Nagios command file deve avere il path impostato a /var/log/nagios/rw/nagios.cmd
5. il parametro Nagios binary file deve avere il path impostato a /usr/bin/nagios
6. il parametro Nagios process file deve avere il path impostato a /var/run/nagios.pid
7. cliccare su Save
8. ricordatevi di effettuare sempre il controllo della configurazione di Nagios tramite NagiosQL per essere sicuri che non ci siano errori. Con NagiosQL si utilizza:  Tools -> Nagios Control -> Check configuration files.

A questo punto non ci resta che definire hosts, printers, switches e tutto ciò che vogliamo monitorare.

TROUBLESHOOTING
1.  Tramite il comando  Tools -> Nagios Control -> Check configuration files, viene visualizzato l’errore:

• Error:  Unable to write to temp_path (‘/var/nagios/spool/checkresults’) – Permission Denied
• Error:  Unable to write to check_result_path (‘/var/nagios/spool/checkresults’) – Permission Denied

E’ un semplice problema di permessi. Per il fix procedere così:

# chown nagios.apache /var/nagios/spool/checkresults/ -R
# chmod 774 /var/nagios/spool/checkresults/ -R

2. Viene visualizzato l’errore:

• Nagios Binary found but not executable, please check permissions!

Per risolvere il problema:

# chmod +x /usr/bin/nagios

- p@olo

Utilizzando il comando yum per gli aggiornamenti dei server Linux, durante l’esecuzione del comando yum update si è presentato l’errore TypeError: unsubscriptable object (vedi figura).

Dopo una breve indagine, il problema è stato risolto lanciando il comando yum clean metadata.

Rieseguendo il comando di aggiornamento, il problema non si è più presentato.

Se non dovesse funzionare, provare ad utilizzare il comando yum clean all.

Veloce soluzione che può evitare un forte mal di testa, soprattutto se si verifica ad un server in produzione!

- p@olo

La sincronizzazione in termini di date & time è un aspetto importante per una rete informatica poichè gli aggiornamenti dei clients e soprattutto le autenticazioni basate su Kerberos (Active Directory) sono influenzati da questi parametri. Per questo scopo bisogna appoggiarsi ad un servizio di sincronizzazione affidabile con un un alto livello di precisione limitando al minimo il valore di scarto.

L’I.N.RI.M (Istituto Nazionale di Ricerca Metrologica) fornisce un servizio di sincronizzazione per sistemi informatici collegati alla rete Internet mettendo a disposizione due servers NTP ad accesso libero con i seguenti indirizzi:

• ntp1.inrim.it          (193.204.114.232)
• ntp2.inrim.it          (193.204.114.233)

Configurazione
Per sistemi Linux, il servizio di sincronizzazione viene gestito dal daemon ntpd che ha la sua configurazione nel file /etc/ntpd.conf. Editando questo file vanno inseriti gli indirizzi dei servers di riferimento:

server ntp1.inrim.it      # server primario
server ntp2.inrim.it      # server primario

Nei sistemi Windows per impostare la sincronizzazione, bisogna operare a livello di registro editando la chiave NtpServer:

HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\NtpServer

I parametri possono essere impostati come nomi DNS (in questo caso bisogna aggiungere ,0×1 alla fine di ogni nome DNS) o indirizzi IP.

Per configurazioni avanzate, Internet offre un’ampia documentazione alla quale fare riferimento.

- p@olo

Con il periodo nero dell’economia mondiale, le aziende stanno facendo un massiccio “cost saving” per arginare i bilanci sempre più critici. Purtroppo il settore IT è quello che più ne fa le spese con pesanti tagli sul budget di investimento informatico. Le nuove soluzioni da proporre al management per la gestione e implementazione dei sistemi IT sono per il momento da tenere nel cassetto in attesa di tempi migliori… che fare allora? E’ qui che sta anche la bravura dei sistemisti… trovare soluzioni funzionali risparmiando drasticamente sui costi.

Ed ecco che si riafferma, soprattutto per le PMI, una tecnologia per la gestione clients che, onestamente, ho sempre ritenuto efficace: WSUS. Tecnologia Microsoft, WSUS è una soluzione molto valida per la gestione dei sistemi di rete che permette di mantenere un parco macchine aggiornato limitando notevolmente i costi di implementazione e amministrazione poichè non prevede nessuna licenza di utilizzo.

Definire l’ambiente operativo
Naturalmente per avere questo servizio con determinati standard funzionali, WSUS deve essere opportunatamente configurato in modo da garantire la continuità del servizio (cluster) e prestazioni di rete adeguate (Network Load Balancing) per meglio distribuire il carico del server destinato a svolgere questo ruolo. Per evitare confusione è bene specificare che WSUS in modalità cluster non ha molto senso… è ben più utile per SQL ed Exchange invece.

Prima di procedere con l’installazione di WSUS, bisogna definire l’ambiente operativo per rispettare i termini di continuità e di prestazioni del servizio. Per fare in modo che il servizio sia fault tolerant e per evitare l’overload del server, il database di WSUS (SUSDB) viene “appoggiato” ad un server SQL configurato in modalità cluster mentre WSUS viene installato su un server in modalità NLB. Oggi giorno quasi tutte le aziende sono dotate di uno storage SAN dedicato ai sistemi “core” come Exchange e SQL. Quindi una valida soluzione può essere l’utilizzo di un LUN dedicato del SAN per rendere accessibili in remoto gli aggiornamenti di WSUS.

Requisiti per WSUS
WSUS richiede per la sua installazione i seguenti requisiti:

• IIS 6.0
• Microsoft .NET Framework v2.0 Redistributable Package
• Microsoft Report Viewer Redistributable 2005
• WSUS SP1

Configurare SQL server 2005 per WSUS
Prima di procedere con l’installazione, è necessario configurare il cluster SQL in modo da operare correttamente con quanto richiesto da WSUS.

• L’utente utilizzato per l’installazione di WSUS ha i diritti di amministratore sul Server SQL.
• L’opzione Nested Triggers è attiva (default).
  • Per verificare, aprire SQL Server Management Studio, fare click col tasto destro sul server nell’Object Explorer e selezionare Properties.
  • In Advanced, impostare l’opzione Allow Triggers to Fire Others come True (default) o False.
• Windows Authentication deve essere utilizzata in SQL. WSUS supporta solo questa modalità.
• Il servizio Remote SQL Connections deve essere impostato come TCP/IP only. Ricordarsi di specificare come Remote computer da configurare il nome del server virtuale SQL (sqlcluster nella figura) poichè è configurato come cluster.

• L’account utilizzato per installare il database utilizzato da WSUS (SUSDB) in SQL deve essere presente in Security -> Login.

Registrazione SPN
Un parametro fondamentale per il corretto funzionamento dell’accesso remoto al database SQL è la registrazione del service principal name (SPN) per questo server. Senza questa impostazione, si avranno problemi di autenticazione Kerberos e quindi WSUS non riuscirà a stabilire la connessione con il database e i clients non riusciranno a connettersi.

Per effettuare la registrazione di SPN è necessario il tool setSPN.exe che è presente nei Support Tools di Windows Server 2003. Procedere in questo modo:

1. Installare i Support Tools in un qualsiasi server di dominio e logarsi come Domain Admin.
2. Dal command prompt eseguire:
   • setspn -A MSSQLSvc/<FQDN> <SQL_Service_Account>
   • es. setspn -A MSSQLSvc/sqlcluster sqlservice
3. Dal command prompt eseguire:
   • setspn -A MSSQLSvc/<FQDN>:<Port> <SQL_Service_Account> (port: normalmente è la 1433)
   • es. setspn -A MSSQLSvc/sqlcluster:1433 sqlservice
4. Riavviare il server SQL dopo che la replica AD è stata effettuata.

Per verificare che SPN è stato correttamente registrato, dal command prompt eseguire:

setspn -L <SQL_Service_Account>

E’ possibile verificare o editare questo parametro utilizzando ADSI Editor che è sempre presente nei Support Tools.

Per verificare che SQL stia effettivamente funzionando con l’autenticazione Kerberos, eseguire la seguente query nel server SQL:

select auth_scheme from sys.dm_exec_connections where session_id=@@spid

Il risultato deve riportare KERBEROS, come illustrato nella figura.

Installazione di WSUS
Installare il primo WSUS server in modo da creare il database SUSDB nel server SQL. Dal command prompt eseguire il programma di installazione:

WsusSetup.exe SQLINSTANCE_NAME=server\instance

Se viene utilizzata l’istanza di default di SQL, specificare solo il nome del server. Per installare altri WSUS front-end servers, eseguire dal command prompt:

WsusSetup.exe /q FRONTEND_SETUP=1 SQLINSTANCE_NAME=server\instance CREATE_DATABASE=0 DEFAULT_WEBSITE=0

Viene installato solo il front-end di WSUS connesso al database SUSDB (precedentemente creato) nel cluster SQL con la porta web impostata su 8530. Una volta terminata l’installazione, l’applicazione richiede la definizione dei parametri operativi (proxy, prodotti, etc.).

Configurare l’area di sharing
Poichè più front-end devono accedere gli stessi contenuti, una buona soluzione può essere l’utilizzo di un LUN dedicato dello storage SAN per salvare i contenuti di WSUS. Naturalmente una qualsiasi area condivisa (Network Share, DFS) è adatta allo scopo.

Appoggiandosi ad un SAN, è necessario installare Microsoft iSCSI nei servers utilizzati per WSUS NLB per assegnare l’area condivisa definendo il disco dedicato (nella figura è indicato come W:\).

Spostare il contenuto di WSUS nell’area di share
Per spostare il contenuto delle directories di sistema di WSUS nell’area di share (SAN in questo caso), è necessario spostare il contenuto dalle directories locali tramite il comando:

cd \Program Files\Update Services\Tools\
wsusutil movecontent sharename logfilename (es. wsusutil movecontent W:\ movelogresult)

Il risultato, come illustrato nella figura, è la creazione delle directories con gli aggiornamenti di WSUS.

Configurare IIS per i servers front-end
Per accedere agli aggiornamenti nell’area condivisa, i servers WSUS front-end devono avere IIS configurata opportunamente per permettere l’accesso remoto.

Tramite IIS Manager, impostare l’accesso all’area condivisa.

Configurare NLB
A questo punto è finalmente possibile configurare NLB. Poichè la documentazione in Internet su come implementare NLB è ampia e facilmente reperibile, non viene illustrata in questo articolo.

Terminata la procedura, effettuiamo un check per verificare che NLB sta funzionando. Dal command prompt eseguire il comando nlb query.

Verificati che gli hosts coinvolti in NLB hanno uno stato CONVERGED, il cluster NLB è operativo e funzionante.

Configurare WSUS clients
Poichè i clients sono generalmente configurati tramite GPO, il parametro utilizzato per identificare l’Intranet update service location deve essere l’indirizzo del Web virtuale (nlbcluster). nlbcluster è il DNS name del cluster NLB.

Testare WSUS
Naturalmente prima di mettere in produzione il servizio WSUS con questa configurazione, è opportuno testare il tutto con pochi clients o meglio in un ambiente di LAB per evitare spiacevoli sorprese e forti mal di testa.

- p@olo

Da qualche giorno uno dei server SBS 2003 notificava un alert inerente ad un uso eccessivo di memoria da parte di un qualche processo.

L’alert riportava il messaggio:
“A large amount of memory is committed to applications and processes. Consistently high memory usage can cause performance problems.
To determine which processes and applications are using the most memory, use Task Manager. Monitor the activity of these resources over a few days. If they continue to use a high level of memory and are less critical processes or services, try stopping and then restarting them.
You can disable this alert or change its threshold by using the Change Alert Notifications task in the Server Management Monitoring and Reporting taskpad.“

Analizzando il Task Manager, ho notato dei processi sqlservr.exe che hanno attirato la mia attenzione. Abilitando la visualizzazione del PID (non visibile da default), ho preso nota dei numeri associati a questi processi.

Per verificare quale istanza SQL fosse la causa dell’uso eccessivo di memoria, ho identificato tramite il comando tasklist /svc eseguito dal command prompt l’istanza associata ai PID precedentemente annotati.

In questo caso, il PID 1888 associato all’istanza MSSQL$SBSMONITORING è la causa che genera questo alert. Per ridefinire la quantità massima di memoria utilizzabile dall’istanza, dal command prompt ho eseguito questi comandi:

• C:\> osql -E -S nomeserver\SBSMONITORING
• 1> sp_configure ’show advanced options’,1
• 2> reconfigure with override
• 3> go
  DBCC execution completed. If DBCC printed error messages, contact your system administrator.
  Configuration option ’show advanced options’ changed from 0 to 1. Run the RECONFIGURE statement to install.
• 1> sp_configure ‘max server memory’,100
• 2> reconfigure with override
• 3> go
  DBCC execution completed. If DBCC printed error messages, contact your system administrator.
  Configuration option ‘max server memory (MB)’ changed from 2147483647 to 100. Run the RECONFIGURE statement to install.
• 1>

Una volta terminata la procedura, tramite il Task Manager ho verificato l’utilizzo di memoria del processo “incriminato” (PID 1888) e il valore si era ridotto alla soglia impostata.

Dopo questo intervento, l’alert non è più comparso.

- p@olo

Una delle mille difficoltà che i sistemisti incontrano sempre più di frequente durante la fase di studio e sviluppo di nuove soluzioni, è l’implementazione dell’ambiente LAB per effettuare i test che si avvicini alla topologia di rete reale.

Simulare un ambiente Active Directory completo, ad esempio, con sistemi cluster, NLB, due o più Domain Controllers, alcuni FPS… richiede l’utilizzo di diversi sistemi. Ovviamente è impensabile comprare o reperire tutto l’hardware necessario perchè sarebbe, oltre che economicamente proibitivo, ingestibile all’interno di un ufficio o addirittura in casa. Fortunatamente la virtualizzazione ci viene incontro…

Grazie alla tecnologia della virtualizzazione (io utilizzo l’ormai consolidato software della VMware) è possibile “costruire” una rete con tutte le componenti richieste. E’ necessario però configurare il sistema di virtualizzazione in modo che possa sostenere il carico di lavoro fornendo prestazioni accettabili per l’ambiente LAB.

Dopo vari esperimenti, la combinazione hardware e software che mi permette di effettuare i miei studi e test con prestazioni accettabili investendo una cifra fattibile, si compone dei seguenti sistemi:

PC 1 – VMware Desktop

Hardware

• Motherboard: Asus Rampage Formula
• CPU: Intel Q9400 Core 2 Quad 2.66GHz 8MB cache
• RAM: Kingston 8GB DDR2 800MHz high speed
• HDD: Seagate 2×750GB SATA II 32MB cache 7200 rpm RAID 1
• Video: Asus ATI Radeon HD3850 PCI-E 2.0 512MB
• Power Supply: Enermax Liberty ELT400AWT 400W

Software

• OS: Linux CentOS 5.2
• VM: VMware workstation 6.5.1
• SAN: Openfiler 2.3

PC 2 – VMware ESX 3.5 Upd2

Hardware

• Motherboard: Gigabyte Mini ATX
• CPU: Intel Pentium D930 3.0GHz
• RAM: Kingston 2GB DDR2 667MHz
• NIC: 2 x Intel PRO 1000 GT
• HDD: Seagate 500GB SATA II 7200 rpm

Software

• OS: VMware ESX 3.5 Upd2

La rete è configurata con 3 subnets distinte :

1. Public LAN
2. Heartbeat/Private (utilizzate per cluster e NLB)
3. SAN (utilizzata solo per gli accessi al SAN)

Con questa configurazione HW/SW, riesco a simulare in maniera accettabile gli ambienti che più utilizzo:

• Microsoft AD, Cluster, NLB (1 SAN, 2 DCs, 2 PC cluster, 2 NLB, 2 FPS, 2 Clients).
• VMware Virtual Infrastructure (1 ESX server 3.5, 1 SAN Openfiler).

Naturalmente il tutto deve essere inteso come un ambiente dinamico in continua evoluzione: l’hardware e il software cambiano ogni giorno e man mano che i prezzi si abbassano, i componenti hardware più performanti diventano accessibili senza svenarsi (si sa che l’hardware è già obsoleto anche dopo un solo mese!)…

Naturalmente questa è la configurazione basata sulle mie esigenze e sul budget disponibile… si sa che la fantasia non ha limiti!

- p@olo

Un ulteriore modo per rafforzare la sicurezza di un sistema Linux contro accessi non autorizzati è l’utilizzo della chiave pubblica (public key) durante la fase di login.

Vantaggi

• Elevato grado di sicurezza nel processo di autenticazione.
• Solo gli utenti con la chiave corretta possono autenticarsi nel sistema.
• Ogni chiave può essere protetta da password (ulteriore protezione).

Svantaggi

• Senza la giusta chiave non c’è modo di autenticarsi e quindi di accedere al sistema.
• La gestione delle chiavi può risultare laboriosa.

PROCEDURA

- generare la coppia di chiavi pubblica e privata.
ssh-keygen -t rsa

La chiave privata viene salvata nel file id_rsa.
La chiave pubblica viene salvata nel file id_rsa.pub.

- creare la directory nascosta .ssh nella home user.
mkdir ~/.ssh

- copiare la chiave pubblica nel file authorized_keys.
cat id.rsa.pub > ~/.ssh/authorized_keys

- impostare i permessi sul file per evitare che altri utenti possano leggere i dati della chiave.
chmod go-w ~/
chmod 700 ~/.ssh
chmod go-rwx ~/.ssh

- editare il file sshd_conf (deve essere effettuato come root).
su -
vi /ets/ssh/sshd_conf

- identificare e modificare i parametri come indicato.

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no

- riavviare il servizio ssh per attivare la nuova configurazione
service sshd restart

Una volta effettuato il restart del servizio ssh, l’unico modo per effettuare un login remoto è tramite l’utilizzo delle chiavi generate.

Per generare la chiave pubblica e privata è possibile utilizzare anche altri tools come ad esempio puttygen, membro della famiglia puTTY e soggetto a licenza MIT compatibile con la GNU GPL.

- p@olo

Una volta implementato il servizio RMS, è fondamentale che tutte le componenti siano pienamente funzionanti onde limitare al minimo il rischio di failures del sistema e quindi di accesso ai documenti protetti.

CONFIGURAZIONE
Per un funzionamento ottimale di RMS, seguire alcune semplici regole può evitare dei forti mal di testa…

• Il servizio RMS non dovrebbe risiedere su domain controllers o Exchange servers onde evitare il workload dei sistemi con conseguenti rallentamenti dei servizi svolti.
• Nel DNS, è opportuno creare un CNAME alias dell’URL definito nell’SCP (Service Connection Point) anzichè il nome del server perchè nel caso di una sostituzione del server o cambio dell’IP del server stesso, il servizio continua a funzionare e non viene interrotto (in configurazione cluster). Si possono utilizzare più CNAME dello stesso url che puntano su diversi servers.

• Utilizzare un servizio web (IIS) dedicato solo per RMS.
• I certificati per la protezione dei documenti vengono emessi basandosi sull’indirizzo e-mail dell’account. Verificare che ad ogni account venga attribuito un indirizzo e-mail.
• Per generare il certificato è meglio utilizzare il nome del cluster.
• E’ fortemente consigliato che il servizio RMS e il database SQL risiedano fisicamente su due servers diversi. Un server SQL generalmente dovrebbe essere configurato in maniera da garantire tempi minimi di ripristino in caso di crash (cluster, backup). Da non dimenticare che tutte le info, certificati e configurazioni risiedono nel database SQL.
• Per attivare SCP (registrare l’url in Active Directory) sono richiesti i diritti di Enterprise Admin. Se l’SCP è stato precedentemente registrato e devo re-installare da zero il servizio RMS, SCP va rimosso.

RIMUOVERE SCP
Per rimuovere l’SCP, si può procedere tramite la console grafica Windows RMS Administration.

Un altro metodo per effettuare l’operazione è tramite lo snap-in ADSIEDIT.MSC (si trova nei Support Tools in W2K3) connettendosi alla Configuration naming context. Aprire il nodo cn=Services e cancellare il nodo cn=RightManagementService che rimuoverà il Service Connection Point. Attenzione ad utilizzare questo tool.

Come alternativa è possibile utilizzare il DRM Toolkit lanciando il comando ADSCPRegister:

ADSCPRegister unregisterscp https://my_domain/_wmcs/Certification

Il comando ADSCPRegister permette la registrazione dell’SCP in Active Directory. E’ utile nel caso non si abbiano sufficienti diritti in AD: mando l’istruzione all’Enterprise Admin per farla eseguire ed effettuare quindi la registrazione. Evito inoltre che altri accedano al server.

SOSTITUIRE IL SERVER RMS
Se ci troviamo nella situazione di dover sostituire un server impiegato per il servizio RMS (hardware obsoleto, upgrade, etc.), l’operazione è semplice in quanto è sufficiente installare un nuovo server nel cluster e rimuovere il vecchio.

• Una volta configurato il nuovo server, questo deve essere aggiunto nel cluster.
• Nel vecchio server da rimuovere deve essere fatta l’operazione di unprovisioning (riduzione del numero dei servers nel cluster) che ne azzera la configurazione.
• Il CNAME precedentemente impostato nel DNS deve essere aggiornato per far puntare l’URL al nuovo server.
• Aggiornare l’eventuale load balancing se impostato.

RIMUOVERE IL SERVIZIO RMS
Se spengo il server RMS, tutti i documenti protetti non sono più accessibili. Per la corretta rimozione del servizio RMS deve essere effettuata l’operazione di decommisioning per ripristinare l’accesso ai documenti. Tutti i servers coinvolti devono essere messi in questo stato.

Quando il server è in uno stato di decommissioning, solo le use licenses vengono fornite. Per rimuovere tutte le protezioni è quindi sufficiente aprire il documento protetto e poi salvarlo.

Questa procedura è utile nel caso il progetto pilota non venga approvato.

BACKUP E DISASTER RECOVERY
Tutte le informazioni, configurazioni e licenze (chiave pubblica e privata) di RMS risiedono nel database SQL, quindi il backup del database è fondamentale. SQL dovrebbe garantire un sistema di fault tolerance (cluster) per evitare blocchi del servizio e naturalmente una strategia di backup adeguata in base all’utilizzo del servizio.

Stesso discorso vale per il server RMS il quale deve essere adeguatamente protetto contro potenziali failures. Per questo scopo possono essere utilizzati sistemi di ripristino come Ghost, Symantec BackupExec o altri per effettuare un veloce ripristino del server.

L’utilizzo di una configurazione cluster (2 front-end) evita il blocco del servizio a patto che il database sia sempre accessibile e funzionante.

- p@olo

L’aspetto della sicurezza dei dati aziendali è ormai recepito come un fattore vitale per il business svolto anche dalle persone predisposte ad autorizzare “spese informatiche” che spesso non hanno un bagaglio tecnico adeguato alle spalle. La sicurezza di una rete non deve essere curata solo ed unicamente per le intrusioni dall’esterno, ma la protezione dei documenti da chiunque non sia autorizzato all’uso è un aspetto generale.

Nel mercato sono presenti diverse tecnologie per la protezione dei documenti più o meno efficienti, più o meno complesse e più o meno costose. Cosa adottare per l’azienda dipende principalmente dalle esigenze specifiche e anche dalle risorse tecnico/finanziarie disponibili.

Già sul mercato da qualche hanno, Microsoft ha introdotto una soluzione per rafforzare la sicurezza della rete mirata alla protezione dei documenti tramite il servizio Rights Management Service (RMS). RMS introdotto per la versione Windows Server 2003, è una tecnologia per la protezione dei documenti ed e-mails con applicazioni abilitate al servizio RMS per favorire la salvaguardia delle informazioni digitali da un uso non autorizzato.

In Windows Server 2008, RMS è già incluso ed è stato rinominato in Active Directory Rights Management Services per riflettere un più alto livello di integrazione con Active Directory.

PERCHE’ RMS

• Sistemi basati su ACL ed Encryption come EFS, ad esempio, non sono efficaci se il file viene spostato dalla partizione NTFS (copiato su un floppy, CD, USB pen).
• Documenti protetti con password possono essere facilmente craccati.
• Se assegno i diritti READ ONLY ad un documento, l’operazione di copia & incolla del contenuto in un altro documento non può essere bloccata.
• Se il dispositivo che contiene i documenti viene perso o rubato, il contenuto può essere accessibile a chiunque.
• RMS rende lo scambio della documentazione interna ad un’azienda più sicura.
• RMS è FIPS compliant.
• E’ un service che non necessita costi aggiuntivi per la licenza.

COSA FA RMS

• Tutti i documenti ed e-mails che si appoggiano a RMS sono criptati.
• La crittografia rimane allegata al file mentre sistemi come EFS proteggono i documenti solo se fisicamente salvati sulla partizione NTFS.
• A differenza di EFS, RMS lavora anche con i gruppi AD per l’assegnazione dei diritti.
• E’ possibile assegnare diverse tipologie di protezione a documenti ed e-mails: read only, modify, copy, print, forwarding, etc.

I LIMITI DI RMS

• In termini di sicurezza, il solo RMS non garantisce il grado più alto di protezione rispetto alla tecnologia PKI, ma scoraggia e rende più complicati eventuali tentativi di intrusione.
• Non protegge i documenti da foto, registrazioni vocali e screen capturing tools diversi da Microsoft.

I REQUISITI

Per il funzionamento di RMS server sono richiesti i seguenti componenti:

• Windows Server 2003
• Active Directory
• SQL server 200x
• ASP.Net
• Message Queuing
• IIS
• RMS server SP2 (solo per la versione 2003, nella versione 2008 è già incluso)

Per il funzionamento di RMS client i requisiti sono i seguenti:

• Office 2003, 2007 Professional – per pubblicare i documenti (publish)
• Office 2003, 2007 Standard – per accedere documenti (consume)
• RMS client SP2 (solo per Office 2003)
• RMS add-on (solo per Internet Explorer 6.0) – permette di accedere ai documenti protetti senza avere Office installato.

La distribuzione dell’RMS client può essere effettuata tramite GPOs, SMS o manualmente.

LA TOPOLOGIA RMS

Il core system è composto da un server RMS (licensing server) che gestisce le licenze per effettuare il publishing e consuming (protezione e accesso) dei documenti e un server SQL che gestisce i tre databases creati da RMS: Configuration, Directory Services e Logging.

La perdita del licensing server non compromette la funzionalità del servizio RMS mentre la perdita o danneggiamento del database RMS comporta un danno talvolta irreversibile nel recupero dei documenti. Per questo motivo è fortemente consigliabile tenere l’RMS e il database SQL su servers diversi .

A seconda della struttura di rete, i licensing servers possono essere distribuiti su varie locazioni nel caso di linee lente, un workload eccessivo, etc.

RMS è implementato a livello di forest nell’AD quindi tutti i domini membri possono beneficiare di questo servizio. Due forests possono utilizzare lo stesso servizio RMS stabilendo una trust relationship.

NOTE
RMS è molto funzionale, relativamente semplice da implementare e soprattutto è un servizio aggiuntivo che non comporta nessun costo in termini di licenze.

Per affermare un progetto di questo tipo presso un’azienda o al management dove implica un “piccolo” stravolgimento della rete presente non sempre è un’impresa semplice. La presentazione deve fare leva sugli aspetti chiave della sicurezza e deve essere supportata da una demo ben fatta in modo da mostrare l’utilizzo pratico e i benefici per l’azienda anche a chi tecnicamente non è ferrato. Far cambiare certe abitudini può a volte essere più complicato che implementare un sistema come RMS:-)…

- p@olo