Colors of Noise

Entries tagged "groupware".

Contatacs, CardDAV, Calypso and the N900
9th March 2016

As a follow up to calendar synchronisation with calypso, syncevolution and the N900 running maemo I finally added contacts to the mix:

on the phone

When you have the calendar sync already running it's as simple as:

First start ssh on the n900 to ease typing:

apt-get install dropbear
echo /bin/sh >> /etc/shells
cd /etc/dropbear && ./run

SSH into the phone and configure contacts synchronization:

cat <<EOF > ~/.config/syncevolution/webdav/sources/addressbook/config.ini
backend = CardDAV
database =

And perform the initial sync:

syncevolution --sync slow webdav addressbook

From there on you can sync contacts and calendars in one go with:

syncevoluton webdav

Looking at the calypso logs on the server it seems that syncevoluton does not always generate an FN entry and so the card gets skipped. This doesn't harm the overall sync, but I need to have a look how to fix this.

on the laptop

In order to use the contacts im mutt there's pycarddav packaged in Debian. This is basically following upstreams documentation.

sudo apt-get install pycarddav
mkdir -p ~/.config/pycard
cp /usr/share/doc/pycarddav/examples/pycard.conf.sample ~/.config/pycard/pycard.conf
# Edit file as needed

cat ~/.config/pycard/pycard.conf
[Account username]
user: username
write_support = YesPleaseIDoHaveABackupOfMyData

where: vcard


debug: False

To use the entries in mutt add the just extend your .muttrc:

cat <<EOF >>~/.muttrc
set query_command="pc_query -m %s"
macro index,pager B "<pipe-message>pycard-import<enter>" "add sender address to pycardsyncer"

This allows you to query contacts using Q and add new conatcs with CTRL-B in mutt's index and pager.

Calypso Changes

We recently moved calypso's git repository to alioth and started to merge several out of tree patches. More will happen during this years Debian Groupware Meeting including a new upload to Debian.

Tags: groupware, maemo, planetdebian, planetfsfe.
Calendar synchronisation between Nokia N900 and the Calypso CalDAV server
5th June 2013

One of the replies to the post about Debian's last groupware meeting was from Patrick Ohly of syncevolution fame pointing out that syncevolution already implements calendar autodetection for CalDAV calendars as described in draft-daboo-srv-caldav-10.

While looking at the code I noticed that there's a backend for the N900s calendar by Ove Kåven as well.

When I tried Ove's latest package on my N900 it lead to an immediate crash when doing a:

syncevolution --print-items target-config@webdav calendar

According to Patrick the bug was supposed to be fixed in recent versions so I set up scratchbox and built a newer git snapshot for maemo (sources). This wouldn't crash but didn't show up any items either. It turned out to be a minor bug in calypso returning no content type for REPORT queries which resulted in libneon discarding the whole reply (now already fixed in calypso upstream).

With this out of the way setting up synchronisation is quiet simple:

# Configuration
syncevolution --configure username=<username> password=<password> \
              calendar/backend=caldav calendar/database=https://${CALDAV_SERVER}:5233/private/my_calendar \
              target-config@webdav calendar
syncevolution --configure --template SyncEvolution_Client sync=none syncURL=local://@webdav username= password= webdav
syncevolution --configure sync=two-way backend=calendar webdav calendar

You should then be able to print the items on the local (N900) and from the remote (CalDAV server) end:

# This lists the current calendar items on the server
syncevolution --print-items target-config@webdav calendar
# This lists the current calendar items on the N900
syncevolution --print-items @default calendar

And from there on sync away:

# initial slow sync
syncevolution --sync slow webdav
# from there on
syncevolution webdav

The syncevolution source code has great documentation about debugging problems (e.g. src/backends/webdav/README). So check that in case you run into problems. The tl;dr version is

SYNCEVOLUTION_DEBUG=1 src/syncevolution loglevel=10 --print-items target-config@webdav calendar

to debug CalDAV related problems. In case you need to run syncevoluton from source be sure to set these beforehand:

export SYNCEVOLUTION_XML_CONFIG_DIR=$PWD/src/syncevo/configs/

On the CalDAV side I used current Calypso git which (with some additional minor fixes) now also interoperates nicely with Iceowl/Icowl-Extension aka Sunbird/Lightning on the desktop side. There's also an ITP for it. So it'll hopefully end up in Debian soon.

Update: in order to do ssl verification with syncevolution/libneon you have to put the CAs certificate to /etc/ssl/certs on the N900 and do a

c_rehash /etc/ssl/certs

otherwise syncevolution won't ve able to verify the server's certificate.

Tags: debian, groupware, maemo, planetdebian, planetfsfe.
Apple Calendarser with Name Service Switch directory backend
22nd June 2008

Apple's Calendarserver uses a file based XML backend by default. This has the disadvantage that new users must be added manually and groups can't be maintained dynamically - the calendarserver needs to be restarted.

Therefore we added a simple Name Service Switch based directory service to the Debian packages - it's best to use 1.2.dfsg-4 or newer. Using this, all users known to the system via getent passwd can have calendars and group calendars can be maintained as simple groups of users. Where your system gets it's user and group information from can be configured via /etc/nsswitch.conf e.g.:

 passwd: files ldap
 group:  files ldap

looks up users and groups in /etc/{passwd,groups} and using ldap via libnss-ldap. For more details use man nsswitch.conf. All of this can be configured dynamically without the need to restart calendarserver.

Calendarserver Configuration

To enable the NSS backend in calendarserver comment out the XML File Directory Service via <!-- ... --> in /etc/caldavd/caldavd.plist then add the NSS one. This example has all the parameters you can set:

<!-- NSS directory service -->
    <string>Your Realm</string>

    <!-- Don't treat user ids smaller than firstValidUid as calendarserver users -->
    <!-- Don't treat user ids larger than lastValidUid as calendarserver users -->

    <!-- Groups starting with this prefix are considered calendarserver groups -->

    <!-- Don't treat group ids smaller than firstValidGid as calendarserver groups -->
    <!-- Don't treat group ids larger than lastValidGid as calendarserver groups -->
    <!-- use username@mailDomain as calender user mail addresses -->

The firstValidUid and lastValidUid parameters allow you to specify which users have calendars. By default uids in the range [1000,65533] are being used. This way system users like lp, mail, news backup and nobody are excluded.

Shared calendars are represented by groups of users. The group name must start with groupPrefix to avoid collisions with system users - the default is caldavd-. The members of these groups are allowed to read/write the calendar. The firstValidGid, lastValidGid have the same meaning as the uid ones above but since you already specified a prefix you normally can simply omit them.

The mailDomain parameter can be used to specify a default mail domain. In the exmaple above a user foo ends up with mail address of - this information is used by some clients for free busy lists and invitations.

The values above - except for the realmName and mailDomain - are the defaults build into calendarserver, so if these suite your needs you can simply skip them:

<!-- NSS directory service -->


After changing this don't forget to restart calendarserver using /etc/init.d/calendarserver restart.

Adding users and groups

Using the configuration above all users in the range [firstValidUid,lastValidUid] readily have a calendar to access at:


Adding a new user is now as easy as adduser <newuser>. The calendar get's created once the user tries to access his calendar for the first time. To add a shared calendar at:


simply do a addgroup caldavd-test. Then simply add users to this group: adduser test <user>. To see which users can access this particular shared calendar you can use:

getent group caldav-test

and to see all shared calendars use:

getent group | grep ^caldavd-

To see which calendars a user can access look at the output of id.

Note that {add,del}{user,group} manipluate users and groups in /etc/passwd and /etc/group only. If you're using other name service switch backends like ldap or postgresql you can use the corresponding tools instead.


User authentication currently only works using Kerberos. This is the recommended form of authentication anyways. Let me know if you have problems setting this up.

Tags: groupware, single-sign-on.

RSS Feed