Hi, I have some problems using calendarserver. I thought of having a common appointment handling for 4 users and installed calendarserver. Unfortunately my setup is acting as a complex /dev/zero device and I am running against lots of walls trying to debug my setup. I am running debian/testing, using the prepackaged version calendarserver_1.2.dfsg-6_all.deb. I am a bit confused by the README.debian documentation, so followed the guideline there verbatim and created two files on my system: ---------------------------------------------------------------------- /etc/caldavd/sudoers.plist: ---------------------------------------------------------------------- <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>users</key> <array> <!-- Sudo user definitions --> <!-- With the exception of username and password none of the following elements are used in the current implementation. --> <dict> <key>username</key> <string>superuser</string> <key>password</key> <string>superuser</string> </dict> </array> </dict> </plist> ---------------------------------------------------------------------- /etc/caldavd/accounts.xml ---------------------------------------------------------------------- <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE accounts SYSTEM "accounts.dtd"> <accounts realm="Test Realm"> <user> <uid>admin</uid> <password>admin</password> <name>Super User</name> </user> <user> <uid>test</uid> <password>test</password> <name>Test_User</name> <cuaddr>mailto:testuser@example.com</cuaddr> </user> <group> <uid>users</uid> <password>users</password> <name>Users Group</name> <members> <member type="users">test</member> </members> </group> <location> <uid>mercury</uid> <password>mercury</password> <name>Mecury Conference Room, Building 1, 2nd Floor</name> <auto-schedule/> <proxies> <member type="users">test</member> </proxies> </location> </accounts> ---------------------------------------------------------------------- There does not seem to be any description anywhere what role the superuser from sudoers.plist or admin from accounts.xml have. I have restarted the server and two logfiles were created: ---------------------------------------------------------------------- /var/log/caldavd/access.log ---------------------------------------------------------------------- Log opened - server start: [Sun Nov 16 16:02:20 2008]. 127.0.0.1 - - [16/Nov/2008:16:05:58 +0200] "PROPFIND /calendars/users/test_user/calendar/ HTTP/1.1" 404 151 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.13pre) Gecko/20080916 Debian/unstable (Codename: sid) Iceowl/0.8" [43.9 ms] 127.0.0.1 - - [16/Nov/2008:16:06:13 +0200] "PUT /calendars/users/test_user/calendar/b152a194-62a0-48bc-96f1-30d6b65615a5.ics HTTP/1.1" 404 191 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.13pre) Gecko/20080916 Debian/unstable (Codename: sid) Iceowl/0.8" [27.3 ms] 127.0.0.1 - - [16/Nov/2008:16:20:23 +0200] "PROPFIND /calendars/users/Test_user/calendar/ HTTP/1.1" 404 151 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.13pre) Gecko/20080916 Debian/unstable (Codename: sid) Iceowl/0.8" [22.6 ms] 127.0.0.1 - - [16/Nov/2008:16:20:39 +0200] "PUT /calendars/users/Test_user/calendar/4a361f89-67f8-4856-bb45-b88c3c293e0d.ics HTTP/1.1" 404 191 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.13pre) Gecko/20080916 Debian/unstable (Codename: sid) Iceowl/0.8" [81.9 ms] ---------------------------------------------------------------------- /var/log/caldavd/error.log ---------------------------------------------------------------------- 2008-11-16 16:02:20+0100 [-] Log opened. 2008-11-16 16:02:20+0100 [-] twistd 8.1.0 (/usr/bin/python 2.5.2) starting up 2008-11-16 16:02:20+0100 [-] reactor class: <class 'twisted.internet.selectreactor.SelectReactor'> 2008-11-16 16:02:20+0100 [-] twistedcaldav.logging.AMPLoggingFactory starting on "'/var/run/caldavd/caldavd.socket'" 2008-11-16 16:02:20+0100 [-] [caldav-8008] /usr/lib/python2.5/site-packages/twisted/plugins/twisted_web2.py:22: DeprecationWarning: mktap and related support modules are deprecated as of Twisted 8.0. Use Twisted Application Plugins with the 'twistd' command directly, as described in 'Writing a Twisted Application Plugin for twistd' chapter of the Developer Guide. 2008-11-16 16:02:20+0100 [-] [caldav-8008] from twisted.scripts.mktap import _tapHelper 2008-11-16 16:02:21+0100 [-] [caldav-8008] [-] Log opened. 2008-11-16 16:02:21+0100 [-] [caldav-8008] [-] twistd 8.1.0 (/usr/bin/python 2.5.2) starting up 2008-11-16 16:02:21+0100 [-] [caldav-8008] [-] reactor class: <class 'twisted.internet.selectreactor.SelectReactor'> 2008-11-16 16:02:21+0100 [-] [caldav-8008] [-] twisted.web2.channel.http.HTTPFactory starting on 8008 2008-11-16 16:02:21+0100 [-] [caldav-8008] [-] Starting factory <twisted.web2.channel.http.HTTPFactory instance at 0x898380c> 2008-11-16 16:02:21+0100 [-] [caldav-8008] [-] set uid/gid 135/144 2008-11-16 16:02:21+0100 [twistedcaldav.logging.AMPLoggingFactory] AMPLoggingProtocol connection established (HOST:UNIXSocket('/var/run/caldavd/caldavd.socket') PEER:UNIXSocket('')) 2008-11-16 16:02:21+0100 [-] [caldav-8008] [-] AMP connection established (HOST:UNIXSocket(None) PEER:UNIXSocket('/var/run/caldavd/caldavd.socket')) 2008-11-16 16:05:58+0100 [-] [caldav-8008] [HTTPChannel,0,127.0.0.1] Provisioning file: <CalendarHomeProvisioningFile: /var/spool/caldavd/calendars> 2008-11-16 16:05:58+0100 [-] [caldav-8008] [HTTPChannel,0,127.0.0.1] Provisioning file: <CalendarHomeTypeProvisioningFile: /var/spool/caldavd/calendars/users> 2008-11-16 16:05:58+0100 [-] [caldav-8008] [HTTPChannel,0,127.0.0.1] Provisioning file: <CalendarHomeTypeProvisioningFile: /var/spool/caldavd/calendars/users> The entried from access.log is the result from using iceowl (debian name for sunbird) creating a nerw calendar and trying to make an entry. The location I specified there was http://localhost:8008/calendars/users/test_user/calendar/ and I tried http://localhost:8008/calendars/users/Test_user/calendar/ too. No password dialog appeared, no error messages. I added an appointment into my new calendar and it vanishes without any error message. I was not sure which side (server or client) was defective, so I searched this mailing list for some sort of known good command line client. I found: http://lists.macosforge.org/pipermail/calendarserver-users/2008-June/000906.... and tried then CalDAVClientLibrary revision 3384: fantasio:~/tmp/CalDAVClientLibrary$ ./runshell.py --server http://localhost:8008 --user=Test_user --pswd=test Ignoring error Ignoring error Traceback (most recent call last): File "./runshell.py", line 32, in <module> shell.runit() File "/mnt/hdd2/home/frank/tmp.nobackup/CalDAVClientLibrary/src/browser/shell.py", line 105, in runit shell = Shell(server, user, pswd, logging) File "/mnt/hdd2/home/frank/tmp.nobackup/CalDAVClientLibrary/src/browser/shell.py", line 43, in __init__ self.account = CalDAVAccount(server, ssl=ssl, user=self.user, pswd=self.pswd, root=paths, principal=paths, logging=logging) File "/mnt/hdd2/home/frank/tmp.nobackup/CalDAVClientLibrary/src/client/account.py", line 24, in __init__ self.principal = principalCache.getPrincipal(self.session, self.session.principalPath) File "/mnt/hdd2/home/frank/tmp.nobackup/CalDAVClientLibrary/src/client/principal.py", line 35, in getPrincipal self.cache[principal.principalURL.toString()] = principal AttributeError: 'str' object has no attribute 'toString' At this point I decided to ask the mailing list. How do I debug this further? Any documents I should have found? kind regards Frank
Use "test" rather than "test_user" in the URL for the calendar. The actual path uses the <uid> element in the XML. -- Cyrus Daboo (Tapped out on my iPhone) On Nov 16, 2008, at 9:47 AM, Frank Hartmann <soundart@gmx.net> wrote:
Hi,
I have some problems using calendarserver. I thought of having a common appointment handling for 4 users and installed calendarserver.
Unfortunately my setup is acting as a complex /dev/zero device and I am running against lots of walls trying to debug my setup.
I am running debian/testing, using the prepackaged version calendarserver_1.2.dfsg-6_all.deb.
I am a bit confused by the README.debian documentation, so followed the guideline there verbatim and created two files on my system:
---------------------------------------------------------------------- /etc/caldavd/sudoers.plist: ---------------------------------------------------------------------- <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd "> <plist version="1.0"> <dict> <key>users</key> <array> <!-- Sudo user definitions --> <!-- With the exception of username and password none of the following elements are used in the current implementation. --> <dict> <key>username</key> <string>superuser</string> <key>password</key> <string>superuser</string> </dict> </array> </dict> </plist>
---------------------------------------------------------------------- /etc/caldavd/accounts.xml ---------------------------------------------------------------------- <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE accounts SYSTEM "accounts.dtd">
<accounts realm="Test Realm"> <user> <uid>admin</uid> <password>admin</password> <name>Super User</name> </user> <user> <uid>test</uid> <password>test</password> <name>Test_User</name> <cuaddr>mailto:testuser@example.com</cuaddr> </user> <group> <uid>users</uid> <password>users</password> <name>Users Group</name> <members> <member type="users">test</member> </members> </group> <location> <uid>mercury</uid> <password>mercury</password> <name>Mecury Conference Room, Building 1, 2nd Floor</name> <auto-schedule/> <proxies> <member type="users">test</member> </proxies> </location> </accounts>
---------------------------------------------------------------------- There does not seem to be any description anywhere what role the superuser from sudoers.plist or admin from accounts.xml have.
I have restarted the server and two logfiles were created:
---------------------------------------------------------------------- /var/log/caldavd/access.log ---------------------------------------------------------------------- Log opened - server start: [Sun Nov 16 16:02:20 2008]. 127.0.0.1 - - [16/Nov/2008:16:05:58 +0200] "PROPFIND /calendars/ users/test_user/calendar/ HTTP/1.1" 404 151 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.13pre) Gecko/20080916 Debian/unstable (Codename: sid) Iceowl/0.8" [43.9 ms] 127.0.0.1 - - [16/Nov/2008:16:06:13 +0200] "PUT /calendars/users/ test_user/calendar/b152a194-62a0-48bc-96f1-30d6b65615a5.ics HTTP/ 1.1" 404 191 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv: 1.8.1.13pre) Gecko/20080916 Debian/unstable (Codename: sid) Iceowl/0.8" [27.3 ms] 127.0.0.1 - - [16/Nov/2008:16:20:23 +0200] "PROPFIND /calendars/ users/Test_user/calendar/ HTTP/1.1" 404 151 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.13pre) Gecko/20080916 Debian/unstable (Codename: sid) Iceowl/0.8" [22.6 ms] 127.0.0.1 - - [16/Nov/2008:16:20:39 +0200] "PUT /calendars/users/ Test_user/calendar/4a361f89-67f8-4856-bb45-b88c3c293e0d.ics HTTP/ 1.1" 404 191 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv: 1.8.1.13pre) Gecko/20080916 Debian/unstable (Codename: sid) Iceowl/0.8" [81.9 ms]
---------------------------------------------------------------------- /var/log/caldavd/error.log ----------------------------------------------------------------------
2008-11-16 16:02:20+0100 [-] Log opened. 2008-11-16 16:02:20+0100 [-] twistd 8.1.0 (/usr/bin/python 2.5.2) starting up 2008-11-16 16:02:20+0100 [-] reactor class: <class 'twisted.internet.selectreactor.SelectReactor'> 2008-11-16 16:02:20+0100 [-] twistedcaldav.logging.AMPLoggingFactory starting on "'/var/run/caldavd/caldavd.socket'" 2008-11-16 16:02:20+0100 [-] [caldav-8008] /usr/lib/python2.5/site- packages/twisted/plugins/twisted_web2.py:22: DeprecationWarning: mktap and related support modules are deprecated as of Twisted 8.0. Use Twisted Application Plugins with the 'twistd' command directly, as described in 'Writing a Twisted Application Plugin for twistd' chapter of the Developer Guide. 2008-11-16 16:02:20+0100 [-] [caldav-8008] from twisted.scripts.mktap import _tapHelper 2008-11-16 16:02:21+0100 [-] [caldav-8008] [-] Log opened. 2008-11-16 16:02:21+0100 [-] [caldav-8008] [-] twistd 8.1.0 (/usr/ bin/python 2.5.2) starting up 2008-11-16 16:02:21+0100 [-] [caldav-8008] [-] reactor class: <class 'twisted.internet.selectreactor.SelectReactor'> 2008-11-16 16:02:21+0100 [-] [caldav-8008] [-] twisted.web2.channel.http.HTTPFactory starting on 8008 2008-11-16 16:02:21+0100 [-] [caldav-8008] [-] Starting factory <twisted.web2.channel.http.HTTPFactory instance at 0x898380c> 2008-11-16 16:02:21+0100 [-] [caldav-8008] [-] set uid/gid 135/144 2008-11-16 16:02:21+0100 [twistedcaldav.logging.AMPLoggingFactory] AMPLoggingProtocol connection established (HOST:UNIXSocket('/var/run/ caldavd/caldavd.socket') PEER:UNIXSocket('')) 2008-11-16 16:02:21+0100 [-] [caldav-8008] [-] AMP connection established (HOST:UNIXSocket(None) PEER:UNIXSocket('/var/run/caldavd/ caldavd.socket')) 2008-11-16 16:05:58+0100 [-] [caldav-8008] [HTTPChannel, 0,127.0.0.1] Provisioning file: <CalendarHomeProvisioningFile: /var/ spool/caldavd/calendars> 2008-11-16 16:05:58+0100 [-] [caldav-8008] [HTTPChannel, 0,127.0.0.1] Provisioning file: <CalendarHomeTypeProvisioningFile: / var/spool/caldavd/calendars/users> 2008-11-16 16:05:58+0100 [-] [caldav-8008] [HTTPChannel, 0,127.0.0.1] Provisioning file: <CalendarHomeTypeProvisioningFile: / var/spool/caldavd/calendars/users>
The entried from access.log is the result from using iceowl (debian name for sunbird) creating a nerw calendar and trying to make an entry. The location I specified there was
http://localhost:8008/calendars/users/test_user/calendar/
and I tried
http://localhost:8008/calendars/users/Test_user/calendar/
too. No password dialog appeared, no error messages. I added an appointment into my new calendar and it vanishes without any error message.
I was not sure which side (server or client) was defective, so I searched this mailing list for some sort of known good command line client. I found:
http://lists.macosforge.org/pipermail/calendarserver-users/2008-June/000906....
and tried then CalDAVClientLibrary revision 3384:
fantasio:~/tmp/CalDAVClientLibrary$ ./runshell.py --server http://localhost:8008 --user=Test_user --pswd=test Ignoring error Ignoring error Traceback (most recent call last): File "./runshell.py", line 32, in <module> shell.runit() File "/mnt/hdd2/home/frank/tmp.nobackup/CalDAVClientLibrary/src/ browser/shell.py", line 105, in runit shell = Shell(server, user, pswd, logging) File "/mnt/hdd2/home/frank/tmp.nobackup/CalDAVClientLibrary/src/ browser/shell.py", line 43, in __init__ self.account = CalDAVAccount(server, ssl=ssl, user=self.user, pswd=self.pswd, root=paths, principal=paths, logging=logging) File "/mnt/hdd2/home/frank/tmp.nobackup/CalDAVClientLibrary/src/ client/account.py", line 24, in __init__ self.principal = principalCache.getPrincipal(self.session, self.session.principalPath) File "/mnt/hdd2/home/frank/tmp.nobackup/CalDAVClientLibrary/src/ client/principal.py", line 35, in getPrincipal self.cache[principal.principalURL.toString()] = principal AttributeError: 'str' object has no attribute 'toString'
At this point I decided to ask the mailing list. How do I debug this further? Any documents I should have found?
kind regards Frank _______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
Cyrus Daboo <cdaboo@apple.com> writes:
Use "test" rather than "test_user" in the URL for the calendar. The actual path uses the <uid> element in the XML.
Hi Cyrus, thank you very much! Works now! Still playing with it and looks fine. I have one other question: I am not familar with these xattr filesystem extensions and the manpage stated that these are required for CalendarServer. What is the procedure to backup a CalendarServer db? Do I have to preserve the xattrs somehow? Do I need to shutdown the CalendarServer while doing the backup? kind regards Frank
Hi Frank, --On November 16, 2008 9:59:50 PM +0100 Frank Hartmann <soundart@gmx.net> wrote:
thank you very much! Works now! Still playing with it and looks fine.
I have one other question: I am not familar with these xattr filesystem extensions and the manpage stated that these are required for CalendarServer.
What is the procedure to backup a CalendarServer db? Do I have to preserve the xattrs somehow?
Yes you need to preserve xattrs. How you do that will depend on what tools you want to use. Typically there are options for tar and rsync, for example, that you may need to turn on to ensure xattrs are saved and restored.
Do I need to shutdown the CalendarServer while doing the backup?
It is probably best to do that as there could be times when the server is in the process of doing updates to a resource and the calendar index file - and the two could be out of sync for a short while as the operation is being executed. -- Cyrus Daboo
Guido Günther <agx@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
Hi Frank, On Tue, Nov 18, 2008 at 09:11:18PM +0100, Frank Hartmann wrote:
Guido Günther <agx@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. Thanks for the patch!
[..snip..]
+<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:
Sudoers can act as (impersonate) other principals as I understand things. So your sudo users can manipulate calendars of other users.
+ +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> The admin user has DAV:all access so is allowed to "write,read,rm everywhere". Is that correct? Cheers, -- Guido
On Wed, Nov 19, 2008 at 07:34:33PM +0100, Guido Günther wrote: [..snip..]
+The example configuration in /usr/share/doc/calendarserver/examples/sudoers.plist +achieves the following:
Sudoers can act as (impersonate) other principals as I understand things. So your sudo users can manipulate calendars of other users.
+ +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> The admin user has DAV:all access so is allowed to "write,read,rm everywhere". Is that correct? Does this make sense? -- Guido
participants (3)
-
Cyrus Daboo
-
Frank Hartmann
-
Guido Günther