Apple's Calendarserver uses a file based XML backend by default. This has the
disadvantage that new users must be added manually and groups can't be
maintained dynamically - the calendarserver needs to be restarted.
Therefore we added a simple Name Service Switch based directory service
to the Debian packages - it's best to use 1.2.dfsg-4 or
newer. Using this, all users known to the system via getent passwd can have
calendars and group calendars can be maintained as simple groups of users.
Where your system gets it's user and group information from can be configured
via /etc/nsswitch.conf e.g.:
passwd: files ldap
group: files ldap
looks up users and groups in /etc/{passwd,groups} and using ldap via
libnss-ldap. For more details use man nsswitch.conf. All of this can be
configured dynamically without the need to restart calendarserver.
Calendarserver Configuration
To enable the NSS backend in calendarserver comment out the XML File
Directory Service via <!-- ... --> in /etc/caldavd/caldavd.plist then add
the NSS one. This example has all the parameters you can set:
<!-- NSS directory service -->
<key>DirectoryService</key>
<dict>
<key>type</key>
<string>twistedcaldav.directory.nss.NssDirectoryService</string>
<key>params</key>
<dict>
<key>realmName</key>
<string>Your Realm</string>
<!-- Don't treat user ids smaller than firstValidUid as calendarserver users -->
<key>firstValidUid</key>
<integer>1000</integer>
<!-- Don't treat user ids larger than lastValidUid as calendarserver users -->
<key>lastValidUid</key>
<integer>65533</integer>
<!-- Groups starting with this prefix are considered calendarserver groups -->
<key>groupPrefix</key>
<string>caldavd-</string>
<!-- Don't treat group ids smaller than firstValidGid as calendarserver groups -->
<key>firstValidGid</key>
<integer>1000</integer>
<!-- Don't treat group ids larger than lastValidGid as calendarserver groups -->
<key>lastValidGid</key>
<integer>65533</integer>
<!-- use username@mailDomain as calender user mail addresses -->
<key>mailDomain</key>
<string>example.com</string>
</dict>
</dict>
The firstValidUid and lastValidUid parameters allow you to specify which
users have calendars. By default uids in the range [1000,65533] are being used.
This way system users like lp, mail, news backup and nobody are excluded.
Shared calendars are represented by groups of users. The group name must start
with groupPrefix to avoid collisions with system users - the default is
caldavd-. The members of these groups are allowed to read/write the calendar.
The firstValidGid, lastValidGid have the same meaning as the uid ones above
but since you already specified a prefix you normally can simply omit them.
The mailDomain parameter can be used to specify a default mail domain. In the
exmaple above a user foo ends up with mail address of foo@example.com -
this information is used by some clients for free busy lists and invitations.
The values above - except for the realmName and mailDomain - are the
defaults build into calendarserver, so if these suite your needs you can simply
skip them:
<!-- NSS directory service -->
<key>DirectoryService</key>
<dict>
<key>type</key>
<string>twistedcaldav.directory.nss.NssDirectoryService</string>
<key>params</key>
<dict>
<key>realmName</key>
<string>sigxcpu.org</string>
<key>mailDomain</key>
<string>sigxcpu.org</string>
</dict>
</dict>
After changing this don't forget to restart calendarserver using
/etc/init.d/calendarserver restart.
Adding users and groups
Using the configuration above all users in the range
[firstValidUid,lastValidUid] readily have a calendar to access at:
http://localhost:8008/calendars/users/<user>/calendar
Adding a new user is now as easy as adduser <newuser>. The calendar get's
created once the user tries to access his calendar for the first time. To add a
shared calendar at:
http://localhost:8008/calendars/groups/test/calendar
simply do a addgroup caldavd-test. Then simply add users to this group:
adduser test <user>. To see which users can access this particular shared
calendar you can use:
getent group caldav-test
and to see all shared calendars use:
getent group | grep ^caldavd-
To see which calendars a user can access look at the output of id.
Note that {add,del}{user,group} manipluate users and groups in
/etc/passwd and /etc/group only. If you're using other name service switch
backends like ldap or postgresql you can use
the corresponding tools instead.
Limitations
User authentication currently only works using Kerberos. This is the
recommended form of authentication anyways. Let me know if you have problems
setting this up.
