====== 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§ion=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''**: 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** DirectoryIndex index.php AllowOverride None Require all granted 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/ 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"; ==== 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 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. ==== 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**: 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 ===== 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: /davical/caldav.php/// 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:///davical/caldav.php///%%''. * 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: $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: - 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.