[CalendarServer-users] Problems with XMLDirectoryService

Cyrus Daboo cdaboo at apple.com
Fri Jun 13 13:26:01 PDT 2008 

There is a caching bug whereby some http headers are not bring  
returned on a cached response and that is causing iCal to disable  
certain features. A fix for this is in the works.

-- 
Cyrus Daboo
(Tapped out on my iPhone)


On Jun 13, 2008, at 1:15 PM, Ed Poe <thinman at malted.net> wrote:

> I don't even mind having to set up the delegation manually in this
> particular test, but what I do mind is that this is reliably broken.
>
> I can set up manual proxies using the command line tools, but as soon
> as anything strange happens on the server (today's example was me
> trying to play with Sunbird instead of iCal) the server's concept of
> the proxy list seems to go sideways.  iCal will then refuse to allow
> availability to be set, and if it shows the delegation options at all
> it's only briefly before switching the pane to say that delegation
> isn't supported.  Oddly, any delegated calendar will continue to show
> up in the list in the main iCal window, and you can continue to
> create, edit, and delete events even though the preferences window
> tells you it's not supported.
>
> Steps to reproduce:
>
> 1.  On a new server, create a new accounts.xml with two users, both
> members of a group, both proxies for one resource.
> 2.  Start the server and use iCal to log in as one of the new users.
> 3.  Sometimes you actually get the delegation screen in that first run
> of iCal after configuration, so quit it and launch it again.
> 4.  Open iCal accounts preferences.  Note that availability and
> delegation are not (or are no longer) supported.  Quit iCal.
> 5.  Using runshell.py, add a new proxy to a user.
> 6.  Launch iCal again and open the accounts preferences.  Availability
> and delegation will be supported again.
>
> - e
>
> On 12 Jun 2008, at 4:42 PM, tack wrote:
>
>> Attendee autocomplete and iCal delegation prefs are things that go
>> best with Open Directory, sadly.
>>
>> Cheers,
>> tack
>>
>> On Jun 12, 2008, at 1:35 PM, Ed Poe wrote:
>>
>>> 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
>>>
>>> _______________________________________________
>>> 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