Come è noto Scalix offre un connettore per Outlook che funziona quale strato di emulazione MAPI: in parole povere Outlook funziona connesso a Scalix come se dietro ci fosse Exchange. Tra le caratteristiche salienti di questo connettore vi è la possibilità di implementare un sistema di SSO (Single Sign On) ovvero quella tecnica per la quale, all’apertura di Outlook, l’utente non dovrà inserire alcuna password nè vi sarà necessità di memorizzarne una nel profilo. In questo modo le policy di scadenza delle password di Windows potranno essere tranquillamente mantenute e l’autenticazione a Scalix avverrà tramite scambio di gettoni (token) Kerberos.

La parte propedeutica alla attivazione del sistema SSO prevede la configurazione di agreement di sincronizzazione con Active Directory (ovviamente dovete avere un Dominio AD configurato) tramite il quale Scalix “carica” e mantiene aggiornati gli utenti secondo quanto specificato in AD. Questa parte non è argomento di questo post.

Quello di cui mi voglio occupare invece è la parte in cui la documentazione Scalix richiede la creazione di un account speciale “scalix-ual” che serve per lo scambio dei messaggi Kerberos tra il server Scalix ed il server Windows. La procedura prevede la creazione, appunto, di un normale account utente chiamato scalix-ual (potrebbe anche essere un altro nome ma bisognerebbe spippolare poi nella configurazione di Scalix per cambiare il principal name), assegnargli una password, generare un file keytab tramite i Support Tools di Windows, ed importare il keytab generato nel database del server Scalix. (Scalix Setup and Administration Guide 11.3 pagina 54 e successive).

La procedura è corretta … tranne in un caso : ovvero quando avete configurato Samba sul vostro server Scalix e avete fatto il join al dominio di Windows.

In questo secondo scenario, infatti, la procedura con cui Samba si aggancia al dominio prevede la creazione di un account per il computer nel container Computer di AD e contestualmente genera anche un database keytab per Kerberos. Se, essendo in questa situazione, seguite la procedura indicata da Scalix per l’implementazione del Kerberos SSO vi troverete con :

• Diversi errori nel log degli eventi del server Windows (sezione Sistema) con ID Evento 11 e origine KDC. Il messaggio (in inglese) recita così : There are multiple accounts with name scalix-ual/HOST.FQDN of type DS_SERVICE_PRINCIPAL_NAME.
• L’autenticazione dei client Outlook fallisce sistematicamente

Questo comportamento è dovuto al fatto che già l’account del computer inserito in dominio ricopre la funzione di Principal per lo scambio di messaggi Kerberos e accoglie in maniera jolly tutte le richieste di servizio Kerberos. Creare un secondo account utente per questo scopo causa l’errore KDC 11.

Se avete inserito il server Scalix in un dominio AD tramite Samba tutto quello che dovete fare è editare, in active directory, l’account del computer, accedere al tab Delega ed abilitare l’opzione “Considera attendibile per tutti i servizi (Solo Kerberos)”.

Non c’è null’altro da fare.

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.

Dopo un paio d’anni di onesta militanza del nostro Scalix 11.3 ospitato da una datata SuSE 10.1 era arrivato il momento di aggiornare alla versione ultima disponibile 11.4.3. Sfortunamente, causa fretta, non mi sono letto le specifiche di compatibilità di Scalix 11.4.3 e, sull’onda dell’entusiasmo, ho installato una SuSE 11.1 per accorgermi che su questa release di distribuzione Scalix non funziona. E’ garantita infatti la compatibilità solo con la 11.0 a causa del compilatore GCC.

Dopo aver perso diverse ore per scaricarmi la 11.1 non avevo assolutamente intenzione di perdere nuovamente altro tempo per riscaricare il DVD della SuSE 11.0 e ho deciso di darmi un’occhiata in giro per valutare soluzioni host alternative. Ho optato alla fine per CentOS 5.3 (compatibile con Scalix 11.4.3) e, al termine della procedura che sto per descrivervi, si è rivelata una scelta assolutamente vincente.

Ecco dunque come procedere per spostare Scalix da un server ad un altro oppure per migrare Scalix su un’altra distribuzione Linux.

1. Preparare il necessario: prima di cominciare prendete nota della versione di Scalix che avete attualmente installato ed accertatevi di avere a disposizione il package di installazione corrispondente. In questo caso, avendo in produzione Scalix 11.3 ho scaricato i binari di installazione per RedHat/CentOS che sarà la distribuzione che installerò. Ovviamente, già che ci siete, scaricatevi anche i binari di installazione di Scalix 11.4.3 (o i più recenti se ve ne sono) per la stessa distribuzione.
    
2. Una bella copia di backup, magari due: salti nel buio non se ne fanno. Prima di iniziare ho effettuato un bell’export di tutte le nostre mailbox e delle cartelle pubbliche configurate sul nostro server utilizzando l’utilità sxstoreexp. Questo tipo di esportazione non è veramente completa in quanto esporta solo i dati contenuti nelle cartelle e nelle mailbox ma non si porta dietro le eventuali regole automatiche configurate per i singoli utenti (come ad esempio le regole “Fuori Ufficio”). E’ comunque una bella ancora di salvezza perchè, nel caso, potrete comunque ricreare tutta la struttura del server di posta e poi a manina rimettere al loro posto le regole. Salvatevi il contenuto della copia in un bel dvd o su un disco di rete o dove ritenete opportuno. Nel mio caso ho effettuato il travaso su un minidisk LaCie formattato in NFTS che mi ha obbligato a montare sulla mia “vecchia” SuSE 10.1 i driver ntfs-3G per poter scrivere con Linux su dischi NTFS.
   La seconda copia da effettuare è quella che verrà utilizzata per la migrazione vera e propria: tutto quello che dovete fare è crearvi un archivio dell’intero contenuto della directory /var/opt/scalix/xx/s/ (dove xx sono la prima e l’ultima lettera del nome host della macchina su cui è installato Scalix: nel mio caso la macchina si chiama suse1 e quindi la directory completa è /var/opt/scalix/s1/s). Salvatevi anche questo archivio da qualche parte (potrebbe volerci del tempo in funzione delle dimensioni).
    
3. Installiamo la nuova distro: siamo ora pronti per “brasare” la vecchia suse e rimpiazzarla con CentOS. Se avete già a disposizione un server Linux installato con la nuova distribuzione saltate questo punto. Per la mia installazione ho optato per la modalità via rete (mi sono scaricato solo il disco di boot per l’installazione di rete). Durante il setup ho apprezzato di CentOS il fatto che per impostazione predefinita propone un minimo set di applicazioni lasciando poi ad una fase successiva la possibilità di “ampliare” le funzionalità. Questo ovviamente riduce i tempi installazione. Già che c’ero ho comunque richiesto l’installazione dei componenti minimi per poter far funzionare Scalix e quindi ho incluso Apache, il supporto Java, Sendmail, Postgres, gcc, compat-libsdtc.
   L’installazione è andata senza problemi di sorta (ottimo!!!) ed ha richiesto circa 40 minuti tra il download dei pacchetti ed il setup. Alla fine effettuo il login nel nuovo desktop Gnome. Nota personale: le differenze tra SuSE e CentOS sono evidenti in prima battuta nella differenti “preferenze” desktop. Il nuovo KDE 4 che ho già assaggiato sulla SuSE 11.1 sarà anche bello graficamente ma non è proprio il prototipo della leggerezza mentre Gnome mantiene ancora quel fascino delle “cose antiche” con il quale ho ancora tanta familiarità. Ok sono pronto per procedere. A proposito : il mio nuovo server non si chiama più suse1 ma gli ho dato un nuovo nome : scalix1. Questa nota è fondamentale (e avendolo saputo prima non l’avrei fatto) perchè tutti i dati di scalix sono profondamente legati al nome dell’host su cui è installato. Grazie al cielo si può ovviare al problema ma … ci sarà del lavoro da fare.
    
4. Nuovo Server … installiamo Scalix. Installo sul nuovo server il pacchetto di Scalix “vecchio”. Ero in produzione con Scalix 11.3 e quindi reinstallo la 11.3 (questa volta per CentOS). In questo modo sono ragionevolmente sicuro che la struttura di dati e directory sarà la stessa. L’installazione di Scalix su CentOS è dannatamente veloce (almeno il doppio della velocità che avevo sperimentato sulla vecchia SuSE (con lo stesso identico hardware) ed in pochi minuti ho Scalix up-and-running. Ovviamente vuoto e con solo gli account di base (sxadmin e sxqueryadmin) ed i 4 gruppi amministrativi di base.
    
5. ClamAV era installato ? Se avevate installato, come me, ClamAV è arrivato il momento di installarlo. Se non lo avevate montato passate al punto successivo.
   Per installare ClamAV su CentOS i passi sono brevi e semplicissimi. Utilizzeremo i binari di Dag Wieers RPM per Red Hat, RHEL, CentOS e Fedora.
   Aprite una finestra Terminal con privilegi di root e digitate il comando :
    
   cd /etc/yum.repos.d

   Scaricate ora i file di configurazione del repository digitando il comando
    
   wget http://www.linux-mail.info/files/dag-clamav.repo
    
   Siamo ora pronti per avviare l’installazione di ClamAV che avvieremo con il comando:
    
   yum install clamav clamav-devel clamd
    
   alla richiesta di conferma del download confermate con Y.
   Al termine dell’installazione lanciate il comando freshclam (che effettuerà l’aggiornamento del db delle impronte virali) e provate con clamscan la scansione di una directory qualsiasi. L’installazione di ClamAV crea un nuovo utente di sistema che si chiama clamav. Prima di procedere assicuratevi che l’utente clamav venga inserito anche nel gruppo scalix.
    

6. E’ ora di ripristinare la nostra vecchia base dati. Arrestiamo tutti i servizi di Scalix e Sendmail sempre da riga di comando digitando :
    
   /etc/init.d/scalix stop <enter>
/etc/init.d/sendmail stop <enter>
    
   Siamo ora pronti per recuperare l’archivio che abbiamo salvato dalla vecchia /var/opt/scalix/s1/s ed espanderlo all’interno della nuova directory s che si trova nel percorso /var/opt/scalix/xx/ (dove xx sono la prima e l’ultima lettera del nome host della macchina su cui è installato Scalix: nel mio caso la macchina si chiama scalix1 e quindi la directory completa è /var/opt/scalix/s1/s). Attenzione ! non fatevi ingannare da questa similitudine. Il fatto che il nome dell’istanza sia ancora s1 non vuol dire nulla: il nome host è comunque cambiato da suse1 a scalix1 quindi abbiamo del lavoro da fare !!
   A questo punto siamo pronti per alcune verifiche e correzioni: per prima cosa dobbiamo verificare che i permessi sui file che abbiamo appena ripristinato dall’archivio tar siano corretti e che non ci siano errori. Lanciate quindi il seguente comando :
    
   omcheck -i -d <enter>

   ed esaminate i risultati. Se gli errori rilevati sono pochi potrete effettuare le correzioni a mano, in caso contrario o comunque se volete essere sicuri potete eseguire :
   
omcheck -s -d > /tmp/scalixfix.sh <enter>
sh /tmp/scalixfix.sh <enter>
    
   Questa procedura ripristinerà i corretti permessi e farà il touch di file eventualmente mancanti.
    

7. Correggiamo il nome host : se il nome host del vostro server non è cambiato potete saltare questo passo, altrimenti, come me, dovrete eseguire questa procedura per poter modificare i file interni di configurazione di Scalix in modo che puntino al nome host corretto. Cominciamo (l’articolo completo su come fare lo trovate qui.) :
   Dunque il mio vecchio server si chiamava suse1.anlan.com mentre questo nuovo si chiama scalix1.anlan.com. Dobbiamo modificare le impostazioni del nodo sulle impostazioni di utenti e cartelle digitanto il seguente comando :
    
   sxmodfqdn -o suse1.anlan.com -n scalix1.anlan.com <enter>
    
   Questa procedura si passa tutte le entità interne di scalix ed effettua la correzione. Ma non è ancora finita: dovremo fare le opportune modifiche anche su altri file di configurazione che si trovano nella directory di scalix. Questa istruzione consente la modifica automatica di tutto quanto necessario:
   
[root@scalix1 ~]# source /opt/scalix/global/config; \
for i in /var/opt/scalix//* ; do \
if [ $i != $OMDATADIR ]; then \
sed -i -e 's/suse1.anlan.com/scalix1.anlan.com/g' \
`grep -iRl suse1.anlan.com $i 2>/dev/null \
| egrep -iv 'scalix1.anlan.com|logs|indexes|postgres/data' \
| xargs`; fi; done <enter>
 
per essere sicuri dell’esito del comando digitate :
   
[root@scalix1 ~]# source /opt/scalix/global/config; for i in /var/opt/scalix//* ; do \
if [ $i != $OMDATADIR ]; then grep -iR $OMHOSTNAME $i 2>/dev/null| egrep -iv 'logs|indexes|postgres/data'; \
fi; done <enter>

   per ottenere un output di questo titpo:
   
/var/opt/scalix/s1/caa/scalix.res/config/ubermanager.properties:ubermanager.query.server=scalix1.anlan.com
/var/opt/scalix/s1/caa/scalix.res/config/ubermanager.properties:ubermanager.console.localDomains=scalix1.anlan.com
/var/opt/scalix/s1/mobile/mobile.properties:platform.url=scalix1.anlan.com
/var/opt/scalix/s1/platform/platform.properties:imap.host=scalix1.anlan.com
/var/opt/scalix/s1/platform/platform.properties:smtp.host=scalix1.anlan.com
/var/opt/scalix/s1/platform/platform.properties:hibernate.connection.url = jdbc:postgresql://scalix1.anlan.com:5733/scalix
/var/opt/scalix/s1/res/config/res.properties:res.ubermanager.host=scalix1.anlan.com
/var/opt/scalix/s1/res/config/res.properties:res.kerberos.allowedclients=ubermanager/scalix1.anlan.com
/var/opt/scalix/s1/webmail/swa.properties:swa.email.domain=scalix1.anlan.com
/var/opt/scalix/s1/webmail/swa.properties:swa.email.imapServer=scalix1.anlan.com
/var/opt/scalix/s1/webmail/swa.properties:swa.email.smtpServer=scalix1.anlan.com
/var/opt/scalix/s1/webmail/swa.properties:swa.platform.url=http://scalix1.anlan.com:8080/api
/var/opt/scalix/s1/webmail/swa.properties:swa.ldap.1.server=scalix1.anlan.com
/var/opt/scalix/s1/webmail/swa.properties:swa.ldap.2.server=scalix1.anlan.com
 
   Da ultimo dovremo correggere tutti gli URL del servizio SIS che sono memorizzati all’interno di ogni account. Infatti se digitiamo il comando :
   
[root@scalix ~]# omshowu -n sxadmin
Authentication ID: sxadmin
...
SIS URL : sxidx://suse1.anlan.com/0d100000d97e5164-041.261.961.18
vediamo come il puntamento sia ancora indirizzato al servizio SIS del “vecchio” server. Potremo facilmente cambiare l’impostazione su tutti gli account con questo comando :

   omshowu -m all| while read line; do ommodu "$line" --index `omshowu -n "$line"|grep -i sis|\
sed -e 's/^.*suse1.anlan.com/sxidx:\/\/scalix1.anlan.com/g'`; done


   L’ultima operazione richiesta prevede la correzione del mapping al mailnode corretto. Infatti se digitiamo il comando per la visualizzazione del mailnode corrente otterremo :
   
[root@scalix1 ~]# omshowmnmp <enter>
suse1 suse1.anlan.com


   che non è corretto in quanto è l’impostazione del vecchio server. Per correggerla dobbiamo eliminarla e crearla nuova.

    [root@scalix1 ~]# omdelmnmp suse1 <enter>
Disabling 1 subsystem(s).
Directory Relay Server Stopped
Enabling 1 subsystem(s).
Directory Relay Server Started

    [root@scalix1 ~]# omaddmnmp scalix1 scalix1.anlan.com <enter>
Disabling 1 subsystem(s).
Directory Relay Server Stopped
Enabling 1 subsystem(s).
Directory Relay Server Started
[root@scalix1 ~]# omshowmnmp
scalix1 scalix1.anlan.com 

8. Ok tutto fatto. Potete riavviare il server e tornare ad operare con il vostro Scalix aggiornato. Non dimenticate che se avete cambiato il nome di host o l’indirizzo ip del server, dovrete modificare le impostazioni di connessione dei client.

Sempre più spesso mi imbatto in piccole/piccolissime realtà aziendali per le quali l’esigenza di un budget stringato è imperativa. Specialmente quando si parla di piccole start-up. Paradossalmente, tuttavia, il costo inziale delle licenze software che queste sopportano è decisamente elevato … sempre che lo abbiano effettivamente sopportato (in questo caso ovviamente il costo è occulto nella forma di un rischio che alcuni “imprenditori” si assumono).

Le motivazioni di questa scelta sono le più variegate anche se, nella maggioranza dei casi, possono essere ricondotte a queste semplici tipolgie : una mancanza di conoscenza delle possibilità alternative, la “sicurezza” data dal fatto che il cugino-del-nipote-del-fratello-di-mio-zio da una mano a mettere su il server, la non-voglia di tirarsi un po’ su’ le maniche. E succede allora che, magari complice il fatto che ci si è ritrovata in mano una copia anonima, in quattro e quattr’otto si è messo su un bel server Windows corredato da Exchange, SQL Server e servizi Fax: giusto quel tanto che basta per avviare l’ufficio unitamente alla bella ADSL nuova nuova. Facciamo finta di niente poi se tutti i client, per risparmiare, sono Windows XP Home Edition oppure Vista Basic e le copie di Microsoft Office non sono proprio tutte con licenza regolare.

Eppure la soluzione alternativa c’è, costa poco e comunque una frazione del costo complessivo risultante dall’acquisizione di un server Windows based, dei necessari software di protezione (e che non vogliamo mettere un antivirus su un server Windows ??) degli applicativi server ed infine delle licenze CAL.

Vediamo come si potrebbe fare.

Partiamo dal server : comprare un server “vuoto” costa sicuramente meno di uno con Windows preinstallato … questo va da se. Ma poi che quale sistema operativo ci metto ? Linux ! Si ma quale ? La scelta tra le distribuzioni può risultare ardua se non altro perchè non si conoscono le caratteristiche di ognuna. Lungi da me l’intenzione di premiare un nome al posto di un altro però posso suggerire che openSUSE 11.0 è un buon punto di partenza. Il sistema operativo si installerà già con le funzionalità necessarie a creare un sistema di cartelle condivise sul server per l’archiviazione centralizzata (Samba). E qui siamo già al 90% delle esigenze di una piccola lan … coperte. Ma se si vuole spingersi un po’ più a fondo troveremo tra i vari applicativi, sempre rigorosamente gratuiti, Squid (per far diventare il nostro server un proxy per l’accesso ad internet), il firewall (per proteggersi dagli accessi indesiderati), Bind (per avere il proprio server DNS interno), il servizio DHCP (per distribuire l’assegnazione degli indirizzi IP in rete) ecc. Insomma … tutto quello che è disponibile anche per il server Windows ma ancora non avete speso il becco di un quattrino (a parte la macchina ed il tempo che ci state mettendo per configurare il tutto). Volete anche l’autenticazione centralizzata ? Nessun problema … con LDAP e un po’ di olio di gomito potete gestire l’accesso ai client tramite autenticazione centralizzata.

Ok … il server è su … i file sono condivisi. Che serve ancora ? Molti potrebbero sentire l’esigenza di disporre di un server groupware (per la posta elettronica, le rubriche condivise, i calendari condivisi e, perchè no, la possibilità di consultare la posta dell’ufficio da fuori tramite webmail). L’associazione mentale del problema con Microsoft Exchange è praticamente immediata. A questo punto entrano in gioco varie possibili soluzioni compatibili con il vostro server Linux nuovo di zecca. Per semplicità e per non mettere troppa carne al fuoco ve ne segnalo una : Scalix. Si tratta di un server di posta che “clona” quasi tutte le caratteristiche di Exchange e, molto importante, è utilizzabile direttamente tramite Microsoft Outlook (che quasi certamente vorrete sui computer client) anche se potreste farne tranquillamente a meno visto che dispone di una webmail (accessibile sia da dentro la rete che da fuori) che non ha nulla da invidiare al blasonato prodotto di casa Redmondiana. Dimenticavo : se in rete siete al massimo 10 utenti … non costa nulla.

Già sento le prima obiezioni … “si ma io non ho un dominio di posta elettronica e non posso far recapitare la posta direttamente al mio server … la devo scaricare dal mio provider”. La prima risposta che mi viene in mente è : registratevi un dominio santo cielo. Costa talmente poco ormai che il gioco vale la candela … e poi volete mettere quanto ne guadagna l’immagine ? Ma se proprio non volete o non potete farlo (magari la vostra Adsl non dispone di un IP fisso … ) non ci sono problemi : la soluzione si chiama fetchmail ed esegue, meglio a mio parere, il lavoro di tanti POP3 connectors che si trovano in giro magari a pagamento.  Anche fetchmail è gratuito e direttamente installabile dal gestore pacchetti della vostra openSUSE.

Vediamo … cosa manca ora ? Vi serve percaso il fax elettronico che vi mandi direttamente nella casella di posta i documenti ricevuti in PDF ? Sai quanta carta risparmiata e quanti fax pubblicitari cancellati con un clic senza doverli mettere nella risma da riciclare ? Anche qui il mondo open vi viene in aiuto: HylaFax è il servizio fax per Linux che si interfaccia perfettamente con il vostro Scalix e potrete utilizzarlo sia per ricevere fax che per inviarli direttamente dal computer (si si … anche dal computer Windows).

Serve altro ? Diciamo che per avviare l’ufficio questo dovrebbe essere sufficiente … tenete comunque presente che grazie al Web server (Apache) integrato nella vostra openSUSE (come in qualsiasi altra distribuzione Linux) potrete scegliere tra una miriade di applicazioni Web based per la gestione dei progetti di lavoro, per la fatturazione, per la contabilità (basica) ecc. appoggiandovi anche al database MySql che, come per tutto il resto, non vi costerà nulla (a parte un po’ di tempo … lo ripeto).

Passiamo ora ai client: molto probabilmente avrete già comprato una serie di Pc Windows. Su questo potreste ancora aver avuto ragione visto che vorrete collegarci il black-berry, la fotocamera, il lettore MP3, ecc. ecc. Esistono soluzioni che vi permettono di fare le stesse cose anche su Linux ma per il momento sono un poco macchinose e non voglio farvi perdere ore di sonno per sacramentare durante la ricerca di un driver. Però è possibile risparmiare qualcosa nel pieno rispetto della legge anche nella oculata scelta delle dotazioni software da regalare ai vostri pc.

Per esempio, se proprio non avete bisogno di Microsoft Access, potrete optare per OpenOffice al posto di Microsoft Office. Di conseguenza rinuncereste anche ad Outlook ma, come vi ho già detto, niente paura perchè Scalix vi offre già tutto quello che serve tramite la sua Webmail. E se proprio non potete fare a meno di un client di posta provate ad utilizzare Thunderbird corredato del plugin Lightning: avrete comunque cartelle e calendari condivisi.

Insomma … dovendo partire con una nuova piccola rete perchè non valutare le alternative ? Una configurazione come questa, paragonata ad una identica basata su server Windows con tutte le licenze in regola, vi potrebbe far risparmiare, se si calcolano una decina di utenti, circa 5.000 euro !!! Sono pochi ? … al giorno d’oggi non credo !

Chiedete, informatevi … non costa nulla e nel mondo open sicuramente troverete gente appassionata e competente. In fondo è meglio spendere qualcosa per avere una consulenza qualificata e poi sentire che il sistema è “vostro” piuttosto che comprare qualcosa che vostro non sarà mai.