[CalendarServer-users] debian, getting started

[Frank Hartmann]

Guido Günther <agx at sigxcpu.org> 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