A Linux tale… [updated]

My wife and I seem to share a lot of activities recently. We finally gathered a few friends around here with which we do regularily stuff like playing card games and she even got me to take Salsa dancing lessons with her. Beside that my political interests and meetings are quite regular as well, so it was just natural to think about a event planning solution which would allow us to view, add and edit events. I decided we need a calendar server!

So I started looking around for calendar server solutions. I already had a rather hacky webdav-alike setup on my Virtual Private Server (VPS) which consisted of a single ICS file, secured by a simple HTTP authentication and made writable through a PHP script, but this doesn’t seem to be the right solution for me. I wanted something better, something stable, something nice – and I apparently found it: Apple released its Darwin Calendar Server, which is the base of their commercial calendar server solution on Mac OS X Server, as Open Source under the Apache Software License 2.0 some time ago. “This will replace the old hackish setup on my VServer!”, I thought…

I logged into the server and quickly downloaded the project’s sources from the public SVN repository. The README file stated that it should apparently be enough to start the `run` script in the base directory which would take care of everything, i.e. download and install all dependencies which would be needed for the software to run. This even worked flawlessly (with only one little modification). Up to that point I was very cheerful – until I actually tried to start the server:

IOError: [Errno 95] Operation not supported: \
'/opt/calendarserver/CalendarServer/twistedcaldav/test/data'

Uh? Ah well, there was something in the README I overlooked:

WEBDAV PROPERTY STORAGE
-----------------------

For starters, twisted.web2.dav requires Bob Ippolito's xattr
library to access file system extended attributes, which are
used to store WebDAV properties.  File system extended 
attributes are available on all file systems in Mac OS X, and
on some file systems on Linux and FreeBSD.  Another 
alternative is to implement a new property store class which
does not use extended attributes. The Apache HTTP Server, for
example, uses a database to keep track of properties on files,
and this method works on many more platforms and file systems.

xattr? Hrm… I never heard of that before – but Google shed light into my darkness: As Wikipedia amongst others states, they are “[…] a file system feature that enables users to associate computer files with metadata not interpreted by the filesystem […]”, basically simple key-value pairs of arbitrary size and content. A quick grep over the config file of the currently running kernel showed me that at least support was already compiled into it:

$ cat /boot/config-2.6.11.4-20a-smp | grep XATTR
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_REISERFS_FS_XATTR=y
CONFIG_DEVPTS_FS_XATTR=y
CONFIG_TMPFS_XATTR=y
CONFIG_CIFS_XATTR=y

Cool! I read somewhere that in this case one would just have to add the mount option `user_xattr` to /etc/fstab and remount the filesystem in question and everything would be fine… Well, it would be fine if my /etc/fstab would actually contain an entry for `/`! Being on a virtual server started to get a little annoying.

But I didn’t capitulated, not yet. “Wasn’t there a way to create and mount a filesystem from a disk image?” I wondered. I used this technique a couple of times to mount ISO images and browse their contents back in my old Linux days. I read a bit further on this topic and found many helpful ressources on this topic. At first I needed to create an image file and format that with a filesystem:

# 128 blocks of 1MByte size
$ dd if=/dev/zero of=caldavdata.image bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes (134 MB) copied, 0.506394 seconds, 265 MB/s
$ mkfs.ext3 -v caldavdata.image
mke2fs 1.36 (05-Feb-2005)
caldavdata.image is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
32768 inodes, 131072 blocks
6553 blocks (5.00%) reserved for the super user
First data block=1
16 block groups
8192 blocks per group, 8192 fragments per group
2048 inodes per group
Superblock backups stored on blocks: 
        8193, 24577, 40961, 57345, 73729

Writing inode tables: done                            
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 28 mounts
or 180 days, whichever comes first.
Use tune2fs -c or -i to override.

“Great! Now I only need to mount that baby!” I thought:

$ mount caldavdata.image /opt/caldavdata -t ext3 -o loop
mount: could not find any device /dev/loop#

Indeed, there was not one single block device in /dev starting with `loop` – in fact the only two block devices I found there at all were related to the virtual server’s own file system. In my naive thinking I continued: “Hey, if this block device is not existent, I’m pretty much sure that I can create it with mknod!”. Indeed, mknod can create any kind of char or block devices. This site pointed me to the correct needed major and minor numbers for such a device:

$ mknod /dev/loop0 b 7 0 # 'b' stands for block device
$ ls -lah /dev/loop0 
brw-r--r--  1 root root 7, 0 Feb  1 21:25 /dev/loop0

“Success!” I thought and tried the mount command again:

$ mount caldavdata.image /opt/caldavdata -t ext3 -o loop
mount: Could not find any loop device. Maybe this kernel does
       not know about the loop device?
       (If so, recompile or `modprobe loop'.)

“Yeah, apparently it does not know about device” and ran the proposed `modprobe loop`:

$ modprobe loop
FATAL: Module loop not found.

Hrm… could it be that loop wasn’t compiled as module? Grepping the config told me yes:

$ cat /boot/config-2.6.11.4-20a-smp | grep LOOP
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=m

So, the last thing I could think of (as an ignorant Linux user) was to reboot the server and hope that it would somehow recognize the loopback file.

Of course, this did not work out.

I’m now in the sad process to get used to Google Calendar…

[Update: Actually the only bad things about Google Calendar until today are

a) I don’t have full control of the server-side storage / backup

b) I can’t publish events to Google via iCal – well, at least I could not until today.

Apparently Google offers an RSS-alike API to access calendar data and somebody wrote a small Java server which “translates” between this custom RSS format and the standard ical format. It allows file-based synchronization (i.e. particularily useful for iCal which can’t just embed and write CalDAV ressources) and even contains a small web server to do the translation live and in place – how neat is that?!

You can download GCalDaemon here.]