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


Playing with the Darwin Calendar Server

Sorry for the lack of posts lately, I've been caught up with school and updating my FOSS on the side whenever I have some spare time.

The server that runs this site as well as and a few others is almost always idle - the load averages rarely exceed 0.5, and are most often sitting somewhere around 0.2 (it's a 1U/Core 2 Quad Q9550@2.83GHz/8GB RAM/2x1TB RAID 1). I have bigger plans for it in the future, but at the moment there just isn't a great deal for it to do since it handles everything so quickly.

I have been wanting to see how KVM VMs perform on it as well as try out the Darwin Calendar Server (DCS)... Seeing as DCS requires Python 2.5 and I didn't want to mess around with the live server's configuration (CentOS 5.x ships with Python 2.4), I installed Fedora 13 in a virtual machine so I could test the calendar server safely.

To my surprise, KVM works really, really well... I wasn't expecting that seeing as the versions I had used in Fedora were so much more recent. The performance is good - I haven't performed any stress-testing yet (which obviously will show a gap between the VM and running natively) but the DCS is running very smoothly and feels very responsive, so I'm confident that the difference in performance is not so large.

How I got the DCS running on Linux is a whole other story... I'll save that another post (F13/F14 DCS installation guides coming soon) but is it ever handy to have a CalDAV server! Previously, I was only able to sync calendars manually (with the USB cable) which made checking for homework assignments extremely annoying, as half of the information was always my iPod and the other half on iCal and I had to sync all the time. Now it's all over-the-air, so as long as there's Internet connectivity the calendar events can be pulled in or pushed out.


Fixing the iTunes 10 badness

I think many will agree that iTunes 10 was more of a marketing ploy than anything else... I found that iTunes 10.0 was worse than 9.x, primarily because of the "traffic light" style buttons in the window corner and graystyle icons. That was bearable though, and then the update to 10.0.1 came along made things even worse. No more Genius sidebar, and obnoxious "Ping" buttons every time a song is selected.

So I went on a quest to fix it, and found these commands on various forum threads and blogs:

(If you are unsure how to run these commands, quit iTunes and open Application > Utilities > Terminal. Copy/paste these commands in, hitting <Enter> after each to execute it.)

defaults write hide-ping-dropdown 1
Disables the obnoxious "Ping" drop-down menu I mentioned earlier.

defaults write show-store-link-arrows -bool TRUE
Restores the store arrow links present when a song is selected in 10.0 and earlier.

defaults write disablePingSidebar 1
Disables the ping sidebar. Sadly, I haven't found a way to re-enable the Genius sidebar.

defaults write full-window -boolean YES
Puts iTunes in "full window" mode, removing the traffic light window controls.

Now, the last thing is to restore color in iTunes. To do this, download the iTunes.rsrc file linked to in comment #7 on this thread. Next, right-click on iTunes in the Applications folder and select Show Folder Contents. Inside the Contents/Resources folder, copy the downloaded iTunes.rsrc file and opt to replace existing files when prompted. Restart iTunes and you should have coloured icons!

Note: If you're reading this but you're running iTunes on Windows, a user on Apple Discussions has posted how to do the same on Windows.


Some hidden gems in the iTunes 9 visualizer

It's more or less well known that the stunning visualizer in iTunes 9 is actually a modified version of The Barbarian Group's Magnetosphere. I recently downloaded a copy of the original magnetosphere visualizer, and one thing I enjoyed was the ability to control the amount and intensity of the particles (the glowing, moving dots). The following is displayed in the visualizer's help screen:

+/- Increase or decrease the intensity
A/S Add or Subtract particles (100 at a time)

While these commands are not listed in the help screen of the official iTunes version of the visualizer, to my surprise I found that they still work! They've proved useful for when the iTunes visualizer seems to get stuck for a bit with one of the big black stars blocking the view.


Installing PHP 5.2.10 on OS X 10.6 Snow Leopard

Since my update to Snow Leopard, I was pleasantly surprised to find that Apple has updated PHP to version 5.3 and also included the GD extension. While I no longer have to rebuild the extension manually like on Leopard, these changes to PHP brought around a different problem: Drupal is currently not compatible with PHP 5.3 (#360605).

I've been trying to get my local Drupal installations working, and although the patch from post #84 works pretty well (when applied to a D6 CVS checkout), Ubercart is still nonfunctional. Since I am currently building and testing Ubercart-enabled sites, my only remaining option was to downgrade to PHP 5.2.10. I wanted to have the same extensions and options that Apple's PHP 5.3 build had, so I started by viewing the output of phpinfo() and copying the configure command. To compile PHP, locally installed copies of libpng, libjpeg and pcre are required so let's started with that:

  1. (Like in the Leopard tutorial, I assume you have installed the Xcode & related developer utilities and that all downloads are saved in the "Downloads" folder in your home). Visit the libpng, libjpeg and PCRE homepages and download the latest release available for both. As of writing, the most recent releases are libjpeg 7, libpng 1.2.39 and PCRE 7.9.
  2. Compile libpng and libjpeg statically:
    cd ~/Downloads && tar xfz libpng-1.2.39.tar.gz
    cd libpng-1.2.39
    ./configure --disable-shared --enable-static
    make && make install DESTDIR=`pwd`/localinstall

    cd ~/Downloads && tar xfz jpegsrc.v7.tar.gz
    cd jpeg-7
    ./configure --disable-shared --enable-static
    make && make install DESTDIR=`pwd`/localinstall

    cd ~/Downloads && tar xfj pcre-7.9.tar.bz2
    cd pcre-7.9
    ./configure --disable-shared --enable-static
    make && make install DESTDIR=`pwd`/localinstall
  3. Since PHP will be built with MySQL support, download and install MySQL x86_64 for OS X. As of writing, the latest version is 5.1.38.
  4. Download PHP 5.2.10, available here
  5. Next, PHP needs to be prepared for compilation. As detailed in PHP bug #49267, a small change is required to get PHP to compile on Snow Leopard:
    1. Type in the terminal:
      cd ~/Downloads && tar xfj php-5.2.10.tar.bz2
      cd php-5.2.10
      nano ext/iconv/iconv.c
    2. Skip down to line 185 (Tip: <ctrl+c> shows current line)
    3. Remove the lib on #define iconv libiconv so that the code reads like this:
      #ifdef HAVE_LIBICONV
      #define iconv iconv
    4. Hit <ctrl+o> and to save the file
    5. Hit <ctrl+x> to quit nano
  6. Now, PHP is ready for compilation. We will use a configure command relatively similar to the command extracted from phpinfo() earlier:
    ./configure '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-dependency-tracking' '--sysconfdir=/private/etc' '--with-apxs2=/usr/sbin/apxs' '--enable-cli' '--with-config-file-path=/etc' '--with-libxml-dir=/usr' '--with-openssl=/usr' '--with-kerberos=/usr' '--with-zlib=/usr' '--enable-bcmath' '--with-bz2=/usr' '--enable-calendar' '--with-curl=/usr' '--enable-exif' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/Users/shortname/Downloads/jpeg-7/localinstall/usr/local' '--with-png-dir=/Users/shortname/Downloads/libpng-1.2.39/localinstall/usr/local' '--enable-gd-native-ttf' '--with-ldap=/usr' '--with-ldap-sasl=/usr' '--enable-mbstring' '--enable-mbregex' '--with-mysql=/usr/local/mysql/' '--with-mysqli=/usr/local/mysql/bin/mysql_config' '--with-mysql-sock=/tmp/mysql.sock' '--with-iodbc=/usr' '--enable-shmop' '--with-snmp=/usr' '--enable-soap' '--enable-sockets' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--with-xmlrpc' '--with-xsl=/usr' '--with-pcre-regex=/Users/shortname/Downloads/pcre-7.9/localinstall/usr/local'

    EXTRA_CFLAGS="-lresolv" make -j2
    Remember to replace shortname in /Users/shortname to your system account's shortname. If you're not sure what that is, type whoami in a terminal to find out.
  7. Finally, backup Snow Leopard's PHP extension so that PHP 5.3 can be restored later, and copy the PHP 5.2.10 extension in its place:
    sudo mv /usr/libexec/apache2/ /usr/libexec/apache2/
    sudo cp libs/ /usr/libexec/apache2/
  8. The final step is to restart Apache - this can be done by toggling Web Sharing in System Preferences, or alternatively via the apachectl command:
    sudo apachectl restart
  9. That's all! Now run phpinfo() and verify that PHP 5.2.10 is up & running. While I was trying to get this working, I stumbled accross two compile errors - for the sake of completeness, I've listed them below along with the failure cause:

    1. This error occurs if EXTRA_CFLAGS="-lresolv" is not used while compiling PHP:
      Undefined symbols:
        "_res_9_dn_expand", referenced from:
            _zif_dns_get_mx in dns.o
        "_res_9_search", referenced from:
            _zif_dns_get_mx in dns.o
            _zif_dns_check_record in dns.o
        "_res_9_dn_skipname", referenced from:
            _zif_dns_get_mx in dns.o
            _zif_dns_get_mx in dns.o
      ld: symbol(s) not found
        "_res_9_dn_expand", referenced from:
            _zif_dns_get_mx in dns.o
        "_res_9_search", referenced from:
            _zif_dns_get_mx in dns.o
            _zif_dns_check_record in dns.o
        "_res_9_dn_skipname"collect2: , referenced from:
            ld returned 1 exit status_zif_dns_get_mx
      in dns.o
            _zif_dns_get_mx in dns.o
      ld: symbol(s) not found
      collect2: ld returned 1 exit status
    2. This error occurs if the #define iconv libiconv is not changed to #define iconv iconv
      Undefined symbols:
        "_libiconv", referenced from:
            __php_iconv_strlen in iconv.o
            _php_iconv_string in iconv.o
            _php_iconv_string in iconv.o
            __php_iconv_strpos in iconv.o
            __php_iconv_appendl in iconv.o
            __php_iconv_appendl in iconv.o
            _zif_iconv_substr in iconv.o
            _zif_iconv_mime_encode in iconv.o
            _zif_iconv_mime_encode in iconv.o
            _zif_iconv_mime_encode in iconv.o
            _zif_iconv_mime_encode in iconv.o
            _zif_iconv_mime_encode in iconv.o
            _zif_iconv_mime_encode in iconv.o
            _php_iconv_stream_filter_append_bucket in iconv.o
            _php_iconv_stream_filter_append_bucket in iconv.o
      ld: symbol(s) not found
      collect2: ld returned 1 exit status