Calendari CalDav sincronizzati e gestiti da terminale

2016-12-16: ATTENZIONE, questo articolo è obsoleto.

Leggi l’articolo aggiornato:
Calendari CalDav sincronizzati e gestiti da terminale [Update]

Questo articolo è rivolto a tutti coloro che non vogliono usare client dispendiosi di risorse e/o troppo legati ad un Desktop Environment, ma vogliono comunque poter sincronizzare, gestire ed editare i propri calendari remoti, pubblicati con CalDav.
Per i più pigri, e per quelli che amano le interfacce ‘easy and fancy’ invece consiglio i soliti programmi, ovvero:

Tutti client belli, completi, eleganti, pesanti, avidi di risorse e legati a doppio filo a qualche ambiente o applicazione.

C’è però una speranza anche per gli utenti che usano ambienti leggeri (xfce, icewm, fluxbox, blackbox…mi fermo, sono davvero innumerevoli) o addirittura per chi usi “solo” le tty.
I software (sono due, uno per il sync e uno per la gestione dei calendari) sono khal e vdirsyncer.

Installazione

L’installazione in Debian è semplicissima, basta installare da pacchetti il software python-pip

sudo apt-get install python-pip

e quindi con quest’ultimo installare khal (vdirsyncer verrà installato come dipendenza):

sudo pip install khal

Configurazione

Innanzitutto occorre mettersi il cuore in pace: non esistono semplici wizard per la configurazione dei due software, i cui file di configurazione devono essere creati ed editati a mano. Fortunatamente, è tutto molto semplice.

Partiamo dal file di configurazione di vdirsyncer, che deve essere creato nella posizione ~/.vdirsyncer/config (create la directory .vdirsyncer se necessario).
Qui sotto un semplice file di esempio dove vengono sincronizzati due calendari remoti pubblicati da un server owncloud:

[general]
# A folder where vdirsyncer can store some metadata about each pair.
status_path = ~/.vdirsyncer/status/


# CALDAV
[pair bob_calendar]
a = bob_calendar_local
b = bob_calendar_remote
collections = ["personal", "shared"]

[storage bob_calendar_local]
type = filesystem
path = ~/.calendars/
fileext = .ics

[storage bob_calendar_remote]
type = caldav
url = https://owncloudserver.local/remote.php/caldav/
username = user
password = password

(Questo è un esempio semplificato del più articolato file di esempio reperibile qui)
Come si può notare la sintassi è molto semplice; val la pena fare notare che se ci si collega a servizi via https con certificato self-signed è necessario aggiungere una riga alla sezione contenente le direttive per il collegamento a caldav, con la variabile verify_fingerprint valorizzata al fingerprint SHA1 del certificato self-signed.

Salvato il file (e creata la directory ~/.calendars) è possibile lanciare il primo sync, verificandone il funzionamento, con il comando

vdirsyncer sync

Ora non resta che scrivere la configurazione di khal (da creare nel file ~/.khal); per l’esempio riportato qui sopra il rispettivo file di configurazione di Khal sarà

[calendars]

[[personal]]
path = ~/.calendars/personal/

[[Condiviso]]
path = ~/.calendars/shared/

[locale]
local_timezone= Europe/Rome
default_timezone= Europe/Rome
timeformat= %H:%M
dateformat= %d.%m.
longdateformat= %d.%m.%Y
datetimeformat= %d.%m. %H:%M
longdatetimeformat= %d.%m.%Y %H:%M

Visualizzazione e gestione dei calendari

Con khal è possibile visualizzare e gestire i propri calendari, direttamente da terminale; khal prevede diversi comandi (khal –help per vederli tutti, naturalmente), ma il più interessante è probabilmente khal interactive che permette la visualizzazione e la gestione interattiva dei propri calendari (compresa l’aggiunta e rimozione di eventi).
Vale la pena ricordare che khal crea e modifica gli eventi in locale; il sync con il calendario remoto si ottiene lanciando successivamente il comando vdirsyncer sync.

Uno script per automatizzare il tutto

A chiusura di articolo propongo un semplice script (da associare magari a un lanciatore .desktop da tenere a portata di click) che si occupa di sincronizzare i calendari e di lanciare khal in modalità interattiva.
Lo script è pensato per l’ambiente Xfce4, ma è facilmente personalizzabile con altri ambienti ed emulatori di terminali.

#!/bin/bash
#Simple script to mantain up-to-date CalDav resources with vdirsyncer and khal
#By Franco 'frakbe' Bersani

#Perform first sync
vdirsyncer sync

#exec xfce4-minimal terminal
xfce4-terminal --hide-menubar -T "Calendario" --hide-toolbar --geometry=80x25 -x khal interactive

Nota: probabilmente può comunque valere la pena spostare il comando di sync al di fuori dello script e farlo girare con cron, ma sono valutazioni personali 🙂

Khal in azione

Uno screenshot di khal in azione in una finesta di xfce4-terminal.
khal

Keys anche per Arch Linux (e derivate)

Ho pacchettizzato keys anche per Arch Linux (e derivate).
Potete scaricare il binario, al solito, dal sito del progetto (https://sf/net/p/keys).
Qui sotto comunque trovate il link diretto!

arch-linux-logo

 

 

 

 

P.S. Se riesco a costruire un source tarball che piaccia ad AUR, il pacchetto verrà pubblicato anche sui repo community 😉

!UPDATE!
Sono riuscito a costruire un tarball abbastanza decente da andare su AUR, primo step per essere un pacchetto dei repo community.
Perché rimanga però servono almeno 10 voti da parte degli utenti; quindi se qualcuno è interessato che keys rimanga nei repo community di AUR, può cliccare  a questo indirizzo (https://aur.archlinux.org/packages/keys/) e dare il proprio voto 🙂

Keys anche per OpenSuse/Suse

Mi sono accorto che l’rpm di keys non si installava correttamente su OpenSuse (ho eseguito il test sull’ultima attualmente disponibile, la 13.2) per un banale errore di dipendenze.
Ho creato quindi un rpm per gli utenti Opensuse/Suse, da usare al posto dell’rpm “standard” (che invece funziona su RedHat/Fedora/CentOS).
Il pacchetto è scaricabile dal sito del progetto ( https://sf.net/p/keys ), qui sotto il link diretto.

Enjoy!

rpm_package_icon

Keys Virus Free!

Oggi tornando sulla pagina del mio progetto su SourceForge ho notato che SF certifica come Virus Free la mia applicazione!
Ecco , se non fosse che ero comunque – personalmente – tranquillo della “bontà” del software (avendolo scritto io), ora mi sentirei certamente più al sicuro 😉
Allego qui sotto screenshot.

virusfreeAh, aggiungo una piccola nota di servizio: soruceforge propone come download predefinito il pacchetto rpm, ma basta scegliere “Browse all files” per scaricare il deb o il tragz.

Keys non funziona su KDE?

Scrivo questo breve howto dopo essermi imbattuto in un problema con il desktop KDE e il mio software di gestione delle password – Keys.
Apparentemente, Keys non funziona correttamente, non proponendo la maschera di inserimento password all’apertura di una Key DB.
Tutto questo nonostante il software necessario, GPG2 incluso, sia correttamente installato sul sistema.
Il problema, in questo caso, è relativo al programma pinentry, che si occupa (come dice il nome stesso) di chiedere, attraverso una maschera grafica, e intercettare le password per la decifrazione delle chiavi.
Esistono tre interfacce grafiche per pinentry: pinentry-curses (interfaccia che si basa sulle ncurses), pinentry-gtk (basata sulle libreire gtk) e pinentry-qt (basata sulle librerie qt).
Ed è proprio pinentry-qt il responsabile del problema; per ovviare al problema, occorre:
– installare pinentry-gtk (alcune distribuzioni lo chiamano pinentry-gtk2 o pinentry-gtk-2, regolate i comandi successivi di conseguenza)
– controllare dove è installato pinentry-gtk con il comando

which pinentry-gtk

(tipicamente, sarà in /usr/bin/pinentry-gtk)
– editare il file ~/.gnupg/gpg-agent.conf mettendo la riga

pinentry-program /usr/bin/pinentry-gtk

(da modificare se pinentry-gtk è installato in altra directory)
– Killare le istanze di gpg-agent con il comando

killall gpg-agent

Ora Keys dovrebbe nuovamente funzionare correttamente!
P.S. Ho testato il bug con Kubuntu 14.04.1 e con Fedora 20.