Installing the Darwin Calendar Server 2.4 on Fedora 13 or Fedora 14

As I mentioned in my last post, I've been playing with the Darwin Calendar Server (DCS) on Linux... Today I was able to re-test my setup notes to see if they worked properly, so below I've written a tutorial on how to get your own DCS server going on Fedora 13 or 14.

Installing Dependencies

Since we will be installing CalendarServer directly from the 2.4 branch subversion repository, the first thing to do is to install subversion and the dependencies for DCS:

su -
# Required to check out the source code from the repository
yum install subversion
# Dependencies
yum install patch memcached krb5-devel python-zope-interface PyXML pyOpenSSL python-kerberos
# Requirements for compiling xattr
yum install python-setuptools gcc gcc-c++ python-devel

Enable extended file attributes (xattrs)

DCS requires user extended file attributes so the user_xattr mount option must be enabled for the partition on which CalendarServer will be storing its documents and data (in this case, /srv). If you have not already enabled this option (it is disabled by default), edit /etc/fstab and add the user_xattr mount option after defaults, for example:

/dev/mapper/VolGroup-lv_root /                       ext4    defaults,user_xattr        1 1

Grab DCS from SVN and run auto-setup

Once these packages have been installed and extended file attributes have been enabled, we will begin setting up the CalendarServer as your regular, non-root user.

# Directory to hold CalendarServer checkout and its dependencies
mkdir CalendarServer
cd CalendarServer
# Checkout the code from the repo
svn checkout CalendarServer-2.4
cd CalendarServer-2.4
# Start auto-setup
./run -s

Auto-setup will now attempt to grab any missing dependencies for CalendarServer an will unpack and patch them accordingly. You may find that the download for PyDirector stalls - if so, hit to abort setup and download it manually:
pushd ..
tar xfz pydirector-1.0.0.tar.gz
# Resume unpacking
./run -s

Prepare for installation

Since DCS bundles a modified version of Twisted as well as a few other projects (such as pydirector), we will now prepare an installation root folder to avoid conflicts with system libraries (i.e., Twisted if it has been installed from the Fedora repos). This code will be run as root.

su -
# setup data & document roots
mkdir -p /srv/CalendarServer/{Data,Documents}
chown -R daemon:daemon /srv/CalendarServer/
# setup installation root
mkdir -p /opt/CalendarServer/etc/caldavd
mkdir -p /opt/CalendarServer/var/run/caldavd
mkdir -p /opt/CalendarServer/var/log/caldavd

Install DCS and configure the server instance

The last step is to install DCS from the Subversion checkout we made earlier into the installation root. Replace /home/regularuser with the actual path to the home directory of your regular user.

# install DCS to installation root
cd /home/regularuser/CalendarServer/CalendarServer-2.4
./run -i /opt/CalendarServer
rm -rf /opt/CalendarServer/usr/caldavd/caldavd.plist
# copy sample configuration files
cp conf/servertoserver-test.xml /opt/CalendarServer/etc/caldavd/servertoserver.xml
cp conf/auth/accounts.xml /opt/CalendarServer/etc/caldavd/accounts.xml
cp conf/caldavd-test.plist /opt/CalendarServer/etc/caldavd/caldavd.plist
cp conf/sudoers.plist /opt/CalendarServer/etc/caldavd/sudoers.plist
# change permissions; passwords are stored plaintext!
chmod 600 /opt/CalendarServer/etc/caldavd/*

I have reported bugs #390 and #391 about problems with the setup script on 64-bit machines as well as a problem if a custom destination installation directory is used (which we did). This bit of code works around both of the bugs:
# 64-bit fix - see
sitelib="$(python -c 'from distutils.sysconfig import get_python_lib; print(get_python_lib())')"
sitearch="$(python -c 'from distutils.sysconfig import get_python_lib; print(get_python_lib(1))')"
if [ "$sitelib" != "$sitearch" ];then
  mv /opt/CalendarServer"${sitelib}"/twisted/plugins/* /opt/CalendarServer"${sitearch}"/twisted/plugins
  # PYTHONPATH fix for 64-bit - see
  sed -i.orig 's|PYTHONPATH="'"${sitelib}"'|DESTDIR=/opt/CalendarServer\nPYTHONPATH="${DESTDIR}'"${sitelib}"':${DESTDIR}'"${sitearch}"':|' /opt/CalendarServer/usr/bin/caldavd
  # PYTHONPATH fix for 32-bit - see
  sed -i.orig 's|PYTHONPATH="'"${sitelib}"'|DESTDIR=/opt/CalendarServer\nPYTHONPATH="${DESTDIR}'"${sitelib}"':|' /opt/CalendarServer/usr/bin/caldavd

If you would like your server to use SSL (highly recommended), you will need to generate a certificate. If you have a certificate and key ready to install, place it in /opt/CalendarServer/etc/tls. If not, you can easily generate a free self-signed one:

# Generate SSL keys
mkdir /opt/CalendarServer/etc/tls
openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout -out

Now, edit /opt/CalendarServer/etc/caldavd/caldavd.plist in your favorite editor and configure the server as follows:
    <!-- Network host name [empty = system host name] -->
    <string></string> <!-- The hostname clients use when connecting -->

# Data roots
    <!-- Data root -->
    <!-- Document root -->

# Test accounts configuration
    <!-- XML File Directory Service -->

# Sudoers configuration
    <!-- Principals that can pose as other principals -->

# Delete this section
<!-- Wikiserver authentication (Mac OS X) -->

# logging

    <!-- Apache-style access log -->

    <!-- Server activity log -->

    <!-- Log levels -->
    <string>info</string> <!-- debug, info, warn, error -->
# a bit further down…
    <!-- Global server stats -->
# <snip>
    <!-- Server statistics file -->
    <!-- Server process ID file -->

# SSL 
    <!-- Public key -->
    <!-- Private key -->

# Privilege drop
        Process management

# iSchedule server-to-server settings
      <!-- iSchedule protocol options -->

# Communication socket
    <!-- A unix socket used for communication between the child and master processes.
         An empty value tells the server to use a tcp socket instead. -->

# Twisted

# Load balancer
        Python Director





Try starting the server!

/opt/CalendarServer/usr/bin/caldavd -T /opt/CalendarServer/usr/bin/twistd -f /opt/CalendarServer/etc/caldavd/caldavd.plist -X

If all goes well, press to kill the process and then daemonize it:
/opt/CalendarServer/usr/bin/caldavd -T /opt/CalendarServer/usr/bin/twistd -f /opt/CalendarServer/etc/caldavd/caldavd.plist



The Pyflakes server is down and the ./run -s command fails to get that module. You have to download it from or somewhere and unpack it just like the Pydirector module.

I've got some kind of config error with Pydirector but I'm hoping the second time is the charm.

Hi, I'm trying to follow your guide but I'm like the above commenter, falling foul of the Pyflakes server seemingly being down. I tried manually downloading, using the steps you did for Pydirector but I can't advance any further, it still tries to check out Pyflakes. Would appreciate some advice.
Thank you.

Which folder did you save the pydirector tarball to? It should be one directory above the current one where the checkout/build is happening.

Hi Stuart,

I performed all the actions you mention on a F14/x86_64 machine and I had only 1 problem when installing Pyflakes ( their svn server seems down ). I downloaded each file from launchpad to recreate the Pyflakes directory at same level as CalendarServer-2.4.

When I start the server with command line "/opt/CalendarServer/usr/bin/caldavd -T /opt/CalendarServer/usr/bin/twistd -f /opt/CalendarServer/etc/caldavd/caldavd.plist -X", I always have the following error : "/opt/CalendarServer/usr/bin/twistd: Unknown command: caldav"

Is there any other RPM that I should install or any other things to perform in order to have the caldav command in Twistd available ?



That's bizarre, it seems like the DCS twisted plugin was either installed to the wrong directory or it is missing. What is the output of the following command:

ls /opt/CalendarServer/usr/lib*/python*/site-packages/calendarserver/tap

Hi Stuart,

I reprocessed your installation with a bash file containing your patch code :
# 64-bit fix - see

The new output of "ls /opt/CalendarServer/usr/lib*/python*/site-packages/calendarserver/tap" is now : caldav.pyc __init__.pyc test

But :
1/ there are still many things in /opt/CalendarServer/usr/lib instead of /opt/CalendarServer/usr/lib64, should I copy everything to the lib64 and then remove the lib directory ?
2/ there is no file /opt/CalendarServer/etc/pydir.xml as stated in file /opt/CalendarServer/etc/caldavd/caldavd.plist, is there any template that should be created ?
3/ The server starts but no listening port are opened (neither 8008 nor 8443) and the last message is
pydirector.pdconf.ConfigError: expected 'service' or 'admin', got 'control', can it be related to the pydir.xml missing file ?


Hi Eric,

Are you starting the server manually as root? This can cause some problems for memcached and I think this pydirector error is a side-effect of that. I do not have a pydir.xml file either, so that isn't the problem...

If you can please put the full output of a test run to a pastebin and post it back here so that we can have a look.


Hi Stuart,

Here is the full log of " /opt/CalendarServer/usr/bin/caldavd -T /opt/CalendarServer/usr/bin/twistd -f /opt/CalendarServer/etc/caldavd/caldavd.plist -X" run as root :

[ edited: contents in ]


I've added the output to a pastebin to avoid flooding the comments page, I hope you don't mind :)

You'll notice near the beginning of the output there's a line:

Adding pydirector service with configuration: /tmp/pydironavzj

Can you post the output of the file listed on that line when you try running the server again (that filename will change with each server run)? Mine current one looks like this:
<pdconfig><service name="http"><listen ip=":8008" /><group name="main" scheduler="leastconns"><host name="caldav-8009" ip="" />
<host name="caldav-8010" ip="" /></group><enable group="main" /></service>
<service name="https"><listen ip=":8443" /><group name="main" scheduler="leastconns"><host name="caldav-8009" ip="" />
<host name="caldav-8010" ip="" /></group><enable group="main" /></service><control socket="/opt/CalendarServer/var/run/caldavd/caldavd-pydir.sock" /></pdconfig>

Hi Stuart,

I have also the same content as you can see :

<pdconfig><service name="http"><listen ip=":8008" /><group name="main" scheduler="leastconns"><host name="caldav-8009" ip="" />
<host name="caldav-8010" ip="" /></group><enable group="main" /></service>
<service name="https"><listen ip=":8443" /><group name="main" scheduler="leastconns"><host name="caldav-8009" ip="" />
<host name="caldav-8010" ip="" /></group><enable group="main" /></service><control socket="/opt/CalendarServer/var/run/caldavd/caldavd-pydir.sock" /></pdconfig>



Does it work if you re-compile using pydirector-1.0.0 downloaded from here?

Hi Stuart,
When I launch ./run -i, it downloads the exact same file ( identical checksums) pydirector-1.0.0.tar.gz as the one I downloaded on your URL. How can I know if the pydirector used by DCS is really this one ?

I'm not sure what's going on then... When F15 comes out (next week or the week after that) I'll re-test from scratch and see if I can reproduce the issue.

Hi Stuart,

I started all again using CalendarServer 2.5 on F14 following your instructions.

The server is now starting and listening on ports 8008, 8009, 8010, 8443, 8444 and 8445 :-)) !

When I try to create a new Webcal Calendar in Evolution using user admin/admin I get the following error "Cannot Open Calendar : permission denied".

What can I do now to test if it's working correctly ?
Are there any tools provided that I can use to test if it's working fine ?
Can I use its Web Interface to test anything ?


Hi Stuart,

Following my last message, I managed to set up correctly DCS in Evolution.

One has to set up the URL as caldav://:/calendars/users//calendar/

And everything is working fine afterwards.

However, I have another question as I can't manage to have access to an Address Book managed by DCS; Do you know what URL should be given to access the user DCS managed address book ?



Hi Eric,

Glad to hear it's working now! Configuring DCS for CardDAV (via carddavd) may be a bit difficult, I couldn't find any readily available examples or documentation on it like there is for the CalDAV (caldavd). This may help:


Hi Stewart,

I currently use pam_sssd and OpenLDAP to manage users in a central repository.

Is it possible to use such kind of configuration (PAM or LDAP) to have DCS look for users instead of using the accounts.xml file manually ? I can't seem to find any howto on that subject @ google.


Although I have not attempted to configure or test a configuration like this, it should be possible. In the caldavd.plist configuration file, you'll find several lines relating to LDAP:

# cat caldavd.plist | grep -i ldap
    <!--  OpenLDAP Directory Service -->

This ticket may also be of interest to you:

Hi Stuart,

From the link you mention I understand that there is no support for the 2.x version ( at least I can't find anywhere in the source code nor in the caldavd.plist files where this happens).

However, when I look at the 3.0-dev version, it seems that the OpenLDAP authentication is part of it, so it should be possible in this release.