[CalendarServer-users] Problems with XMLDirectoryService

Ed Poe thinman at malted.net
Thu Jun 12 13:35:06 PDT 2008 

Aha!  I manually added proxies for the group and for the other user  
account, and magically iCal started letting me set availability and  
delegate, even for the resource that already had proxies defined in  
accounts.xml.  I had an odd behavior where iCal would briefly flash  
the proxies and then switch the pane to say that delegation wasn't  
supported, but it's working properly now after a restart.

Why would editing a proxy for a user fix delegation for a resource  
that already had proxies assigned?  Is there a database that doesn't  
get populated until you edit something?

Thanks for the help!

- e

On 12 Jun 2008, at 3:55 PM, tack wrote:

> 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
>>
>
> _______________________________________________
> calendarserver-users mailing list
> calendarserver-users at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users

More information about the calendarserver-users mailing list