[CalendarServer-users] Problems with XMLDirectoryService

Thu Jun 12 12:55:36 PDT 2008

For sharing calendars, you have to edit the ACL on the calendar, not  
the person who's calendar it is.  When I've had permissions issues in  
the client tool, I've cd'd down into the directories.  It helps.

You could also add people as a proxy to others, rather than setting  
ACL's:

 From an earlier post by Cyrus:
--------------------------------
./runshell.py ...
> proxies -i -p /principals/users/user01
Proxy > add -r
New principal [q - quit]: /principals/users/user02

That will add user02 as a read-only proxy to user01.
--------------------------------

You can get the dirt on the proxies command the same way as the acl  
command.

Cheers,
tack

On Jun 12, 2008, at 12:20 PM, Ed Poe wrote:

> tack -
>
> Thanks for the quick reply.
>
> I commented out the guid elements (and deleted and regenerated the
> server data) with no effect.
>
> Using the command line client, I get the following errors with a props
> command in a user directory:
>
> Failed Properties:
>     {DAV:}acl: 401
>     {DAV:}current-user-privilege-set: 401
>
> It fails in any path under /principals, but doesn't fail in a path
> like /calendars/users/<username> so I may just be misunderstanding in
> what context the acl command is supposed to work.
>
> If I had to guess I'd say it looks more like user authentication fails
> outside the user's own directory, but I don't know why.  In
> troubleshooting this I changed the AdminPrincipals in caldavd.plist
> and now my user account can at least subscribe to the other account
> and the group, but I still can't delegate the resource or directly add
> events for the group, and availability is still not supported on the
> server (according to iCal, anyway).
>
> - e
>
> On 12 Jun 2008, at 1:39 PM, tack wrote:
>
>> Hi Ed,
>>
>> Try commenting out the guid element in the users.  That was one of  
>> the
>> earlier solutions to some things.  I don't have it in my accounts.xml
>> and we can use availability.
>>
>> As far as permissions, you can edit the ACL's with the command line
>> client:
>>
>> http://trac.calendarserver.org/wiki/CalDAVClientLibrary
>>
>> and this oughta get you started navigating the tool:
>>
>> http://wantedfornerder.blogspot.com/2008/04/darwin-calendar-server-client-tool.html
>>
>> Cheers,
>> tack
>>
>> On Jun 12, 2008, at 9:15 AM, Ed Poe wrote:
>>
>>> I have a server built from SVN running on debian etch (with python
>>> 2.5
>>> from sid).  It's configured to use XMLDirectoryService.  Client
>>> software is iCal 3.0.3 (1244) on 10.5.3.
>>>
>>> Although users can log in and edit their own calendars, free/busy
>>> doesn't work ("Availability is not supported on the server for this
>>> account) and delegates for resources don't work ("Delegation is not
>>> supported on the server for this account".  Also following
>>> instructions I've found in the archives I'm unable to set up iCal to
>>> access shared calendars ("Access is denied at https://<server>:8443/
>>> calendars/groups/<group>/calendar with this login and password."),
>>> although I'm not positive that iCal is supposed to be able to do  
>>> this
>>> anyway as the documentation is lacking (as has been discussed on  
>>> this
>>> list).  The cert is self-signed, but the CA is imported into the
>>> keychain and it works fine in Safari and Mail.app so I don't think
>>> it's an https problem, and I have the same issue with http  
>>> anyway.  I
>>> do get this message in the error_log:
>>>
>>> 2008-06-12 12:02:05-0400 [-] [caldav-8009]  [AMP,client]
>>> [twisted.web2.dav.resource#info] Authentication failed: Incorrect
>>> credentials for
>>> <
>>> XMLDirectoryRecord
>>> [users at 55a7b2a7-2238-57a0-8539-652e8aad9fdf(Calendar)]
>>> bf6c39d3-5267-5bfc-8df1-39d7d1591e80(ed) 'Ed Poe'>
>>>
>>> Is this just a subtle syntax error in my accounts.xml file, or is
>>> something else going on?  I've tried deleting data files on the
>>> server
>>> (both the sqlite data and the contents of the CalendarServer/
>>> Documents
>>> directory).  If I use a web browser I can see that the principals  
>>> all
>>> exist.
>>>
>>> <accounts realm="Calendar">
>>> <user>
>>> <guid>f1f8ce95-2482-5c41-9c47-952ec8394056</guid>
>>> <uid>admin</uid>
>>> <password>XXXX</password>
>>> <name>Super User</name>
>>> <cuaddr>mailto:root at mydomain</cuaddr>
>>> </user>
>>> <user>
>>> <uid>ed</uid>
>>> <guid>bf6c39d3-5267-5bfc-8df1-39d7d1591e80</guid>
>>> <password>XXXX</password>
>>> <name>Ed Poe</name>
>>> <cuaddr>mailto:nobody at nowhere.int</cuaddr>
>>> </user>
>>> <user>
>>> <uid>kate</uid>
>>> <guid>673a4166-e05b-5908-8066-60756837fe74</guid>
>>> <password>XXXX</password>
>>> <name>her name</name>
>>> <cuaddr>mailto:nobody at nowhere.int</cuaddr>
>>> </user>
>>> <group>
>>> <uid>groupname</uid>
>>> <guid>1b8539c4-074f-5bd2-ba3d-963049bfb044</guid>
>>> <password>XXXX</password>
>>> <name>our group</name>
>>> <members>
>>> <member type="users">ed</member>
>>> <member type="users">kate</member>
>>> </members>
>>> </group>
>>> <resource>
>>> <uid>car</uid>
>>> <guid>a8b27dba-8cf6-513e-a7cf-b940ffed94fe</guid>
>>> <password>XXXX</password>
>>> <name>Honda del Sol VTEC</name>
>>> <auto-schedule/>
>>> <proxies>
>>> <member type="users">ed</member>
>>> <member type="users">kate</member>
>>> </proxies>
>>> </resource>
>>> </accounts>
>>>
>>> _______________________________________________
>>> calendarserver-users mailing list
>>> calendarserver-users at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver- 
>>> users
>>>
>>
>> _______________________________________________
>> calendarserver-users mailing list
>> calendarserver-users at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
>
> _______________________________________________
> calendarserver-users mailing list
> calendarserver-users at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
>