Ricerche IT

Panoramica

Nel precedente articolo riguardante la posta elettronica su Linux (le cui avvertenze valgono anche per il presente post), è stato creato un mail server in grado di gestire un unico dominio di posta. Accade però piuttosto spesso di dover gestire più domini di posta, per cui, o si installa un mail server per ogni dominio (cosa che avrebbe un senso solo in caso di alto traffico), oppure, si fanno convivere sullo stesso server di posta più domini, che in caso di realtà medio-piccole è la soluzione ideale. Un’altra casistica non contemplata nel precedente articolo riguarda le liste di distribuzione, cioé la possibilità di avere un indirizzo di posta che recapiti il messaggio ricevuto su più caselle postali. Per questi test faremo riferimento all’ambiente di test descritto in precedenza, dove verrà utilizzato il mail server di test Titano, il quale gestisce il dominio urano.mail; tenere presente che dobbiamo creare le zone DNS relative ai domini virtuali utilizzati nel server DNS Windows Server 2003 DCServer.

Alias e domini virtuali

Per poter gestire la posta di più domini, è necessario definire, oltre al già citato urano.mail (indicato nella direttiva mydestination del file di configurazione /etc/postfix/postfix.conf) che sarà il dominio locale, anche i cosidetti domini virtuali, che corrispondono ai domini che dovremo gestire. A questo punto, è utile distinguere i domini locali dai domini virtuali: nel nostro caso, abbiamo un dominio locale, urano.mail, in cui, ad ogni utente creato sul sistema, corrisponde una casella di posta elettronica; in questo contesto, l’utilizzo di un dominio virtuale, ci consente di definire degli indirizzi di posta con dominio diverso da quello locale, che vengono mappati su una casella di posta elettronica del dominio locale, e che vengono quindi definiti alias virtuali.

Supponiamo, ad esempio, che il nostro mail server debba gestire i domini virtuali miranda.mail, ariel.mail e umbriel.mail; per farlo, dovremo dire a Postfix che intendiamo agire da server SMTP anche per questi domini, come mostrato di seguito:

virtual_alias_domains = miranda.mail ariel.mail umbriel.mail

Ora, dobbiamo inserire nel file di configurazione di Postfix (main.cf) il percorso del file in cui è contenuta la mappa con gli alias virtuali, in cui, ad una casella di posta locale, corrispondono uno o più indirizzi appartenenti ai domini virtuali definiti poc’anzi:

virtual_alias_maps = hash:/etc/postfix/virtual

Definito il file della mappa degli alias virtuali, dobbiamo creare il file stesso ed editarlo:

touch /etc/postfix/virtual
nano /etc/postfix/virtual

Il file va creato seguendo uno stile preciso, come mostrato di seguito:

h.mallow@miranda.mail       hober.mallow@urano.mail
s.hardin@ariel.mail         salvor.hardin@urano.mail
p.palver@umbriel.mail       preem.palver@urano.mail
s.gendibal@umbriel.mail     stor.gendibal@urano.mail

Come si può vedere, nella colonna sinistra del file mettiamo gli alias virtuali, mentre nella colonna di destra, indichiamo a quale utente di sistema va recapitata la posta indirizzata a quello specifico alias virtuale. Ora dobbiamo creare la mappa vera e propria, tramite la “compilazione” in formato binario del file /etc/postfix/virtual, con il comando postmap:

postmap /etc/postfix/virtual

che creerà il file /etc/postfix/virtual.db che sarà quello effettivamente usato da Postfix per l’interrogazione degli alias virtuali.

Così facendo, se spediamo ad esempio una mail a s.hardin@ariel.mail, questa verrà depositata fisicamente nella casella di posta salvor.hardin@urano.mail; ciò in alcune situazioni può andare bene, ma in altre situazioni, questo stato di cose potrebbe non andarci a genio, come in quei casi in cui vogliamo che le caselle di posta dei domini virtuali siano trattate come mailbox a sé stanti, e non legate agli utenti di sistema. Postfix permette di gestire anche queste casistiche, tramite le mailbox virtuali, che verranno esaminate in un articolo successivo.

Liste di distribuzione tramite alias virtuali

Tramite gli alias virtuali è possibile creare anche liste di distribuzione, ovvero indirizzi di posta elettronica virtuali che servono per reindirizzare i messaggi ricevuti dall’alias virtuale stesso agli indirizzi di posta specificati come destinatari del messaggio.

Vediamo un esempio: aggiungiamo una riga al file /etc/postfix/virtual come mostrato di seguito:

oratori@umbriel.mail        p.palver@umbriel.mail, s.gendibal@umbriel.mail

Come già specificato, sulla sinistra compare l’alias virtuale, sulla destra compaiono gli indirizzi di posta a cui vogliamo reindirizzare i messaggi ricevuti sull’indirizzo oratori@umbriel.mail; da notare che i diversi indirizzi devono essere separati da una virgola, e che, in questo caso i membri della lista di distribuzione sono a loro volta alias virtuali, ma potrebbero essere tranquillamente utenti di sistema.

Salvato il file, dobbiamo ricompilare il file /etc/postfix/virtual in questo modo:

postmap /etc/postfix/virtual

Ora possiamo testare il corretto funzionamento della lista di distribuzione, e se tutto va bene, inviando un messaggio all’indirizzo oratori@umbriel.mail, il messaggio arriverà ai due indirizzi p.palver@umbriel.mail e s.gendibal@umbriel.mail, i quali, essendo alias, non hanno una propria casella di posta e quindi il messaggio finirà effettivamente nelle caselle di posta preem.palver@urano.mail e stor.gendibal@urano.mail.

Conclusioni

In questo articolo abbiamo apportato qualche miglioramento al nostro server di posta basilare, ora possiamo gestire più domini sulla stessa macchina e possiamo gestire liste di distribuzione all’interno della nostra organizzazione. I metodi utilizzati possono essere utilizzati in piccole realtà, ma per ambienti più complessi, è bene utilizzare altre metodiche per raggiungere gli stessi risultati, che verranno illustrate in altri articoli sull’argomento.

Avvertenza

Questo articolo è stato redatto a scopo didattico e di test, per cui, si sconsiglia fortemente di adottare questa configurazione in ambiente di produzione, poiché non fornisce i necessari requisiti di sicurezza, a causa del tipo di installazione trattata e NON dei prodotti utilizzati.

Panoramica

In questo articolo verrà trattata l’installazione basilare di un server di posta elettronica su un server Debian Etch. La configurazione proposta rispecchia quella trattata nell’ambiente di test precedentemente descritto, dove verrà preso come server di posta il server Titano, il quale ha l’indirizzo IP 192.168.1.11 e su cui verrà configurato il dominio di posta urano.mail. I prodotti scelti per questa installazione di test sono Postfix, che funge da MTA ed espone il servizio SMTP, e Dovecot, che verrà utilizzato per esporre i servizi POP3 ed IMAP4, per far sì che gli utenti della rete possano consultare la propria posta elettronica. Lo scambio di e-mail avverrà con il server Exchange DCServer (dominio giove.mail) e con il server Linux Giapeto (dominio saturno.mail), il quale verrà configurato allo stesso modo del server Titano.

Cenni teorici

In questo articolo, verranno usati software che permettono la trasmissione e la ricezione di messaggi di posta elettronica. Per scambiare i messaggi tra i vari mail server, il protocollo usato sulla rete Internet è SMTP (Simple Mail Transfer Protocol), il quale, come dice il nome, è responsabile della trasmissione, e ricezione, dei messaggi di posta elettronica tra server di posta. Il server SMTP passa il messaggio ricevuto al Mail Delivery Agent (MDA), che spesso diventa un Local Delivery Agent (LDA), il quale si occupa di depositare il messaggio nella casella di posta elettronica dell’utente locale.

L’archiviazione del messaggio ricevuto, per quanto concerne il mondo Linux / Unix, può avvenire principalmente in due formati, mbox e maildir. Mbox ha la peculiarità di archiviare tutti i messaggi di posta elettronica in un unico file per ogni utente, mentre maildir crea un file per ogni messaggio ricevuto. Entrambi i sistemi presentano vantaggi e svantaggi in termini di flessibilità e prestazioni; a mio parere lo svantaggio principale di mbox è il fatto che, usando un unico file monolitico per ogni casella, in caso di problemi si rischia di perdere l’intero contenuto della casella stessa, cosa che diventa molto più difficile utilizzando maildir.

Un MTA ha il compito di movimentare i messaggi di posta, ma non è in grado di presentarli in una qualche forma all’utente finale. Per raggiungere lo scopo, bisogna installare un server POP3 e/o IMAP4, protocolli che permettono di poter presentare i messaggi di posta in un formato riconoscibile ad una applicazione client installata sull’host dell’utente finale, chiamata client di posta elettronica o Mail User Agent (MUA). POP3 è un protocollo piuttosto datato che consente appunto la lettura della posta elettronica tramite un Mail User Agent, il quale normalmente si connette al server POP3 e scarica i messaggi cancellandoli dal server; tale comportamento è d’ostacolo per quegli utenti che debbono consultare la posta da diverse posizioni, oppure per quegli utenti che condividono l’utilizzo di una mailbox. Per ovviare a questi problemi, esiste il protocollo IMAP4, che mantiene i messaggi di posta sul server, in modo tale da metterli a disposizione a prescindere dalla posizione dalla quale ci si connette; inoltre, mantiene una connessione permanente tra client e server, con i vantaggi del caso, rendendosi quindi il protocollo da scegliere per utilizzi professionali del servizio di posta elettronica.

Nel nostro caso, useremo Postfix come MTA, archiviando la posta nel formato maildir, quindi utilizzeremo Dovecot come server IMAP e POP3 e Outlook e Windows Mail come MUA.

Installazione e configurazione di Postfix

Per installare i software che ci servono, utilizzeremo i pacchetti .deb della distribuzione, in modo da mantenere un ambiente coerente, rinunciando però alle ultime versioni dei software (che è la filosofia di Debian, orientata alla stabilità ed alla sicurezza). Riguardo all’installazione di Postfix, basta un semplice:

apt-get install postfix

che richiede di specificare che tipo d’installazione di Postfix effettuare, noi sceglieremo “Sito Internet”, senza specificare uno smart host, poiché, nell’ambiente di test, non è necessario spedire mail al “mondo reale”:

Figura 1 - Scelta installazione Postfix

dopodiché, ci verrà richiesto il dominio da utilizzare per la posta elettronica, noi indicheremo il dominio urano.mail, come mostrato in figura 2:

Figura 2 - Scelta del dominio

Ora Postfix è installato, si tratta di fare qualche piccolo aggiustamento alla configurazione. Per prima cosa, abilitiamo la rete LAN del server Titano a mandare posta tramite il nostro MTA aggiornando il parametro mynetworks nel file di configurazione /etc/postfix/main.cf, che diventerà così:

mynetworks = 127.0.0.1/8 192.168.1.0/24

Quindi aggiungiamo due parametri, che indicano la directory di spooling delle mail e il formato di archiviazione dei messaggi delle mailbox, scegliendo Maildir, che creerà una directory Maildir per ogni home directory presente sul sistema:

queue_directory = /var/spool/postfix
home_mailbox = $HOME/Maildir/

Fatto questo, chiudiamo e salviamo il file /etc/postfix/main.cf, quindi possiamo far ripartire Postfix tramite il comando:

/etc/init.d/postfix restart

Ora, possiamo creare gli utenti di sistema, che fungeranno anche da mailbox per il server di posta. Gli utenti non hanno bisogno di un accesso shell, per cui verrà fornita loro la shell /bin/false, e faranno parte del gruppo mail:

useradd -m -g mail -s /bin/false salvor.hardin
useradd -m -g mail -s /bin/false hober.mallow

Ora possiamo provare a mandare una mail da un client di posta già configurato nell’ambiente di test all’indirizzo salvor.hardin@urano.mail, se tutto va come deve andare, dando il seguente comando

ls -l /home/salvor.hardin/Maildir/new

dovremmo vedere un file, ed aprendolo con un editor di testo, è possibile leggere il contenuto che altri non è che il testo della mail precedentemente inviata, comprese le intestazioni. A questo punto possiamo considerare terminata la configurazione di Postfix.

Installazione e configurazione di Dovecot

Per verificare il corretto funzionamento di Postfix, abbiamo consultato il file system del server Titano, ma per un utente “normale”, la cosa è alquanto scomoda. Si impone quindi l’installazione di un server POP3 - IMAP che consenta ad un qualsiasi client con installato un MUA di consultare la posta elettronica. La nostra scelta ricade su Dovecot, il quale ha la simpatica caratteristica di cercare di rendere semplice la propria configurazione e di supportare entrambi i formati di archiviazione della posta più diffusi, mbox e maildir. Per installare Dovecot ricorriamo al solito apt:

apt-get install dovecot-common dovecot-popd dovecot-imapd

Fatto questo, come per Postfix, anche con Dovecot dovremo fare qualche piccola modifica al file di configurazione, il cui percorso è /etc/dovecot/dovecot.conf. Per prima cosa, andremo a specificare quali protocolli rendere disponibili con Dovecot, impostando in questo modo la direttiva protocols:

protocols = imap imaps pop3 pop3s

Scendendo poco più giù nel file di configurazione, configureremo Dovecot in modo tale che accetti le password inviate dal client come testo in chiaro (ciò non è molto sicuro ma ci aiuta a semplificarci la vita in questo ambiente di test), impostando questa direttiva:

disable_plaintext_auth = no

Ora dobbiamo impostare il percorso in cui si trovano le caselle di posta ed il formato in cui sono archiviati, nel nostro caso maildir:

mail_location = maildir:~/Maildir

Il resto del file può essere lasciato invariato, quindi salviamo il file e riavviamo il demone Dovecot, tramite il solito

/etc/init.d/dovecot restart

dopodiché possiamo testare il nostro server IMAP configurando un qualsiasi MUA che supporti il protocollo IMAP; io ad esempio, per velocità, ho testato Windows Mail, il client di posta predefinito di Windows Vista, che funziona senza problemi con il server IMAP Dovecot senza bisogno di accorgimenti particolari, se si esclude il fatto che a prima vista sembra non comparire la cartella Posta in arrivo; in questo caso, basta sottoscrivere la cartella Posta in arrivo, la quale comparirà immediatamente rendendo possibile leggere i messaggi presenti nella casella di posta in oggetto.

Considerazioni personali sui MUA per Windows

Siccome, per i miei test, avevo a disposizione Windows Mail, ho utilizzato quello. Ho testato altri client di posta, cominciando da Microsoft Outlook (quello compreso nella suite Office, per intenderci), ed i risultati sono stati sconfortanti. Utilizzando Outlook 2003 per connettermi in IMAP sul server di posta, per prima cosa sul server vengono create solo le cartelle Posta in arrivo e Posta indesiderata, per cui, tra le altre cose, non viene creata la cartella Posta inviata; se anche creiamo la cartella Posta inviata a mano, con Outlook 2003 non c’è modo di archiviare la posta inviata nella cartella sul server.

Inizialmente, non usando praticamente mai IMAP, pensavo che fosse un mio problema, invece, surfando sul Web, ho potuto constatare che si tratta di una “caratteristica” di Outlook, che è aggirabile solamente creando una regola ad hoc. Per me tutto ciò è delirante. Si comporta leggermente meglio invece Outlook 2007, che ha gli stessi difetti di Outlook 2003, ma il cui comportamento relativamente alla posta inviata è modificabile in modo semplice agendo sulla configurazione dell’account di posta. In questo articolo del blog ilcava.it è descritto come procedere in questi casi. Da quanto ho potuto vedere io, anche con Outlook 2007 la cartella Posta inviata va creata a mano.

A questo punto ho voluto provare anche Thunderbird per Windows, che si comporta decisamente meglio, infatti, basta configurare normalmente un account di posta, che crea solamente le cartelle Posta in arrivo e Cestino, ma al primo invio di un messaggio, viene creata automaticamente sul server la cartella Posta inviata, così come viene creata una cartella Drafts se si salva un messaggio come bozza. Come già segnalato, Windows Mail si comporta piuttosto bene con IMAP.

Non ho provato alcun MUA per Linux, ma immagino che non diano particolari problemi.

Se qualcuno tra i lettori ha qualche suggerimento relativamente a quanto scritto con l’utilizzo di Outlook con IMAP, ed in particolare dell’interazione tra Outlook e Dovecot, i commenti sono a disposizione.

Conclusioni

Dopo aver testato con successo il corretto funzionamento di Postfix e Dovecot, possiamo ritenere conclusi, per il momento, i nostri test. Come scritto nell’avvertenza all’inizio dell’articolo, questa configurazione è adatta solamente a scopi (auto)didattici, poiché, configurando in questo modo un server di posta, non abbiamo nessuna protezione contro i virus, contro lo spam e contro il phishing (anche se, soprattutto nell’ultimo caso, la miglior protezione l’abbiamo sopra le spalle, basta usarla), inoltre, non utilizziamo quegli strumenti (come database relazionali o LDAP) per definire domini virtuali e caselle di posta. In poche parole, questa configurazione è decisamente migliorabile, e questi passi in avanti saranno oggetto dei prossimi articoli sull’argomento.

Link di riferimento

• Postfix (home page)
• Dovecot (home page)
• Protocollo SMTP (Wikipedia)
• Protocollo POP3 (Wikipedia)
• Protocollo IMAP (Wikipedia)
• MTA, MDA, MUA (Documentazione Red Hat Linux)
• Configurazione di Postfix (Blog di Marco Buttignon)

In questo articolo viene descritto l’ambiente di test che ho utilizzato e che ho migliorato in questi giorni per poter fare alcuni studi sul funzionamento della posta elettronica su Linux e su Windows, relativamente anche a temi come lo spam ed i virus; lo pubblico qui poiché farò spesso riferimento a questo post nei prossimi articoli. L’ambiente è mostrato in figura 1:

Figura 1 - Ambiente di test

Per prima cosa, tutti i computer mostrati nell’immagine sono macchine virtuali che funzionano su VMWare Server, per cui l’ambiente è totalmente virtualizzato. Si può vedere che esistono due reti, la rete A e la rete B, che hanno questo indirizzamento:

• Rete A: 172.16.1.0/24
• Rete B: 192.168.1.0/24

Le due reti sono state ottenute tramite la funzionalità di Virtual Networking di VMWare Server, perciò, in condizioni normali, le due reti sono separate; in questo caso però, ad unire le due reti, è il firewall Linux, il quale in realtà non fa altro che mettere in comunicazione le due reti tra di loro senza alcun blocco, ma che può essere configurato a piacere con iptables per eventuali regole di restrizione delle comunicazioni di rete. Il firewall Linux inoltre funge da default gateway per ogni host delle due reti, e comunica col mondo Internet tramite il router che si interfaccia con la connessione ADSL, in questo modo, tutti i nodi delle due reti possono accedere alla Rete.

Su entrambe le reti è presente un controller di dominio Windows Server 2003 R2. Entrambi i domain controller fanno parte di un unico dominio (terminus.lan), anche se sono su due reti differenti, inoltre i due server sono posti su due siti Active Directory diversi, questo è utile per i miei test su DFS, che prima o poi dovrei portare a termine. Il domain controller DCServer (Rete A), funge anche da server Exchange, ed inoltre, funge da server DNS per tutti gli host delle due reti, poichè su quel server DNS ho configurato le zone per tutti i domini di posta dell’ambiente di test, definiti sia sul server Exchange sia sui server Linux. Il domain controller Coriolis (Rete B), oltre alle normali funzioni, funge da server SQL Server 2005, che in prima istanza tornerà utile come appoggio per il greylisting sul server Exchange.

Per quanto concerne i due server Linux, in un primo momento verranno configurati come server di posta su due domini separati, mentre più avanti, una volta presa confidenza con la funzionalità di mail server su Linux, configurerò uno dei due server come mail server di “frontiera”, che prenderà in carico la posta, la ripulirà da spam e virus, e quindi la passerà in carico o al server Linux o al server Exchange.

Per la parte client, c’è poco da dire, nel senso che basterà mettere i client su una delle due reti, fare il join al dominio e configurare i client di posta per accedere al mail server del caso.

Si consideri una rete aziendale con sedi distaccate, dove per i più svariati motivi, alcune applicazioni vengono utilizzate via Terminal Services su un server Windows Server 2003, utilizzando client Windows XP Professional o Windows Vista Business; in questo caso, è evidente che, quando si ha bisogno di stampare un qualsiasi documento, non è pratico mandare la stampa su una stampante presente nella sede principale, dovranno essere utilizzate le stampanti presenti nella sede distaccata.

Gestire le stampanti con Windows Server 2003 con abilitati i Terminal Services può essere una cosa piuttosto antipatica; perché le cose funzionino bene, è necessario che sul server sia installato il driver della stampante installato sul client, in più, per essere certi di non avere problemi, se possibile, sarebbe ancor meglio utilizzare per le stampanti i driver Microsoft, e non i driver dei vari produttori delle stampanti.

Microsoft ha migliorato le cose con Windows Server 2008, dove, se ho capito bene il tutto, abilitando i Terminal Services, il server invia la coda di stampa al client sotto forma di file XPS, che quindi viene stampato dal client utilizzando lo spooler ed il driver del client, eliminando il problema; non sono sicuro che le cose funzionino proprio così, ma non dovrei essermi allontanato troppo dal vero. Questo meccanismo prende il nome di Easy Print.

Tornando a Windows Server 2003, se per l’accesso ai servizi Terminal si utilizza un client Windows XP, è bene aggiornare il client RDP alla versione 6, quindi, bisogna fare i conti con le stampanti che si posseggono. Prendiamo ad esempio uno scenario in cui mi sono trovato ad operare: server Windows 2003 con abilitati i servizi Terminal, a cui accedono alcuni client con Windows XP (con client di servizi Terminal versione 6) tramite un collegamento geografico; questi client utilizzano una stampante HP LaserJet 2420 dn, cioè una stampante con un print server ed una unità fronte-retro.

In una situazione simile, è una scelta obbligata quella di permettere la stampa da applicazioni distribuite tramite Terminal Services sulle stampanti locali dei client, per cui, bisogna fare in modo che il server Terminal riconosca le stampanti locali dei client. Nel caso in oggetto, bisogna quindi, all’atto della connessione, assicurarsi che le risorse locali (in questo caso le stampanti) vengano mappate sul server, tramite un’impostazione raggiungibile dal client RDP cliccando su Opzioni, tab Risorse locali, dove è possibile scegliere quali risorse locali “traslare” sul server, come mostrato in Figura 1:

Fig. 1 - mappatura risorse locali su server

Nell’immagine si può notare l’impostazione di mappatura delle stampanti, abilitata cliccando sulla casella relativa; a questo punto, è possibile connettersi per verificare se la stampante verrà installata anche sul server.

Una volta effettuata la connessione, se andiamo nella cartella stampanti, possiamo notare che la stampante HP LaserJet 2420 non è stata installata; nel event viewer (e più precisamente nel log System), abbiamo un evento con id 1111 ed origine TermServDevices che ci segnala l’impossibilità di installare il driver della stampante poiché sconosciuto, come mostrato in figura 2.

Fig. 2 - evento 1111 TermServDevices

Ciò è normale, e dipende dal fatto che il driver della stampante non è un driver Microsoft ma HP, che quindi Windows Server 2003 non ha e non può installare.

Una prima soluzione a questo problema, può essere quella di installare sui client una stampante HP LaserJet che stampi con protocollo PCL e che possieda la possibilità di installare un’unità fronte-retro, come ad esempio la HP LaserJet 4100, utilizzando il driver Microsoft configurato con un’unità duplex per il fronte-retro. Così facendo, la stampante viene correttamente installata, come mostrato in figura 3

Fig. 3 - stampante HP 4100 installata

ed anche nel log degli eventi compaiono diversi eventi (con id 20, 15, 9 e 2) ed origine Print che indicano i vari passaggi di installazione della stampante. Provando a stampare su quella stampante, le stampe arrivano alla stampante HP 2420 perfettamente, peccato però che non funzioni il fronte-retro, che andrebbe impostato sulla stampante ad ogni sessione Terminal, poiché, per un motivo che non conosco, ad ogni sessione questa impostazione viene perduta; una scomodità inaccettabile. Un’altra soluzione potrebbe consistere nell’installazione del driver HP della stampante LaserJet 2420, ma anche in questo caso non funziona il fronte-retro, che è disponibile ma dà problemi in fase di stampa; perchè questo avvenga, non l’ho proprio capito, probabilmente un’incompatibilità del driver in ambiente Terminal Services.

A questo punto, la prima soluzione al problema consiste nell’accontentarsi del mancato funzionamento del fronte-retro, mentre la soluzione n. 2 è un attimino più professionale, e prevede l’installazione di un driver HP chiamato Universal Print Driver, un driver appunto “universale”, rilasciato da HP che permette di installare un unico driver compatibile con tutte le stampanti di rete HP LaserJet e con gran parte delle stampanti inkjet HP, e che prevede la possibilità di abilitare diverse funzioni tra le quali il fronte-retro.

Scaricato questo driver, il primo passo consiste nell’installazione di una stampante HP Universal Printing sui client. Se nella rete sono presenti più stampanti HP, conviene installare il driver della stampante in modalità dinamica, in modo tale da poter scegliere di volta in volta su quale stampante mandare le code di stampa, altrimenti è possibile installare il driver in modalità tradizionale, in cui verrà richiesta la porta di stampa e le altre solite informazioni. Tenere presente che in modalità dinamica, verranno ricercate esclusivamente stampanti in rete (o almeno, io non ho visto nessuna voce di menu in cui poter scegliere di installare una stampante attaccata direttamente al PC), ed inoltre, se nella rete abbiamo stampanti con un print server JetDirect, è possibile lanciare una rilevazione che troverà automaticamente queste stampanti. Scelta una modalità di installazione, ed installata la stampante, verrà creata nella cartella stampanti un oggetto chiamato “HP Universal Printing PCL 6″ sui client; nel caso in esame, la cosa migliore secondo me è installare la stampante in modalità dinamica, poiché la HP LaserJet 2420 possiede un print server JetDirect, ed è quindi ricercabile tramite il comodo tool in fase di installazione.

Ora bisogna installare il driver sul server, utilizzando una modalità diversa da quella usata sui client, poiché sul server non abbiamo bisogno di installare una stampante, è sufficiente installare il driver; per far questo, andare nella cartella stampanti, quindi cliccare sul menu File -> Server properties, quindi cliccare sulla scheda Drivers, cliccare poi sul pulsante Add, partirà il classico wizard di installazione del driver della stampante tramite il quale va installato il driver HP Universal Printing, in tal modo il driver è presente ma sul server non viene creata la stampante.

Compiuti questi passaggi, se effettuiamo la connessione al server Terminal, possiamo notare in figura 4 che è stata creata sul server la stampante HP Universal Printing PCL 6

Fig. 4 - stampante HP Universal Print

Tramite questa stampante, abbiamo la possibilità di stampare sulla stampante locale anche in fronte-retro, semplificando la gestione di altre eventuali stampanti HP e risparmiando quindi tempo e rotture di scatole. Bisogna dire però che questa modalità funziona solo con stampanti HP, e nemmeno con tutte, infatti ho avuto problemi con una multifunzione inkjet, che sarebbero oggetti anche utili in determinati contesti, ma che dal punto di vista dei driver rappresentano il Male.

Non ho ancora avuto esperienze con stampanti non HP su server Terminal, però mi sento di consigliare in casi simili, quando possibile, di utilizzare sempre driver Microsoft per evitare problemi.

Link e approfondimenti

Problematiche connesse alla migrazione di un Server Terminal

Stampanti supportate con Universal Print Driver in ambiente Citrix (documento PDF)

Easy Print con Terminal Services su Windows Server 2008 (aggiornamento del 21 dicembre 2008)

Si prenda in considerazione uno scenario in cui si ha un server Windows Server 2003 con i Terminal Services installati ed un client Windows, diciamo Windows 2000 Professional o Windows XP Professional; in uno scenario del genere, per un motivo che ancora non ho capito, per il semplice motivo che mi rifiuto di capire la perversa politica di licensing di Microsoft, può capitare saltuariamente che uno di questi client, all’atto della connessione al server Terminal, dia questo errore:

The remote session was disconnected because there are no Terminal Server client access licenses available for this computer

La soluzione a questo problema che ho trovato non è certamente elegante, ma funziona, e consiste nel cancellare la chiave del registro di configurazione

HKEY_LOCAL_MACHINE\Software\Microsoft\MSLicensing

In questo “posto” vengono archiviate le informazioni relative alla licenza client per la connessione ad un server con i Terminal Services abilitati. Cancellando questa chiave, si cancella quindi la licenza client, per cui, ritentando la connessione, viene installata nuovamente la licenza client e si riuscirà ad accedere nuovamente al server via RDP.

Sito di riferimento

http://www.chicagotech.net/netforums/viewtopic.php?p=936

Su un server Linux, uno strumento indispensabile per l’amministrazione del server stesso è il server SSH, come OpenSSH, tramite il quale possiamo avere un accesso sicuro alla shell del sistema operativo, per poter amministratore comodamente il nostro server Linux.

In ambiente Windows, un accesso SSH non è una cosa indispensabile, risulta più utile avere un accesso via Remote Desktop per amministrare il server, allo stesso tempo però, può comunque avere un senso l’accesso SSH su server Windows, un po’ per determinate operazioni da svolgere via riga di comando, un po’ per poter scaricare o caricare file da o sul server attraverso SCP e SFTP, che possono diventare comodi soprattutto se ci connettiamo al server in remoto, via VPN, oppure se dobbiamo amministrare o trasferire dati da una macchina Linux ad una macchina Windows, in questo modo non saremo costretti ad utilizzare X oppure ad installare Samba per il trasferimento dati da/verso Windows.

Per quanto concerne il software che funge da server SSH, ne esistono diversi, e direi che più o meno tutti sono un’implementazione di SSH in ambiente emulato Cygwin; io ne ho provati due, Freesshd e CopSSH, che rispondono a due esigenze diverse, in particolare, Freesshd fornisce l’ambiente di shell di Windows, mentre CopSSH fornisce un sottoinsieme dei comandi presenti nella shell Bash di Linux.

Personalmente, tra un’implementazione completa della shell di Windows come quella di Freesshd (che appunto richiama direttamente l’interprete dei comandi di Windows, cmd.exe) ed una che (secondo le mie prove, che ammetto non essere state esaustive) risulta, all’atto pratico, avere una parte dei comandi Bash ed una parte dei comandi di Windows, come accade con CopSSH, preferisco Freesshd; tanto per fare un esempio, con Freesshd riesco a vedere i processi in esecuzione con il comando tasklist, cosa che non riesco a fare con Copssh.

Per poter utilizzare un server SSH su Windows, l’utente col quale faccio il logon al server deve obbligatoriamente consentire l’accesso interattivo al server, se così non è, va modificata l’opportuna policy (si tratta di policies diverse a seconda se il server è controller di dominio oppure no) sul server Windows, e questo può comportare qualche problema di sicurezza in più, cosa che secondo me rappresenta il vero svantaggio dell’avere attivo un server SSH su Windows. Entrambi i software hanno una procedura che permette di specificare quali utenti definiti sul server Windows possono accedere via SSH al server stesso, va da sé che, se vogliamo amministrare decentemente il server Windows, dovremo accedere allo stesso con un’utenza amministrativa, se invece necessitiamo del solo SFTP, è sufficiente abilitare l’utente all’accesso, dopodiché saranno le autorizzazioni impostate sulle cartelle del server Windows a stabilire le possibili azioni dell’utente.

Tornando a FreeSSHD, l’installazione del prodotto è decisamente banale, basta cliccare sempre su Avanti (Next); durante l’installazione verrà creato il servizio FreeSSHDService, in modo che il “demone” sia sempre attivo, quindi dovremo accedere alla configurazione del programma, cliccando col tasto destro sull’icona del programma posta nella systray e, scegliendo la voce Settings dal menu contestuale, è possibile gestire il server SSH, e soprattutto, è possibile abilitare o disabilitare l’accesso SSH agli utenti di Windows tramite la scheda Users, come mostrato in figura 1:

Figura 1 - Scheda Users di FreeSSHD

A questo punto, è sufficiente utilizzare un client SSH come Putty in ambiente Windows, o utilizzando il comando ssh in ambiente Linux/Unix, e collegandosi al server (finora ho provato solamente con nome utente e password, senza utilizzare certificati) si può testare il corretto accesso al server Windows.

Purtroppo, per un motivo che non sono ancora riuscito a capire, al primo tentativo viene restituito l’errore “Incoming packet was garbled on decryption” con Putty oppure l’errore “Bad packet length” su Linux, seguito da un numero; la cosa strana è che tentando una seconda volta, senza cambiare nulla, la connessione avviene senza nessun problema, se qualcuno sa o ha idea da cosa possa dipendere, farebbe cosa molto gradita scrivendolo nei commenti.

Una volta verificato il corretto accesso al server Windows, è possibile configurare anche SFTP, andando a specificare nella configurazione di FreeSSHD qual è la directory root SFTP del server Windows tramite la scheda SFTP, come mostrato in figura 2:

Figura 2 - Scheda SFTP di FreeSSHD

Ora non ci resta che testare il corretto funzionamento di una connessione SFTP; per Windows, si possono utilizzare due programmi, WinSCP (che a dispetto del nome consente anche la connessione SFTP) e FileZilla, il quale, oltre alle normali connessioni FTP, permette di stabilire connessioni SFTP basandosi sull’onnipresente Putty.

Questa configurazione, secondo le prove che ho potuto fare, funziona abbastanza bene, con alcuni difetti: per prima cosa, ho letto sul Web che FreeSSHD peccherebbe un po’ in stabilità, finora io non ho avuto problemi, ma non ne ho fatto un uso intensivo; secondariamente, per quanto riguarda SFTP, l’unica configurazione possibile riguarda la root directory accessibile dagli utenti, impedendo agli stessi di poter accedere alle cartelle di livello superiore, e ciò è positivo dal punto di vista della sicurezza, poiché in questo modo si possono abilitare diversi utenti che comunque non hanno la possibilità di gironzolare per il disco, però, allo stesso tempo, questa impostazione riguarda TUTTI gli utenti, per cui anche gli utenti con privilegi amministrativi, utilizzando SFTP, non possono operare ad un livello superiore rispetto alla home directory, anche se, in realtà, utilizzando Linux, è possibile superare questa limitazione utilizzando scp, per poterlo fare però bisogna conoscere il percorso esatto del file da prelevare; altra limitazione, la shell fornita per default da FreeSSHD è quella di Windows, per cui WinSCP non funziona in modalità SCP, funziona però perfettamente in modalità SFTP.

In conclusione, installare un server SSH su Windows, è utile, secondo me, solo in determinate occasioni, soprattutto se da client Linux dobbiamo accedere o condividere file con un server Windows, oppure può risultare utile su connessioni remote particolarmente lente, altrimenti, secondo me è più utile utilizzare Remote Desktop, utilizzabile anche da Linux tramite il pacchetto rdesktop.

La versione pacchettizzata di MySQL Server 5 per Linux Debian Etch 4.0 ha una caratteristica, non accetta connessioni sulla porta 3306 (la porta a cui risponde MySQL) se non da localhost, cioè sé stesso. Questo può essere un problema se vogliamo o dobbiamo tenere due macchine separate per un’applicazione (o sito) ed il relativo database.

La soluzione al problema è molto semplice, si tratta di commentare la seguente voce

bind-address = 127.0.0.1

presente nel file di configurazione di MySQL, /etc/mysql/my.cnf, dopodiché, dobbiamo abilitare uno o più utenti per poter connettersi in remoto su un particolare database utilizzando l’istruzione SQL GRANT:

GRANT ALL privileges ON testDB.* TO 'testUSR'@'192.168.0.3' IDENTIFIED BY 'testPWD'

così facendo, si abilita l’utente testUSR a connettersi al database testDB dall’host 192.168.0.3. A questo punto, è sufficiente far ripartire il demone di MySQL per abilitare la modifica effettuata al file my.cnf:

/etc/init.d/mysql restart

e questo è tutto.

Facendo riferimento al precedente articolo, che trattava la configurazione degli host virtuali in Apache su un sistema Debian, proseguiamo sulla stessa falsariga e vediamo come configurare in modo opportuno un server FTP che consenta una gestione separata dei diversi siti, impedendo nello stesso tempo agli utenti di girare per il file system e quindi di accedere ad aree della macchina che non competono loro; in questo articolo parlerò di ProFTPD, anche se nell’articolo precedente avevo citato vsftpd, purtroppo, nell’installazione in cui ho in funzione vsftpd, ho avuto alcuni problemi di cui non sono riuscito a capire l’origine, problemi che mi hanno costretto ad utilizzare un altro server FTP, ProFTPD appunto.

Ora dobbiamo configurare in modo opportuno ProFTPD in modo da avere due utenti distinti che gestiscano i due siti creati come descritto nell’articolo precedente, creando due siti FTP virtuali, con l’ausilio di un database dedicato su MySQL; installiamo quindi ProFTPD con il supporto per MySQL:

# apt-get install proftpd proftpd-mysql

Ora dovremo creare il database per ProFTPD, entrando in MySQL col comando:

$ mysql -u root -p

quindi, dopo aver inserito la password, creiamo il database proftpd col comando:

> CREATE DATABASE proftpd;

ed ora, creiamo l’utente MySQL proftpd, al quale diamo le autorizzazioni del caso al database proftpd:

> GRANT SELECT, INSERT, UPDATE, DELETE ON proftpd.* TO ‘proftpd’@'localhost’ IDENTIFIED BY ‘pwdProFTPD’;
> FLUSH PRIVILEGES;

dove, al posto di pwdProFTPD metteremo la password che più ci aggrada.

A questo punto, seguiamo le istruzioni contenute nel preziosissimo tutorial di Howtoforge, che spiega passo passo come realizzare un server FTP che permetta di definire dei virtual host, a cominciare dalle indicazioni su come creare un utente ed un gruppo di sistema per ProFTPD, per poi passare alle istruzioni su come creare le tabelle nel database MySQL riguardanti gli utenti e le ftpquotas (le quote di spazio riservato su disco per ogni utente), dopodiché, a pagina 2 della guida, viene spiegato quali righe aggiungere al file di configurazione /etc/proftpd/proftpd.conf per consentire a ProFTPD di utilizzare un database MySQL come supporto. In particolare, vediamo la riga SQLConnectInfo (in cui vanno inseriti i parametri di connessione al database), la quale, se utilizziamo un database MySQL configurato come descritto in precedenza, va scritta così:

SQLConnectInfo proftpd@localhost proftpd pwdproftpd

Giunti qui, dobbiamo inserire gli utenti nel database MySQL, in particolare nella tabella ftpuser (ho tralasciato volutamente la parte riguardante le quote disco); la guida presente su Howtoforge è fatta molto bene, ma ha il difetto di inserire le password degli utenti in chiaro nella tabella del database, cosa che comporta problemi di sicurezza, per cui, dovremo per prima cosa cambiare una direttiva nel file di configurazione di ProFTPD, per poi utilizzare un’istruzione SQL INSERT diversa da quella riportata su Howtoforge. Il primo passaggio, come detto, consiste nel modificare la direttiva SQLAuthTypes, impostandola in questo modo:

SQLAuthTypes Crypt Plaintext

che significa che le password degli utenti definiti nel database MySQL devono essere criptate, altrimenti l’utente non riuscirà ad autenticarsi su ProFTPD. Ora , dopo aver fatto ripartire il demone proftpd, passiamo all’inserimento vero e proprio degli utenti nel database proftpd in MySQL, in cui dobbiamo prestare attenzione ad indicare la home directory su cui verrà rimbalzato l’utente che si autentica su ProFTPD; in particolare, facendo riferimento all’articolo riguardante l’hosting virtuale con Apache, creeremo un utente chiamato u_webtest con password p_webtest (password insicura, utilizzata per comodità) e home directory /var/www/webtest, quindi creeremo un altro utente chiamato u_webprova con password p_webprova e home directory /var/www/webprova:

> INSERT INTO ftpuser (userid, passwd, uid, gid, homedir, shell, count, accessed, modified) VALUES
> (’u_webtest’, ENCRYPT(’p_webtest’), 2002, 2002, ‘/var/www/webtest’, ‘/sbin/nologin’, 0, ”, ”);

> INSERT INTO ftpuser (userid, passwd, uid, gid, homedir, shell, count, accessed, modified) VALUES
> (’u_webprova’, ENCRYPT(’p_webprova’), 2003, 2003, ‘/var/www/webprova’, ‘/sbin/nologin’, 0, ”, ”);

Da notare che per inserire la password è stata usata la funzione di MySQL ‘ENCRYPT’, la quale utilizza la chiamata di sistema crypt() presente sul sistema operativo, quindi di fatto utilizza lo stesso metodo di cifratura utilizzato da Linux per cifrare le password degli utenti di sistema. Ora, rimangono da impostare i permessi sulle directory dei due siti web, per far sì che gli utenti FTP possano scrivere al loro interno, dando l’autorizzazione in scrittura all’utente ftpuser creato in precedenza:

# chown -R ftpuser:www-data /var/www/webtest
# chown -R ftpuser:www-data /var/www/webprova
# chmod -R 775 /var/www/webtest
# chmod -R 775 /var/www/webprova

Arrivati fin qui, dobbiamo solamente utilizzare un client FTP per testare la funzionalità del nostro server FTP, e, se tutto è andato bene, dovremmo essere pronti per utilizzare il nostro ProFTPD.

Se un server Linux Debian viene utilizzato come server Web, è abbastanza probabile che questo ospiti più siti, ed è piuttosto comune che questi siti vengano gestiti da persone diverse, che debbono avere quindi un accesso FTP dedicato per poter caricare i file del proprio sito, e magari poter avere l’accesso al proprio database MySQL tramite PhpMyAdmin, facendo in modo che gli operatori non vadano a gironzolare su directory o database non di loro competenza.

In questo primo articolo (il prossimo tratterà della configurazione del server FTP vsftpd), darò per scontato che siano già installati (tramite il solito apt) Apache2, PHP5, MySQL; ipotizziamo quindi di dover creare due siti, webtest.it e webprova.it, e creiamo le relative directory:

# mkdir /var/www/webtest
# mkdir /var/www/webprova

Ora, create le directory, dobbiamo configurare gli host virtuali in Apache. Apache2, in Debian, consente la configurazione degli host virtuali inserendo un file di configurazione per ogni host virtuale che si intende creare nella directory /etc/apache2/sites-available, per cui, andremo a creare i due file per i due domini:

# touch /etc/apache2/sites-available/webtest.it
# touch /etc/apache2/sites-available/webprova.it

A questo punto, creati i file vuoti, vanno editati con questi contenuti:

File /etc/apache2/sites-available/webtest.it

NameVirtualHost *:80
<VirtualHost *:80 >
ServerAdmin webmaster@webtest.it
ServerName www.webtest.it
DirectoryIndex index.html index.php
DocumentRoot /var/www/webtest
<Directory "/var/www/webtest">
Order Deny,Allow
Allow from all
Options -Indexes
</Directory>
ErrorLog /var/log/apache2/webtest.it.log
LogLevel warn
CustomLog /var/log/apache2/access.webtest.it.log combined
</VirtualHost>

File /etc/apache2/sites-available/webprova.it

<VirtualHost *:80 >
ServerAdmin webmaster@webprova.it
ServerName www.webprova.it
DirectoryIndex index.html index.php
DocumentRoot /var/www/webprova
<Directory "/var/www/webprova">
Order Deny,Allow
Allow from all
Options -Indexes
</Directory>
ErrorLog /var/log/apache2/webprova.it.log
LogLevel warn
CustomLog /var/log/apache2/access.webprova.it.log combined
</VirtualHost>

Ora i due siti sono configurati con impostazioni "normali", vediamo il loro significato:

NameVirtualHost *:80
Serve per definire su quale interfaccia di rete e su quale porta deve rimanere in ascolto l’host virtuale Apache, in questo caso rimane in ascolto su tutte le interfacce sulla porta 80

<VirtualHost *:80 >
Identifica l’apertura della sezione relativa alla configurazione dell’host virtuale, l’indicazione successiva a VirtualHost (*:80) deve essere identica a quella della direttiva NameVirtualHost

ServerAdmin webmaster@webtest.it
Indica l’indirizzo e-mail dell’amministratore del dominio

ServerName www.webtest.it
Rappresenta il nome FQDN del sito, è fondamentale scrivere bene questa voce altrimenti il nostro sito non sarà visibile

DirectoryIndex index.html index.php
Esprime l’ordine di ricerca di determinate pagine Web rappresentanti la home page quando viene fatta da un browser una richiesta del tipo www.webtest.it/ o www.webtest.it/test/, se in queste directory non esiste una pagina chiamata index.html o index.php (o qualsiasi altro nome file indicato nella direttiva DirectoryIndex), Apache restituirà un errore 403 Forbidden se usiamo la direttiva "Options -Indexes" (come effettivamente faremo), oppure, se questa direttiva non viene utilizzata, visualizzeremo i files presenti nella directory

DocumentRoot /var/www/webtest
Indica la directory in cui sono posizionati i file del nostro sito

<Directory "/var/www/webtest">
Identifica l’inizio della configurazione delle autorizzazioni per la directory del sito

Order Deny,Allow
Allow from all
Queste due righe stanno ad indicare che il sito è visibile a tutti

Options -Indexes
Come indicato in precedenza, questa opzione permette di visualizzare un errore 403 di accesso negato se si digita un indirizzo del tipo www.webtest.it/test/ ed in questa directory non esiste un file chiamato con uno dei nomi file indicati nella direttiva DirectoryIndex; se non si specifica questa opzione, sarà visibile il contenuto dell’intera directory, cosa da evitare.

ErrorLog /var/log/apache2/webtest.it.log
LogLevel warn
CustomLog /var/log/apache2/access.webtest.it.log combined
ErrorLog fornisce un percorso per il file di log contenente le segnalazioni di errore che incontra Apache, mentre LogLevel indica la verbosità delle operazioni di logging attraverso un sistema di livelli, di cui "warn" è uno dei più bilanciati; CustomLog identifica la posizione del file di log che registra gli accessi al sito Web.

Giunti qui, andiamo a creare i file di log che abbiamo specificato nei file di configurazione dei virtual hosts:

# touch /var/log/apache2/access.webtest.it.log
# touch /var/log/apache2/webtest.it.log
# touch /var/log/apache2/access.webprova.it.log
# touch /var/log/apache2/webprova.it.log

dopodiché, bisogna abilitare i siti virtuali, e ciò è possibile tramite il comando a2ensite, il quale crea dei link simbolici nella cartella /etc/apache2/sites-enabled/ che puntano ai file di configurazione creati in precedenza nella cartella /etc/apache2/sites-available/:

# a2ensite webtest.it
# a2ensite webprova.it

ciò è necessario poiché nel file di configurazione di Apache (/etc/apache2/apache2.conf) vi è una direttiva che include i file presenti nella cartella /etc/apache2/sites-enabled/.

Ora non rimane altro che riavviare Apache ed avremo i nostri virtual hosts funzionanti.

Giunti qui, rimane da fare un’unica cosa, cioé installare e configurare PhpMyAdmin per poter gestire il proprio database MySQL tramite sito Web. Per installare PhpMyAdmin, possiamo utilizzare il comando

# apt-get install phpmyadmin

dopodiché, dobbiamo creare un alias su ogni sito sul quale vogliamo rendere disponibile PhpMyAdmin; l’alias si rende necessario poiché l’installazione di PhpMyAdmin viene effettuata nella directory /usr/share/phpmyadmin, per cui, o si fa l’alias, oppure si copia la directory phpmyadmin nella directory del sito, ma ciò non conviene, poiché:

1. è un’operazione che dovremmo ripetere per ogni aggiornamento di PhpMyAdmin
2. nel caso di più host virtuali che utilizzano PhpMyAdmin, dovremmo ripetere la copia per ogni host virtuale che utilizza PhpMyAdmin

per cui, è bene utilizzare un alias per ogni virtual host, che mappi una directory virtuale (ad esempio, /phpmyadmin) per ogni host virtuale che utilizza PhpMyAdmin. Configurare l’alias è molto semplice, prendendo ad esempio i file di configurazione dei due domini citati precedentemente, basta aggiungere questa riga dopo l’istruzione DocumentRoot:

Alias /phpmyadmin /usr/share/phpmyadmin

quindi, dopo aver chiuso e salvato il/i file di configurazione, basta far ripartire Apache per poter utilizzare PhpMyAdmin, la cui configurazione esula dagli scopi di questo articolo; in ogni caso, tenere presente che, se PhpMyAdmin è configurato con un livello di sicurezza ‘cookie’, nome utente e password richiesti per entrare in PhpMyAdmin, non sono altro che gli utenti definiti in MySQL, per cui, bisogna fare attenzione alle autorizzazioni che si assegnano ai vari database, onde evitare che certi utenti possano accedere a database non di loro competenza.

Link di riferimento
Gestione Moduli e Virtual Hosts di Apache2 su Debian e Ubuntu
HowTo: Configurazione dei Virtual Hosts (alias) con Apache2 su Debian ETCH

ExMerge è un’utilità fornita da Microsoft, che consente di esportare o importare, da o verso Exchange, cassette postali in formato .PST. Questa utility è utile soprattutto quando è necessario spostare le cassette postali da un server Exchange ad un altro server Exchange, oppure se si vuole fare un “backup dei poverelli” delle cassette di posta, utile se per fare il salvataggio di Exchange abbiamo solo NTBackup, che fa il backup dell’Information Store ma non delle singole caselle di posta.

Per utilizzare ExMerge, dobbiamo assicurarci di non avere nella nostra organizzazione cassette postali superiori ai 2GB; se queste esistono, è necessario ridurre le loro dimensioni, dopodiché, è possibile scaricare ExMerge dal sito Microsoft, file che quindi va scompattato, per poi copiare i file ExMerge.exe e ExMerge.ini nella cartella degli eseguibili dell’installazione di Exchange, “c:\Percorso-Cartella-Installazione-Exchange\bin”. Prima di poter eseguire l’utility però, bisogna compiere alcuni passi preliminari:

1. creare e/o modificare un utente che abbia accesso alle cassette postali con i privilegi “Send as” e “Receive as”
2. fermare, se necessario, il servizio SMTP per non ricevere ed inviare messaggi di posta durante la fase di esportazione/importazione
3. effettuare un salvataggio completo dell’Information Store, per poterlo ripristinare in caso di problemi

Il passaggio n. 1 consiste nella creazione di un utente, che chiameremo ExMerge, che possa accedere alle cassette postali di tutti gli utenti con i privilegi “Send as” e “Receive as”. Per creare l’utente, utilizzare la console “Active Directory Users and Computers”, e da qui rendere l’utente appartenente al gruppo Administrators (già presente di default in ogni installazione di Windows Server 2003), dopodiché, delegare l’amministrazione dell’organizzazione Exchange all’utente ExMerge andando su System Manager, quindi cliccare col tasto destro sul nome dell’organizzazione Exchange e selezionare la voce “Delegate Control”, che apre un wizard, da lì aggiungere l’utente ExMerge agli utenti che già hanno la possibilità di amministrare Exchange, avendo cura di assegnargli il ruolo “Exchange Full Administrator”, quindi terminare il wizard confermando le scelte effettuate. A questo punto, bisogna fare i conti con le impostazioni predefinite di Exchange Server 2003, che per gli utenti facenti parte di un gruppo amministrativo (come appunto il gruppo Administrators), nega l’autorizzazione “Send As” e “Receive As” sul (o sui) Mailbox Store, per cui, bisogna impostare in modo esplicito le autorizzazioni “Send As” e “Receive As” sul Mailbox Store per l’utente ExMerge, oppure creare un gruppo di protezione specifico per gli utenti che vogliamo abilitare a questo compito, e delegare a questo gruppo l’amministrazione di Exchange. In questo caso, avendo bisogno di un unico utente, possiamo evitare di creare un gruppo di protezione.

Ora eseguire, se necessario, il passaggio numero 2 e fermare il servizio SMTP, per impedire che vengano spediti e ricevuti ulteriori messaggi di posta, che in una fase di migrazione o ripristino possono incasinare per bene le cose, e che comunque possono essere perduti al termine di questa fase. Non rimane altro da fare che effettuare un salvataggio dell’Information Store, o tramite un software di backup o semplicemente copiando il contenuto della cartella mdbdata (o comunque della cartella in cui è posizionato il database delle mailbox di Exchange).

A questo punto, è possibile far partire ExMerge, non con un doppio click ma cliccando col tasto destro sull’eseguibile selezionando la voce “Run as”, quindi specificare l’utente ExMerge appena creato e cliccare Ok. Ora possiamo scegliere tra due modalità, la modalità “One Step”, che esegue un salvataggio dello store ed un ripristino su un altro server in un unico passaggio - e la modalità “Two Step”, che consente di effettuare l’esportazione e l’importazione delle cassette postali in due fasi distinte, utile se vogliamo fare un backup o un restore delle cassette postali sullo stesso server Exchange.

In questo caso, vediamo la modalità Two Step: dopo aver scelto questa voce, viene richiesto se effettuare lo Step 1 (esportazione) o lo Step 2 (importazione), quindi, dopo aver scelto di fare l’esportazione delle cassette postali, specificare il server Exchange dal quale si vogliono estrarre le cassette di posta, indicando anche il Domain Controller del dominio per velocizzare le operazioni, tenere presente però che il DC va indicato con attenzione se ci troviamo in un ambiente multidominio, poiché verranno esportate solamente le cassette postali facenti parte del dominio a cui appartiene il DC indicato nella casella “Domain Controller (DC) Name”

Giunti fin qui, ExMerge richiede quali cassette di posta vogliamo esportare (nel nostro caso tutte), quindi, una volta selezionate le mailbox che ci interessano, andiamo avanti e selezioniamo l’impostazione della lingua di default (nel nostro caso Italiano) e selezioniamo, per maggior sicurezza, anche il flag “Use last mailbox login locale”, che consente di utilizzare l’impostazione della lingua utilizzata su una determinata casella durante l’ultimo accesso alla stessa.

Ora dobbiamo selezionare la cartella di destinazione in cui salvare i file .PST delle mailbox, quindi, fatto questo, possiamo procedere con l’estrazione vera e propria, la cui durata dipende ovviamente dal numero di caselle di posta e dal loro “peso”. Finita l’esportazione, è possibile controllare il file ExMerge.log per verificare che non vi siano stati errori in questa fase. Se tutto è andato bene, avremo una sorta di backup di tutte le cassette di posta della nostra organizzazione, che sono ripristinabili in ogni momento, con il vantaggio, a differenza di un salvataggio generico dell’Information Store, che possiamo effettuare il restore anche della singola casella postale.

Il restore di una cassetta di posta può essere fatto sempre con ExMerge, e sempre con le stesse modalità descritte in precedenza, tranne che per la scelta dello Step, infatti per effettuare un ripristino deve essere scelto lo Step 2, come mostrato nella figura sottostante:

La cosa a cui dobbiamo prestare attenzione in questa fase, è la modalità di importazione o ripristino della cassette di posta, infatti, quando ci viene richiesto il server Exchange sul quale vogliamo ripristinare le mailbox, è bene, prima di andare avanti, premere il pulsante “Options” e indicare con che modalità avviene il ripristino.

Dall’immagine precedente, è possibile vedere che nella scheda “Import procedure” ci viene richiesto come ripristinare gli elementi della cassetta postale; trattandosi di un ripristino, la cosa più probabile è che si vogliano sovrascrivere gli elementi già presenti, opzione attivabile cliccando su “Replace existing data in target store”, anche se la scelta da effettuare dipende sempre dal contesto nel quale ci troviamo. Ora è possibile proseguire seguendo i passi svolti in precedenza, facendo attenzione a selezionare la cartella sorgente dalla quale pescare i file .PST salvati in precedenza, dopodiché è possibile procedere con il restore vero e proprio. Se tutto è andato bene, avremo ripristinato le nostre cassette di posta, in ogni caso, è sempre bene verificare tramite il file di log (ExMerge.log) che non vi siano stati errori non bloccanti.

E’ importante ricordare che il formato del file .PST creato da ExMerge è quello di Outlook 97-2002, per cui, viene a mancare il supporto ai file con dimensioni superiori ai 2GB, come accennato in precedenza; ho avuto un’esperienza del genere, la quale mi ha insegnato che ExMerge non ha apparentemente problemi a creare file .PST maggiori di 2GB, ma poi, quando si tenta di ripristinare la cassetta postale salvata, viene restituito un errore generico che ci informa che l’importazione del file PST non è andata a buon fine, quindi, spulciando il log di ExMerge (il file ExMerge.log, presente nella cartella in cui abbiamo salvato ExMerge.exe, l’eseguibile dell’utilità) troviamo questa riga:

Error configuring message service (MSPST MS) (UNKNOWN ERROR) (CMapiSession::CreateEMSPSTProfile)

Da questa piccola disavventura, si può trarre l’insegnamento che, in caso di utilizzo di ExMerge, è bene verificare, prima di lanciarlo, che le cassette postali di Exchange non superino i 2GB di dimensione; ancor meglio sarebbe utilizzare delle mailbox quota che impediscano di avere cassette postali più grandi di una certa dimensione, ma questo non sempre si può fare, purtroppo molta gente continua ad utilizzare la posta elettronica in modo improprio, tenendo nella propria casella di posta migliaia di messaggi semplicemente temendo la remota possibilità che servano in un imprecisato futuro.

Link di riferimento:
http://blogs.ugidotnet.org/alexblog/articles/24659.aspx (bell’articolo su ExMerge)
http://support.microsoft.com/kb/292509 (impostazione di un gruppo di protezione per l’utilizzo di ExMerge, io ho usato una strada leggermente diversa)
http://technet.microsoft.com/it-it/library/aa997470(EXCHG.65).aspx (strategie e procedure consigliate per ExMerge)