[CalendarServer-users] Problems with XMLDirectoryService

Ed Poe thinman at malted.net
Fri Jun 13 13:15:16 PDT 2008 

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

More information about the calendarserver-users mailing list