Un calendario personale con Apache

Calendar Server
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!

5 risposte a “Un calendario personale con Apache”

  1. Avatar Rampage
    Rampage

    Interessante come cosa, ma volevo chiederti, la sincronizzazione del calendario è bidirezionale? o ogni volta va uploadato il contenuto?

    mi spiego: quando io uso il protocollo calDAV con google calendar, non appena creo un evento sul mio calendario sunbird, automaticamente me lo ritrovo dopo 1 istante anche su google calendar, e viceversa, lo stesso accade qui con apache?

  2. Avatar Marco Bonetti

    la sincronizzazione è come il cucchiaio di matrix: non esiste 😀
    quando usi webDAV per un calendario stai modificando un file direttamente sul server web: che tu lo legga da sunbird, google-calendar o via GET ottieni sempre lo stesso file. webDAV ti assicura che il file non venga corrotto da scritture simultanee utilizzando un lock (la direttiva DavLockDB di apache).
    calDAV è una versione modificata di webDAV che aggiunge un paio di cosette in più come le scritture simultanee e i ruoli ma per il resto è compatibile con webDAV per la trasmissione dei dati.

  3. Avatar mario pedrazzoli
    mario pedrazzoli

    L’avevo implementato anch’io così, ma sunbird, nelle sue varie versioni per win e mac, per files un po’ grandicelli, diciamo sopra i 100k, fa un po’ fatica a renderizzare, e d itanto in tanto causa la corruzione dei files ics. Stavo cercando un server “intelligente”, ovvero che facesse lavorare apache con un interpretato tipo php e che si poggiasse su un db come mysql: quache idea?

  4. Avatar Marco Bonetti

    Ciao Mario,
    se vuoi passare a soluzioni meno casalinghe e più professionali, ti consiglio Zimbra o Calendar Server. Il primo in realtà fa moltissime cose e il calendario è solo una parte (è una infrastruttura completa mail+chat+calendar e molto altro ancora), un po esoso di risorse ma ricco di soddisfazioni. Il secondo è uno dei prodotti open source di Apple, un po rognoso per essere installato (il supporto fuori da OS X e Red Hat è quasi inesistente) ma funziona abbastanza bene.

  5. Avatar salvatore
    salvatore

    articolo che inizia bene e lasciato in aria.
    Scusa ma poi, dopo aver modificato i file di connfigurazione ?
    devo mettere un file ics in qualche cartella ?

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *