Nella gestione di calendari condivisi sembra che l'anello debole della catena sia la disponibilità di client sufficientemente evoluti. In questa installazione utilizzeremo il client Icedove con il plugin Lightning.
NOTA: Icedove è il nome che il progetto Debian utilizza al posto di Thunderbird, come Iceweasel è utilizzato al posto di Firefox. Una spiegazione di tale rebranding può essere trovata qui: Mozilla Corporation software rebranded by the Debian project.
Il plugin Lightning aggiunge le funzionalità di calendario al programma di posta Icedove. Supporta diversi tipi di calendari: iCalendar (ICS), CalDAV e Sun Java System Calendar Server (WCAP). Tralasciando la soluzione non libera WCAP, il formato CalDAV pare fornire le caratteristiche migliori, soprattutto per quanto riguarda la condivisione di calendari tra più utenti.
Debian fornisce il pacchetto davical, che contiene l'omonimo programma. In Debian Lenny il pacchetto non esiste, per fortuna è sufficiente scaricare i due pacchetti Squeeze davical e libawl-php e installarli manualmente con dpkg -i. Il programma si appoggia su un database PostgreSQL, quindi si deve installare anche il DB server.
La procedura di installazione è descritta nella pagina Installation. Qui di seguito un riassunto delle operazioni.
Il setup del database prevede di fare accesso al DB senza bisogno di password, quindi è necessario impostare quanto segue in /etc/postgresql/8.3/main/pg_hba.conf:
local davical davical_app trust local davical davical_dba trust
La procedura da lanciare è la seguente:
su postgres -c /usr/share/davical/dba/create-database.sh
Al termine viene stampata la password di admin (generata automaticamente) necessaria per accedere all'interfaccia web.
Per rendere accessibili le pagine web di amministrazione è sufficiente un link simbolico di nome davical creato nella DocumentRoot del sito (in questo esempio /var/www/):
ln -s /usr/share/davical/htdocs /var/www/davical
Si consiglia di configurare Apache per gestire un VirtualHost dedicato alle funzioni DAV, creando ad esempio il file /etc/apache2/sites-available/dav.site.org
<Directory /usr/share/davical/htdocs>
DirectoryIndex index.php
AllowOverride None
Require all granted
</Directory>
<VirtualHost *:443>
SSLEngine on
ServerName dav.site.org
SSLCertificateFile /etc/letsencrypt/live/dav.site.org/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/dav.site.org/privkey.pem
DocumentRoot /var/www/html/default
ServerAdmin postmaster@site.org
ErrorLog ${APACHE_LOG_DIR}/dav.site.org/error.log
CustomLog ${APACHE_LOG_DIR}/dav.site.org/access.log combined
Alias /dav /usr/share/davical/htdocs
RewriteEngine On
# PT is important if you are using an alias, it implies L
# Redirect /.well-known URLs
RewriteRule ^/\.well-known/(.*)$ /dav/caldav.php/.well-known/$1 [NC,PT]
# Optionally: redirect /principals/users/ as well
RewriteRule ^/principals/users/(.*)$ /dav/caldav.php/$1 [NC,PT]
RewriteRule ^/principals/resources/(.*)$ /dav/caldav.php/$1 [NC,PT]
RewriteRule ^/calendars/__uids__/(.*)$ /dav/caldav.php/$1 [NC,PT]
RewriteRule ^/addressbooks/__uids__/(.*)$ /dav/caldav.php/$1 [NC,PT]
# Redirect / requests to web login page
RedirectMatch permanent ^/$ https://dav.site.org/dav/
</VirtualHost>
La configurazione minima del server DAViCal è in /etc/davical/config.php:
$c->admin_email = 'postmaster@site.org'; $c->system_name = "DAViCal Server for Rigacci.Org"; $c->pg_connect[] = "dbname=davical user=davical_app password=PwdSecret";
Al termine della configurazione conviene impostare l'accesso al database in modalità md5 (protetta dal password), invece che trust. In /etc/postgresql/8.3/main/pg_hba.conf si imposta:
local davical davical_app md5 local davical davical_dba md5
La connessione ti tipo local significa tramite Unix domain socket, che è utilizzata come impostazione predefinita dal codice PHP di Davical. In alternativa si può approfittare della configurazione predefinita di PostgreSQL che consente l'accesso tramite TCP/IP su indirizzo localhost verificando che esista questa riga:
host all all 127.0.0.1/32 md5
Dal prompt SQL si imposta la password agli utenti:
ALTER USER davical_app PASSWORD 'PwdSecret'; ALTER USER davical_dba PASSWORD 'PwdSecret';
In /etc/davical/config.php si indica la passoword di accesso. Se viene fornito anche il parametro host la connessione avviene tramite socket TCP/IP, altrimenti viene usato uno Unix domain socket:
$c->pg_connect[] = 'dbname=davical user=davical_app host=127.0.0.1 password=PwdSecret';
visto che il file contiene una password sensibile, lo si protegge opportunamente:
chgrp www-data /etc/davical/config.php chmod 640 /etc/davical/config.php
NOTA: Non è chiaro chi e quando fa accesso con l'utente davical_dba, non l'interfaccia web. Sono gli script di installazione create-database.sh e di upgrade update-davical-database. Quindi attenzione: prima di installare un updata forse conviene rimettere l'accesso in modalità trust.
Dall'interfaccia web di amministratore è possibile creare gli utenti (principal) con la loro login e password. Automaticamente viene creato un addressbook e un calendar per ogni nuovo utente.
L'utente registrato può fare login nell'interfaccia web, da questa è possibile accedere a User Functions ⇒ List Users. Quindi la lista di tutti i principal è pubblica per gli utenti registrati. Non una bella idea se l'installazione deve essere condivisa ad esempio tra aziende diverse.
Il problema riguarda anche la pagina View My Details (pagina generale del principal), sezione Principal Grants: viene mostrato l'elenco di tutti gli utenti per permettere la condivisione. Lo stesso discorso si applica anche alla pagina di amministrazione delle Collection, nella sezione Collection Grants.
Forse c'è un sistema per mitigare il problema, vedere il post On davical´s website hide other users resources for normal users.
Quando viene aggiunto un principal di tipo user, viene aggiunta un record alla tabella principal, con i campi principal_id e user_no:
SELECT principal_id, user_no, displayname FROM principal;
principal_id | user_no | displayname
--------------+---------+-----------------------
1 | 1 | DAViCal Administrator
1001 | 1001 | Niccolo Rigacci
Il nome di login e la password (hash) sono invece nella tabella usr:
SELECT user_no, username, password FROM usr WHERE user_no = 1001;
user_no | username | password
---------+---------------------+-----------------------------------------------
1001 | niccolo@rigacci.org | *7J/zWNlkJ*{SSHA}raFPA81mbrAj+skA4SC94V01sa0o=
Al calendario e all'address book corrispondono due record nella tabella collection:
SELECT user_no, dav_name, is_calendar, collection_id FROM collection WHERE user_no = 1001;
user_no | dav_name | is_calendar | collection_id
---------+---------------------------------+-------------+---------------
1001 | /niccolo@rigacci.org/addresses/ | f | 1003
1001 | /niccolo@rigacci.org/calendar/ | t | 1002
Per ogni oggetto creato nella collection calendario (VEVENT) o addressbook (VCARD) viene creato un record nella tabella caldav_data:
SELECT dav_id, caldav_type, collection_id FROM caldav_data
WHERE user_no = 1001 AND collection_id = 1002 ORDER BY dav_id;
dav_id | caldav_type | collection_id
--------+-------------+---------------
2322 | VEVENT | 1002
2323 | VEVENT | 1002
2324 | VEVENT | 1002
2325 | VEVENT | 1002
2326 | VEVENT | 1002
2327 | VEVENT | 1002
Il campo caldav_data contiene il dato vero e proprio nel formato opportuno, ad esempio VCARD che a sua volta contiene gli eventuali tag TEL, EMAIL. PHOTO, ecc.
I dettagli della VCARD sono anche nelle tabelle addressbook_address_adr, addressbook_address_email, addressbook_address_tel e addressbook_resource.
SELECT user_no, caldav_type, fn FROM
caldav_data JOIN addressbook_resource USING (dav_id)
WHERE caldav_type = 'VCARD';
user_no | caldav_type | fn
---------+-------------+-------------
1001 | VCARD | Mario Rossi
SELECT user_no, caldav_type, tel FROM
caldav_data JOIN addressbook_address_tel USING (dav_id)
WHERE caldav_type = 'VCARD';
user_no | caldav_type | tel
---------+-------------+------------------
1001 | VCARD | +39 367 788 2732
Gli oggetti gestiti da un server DAViCal vengono definiti genericamente Principals, possono essere di tipo Users, Resources e Groups (una possibile traduzione: Protagonisti: Utenti, Risorse e Gruppi).
Il tutto viene gestito dall'interfaccia web di DAViCal, tuttavia l'interfaccia web non consente di vedere il contenuto dei calendari.
Per creare un utente: User Functions, Create Principal. Del tutto simile la procedura per creare una risorsa.
Con la versione 1.1.1 di DAViCal, durante la creazione di un utente vengono create automaticamente le collection calendar e addresses ad esso associate.
Per creare un calendario (normalmente associato ad un utente oppure ad una risorsa): List Users, click sull'utente, Principal Collections, Create Collection. Il calendario sarà identificato da un URL del tipo:
<http://host:port>/davical/caldav.php/<principal>/<collection>/
dove principal è il nome dell'utente o della risorsa e collection è il nome del calendario.
lightning-1.0b2-tb-linux.xpi. In Debian Squeeze c'è Icedove 3.0.10, bisogna installare la versione 3.1 da experimental, per fortuna basta scaricare il singolo .deb e installarlo con dpkg -ilightning-1.0b2-tb-linux.xpi.Al termine di questa procedura compaiono due nuove icone in alto a destra, nella barra dei tab: Calendario e Attività.
Dopo aver creato un calendario sul server DAViCal tramite l'interfaccia web, lo si aggiunge a Icedove con la seguente procedura:
http://<host>/davical/caldav.php/<principal>/<collection>/.$HOME/.icedove/.Per gestire la parteciapzione di persone ad eventi, lo standard CalDAV prevede l'esposizione dell'informazione Free/Busy (se una persona è libera in un determinato momento) e l'invio delle notifiche (richiesta di partecipazione, risposta di conferma).
Lightning 1.0 supporta solo parzialmente il meccanismo: l'informazione free/busy viene gestita correttamente, mentre l'invio delle notifiche viene effettuato tramite SMTP da Thunderbird invece che essere delegato al server CalDAV.
Seguendo queste indicazioni, anzitutto si modifica la configurazione del server DAViCal, in modo che non annunci la capacità di gestione notifiche, in /etc/davical/config.php si aggiunge:
$c->override_dav_header = '1, 2, access-control, calendar-access, calendar-schedule, extended-mkcol, calendar-proxy, bind';
cioè viene nascosta al client la caratteristiche calendar-auto-schedule (vedere l'impostazione predefinita in /usr/share/davical/htdocs/caldav.php).
Per creare un evento ed invitare i partecipanti:
Lightning/Thunderbird invia una mail di notifica a ciascundo degli invitati, se l'invitato riponde affermativamente (deve avere il plugin Lightning installato) la mail di conferma viene recapitata nella nostra mailbox. Thunderbird/Lightning riconosce tale riposta ed evidenzia che il messaggio contiene modifiche ad un evento, con il pulsante apposito accettiamo le modifiche.
A questo punto possiamo aprire nuovamente l'evento, cliccando sull'elenco dei partecipanti vedremo chi ha accettato l'invito evidenziato da un bollino verde.