You are here

linux

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 http://svn.calendarserver.org/repository/calendarserver/CalendarServer/tags/release/CalendarServer-2.4 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 ..
wget http://downloads.sourceforge.net/pythondirector/pydirector-1.0.0.tar.gz
tar xfz pydirector-1.0.0.tar.gz
popd
# 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 https://trac.calendarserver.org/ticket/391
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/caldav.py* /opt/CalendarServer"${sitearch}"/twisted/plugins
  # PYTHONPATH fix for 64-bit - see https://trac.calendarserver.org/ticket/390
  sed -i.orig 's|PYTHONPATH="'"${sitelib}"'|DESTDIR=/opt/CalendarServer\nPYTHONPATH="${DESTDIR}'"${sitelib}"':${DESTDIR}'"${sitearch}"':|' /opt/CalendarServer/usr/bin/caldavd
else
  # PYTHONPATH fix for 32-bit - see https://trac.calendarserver.org/ticket/390
  sed -i.orig 's|PYTHONPATH="'"${sitelib}"'|DESTDIR=/opt/CalendarServer\nPYTHONPATH="${DESTDIR}'"${sitelib}"':|' /opt/CalendarServer/usr/bin/caldavd
fi

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 www.example.com.key -out www.example.com.crt

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] -->
    <key>ServerHostName</key>
    <string>example.com</string> <!-- The hostname clients use when connecting -->

# Data roots
    <!-- Data root -->
    <key>DataRoot</key>
    <string>/srv/CalendarServer/Data/</string>
        
    <!-- Document root -->
    <key>DocumentRoot</key>
    <string>/srv/CalendarServer/Documents/</string>

# Test accounts configuration
    <!-- XML File Directory Service -->
    <key>DirectoryService</key>
    <dict>
      <key>type</key>
      <string>twistedcaldav.directory.xmlfile.XMLDirectoryService</string>
         
      <key>params</key>
      <dict>
        <key>xmlFile</key>
        <string>/opt/CalendarServer/etc/caldavd/accounts.xml</string>
      </dict>
    </dict>

# Sudoers configuration
    <!-- Principals that can pose as other principals -->
    <key>SudoersFile</key>
    <string>/opt/CalendarServer/etc/caldavd/sudoers.plist</string>

# Delete this section
<!-- Wikiserver authentication (Mac OS X) -->
      <key>Wiki</key>
      <dict>
        <key>Enabled</key>
        <true/>
        <key>Cookie</key>
        <string>sessionID</string>
        <key>URL</key>
        <string>http://127.0.0.1/RPC2</string>
        <key>UserMethod</key>
        <string>userForSession</string>
        <key>WikiMethod</key>
        <string>accessLevelForUserWikiCalendar</string>
      </dict>

# logging
    <!--
        Logging
      -->

    <!-- Apache-style access log -->
    <key>AccessLogFile</key>
    <string>/opt/CalendarServer/var/log/caldavd/access.log</string>
    <key>RotateAccessLog</key>
    <false/>

    <!-- Server activity log -->
    <key>ErrorLogFile</key>
    <string>/opt/CalendarServer/var/log/caldavd/error.log</string>

    <!-- Log levels -->
    <key>DefaultLogLevel</key>
    <string>info</string> <!-- debug, info, warn, error -->
# a bit further down…
    <!-- Global server stats -->
    <key>GlobalStatsSocket</key>
    <string>/opt/CalendarServer/var/run/caldavd/caldavd-stats.sock</string>
# <snip>
    <!-- Server statistics file -->
    <key>ServerStatsFile</key>
    <string>/opt/CalendarServer/var/log/caldavd/stats.plist</string>
       
    <!-- Server process ID file -->
    <key>PIDFile</key>
    <string>/opt/CalendarServer/var/run/caldavd/caldavd.pid</string>

# SSL 
    <!-- Public key -->
    <key>SSLCertificate</key>
    <string>/opt/CalendarServer/etc/tls/www.example.com.crt</string>
           
    <!-- Private key -->
    <key>SSLPrivateKey</key> 
    <string>/opt/CalendarServer/etc/tls/www.example.com.key</string>

# Privilege drop
    <!--
        Process management
      -->
   
    <key>UserName</key>
    <string>daemon</string>
   
    <key>GroupName</key>
    <string>daemon</string>
       
    <key>ProcessType</key>
    <string>Combined</string>

# iSchedule server-to-server settings
      <!-- iSchedule protocol options -->
      <key>iSchedule</key>
      <dict>
        <key>Enabled</key>
        <false/>
        <key>AddressPatterns</key>
        <array>
        </array>
        <key>Servers</key>
        <string>/opt/CalendarServer/etc/caldavd/servertoserver.xml</string>
      </dict>

# 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. -->
    <key>ControlSocket</key>
    <string>/opt/CalendarServer/var/run/caldavd/caldavd.sock</string>

# Twisted
    <!--
        Twisted
      -->
        
    <key>Twisted</key>
    <dict>
      <key>twistd</key>
      <string>/opt/CalendarServer/usr/bin/twistd</string>
    </dict>

# Load balancer
    <!--
        Python Director
      -->

    <key>PythonDirector</key>
    <dict>
      <key>pydir</key>
      <string>/opt/CalendarServer/usr/bin/pydir.py</string>

      <key>ConfigFile</key>
      <string>/opt/CalendarServer/etc/pydir.xml</string>

      <key>ControlSocket</key>
      <string>/opt/CalendarServer/var/run/caldavd/caldavd-pydir.sock</string>
    </dict>

...Profit!

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
Blog Tags: 
Rating: 

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 diffingo.com 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.

Blog Tags: 
Rating: 

Random thought

In any of my future classes related to operating systems, I want to try saying "sudo" instead of "please" and see how many people get it :P

I'll keep you updated.

Blog Tags: 
Rating: 

Fedora 11 is out!

You can grab it here. I will post some updated howtos soon.

Blog Tags: 
Rating: 

I'm tired of this (rev3)

Apple has been in my good books for a long time because as their computers have no problems. Nearly no viruses, popups or adware at all. No additional software needed. Their computers 'just worked', right out of the box. I'm seeing more and more things in Apple that I don't like, things that I stopped using Microsoft's products for. Apple's products work wonderfully, but in many cases only with other Apple-based products. iPhone. iPod. iLife. iMac. And even then I find they don't work that well all the time.

A perfect example is recently when I was creating a slideshow using music purchased from iTunes. The iTunes Plus tracks worked flawlessly - Drag & drop, that was it. I'm happy Steve Jobs supports it and I really hope the industry moves DRM free... But I'm getting off track. I try the regular iTunes tracks (DRM encumbered) and turns out they refused to be added to the iMovie slideshow claiming the computer wasn't authorized. I entered my password, authorizing from iMovie which didn't work so then from iTunes too. I even deauthorized and reauthorized the Macbook in iTunes to make sure. Then I tried playing the tracks in iTunes - It worked. I switched to iMovie and what d'ya you know, same results. In the end I burnt all the songs to two CDs and then ripped them. Another two hours of my time wasted. Apple's FairPlay doesn't seem too fair at all - I couldn't use it on the very same computer I had purchased the songs from, and forget even trying to play them on another computer. I don't even know if you can put songs purchased from iTunes onto non-iPod players without having to break the DRM first (which is illegal in the US).

This time, Apple has added encrypted firmware and hashes in the database which makes it near impossible to use a new iPod with 3rd party tools (see the article I posted at the beginning of this entry). To make it worse, the encrypted firmware makes you unable to run Linux (aka Rockbox) on it to workaround the database issue. One could say otherwise, but I don't see the advantage of encrypted firmware or hashes in the database to users... What do the 3rd party tools change from Apple point of view? Users have still purchased their iPods, and whether people update iPods from iTunes or GtkPod doesn't make a difference to Apple whatsoever.

Considering one can't use an iPod with Linux anymore, I'll have to use iTunes from Windows or Mac OS X. And considering what happened the last time I used iTunes, I won't be buying the new iPod everyone's talking about either.

Rating: 

My ramblings on Marvell 88E8056, 2.6.21, sky2

The Marvell LAN on my GA-965P-S3 board stopped working all of a sudden after a reboot the other day, and I franticly tried flashing the BIOS & firmware, I undid my overclock, even rewired everything inside. No luck.

The problem was due to the semi-broken sky2 driver... From what I've heard it's been broken for a while (and developers know it). Sky2 seems to work pretty well from my experience.. Apart from this.

Anyways the cause was the new 2.6.21 kernels, which is why it only started happening after a reboot, as I started booting new kernel. Reverting to 2.6.20 (in my case, the FC6 kernel) worked perfectly.

$ /sbin/lspci | grep Ethernet
04:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 14)
Blog Tags: 
Rating: 
Subscribe to RSS - linux