aptitude install calendarserver
Configure Calendar Server
- Since calendarserver uses extended attributes you must mount the filesystem that contains the calendars (/var/spool/caldavd by default) with extended attributes enabled.
- XFS has extended attributes enabled by default.
- On ext3 add the user_xattr to the list. In my case I had /var/spool/caldavd on my "/" partition so I changed it like this:
vi /etc/fstab #change from: /dev/sda2 / ext3 defaults,errors=remount-ro 0 1 #to: /dev/sda2 / ext3 defaults,user_xattr,errors=remount-ro 0 1
- Now we need to add accounts.xml, and sudoers.plist
- Look at the accounts.xml and add any username and passwords in the similar fashion. We will copy the file from our examples folder and use username: admin, password: admin just to get us started. We will change the password when we are done.
cp /usr/share/doc/calendarserver/examples/accounts.xml /etc/caldavd/ cp /usr/share/doc/calendarserver/examples/sudoers.plist /etc/caldavd/
- Just an FYI. If you only require one more username you can quickly change the "test" user to you. So in my case I wanted a username lucas, so I opened the accounts.xml and replaced test with lucas.
Done, I have a lucas username in the system, with password lucas. I will change that password now.
- Uncomment the following line in:
# uncomment to start calendarserver on system startup start_calendarserver=yes
- Start the service:
By default calendarserver listens on localhost only so the URI to your caldav calendar will typically look like http://localhost:8008/calendars/users/<user>/calendar/
Visit this url to see if it works: http://localhost:8008/calendars/users/lucas/calendar/
Add Calendar To Thunderbird
- On Thunderbird/Icedove Install the lightning calendar module or use sunbird. I already have mine installed. On debian I install iceowl aka lightning :
aptitude install iceowl-extension
- Add a new calendar:
- Pick a name for the calendar:
- Done. Now Add events:
When others update, you just click Reload
Enable Calendar on company network
- Edit this file: vi /etc/caldavd/caldavd.plist
Leave this empty to enable all or put in the proper ip address. In my case I've change the <array><string>localhost</string></array> to
<!-- List of IP addresses to bind to [empty = all] --> <key>BindAddresses</key> <array><string></string></array>
Share events and Tasks
- Now follow the same step as we did in Adding calendar on other computers and you have fully functioning shared calendars system.
Moving Root Document Folder
- If for example you want to move a document root folder somewhere else you can do that by changing the following.
- In my case I have xfs running on /home partition so I want to move my calendar there.
#from: <!-- Document root --> <key>DocumentRoot</key> <string>/var/spool/caldavd</string> #to: <!-- Document root --> <key>DocumentRoot</key> <string>/home/caldavd</string>
- Now set the proper permissions
mkdir /home/caldavd chown caldavd:caldavd /home/caldavd
- Restart calendarserver
- Let the fun begin.
- A malformed xml file will be not accepted by the calendar server. Check the logs for error.
- Possible account types are: user, group, resource, location
<uid> is the realm-wide unique identifier (e.g. "lucas"). For all
resources, it determines the final path to the calendar. For users and groups, this is also the login id.
<guid> is the globally unique identifier. In the example file, this is set to the same as the uid, which is fine for testing purposes. For a live service though, you're better off using a proper GUID [link] (e.g. 572C1D4D-8FAC-4E8A-9F44-DFB1EC6B53C6). You can either generate them yourself using the "uuidgen"
apt-get install uuidcdef uuidcdef -u
<password> is the clear-text password of the account (ugh Even resources and locations have uids/passwords though they are seldom
accessed this way (see below). This can come in handy in an automated calendaring workflow, though.
<name> is the plain-text name/description of the account (e.g. "Main Conference Room" or "Conference Room LV-426" or "2nd floor Meeting Room"). It is not strictly required to be unique, though common sense dictates so.
<cuaddr> is an optional element, unique to the realm, that specifies the calendar user address for the account. This is currently a mailto URL (e.g. "firstname.lastname@example.org"). This address is used by calendaring clients to schedule a user or resource to a particular event (c.f. <auto-schedule>), c.f. iCalendar and related standards [link].
Resource and Location
- These account types are very much similar; they only differ in how the client uses them. They have a couple of special elements to them:
<auto-schedule>, if present, allows the resource accept invitations automatically, without the need to respond to mail sent to the <cuaddr>.
<proxies> specifies a list of accounts that have permission to
schedule the resource/location.
- Groups are special in that they both specify group calendars and group membership:
<members> is a list of account that belong to the group. This determines both group membership and the right to use the group
calendar (c.f. <disable-calendar>).
<disable-calendar>, if present, inactivates the calendar function for the group.