Prima di avviarmi in questo nuovo articolo dedicato a Scalix, desidero fare una premessa: non intendo far passare il concetto che Scalix sia in assoluto la migliore alternativa ad Exchange. Ci sono altre soluzioni per il groupware messaging, come Zimbra e Zarafa, per esempio che non sfigurano per nulla. Il motivo di questo mio accanimento con Scalix è molto semplice: abbiamo deciso di utilizzarlo e per il momento la decisione è presa. Non si tratta di ingiustificata cocciutaggine quanto, piuttosto, di una attitudine fondamentale che, a mio avviso, deve essere assunta da chi si lancia nel mondo open-source: ad un certo punto bisogna smettere con i test e concentrarsi sul come mettere in produzione una soluzione scelta. Il problema, infatti, dell’amplissima scelta che ci si trova di fronte, porta ad un allungamento spesso smodato dei trial di valutazione e, più si indugia nelle prove di soluzioni diverse più si apprezzano funzionalità diverse, a volte migliori, controbilanciate da carenze a volte essenziali. In questo modo si perde tempo prezioso quando il proprio target è quello di avviare una soluzione affidabile. Il concetto chiave è molto semplice: che si parli di mail server, di crm, di quelchevipare, difficilmente potrete trovare nel mondo open-source qualcosa che si attagli perfettamente alle vostre esigenze, qualcosa che sostituisca e rimpiazzi in modo assolutamente identico la vostra vecchia soluzione closed ed abbia anche – inutile negare che sia uno dei requisiti che molti cercano – la caratteristica della gratuità. Come ho cercato di spiegare in questo mio precedente articolo, ci sarà sempre del lavoro da fare per fare in modo che il nuovo software vesta come un abito su misura e vi aiuti nella gestione dei problemi quotidiani.

Detto questo … un altro aspetto che ho apprezzato di Scalix è la possibilità, con minimo sforzo, di integrare all’interno della medesima struttura, client di posta di natura diversa. Nel nostro caso specifico i due software principali sono Outlook (2007) e Thunderbird.

Ci si potrebbe chiedere perchè ci debba essere necessità di far coesistere due applicazioni che sostanzialmente dovrebbero fare lo stesso lavoro: spesso le aziende (e i fanatici) tendono ad assumere che ci debba essere una sola soluzione standard adottata universalmente, o una o l’altra. Ritengo questo ragionamento piuttosto miope e comunque in contrasto con un principio base : usa lo strumento migliore per ogni condizione di lavoro e per ogni ambito. Del resto, avrebbe senso che tutte le auto aziendali fossero dello stesso modello ed immatricolate tutte come autocarro ? Ovviamente no. Analogamente avrebbe senso dotare di Outlook tutti i pc aziendali quando su molti di essi la gestione della messaggistica da parte degli utenti NON prevede, per esempio, la necessità di condividere le informazioni libero/occupato degli altri utenti ? Ancora, ovviamente, no. Ha senso aumentare lo stack di investimento nel dotare tutte le postazioni di Windows quando molti utenti lavorano solo con applicazioni strutturate di data-entry ? No.

Nel nostro ambito la scelta di adottare Outlook per un certo tipo di utenza e Thunderbird per un altro è stata facile: le caratteristiche delle due applicazioni, costo a parte, sono molto differenti. Certamente entrambe permettono di inviare e ricevere posta elettronica, ma mentre Outlook è molto utente-centrico (gestisce la mia posta elettronica, il mio calendario, mi permette di integrare e sincronizzare le mie device ecc. mentre per “impersonare” utenti diversi devo affidarmi a sistemi di deleghe che non si attivano con un click-e-via), il secondo è estramente più flessibile nella gestione di identità diverse (senza dover riavviare il client tutte le volte), dispone di tonnellate di plug-in liberamente disponibili che possono aiutare nell’automazione di processi ripetitivi (per esempio QuickText), consente la modalità on/off-line senza necessità di componenti aggiuntivi, permette di disporre di identità connesse a Scalix e altre che scaricano la posta in POP da altre sorgenti e consente comunque di disporre di un sistema calendario condivisibile con gli altri utenti outlook (Lightning). Il tutto, ovviamente, a costo di licenza zero.

Tra l’altro, in ogni momento, gli utenti Thunderbird possono comunque accedere al simil-outlook offerto dall’interfaccia web di Scalix (Scalix Web Access) il che rende trasparente la base dati comune.

Collegare Outlook a Scalix è immediato: basta installare il connettore Scalix Connect per Outlook e configurare un nuovo profilo di posta connesso a Scalix Server. Una nota importante riguarda l’adozione di Scalix Smart Cache: se state configurando la posta per un desktop evitate di attivare Smart Cache in quanto difficilmente potrà accadere che vi sia la necessità di lavorare in modalità Off-line. Al contrario, se state configurando Outlook per la connessione a Scalix su un laptop o comunque su un portatile, vi tornerà utile attivare Smart Cache per le attività di consultazione della posta fuori rete.

Per quanto riguarda Thunderbird la connessione al server Scalix avviene tramite connessione IMAP.  Il difetto (si fa per dire) di Thunderbird è che al momento della prima connessione cercherà di creare sul server IMAP a cui è connesso, le cartelle fondamentali per il proprio funzionamento. Generalmente questo non è un problema ma se si desidera che la struttura delle cartelle con Thunderbird sia la medesima che viene visualizzata con SWA ed, eventualmente, anche utilizzando Outlook, è bene comprendere quale sia la struttura delle cartelle lato Scalix Server e come renderle obbligatorie per Thunderbird.

Se infatti si tenta di aprire il medesimo account una volta con Thunderbird e una volta con Outlook, ognuno dei due client creerà delle proprie cartelle che avranno significato particolare solo per quello specifico client. Ad esempio : Outlook (tramite il connettore Scalix) onora i nomi standard in inglese delle cartelle MAPI di base che sono Inbox (Posta in Arrivo), Outbox (Posta in Uscita), Waste Basket (Cestino), Calendar (Calendario), Contacts (Contatti), Tasks (Attività), Journal (Diario), Drafts (Bozze), Notes (Note) mentre, per la versione localizzata in italiano, la cartella della posta indesiderata viene chiamata appunto ‘Posta Indesiderata’ al posto dell’omologo in inglese Junk. Volendo condividere le medesime impostazioni tra Outlook e Thunderbird dovremo avere l’accortezza di configurare Thunderbird in modo che la cartella della Posta Indesiderata sia proprio quella scritta in italiano. Per eseguire questa impostazione basta accedere al menu Strumenti -> Impostazioni Account di Thunderbird e nell’apposita sezione modificare il nome della cartella di posta indesiderata.

Il mio consiglio è quello di accedere per la prima volta ad un account con Outlook, prendere nota dei nomi delle cartelle, e quindi modificare le impostazioni di Thunderbird di conseguenza.

A questo punto potete installare il plug-in Lightning per Thunderbird ed accedere al calendario associato all’account sul server Scalix. La configurazione è immediata. Create un nuovo calendario remoto (Sulla rete) di tipo CalDAV ed inserite come percorso la seguente riga :

http://<nome-del-vostro-host-scalix>/api/dav/Calendars/Users/<indirizzo-email-utente>/Calendar

Dopo la configurazione iniziale vi viene richiesto di inserire la password dell’account a cui appartiene il calendario … et voilà, anche su Thunderbird il calendario di Scalix con promemoria e allarmi come lo vedete (e impostate) su Outlook.

Il controllo dell’utilizzo della risorsa internet specialmente all’interno delle aziende è aspetto cruciale. Spesso vengono installati software anche molto costosi per monitorare gli accessi oppure negarli. In realtà, a costo zero, SQUID offre un eccellente controllo accessi e, se integrato con software open-source come Dansguardian, può combinarsi in un eccellente strumento per il content-filtering.

Vediamo in questo esempio come un server Linux dotato di una distribuzione CentOS e corredato da SQUID possa essere configurato per consentire l’accesso solo agli utenti che accedono al dominio AD (Active Directory) di una tipica Lan basata su un server Microsoft.

Prima di procedere accertatevi che il vostro server Linux CentOS sia configurato in modo tale che la scheda di rete utilizzi il server DNS offerto dal server Windows autoritativo per AD.

Il primo passo consiste nella integrazione di SAMBA (che CentOS installa per impostazione predefinita) con AD.

• Cliccare su System, selezionare Administration quindi Authentication. Verrà eseguita la pagina di configurazione dell’autenticazione.
• Abilitare la casella di controllo Enable Winbind Support e quindi cliccare su Configure Winbind.
• Impostare Security Model su ads e quindi compilare Winbind Domain, Winbind ADS Realm e Winbind Domain Controllers secondo lo schema seguente:
  • Winbind Domain : il nome di DOMINIO senza estensione ovvero in pratica il Workgroup (per esempio se il vostro dominio è qualchecosa.com inserite QUALCHECOSA tutto in maiuscolo)
  • Winbind Security Model : ads
  • Winbind ADS Realm : il nome dominio completo es QUALCHECOSA.COM
  • Winbind Domain Controllers : il nome di host completo del server autoritativo. Se vi sono più server in AD inserirli di seguito separati da virgole.
• Cliccare su Join Domain : vi verrà richiesto di inserire il nome utente e la password di un account utente autoritativo per il join. Generalmente si utilizza l’Administrator del dominio. Quindi cliccate su Ok
• Cliccate su Ok nuovamente e selezionate il tab Authentication.
• Abilitate il controllo Enable Winbind Support.
• Cliccate su Ok
• Con un editor aprite il file /etc/samba/smb.conf e modificate (o aggiungete) le righe indicate di seguito :

winbind use default domain = yes
winbind enum users = yes
winbind enum groups = yes
obey pam restrictions = yes
allow trusted domains = no
idmap backend = idmap_rid:qualchecosa=16777216-33554431

fate molta attenzione all’ultima riga. Dopo idmap_rid dovete inserire lo stesso valore che avete inserito in Winbind Domain (questa volta in minuscolo)

• Se non si desidera che gli account utente di AD possano effettuare il login direttamente sulla macchina Linux è possibile fermarsi qui e passare direttamente alla configurazione di SAMBA
• Create la cartella che verrà utilizzata come HOME per gli utenti. es. /home/QUALCHECOSA (riportate in maiuscolo il nome del workgroup)
• Con l’editor di testo che preferite modificate il file /etc/pam.d/system-auth ed aggiungete la riga seguente:

session required pam_oddjob_mkhomedir.so skel=/etc/skel umask=0022

• Riavviate ora il servizio winbind ed avviate il servizio oddjobd (verificando anche che sia in start-up automatico)
• Per verificare che tutto funzioni aprite una console di comando e digitate wbinfo -u. Dovrebbe apparire l’elenco degli utenti registrati in AD.

A questo punto possiamo procedere con la configurazione di SQUID

• Con l’editor di testo che preferite aprite il file /etc/squid/squid.conf ed inserite queste righe:

auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 5
auth_param ntlm keep_alive on
auth_param basic program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off
acl authenticated proxy_auth REQUIRED

questa sezione indica a SQUID i riferimenti al programma di autenticazione (NTLM) ed impone l’autenticazione (ultima riga) obbligatoria.

• Riavviate Squid e provate a navigare. Se l’utente non è autenticato da AD non potrà passare da SQUID.

Procedendo oltre diventa facile limitare l’utilizzo di internet per specifici gruppi. Supponete di aver creato un Gruppo di Sicurezza in AD che si chiama NoInternet e di avervi assegnato alcuni utenti. Bisogna configurare SQUID in modo che impedisca l’accesso agli utenti che appartengono a quel gruppo.

• Con l’editor di testo che preferite aprite il file /etc/squid/squid.conf ed inserite queste righe:

external_acl_type ad_group %LOGIN /usr/lib/squid/wbinfo_group.pl
acl banned_users external ad_group NoInternet

La prima riga definisce una acl esterna chiamata ad_group che punta ad un programma Perl che accetta, come parametri, il nome utente ed il gruppo e ritorna Ok se l’utente appartiene a quel gruppo. La seconda riga definiscce una acl (access control list) chiamata banned_users che specifica il gruppo AD NoInternet. Per impedire l’accesso quindi agli utenti del gruppo NoInternet, che vengono associati alla acl banned_users, basterà inserire questa ulteriore riga:

http_access deny banned_users

• Riavviate SQUID e provate a far navigare un utente del gruppo NoInternet.

Uno dei problemi maggiori che tutti gli amministratori di server di posta prima o poi si trovano ad affrontare è costituito dalla smodata (e vergognosa) crescita delle dimensioni delle singole caselle postali e, di conseguenza, dello spazio di storage complessivo. Specialmente con Exchange Server 2000 questa caratteristica era particolamente sentita dato che la versione Standard del software consentiva l’allocazione di una singola unità di storage con spazio limitato.

Imperativo pertanto procedere con periodiche attività di cut-off dei messaggi per recuperare spazio prezioso: non c’è niente di peggio, secondo me, che utilizzare un mail server come sistema di archiviazione eterno di tutte le email ricevute ed inviate dalla notte dei tempi. Se avete bisogno di archiviare le posta vi sono soluzioni interessanti specificamente progettate. Ma, per quanto possibile, istruite i vostri utenti a mantenere snelle le caselle postali e, all’occorrenza, imponete (a rischio di qualche mugugno) dei limiti di aging dei messaggi (almeno nelle cartelle standard – Posta In Arrivo, Posta in Uscita e Cestino).

Lo strumento che Microsoft Exchange mette a disposizione è il Mailbox Agent che permette, tra l’altro, proprio la pulizia automatica delle caselle postali degli utenti in base a criteri specificati dall’amministratore di sistema. Tra le opzioni di pulizia vi sono il semplice spostamento dei messaggi nel cestino oppure l’eliminazione definitiva.

La stessa identica cosa è possibile con Scalix tramite lo strumento omtidyu (per effettuare la pulizia di una singola casella postale) oppure omtidyallu (per eseguire l’operazione di clean-up su tutte le mailbox del server). Tra l’altro, rispetto a Exchange, a mio modestissimo parere, Scalix offre un vantaggio in più: non avendo un’area di storage incapsulata in un singolo file, in seguito ad una pulizia di massa, non è necessario eseguire attività di shrink dello storage per recuperare lo spazio delle pagine database non più allocate.

L’utilizzo dello strumento omtidyallu , come pure omtidyu, pur non disponendo di una interfaccia grafica di configurazione (il tool non è configurabile dalla SAC – Scalix Admin Console), è estremamente rapido e può facilmente essere inserito in un lavoro schedulato (cron) per essere eseguito agli intervalli preferiti con livelli di dettaglio più o meno elevati.

Con questo esempio vengono eliminati dalla Inbox (Posta In Arrivo) di tutti gli utenti, tutti i messaggi che riportano [SPAM] nell’oggetto (tag che avrà inserito il vostro filtro antispam) e che siano più vecchi di 7 giorni (presumo infatti che gli utenti abbiano spostato i messaggi di loro interesse in altre cartelle).

omtidyallu -R -T i -a 7 -t "[SPAM]"

Lo script deve essere eseguito con privilegi di root dalla console del server Scalix.