rigacci.org

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Server DAViCal per calendari e contatti ======

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: [[http://en.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_the_Debian_project|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 **[[http://packages.debian.org/search?keywords=davical&searchon=names&suite=all&section=all|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 **[[http://davical.org/installation.php|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''**:

<file>
local   davical    davical_app   trust
local   davical    davical_dba   trust
</file>

La procedura da lanciare è la seguente:

<code>
su postgres -c /usr/share/davical/dba/create-database.sh
</code>

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:

<code>
ln -s /usr/share/davical/htdocs /var/www/davical
</code>

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**

<file>
<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>
</file>

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

<code 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";
</code>

==== 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:

<file>
local   davical    davical_app   md5
local   davical    davical_dba   md5
</file>

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:

<file>
host    all    all    127.0.0.1/32    md5
</file>

Dal prompt SQL si imposta la password agli utenti:

<code sql>
ALTER USER davical_app PASSWORD 'PwdSecret';
ALTER USER davical_dba PASSWORD 'PwdSecret';
</code>

In ''/etc/davical/config.php'' si indica la **passowrd** di accesso. Se viene fornito anche il parametro **host** la connessione avviene tramite socket TCP/IP, altrimenti viene usato uno Unix domain socket:

<code php>
$c->pg_connect[] = 'dbname=davical user=davical_app host=127.0.0.1 password=PwdSecret';
</code>

visto che il file contiene una password sensibile, lo si protegge opportunamente:

<code>
chgrp www-data /etc/davical/config.php
chmod 640 /etc/davical/config.php
</code>

**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 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 **[[https://linuxich.wordpress.com/on-davicals-website-hide-other-users-resources-for-normal-users/|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**:

<code>
SELECT principal_id, user_no, displayname FROM principal;
 principal_id | user_no |      displayname      
--------------+---------+-----------------------
            1 |       1 | DAViCal Administrator
         1001 |    1001 | Niccolo Rigacci
</code>

Il nome di login e la password (hash) sono invece nella tabella **usr**:

<code>
SELECT user_no, username, password FROM usr WHERE user_no = 1001;
 user_no |      username       |                   password                    
---------+---------------------+-----------------------------------------------
    1001 | niccolo@rigacci.org | *7J/zWNlkJ*{SSHA}raFPA81mbrAj+skA4SC94V01sa0o=
</code>

Al calendario e all'address book corrispondono due record nella tabella **collection**:

<code>
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
</code>

Per ogni oggetto creato nella collection calendario (**VEVENT**) o addressbook (**VCARD**) viene creato un record nella tabella **caldav_data**:

<code>
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
</code>

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

<code>
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
</code>

<code>
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
</code>

===== 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:

<code>
<http://host:port>/davical/caldav.php/<principal>/<collection>/
</code>

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 [[http://www.mozilla.org/projects/calendar/lightning/download.html|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 [[http://sourceforge.net/projects/rscds/forums/forum/622963/topic/3684961|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:

<code php>
$c->override_dav_header = '1, 2, access-control, calendar-access, calendar-schedule, extended-mkcol, calendar-proxy, bind';
</code>

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:

  - Nel tab Calendario attivare e selezionare un calendario CalDAV.
  - Click destro sul planner al giorno desiderato, //New event...//.
  - Click su //Invite Attendees//.
  - 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.
  - Chiudere la finestra degli inviti.
  - 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.