User Tools

Site Tools


doc:appunti:linux:sa:davical

This is an old revision of the document!


Calendario DAViCal

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.

Installazione del server DAViCal

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:

ln -s /usr/share/davical/htdocs /var/www/davical

Nelle impostazioni di Apache (/etc/apache2/sites-available/default) si aggiunge:

    # DAViCal settings.
    Alias /images/ /usr/share/davical/htdocs/images/
    <Directory /usr/share/davical/htdocs/>
        AllowOverride None
        Order allow,deny
        Allow from all
    </Directory>
    php_value include_path /usr/share/awl/inc
    php_value magic_quotes_gpc 0
    php_value register_globals 0
    #php_value error_reporting "E_ALL & ~E_NOTICE"
    php_value default_charset "utf-8"

La configurazione minima del server DAViCal è in /etc/davical/config.php:

  $c->admin_email = 'davical@rigacci.org';
  $c->system_name = "Server DAViCal Rigacci.Org";
  $c->pg_connect[] = 'dbname=davical port=5432 user=davical_app';

Sicurezza accesso PostgreSQL

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

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 passowrd di accesso

$c->pg_connect[] = 'dbname=davical port=5432 user=davical_app password=PwdSecret';

e si protegge opportunamente il file:

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.

Probalema Privacy List Users

Dall'interfaccia web di amministratore è possibile creare creati gli utenti (principal) con la loro login e password. Automaticamente viene creato un addressbook e un calendar per ogni nuovo utente.

Anche l'utente può fare login nell'interfaccia web, dalla quale è possibile accedere a User FunctionsList Users. Quindi la lista di tutti i principal è pubblica per gli utenti registrati. Non una bella idea se l'installazione deve essere condivisa.

Forse c'è un sistema per mitigare il problema, vedere il post On davical´s website hide other users resources for normal users.

Struttura del database

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:

davical=# 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 nel calendario (VEVENT) o nell'addressbook (VCARD) viene creato un record nella tabella caldav_data:

SELECT user_no, caldav_type, dav_id, collection_id FROM caldav_data WHERE user_no = 1001;
 user_no | caldav_type | dav_id | collection_id 
---------+-------------+--------+---------------
    1001 | VEVENT      |   1006 |          1002
    1001 | VCARD       |   1009 |          1003

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. FIXME Come mai ci sono record duplicati? Sono duplicati anche nel dato VCARD.

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
    1001 | VCARD       | +39 367 788 2732
    1001 | VCARD       | +39 367 788 2732
    1001 | VCARD       | +39 367 788 2732

Terminologia di un server DAViCal

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).

  • I calendari sono collezioni di oggetti di tipo risorsa.
  • In teoria tutti i protagonisti possono avere dei calendari, ma normalmente solo gli utenti e le risorse li hanno.
  • Gli utenti sono coloro che normalmente fanno logon, a differenza delle risorse e dei gruppi che non fanno logon.
  • I gruppi consentono di assegnare i permessi (grant) a diversi protagonisti in un colpo solo.

Creazione di un utente e di un calendario

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.

Configurazione di Lightning su Thunderbird/Icedove

  • Scaricare il plugin da mozilla.org, ad esempio 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 -i
  • Da Icedove: Strumenti, Componenti aggiuntivi, Installa…, sfogliare il contenuto del disco e cliccare su lightning-1.0b2-tb-linux.xpi.
  • Riavviare di Icedove.

Al termine di questa procedura compaiono due nuove icone in alto a destra, nella barra dei tab: Calendario e Attività.

Aggiunta di un calendario

Dopo aver creato un calendario sul server DAViCal tramite l'interfaccia web, lo si aggiunge a Icedove con la seguente procedura:

  • Calendario, click destro, Nuovo calendario…, Sulla rete, CalDAV.
  • Come Luogo indicare l'URL del calendario, qualcosa del tipo http://<host>/davical/caldav.php/<principal>/<collection>/.
  • Dare un nome al calendario, verrà usato da Icedove per identificarlo.
  • Viene richiesto nome/password per accedere al server DAViCal.
  • Spuntando Utilizzare Gestione password la password viene memorizzata da Icedove e può essere gestita da Modifica, Preferenze, Sicurezza, Password, Password salvate…. Altrimenti la password viene salvata in qualche file di configurazione in $HOME/.icedove/.

Scheduling e Free/Busy

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:

  1. Nel tab Calendario attivare e selezionare un calendario CalDAV.
  2. Click destro sul planner al giorno desiderato, New event….
  3. Click su Invite Attendees.
  4. Digitare l'indirizzo email degli invitati, la ricerca viene fatta per indirizzo email, che quindi deve essere stato inserito nell'account CalDAV. Le informazioni Free/Busy vengono recuperate in tempo reale e mostrate nel planner.
  5. Chiudere la finestra degli inviti.
  6. Spuntare la casella Notify attendees e cliccare Save and Close.

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.

doc/appunti/linux/sa/davical.1541919378.txt.gz · Last modified: 2018/11/11 07:56 by niccolo