Guido Günther <[EMAIL PROTECTED]> writes: > On Sun, Nov 16, 2008 at 04:47:54PM +0100, Frank Hartmann wrote: >> I am a bit confused by the README.debian documentation, so followed >> the guideline there verbatim and created two files on my system: > Documentation updates to README.Debain are always welcome. > -- Guido Hi Guido,
as told I am confused. This is maybe not the right starting point. On the other hand it might show the experts what a normal user of the tool is facing. So my attempt need some more work: --- /usr/share/doc/calendarserver/README.Debian 2008-08-08 12:02:02.000000000 +0200 +++ Readme.Debian.fjh 2008-11-18 21:05:23.000000000 +0100 @@ -8,6 +8,11 @@ attributes enabled. On ext2/ext3 filesystems use the user_xattr mount option, XFS has extended attributes enabled by default. +During backup these user_xattr have to be preserved. This renders some +backup tools useless, especially GNU tar and afio based solutions do +not support user_xattr. Please check! It is recommended to shutdown +the calendarserver daemon during backups. + You have to add a /etc/caldavd/accounts.xml to tell caldavd about your accounts and users. See /usr/share/doc/calendarserver/examples/accounts.xml for an example. Likewise you have to add a /etc/caldavd/sudoers.plist. Both files have @@ -16,12 +21,50 @@ 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/ + http://localhost:8008/calendars/users/<user_uid>/calendar/ where <user> is the username of a calendarserver user as specified in accounts.xml. And for groups defined in accounts.xml it's: - http://localhost:8008/calendars/groups/<group>/calendar/ + http://localhost:8008/calendars/groups/<group_uid>/calendar/ + + +The example configuration in /usr/share/doc/calendarserver/examples/accounts.xml +achieves the following: + +It defines two 'user' calendars: + + <uid>admin</uid> + <uid>test</uid> + +and two 'group' calenders: + + <uid>users</uid> + <uid>mercury</uid> + +Which have the following properties: + +<BIG GAP: NO IDEA, please fill in> + +<uid>admin</uid> has by the magic +of his name administration rights and can do certain action which +normal users can't, right? +<uid>test</uid> is a plain user. +<uid>mercury</uid> a shared resource- in our example a conference room +which can be booked by all members of group <uid>users</uid>. + + +The example configuration in /usr/share/doc/calendarserver/examples/sudoers.plist +achieves the following: + +It defines a user 'superuser' which is the big brother of 'admin' and +has god like access rights. 'superuser' normally wears a blue suit +with a big red 'S' in front. + +</BIG GAP: NO IDEA, please fill in> + + + Loadbalancing ---------------------------------------------------------------------- kind regards Frank _______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
