Ricerche IT

Alcuni giorni fa, ho finito di rileggere per l’ennesima volta Dune (attenzione, contiene la trama del libro), in cui, in un passaggio del libro, Paul Muad’Dib - Usul, risvegliatosi dal coma dopo aver bevuto l’Acqua della Vita, pretende dalla madre Jessica di poter vedere quel luogo interiore dove le Reverende Madri non possono accedere, e la cui visione è consentita solamente allo Kwisatz Haderach, quale è Paul. Dopo aver giocoforza “condotto” Paul in quel luogo, Jessica spaventata si ritira e le Reverende Madri (o meglio, la loro memoria presente in Jessica) che l’hanno preceduta, sconvolte, si chiedono: “Che cosa è stato? Che cosa è accaduto?“.

Questo passaggio mi è venuto in mente ieri, quando ho appreso che, a causa di un intervento maldestro di un sedicente tecnico, il quale, montando un server in un armadio rack ed un UPS, ha collegato l’UPS a valle di un altro UPS preesistente, che, sottoposto a carico troppo elevato, ha fatto il botto, per cui, tra le altre cose, si è spento un server VMWare ESXi con installate quattro macchine virtuali.

Al riavvio del server, si trattava di far partire le macchine virtuali, ed è stato lì che ho pensato che le quattro macchine virtuali, una volta avviate potessero dire: “Che cosa è stato? Che cosa è accaduto?“.

Ho bisogno di ferie.

Dopo lungo silenzio, dovuto a diversi impegni, ritorno a scrivere sul blog nel segno della più sfrenata autoreferenzialità, per segnalare che ieri sono stati proclamati i vincitori della competizione Miglior Blog Tecnico, ed ho appreso, con somma sorpresa, di essere arrivato secondo nella valutazione della giuria! Gli altri classificati sono Levysoft di Antonio Troise, che ha vinto la competizione, e Google Analytics in 30 secondi di Marco Cilia, che si è classificato al terzo posto, a cui faccio i miei complimenti!

Per me è un risultato assolutamente inaspettato, che penso sia arrivato soprattutto per l’originalità dei contenuti che ho voluto proporre, come era indicato chiaramente nei criteri di valutazione della competizione, così come penso sia stato per gli altri blog primi classificati.

Devo anche dire che tempo fa, avevo dato un’occhiata ad alcuni blog che si erano iscritti alla competizione, e purtroppo alcuni di questi, secondo me molto validi, non hanno indicato i post in competizione, ed è un peccato perché penso avrebbero potuto insidiare le prime posizioni.

Un po’ a me dispiace non avere qualche dettaglio in più sulle valutazioni espresse, soprattutto per capire, per ciò che mi riguarda, cosa è piaciuto di più e cosa meno dei post oggetto di valutazione, ma posso comprendere la scelta della giuria, che si troverebbe probabilmente a dover rispondere ad una marea di domande, e forse ad esporsi a qualche polemica, di cui immagino i giurati non sentano proprio il bisogno.

Da quanto ho letto, sembra si terrà prossimamente un’altra edizione della competizione, che a me sembra molto utile per far emergere blog “piccoli” e meno piccoli che propongono contenuti molto interessanti anche se un po’ di nicchia.

Alla prossima edizione!

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.

Fino ad oggi, avevo sul blog una pagina in cui avevo raccolto alcuni collegamenti ipertestuali a pagine con documentazione varia relativa alle tematiche di questo spazio. Questi link li ho tenuti aggiornati per un po’, dopodiché ho mollato lì la cosa, anche perché nel frattempo mi sono arrangiato con Google Reader, impostando i tag e le stelle agli articoli dei blog che seguo per poterli poi ritrovare in caso di bisogno. Ma i blog del feed reader non sono la mia unica fonte di conoscenza, alle volte, cercando cose che mi interessano, mi imbatto in articoli interessanti che non meritano l’oblio, quindi ho deciso di aprire un account su Delicious, dove, alla bisogna, inserisco i bookmarks che ritengo meritevoli.

Oggi ho pensato ad una cosa: perché non sostituire i link utili nella pagina del blog con la lista dei bookmarks su Delicious? Bene, mi sono messo quindi alla ricerca di un plugin per Wordpress che mi permettesse di inserire la lista dei miei bookmarks di Delicious, peccato che la ricerca non abbia fornito l’esito sperato, infatti ciò che ho trovato io (ma può essere che mi sia sfuggito qualcosa) non risponde alla mia semplice esigenza, poiché ho letto solamente di plugin che permettono di inserire un certo numero di bookmarks in un widget sulla sidebar, cosa che ho provato a fare ma che ho levato subito con un moto di ribrezzo, poiché i link di quel tipo nella sidebar mi paiono decisamente inutili.

Cerca che ti ricerca, ho pensato di andare direttamente alla base, cioé sul sito di Delicious, dove ho trovato una simpatica pagina coi tools relativi a Delicious, tra cui vi sono Linkrolls e Tagrolls. Linkrolls consiste in un semplice script JavaScript, personalizzabile in base a vari parametri, con cui elencare un numero a piacere di bookmarks relativi al proprio account. Ciò era proprio quel che mi serviva, quindi lo provo e vedo che funziona alla perfezione, ma mi rendo subito conto che questa pletora di collegamenti ipertestuali è decisamente dispersiva.

A questo punto, rivolgo la mia attenzione su Tagrolls, che elenca la lista (o la tag cloud) dei tag utilizzati per categorizzare i propri bookmarks. Anche in questo caso, si tratta di uno script JavaScript che possiede diversi parametri personalizzabili (come l’ordinamento e l’aspetto); lo provo, e verifico che pure questo tool funziona perfettamente, ottenendo il risultato voluto.

Tutto bene quindi? Non proprio, perché, trattandosi di uno script JavaScript, chi naviga tenendo disabilitato l’interprete JavaScript, non visualizza un bel niente. Per risolvere il problema, ho pensato di fornire un contenuto alternativo tramite il tag <noscript>, in cui includere il link alla mia pagina su Delicious, così da non escludere chi preferisce navigare con JavaScript disabilitato.

Comunque, se qualcuno dei lettori volesse segnalare un metodo alternativo per gestire i bookmarks di Delicious, o un metodo più elegante riguardante il contenuto alternativo allo script JavaScript, lo può come sempre segnalare nei commenti.

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

Tempo fa mi è capitato di avere per le mani un firewall Cisco PIX 506e che non completava la fase di boot, praticamente, collegandosi in console al dispositivo, arrivava a mostrare quella che chiama la “PCI Device Table”, che dovrebbe essere l’elenco di alcuni componenti del firewall (tra cui le interfacce di rete) e si piantava in quel punto, senza che fosse possibile andare oltre.

Per fortuna, cercando sul Web, ho trovato una soluzione piuttosto semplice anche se “curiosa”, che consiste nello spegnere l’aggeggio (il Pix), aprirlo, e trovare un jumper presente nel bel mezzo della scheda madre; tale jumper fa da ponticello su due piedini, lasciandone un terzo libero, consentendo quindi di posizionare il jumper su due diverse posizioni, per cui, seguendo il consiglio trovato sul Web, ho spostato il jumper nell’unica altra posizione possibile, ho chiuso il firewall, quindi ho avviato il dispositivo, ottenendo il risultato sperato, cioé il corretto funzionamento della macchina.

Link di riferimento

http://www.velocityreviews.com/forums/t56103-cisco-pix-506e-wont-boot.html
http://www.experts-exchange.com/Security/Software_Firewalls/Enterprise_Firewalls/Cisco_PIX_Firewall/Q_23316894.html

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.