Avete mai desiderato un comodo calendario personale sempre online da usare quando e come volete senza bisogno di far sapere ai vari google di turno cosa dovete fare il giovedì pomeriggio? 😉
La soluzione è piuttosto semplice e alla portata di chiunque abbia un server apache2 a disposizione.

Installazione, configurazione ed utilizzo

Ma andiamo con ordine! Se non avete già installato questo web server, fatelo ora, usando il metodo più appropriato per la vostra distribuzione linux preferita. A questo punto dovete editare il file di configurazione di default che può essere apache2.conf oppure httpd.conf e assicurarsi che siano abilitati seguenti moduli:

• mod_authn_file
• mod_authz_user
• mod_auth_basic
• mod_auth_digest
• mod_dav_fs

I primi moduli sono necessari per regolare l’accesso alle risorse di apache, l’ultimo è quello che gestirà tutto il calendario.
Bene, ora modificate la configurazione del modulo dav_fs inserendo le segenti voci:

DavLockDB "/usr/var/DavLock"

    Dav On

    Order Allow,Deny
    Allow from all

    AuthType Digest
    AuthName calendars

    AuthUserFile "/usr/user.passwd"
    AuthDigestProvider file

    
        require user nomeutente
    

La creazione del file /usr/user.passwd si effettua attraverso il seguente, semplice comando:

$ htdigest -c "/usr/user.passwd" calendars nomeutente

Ovviamente per le direttive siete liberissimi di scegliere i percorsi che più vi aggradano.
Vediamo cosa vogliono dire le varie opzioni:

• DavLockDB serve per specificare quale file apache userà come file di lock per impedire rovinose scritture simultanee sui file gestiti via dav_fs
• Dav On usato all’interno di un tag Directory abilita la gestione di quella cartella tramite il modulo dav_fs
• Seguono le direttive standard per gestire l’autenticazione degli utenti tramite file di password
• Infine con la direttiva LimitExcept si definisce il livello di accesso alle risorse

Questa ultima direttiva è decisamente importante: il modulo dav_fs permette di eseguire degli upload di file sul proprio web server e sicuramente non vogliamo che tale comportamento sia aperto e disponibile a qualsiasi utente di internet!
Così come è scritta, la direttiva richiede un accesso autenticato sia per la modifica dei calendari che per la loro lettura, se volessimo rilassare i permessi, possiamo usare LimitExcept GET OPTIONS: in questo modo è possibile a utenti non autenticati di visionare i file salvati in /calendars ma, francamente, sconsiglio di eseguire questo tipo di rilassamento.
Bene, il server è pronto! Aprite la vostra applicazione di calendaring preferita, potete create un nuovo calendario all’indirizzo http://server/calendars/calendario.ics e usarlo per la gestione dei vostri appuntamenti.

Possibili miglioramenti

Prima di concludere, lascio qualche considerazione per possibili migliorie:

• L’acesso protetto da password serve per controllare chi può accedere alle risorse e chi no, ma senza un adeguato supporto crittografigo risulta quasi inutile: vi consiglio di combinare questa configurazione con il supporto di apache per https o di modificare la regola Allow from per restringere l’accesso alle risorse solo da connessioni sicure come tunnel ssh o vpn
• L’architettura presentata è pensata per un calendar server casalingo, tuttavia scala bene se vogliamo tenere directory separate tra più utenti: basta replicare il blocco di direttive Directory per ogni utenza che si vuole aggiungere adattandola, ovviamente, al nuovo username. I problemi nascono quando si vogliono condividere i calendari in sola lettura:
  • Una prima soluzione, semplice, consiste nel mettersi d’accordo sull’accesso alle risorse: gli stessi client permettono di scegliere se impotare i calendari in sola lettura o meno.
  • Una seconda soluzione, più complessa, prevede l’utilizzo di più direttive Limit al posto di una LimitExcept, in questo modo potremmo usare, per esempio, Limit GET OPTIONS su valid_users per permettere la sola lettura agli utenti autenticati e Limit PUT al proprietario del calendario per permettere solo a lui la modifica dei contenuti. Tale strada, però, può essere potenzialmente pericolosa in caso di utilizzo di metodi http sconosciuti, per maggiori informazioni vi rimando alla documentazione ufficiale delle due direttive
• In questo articolo abbiamo usato il modulo dav_fs solo per gestire un file .ics ma in realtà abbiamo configurato un vero e proprio storage personale sul vostro server apache: potete prendere un qualsiasi client dav e caricare file sotto la cartella /calendars

Conclusioni

Questo è tutto! Come avete potuto notare la creazione di un server per un calendario remoto personale non è poi tanto difficile, per quanto riguarda invece gli ambienti enterprise questa soluzione potrebbe essere un po troppo stretta ma in questo caso si possono applicare le altre idee proposte oppure sposarsi su programmi dedicati come la suite Zimbra oppure il Calendar Server di Apple.

Alla prossima!

Marco Bonetti