[CalendarServer-users] delegation help?

Emil Lundberg Emil.Lundberg at bmc.uu.se
Mon Nov 19 05:45:22 PST 2007 

> So are you saying that I should try setting up these accounts as  
> resources instead of users? Or, would these resources be defined in  
> addition to users? I'm assuming the former...

Ideally, users should be users (only) and be able to assign delegates.  
We will need Cyrus, et al, to chime in whether this is possible using  
XML service or not. Even if it's to call us "dorks" for not getting  
it :-)

Depending on what exactly you are trying to achieve, as a workaround  
you can either

a) setup two users and one resource; making both users proxies for the  
resource
b) setup two users and two resources; making both users proxies for  
both resources

I'm reluctant to advise the use of resources only, as iCal 3 (somewhat  
surprisingly) will not let you use a resource principal URL in the  
accounts pane; and there might be other repercussions too.


> What is the effective difference between resources and locations  
> anyway?

I suppose they differ as to where and how they are referenced in a  
calender client interface, and conceptually by other systems. E.g. in  
OD, a location has a capacity, and so on.


> Also, as per your example below, what should be put in place of the  
> stars for GUID? Should this be the GUID as assigned to the user? If  
> so, why would the password have to be provided again if we are just  
> referencing an existing user?

The GUID discussion was long and not entirely clear-cut, but my  
interpretation of it was this:

Optimally, in using the XML directory service, one should let the  
server generate the <guid> element (I think it's optional) for ALL  
entities (users, groups, locations, resources), then immediately paste  
them into the accounts file. This ensures the integrity of calendars  
created by a previous user of the same UID, as the GUID will have  
changed.

However, for testing purposes, I believe it's OK to just use GUID ==  
UID.

Under NO circumstances should you have ANY entities using the same  
GUID, nor any entities of the same kind using the same UID (the XML  
service will just pick the last one as far as I can see).

While it IS possible to have entities of different kinds using the  
same UID (they will be referenced by different URI's and/or by the  
GUID), there is absolutely no relation between a user "userA" and a  
location "userA".

Bottom line: the accounts file should define unique entities of types  
user, group, location, resource. The only way they can reference each  
other is through the <members> element (for groups) or through the  
<proxies> element (for resources & locations).


Clear as mud, I'm sure... ;-)

/Emil


> On Nov 18, 2007, at 7:14 AM, Emil Lundberg wrote:
>
>> Well, an error message would have been really helpful, as my mind- 
>> reading skills aren't yet up to snuff... :-)
>>
>> I must confess I was setting you straight simply on the basis of  
>> Cyrus's instructions. Trying it for real shows the exact behaviour  
>> you and Louis describe. The server will continuously read the  
>> accounts file and fail, until it is properly configured. I'm  
>> running DCS under OS X 10.5.1 Server and the critical piece of log  
>> is:
>>
>> (DCS 1.0 = rev 1995)		ValueError: <auto-schedule> element only  
>> allowed for Resources and Locations: proxies
>> (DCS trunk = rev 2019)	exceptions.ValueError: <auto-schedule>  
>> element only allowed for Resources and Locations: proxies
>>
>> Which suggest (although <auto-schedule/> is not used here) that the  
>> <proxies> element cannot be used for users or groups. Adding <auto- 
>> shedule/> for testing purposes makes it complain about this instead.
>>
>> I guess we need the DCS folks to chime in here.
>>
>> Regarding iCal's (3.0.1 = rev 1205) behavior with DCS, I've found  
>> that it will detect me as a proxy member (even through a group, see  
>> example) for a resource through its native interface, so need to go  
>> through steps 4-6 in this case - just check the approprate  
>> resources under Accounts -> Delegation and a "DELEGATES" header  
>> will appear in the main window.
>>
>> best,
>>
>> /Emil
>>
>> example resource element, delegated by group:
>>
>> <resource>
>>   <uid>my_resource</uid>
>>   <guid>*****</guid>
>>   <password>*****</password>
>>   <name>My Resource</name>
>>   <auto-schedule/>
>>   <proxies>
>>     <member type="groups">my_group</member>
>>   </proxies>
>> </resource>
>>
>>
>>
>>
>> 18 nov 2007 kl. 07.02 skrev Joe Auty:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Also note that as soon as I comment out the proxies belonging to  
>>> these two users, I can startup the server again...
>>>
>>> Thanks in advance for your help here!
>>>
>>> On Nov 18, 2007, at 1:01 AM, Joe Auty wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>>
>>>> On Nov 17, 2007, at 5:30 AM, Emil Lundberg wrote:
>>>>
>>>>> Hey Joe,
>>>>>
>>>>> You've confused the sample accounts file where locations have  
>>>>> delegates (which is normal), with cyrus's example. You now have  
>>>>> users and locations with duplicate uid's which is definitely not  
>>>>> what you intended :-)
>>>>>
>>>>> Here's what your accounts.xml file should look like (but c.f.  
>>>>> the previous discussion on the use of the guid field):
>>>>>
>>>>> <user>
>>>>> <uid>userA</uid>
>>>>> <guid>userA</guid>
>>>>> <password>password</password>
>>>>> <name>user A</name>
>>>>> <proxies>
>>>>> <member type="users">userB</member>
>>>>> </proxies>
>>>>> </user>
>>>>> <user>
>>>>> <uid>userB</uid>
>>>>> <guid>userB</guid>
>>>>> <password>password</password>
>>>>> <name>user B</name>
>>>>> <proxies>
>>>>> <member type="users">userA</member>
>>>>> </proxies>
>>>>> </user>
>>>>>
>>>>
>>>> Hmmm... setting up my accounts-test.xml file results in the  
>>>> server not being able to startup (I could paste in the error if  
>>>> helpful, but it is quite long)
>>>>
>>>> I have taken out my locations I have defined, and modifed my  
>>>> users declarations to match the following:
>>>>
>>>> <user>
>>>> <uid>joe</uid>
>>>> <guid>joe</guid>
>>>> <password>mypassword</password>
>>>> <name>Joe Auty</name>
>>>> <proxies>
>>>> <member type="users">test</member>
>>>> </proxies>
>>>> </user>
>>>> <user>
>>>> <uid>test</uid>
>>>> <guid>test</guid>
>>>> <password>mypassword</password>
>>>> <name>Joe Auty (test)</name>
>>>> <proxies>
>>>> <member type="users">joe</member>
>>>> </proxies>
>>>> </user>
>>>>
>>>>
>>>> Here is the first few lines of my error message:
>>>>
>>>>> 2007-11-18 01:01:19-0500 [-] [caldav-8008]  [-] Log opened.
>>>>> 2007-11-18 01:01:19-0500 [-] [caldav-8008]  [-] twistd  
>>>>> 2.5.0+rUnknown (/usr/local/bin/python 2.4.4) starting up
>>>>> 2007-11-18 01:01:19-0500 [-] [caldav-8008]  [-] reactor class:  
>>>>> <class 'twisted.internet.selectreactor.SelectReactor'>
>>>>> 2007-11-18 01:01:19-0500 [-] [caldav-8008]  [-] Configuring  
>>>>> directory service of type:  
>>>>> twistedcaldav.directory.xmlfile.XMLDirectoryService
>>>>> 2007-11-18 01:01:19-0500 [-] [caldav-8008]  [-] Traceback (most  
>>>>> recent call last):
>>>>> 2007-11-18 01:01:19-0500 [-] [caldav-8008]  [-]   File "../ 
>>>>> Twisted/bin/twistd", line 21, in ?
>>>>> 2007-11-18 01:01:19-0500 [-] [caldav-8008]  [-]     run()
>>>>> 2007-11-18 01:01:19-0500 [-] [caldav-8008]  [-]   File "/usr/ 
>>>>> local/src/Twisted/twisted/scripts/twistd.py", line 27, in run
>>>>> 2007-11-18 01:01:19-0500 [-] [caldav-8008]  [-]      
>>>>> app.run(runApp, ServerOptions)
>>>>> 2007-11-18 01:01:19-0500 [-] [caldav-8008]  [-]   File "/usr/ 
>>>>> local/src/Twisted/twisted/application/app.py", line 379, in run
>>>>> 2007-11-18 01:01:19-0500 [-] [caldav-8008]  [-]     runApp(config)
>>>>> 2007-11-18 01:01:19-0500 [-] [caldav-8008]  [-]   File "/usr/ 
>>>>> local/src/Twisted/twisted/scripts/twistd.py", line 23, in runApp
>>>>> 2007-11-18 01:01:19-0500 [-] [caldav-8008]  [-]      
>>>>> _SomeApplicationRunner(config).run()
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Then follow steps 4-6 below. Note that using iCal server (or DCS  
>>>>> w/ OD directory service I presume), iCal let's a user define  
>>>>> delgates for himself from within iCal, as well as lets the  
>>>>> delegate see calendars for which he is the delegate.
>>>>>
>>>>> /Emil
>>>>>
>>>>>
>>>>> On 17 nov 2007, at 07.10, Joe Auty wrote:
>>>>>
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> Finally had time to test this, but this doesn't seem to work...  
>>>>>> here are the your instructions again, Cyrus, as well as my  
>>>>>> results...
>>>>>>
>>>>>> On Nov 12, 2007, at 10:13 AM, Cyrus Daboo wrote:
>>>>>>>>
>>>>>>>
>>>>>>> OK, here are some step-by-step instructions for setting up  
>>>>>>> delegates:
>>>>>>>
>>>>>>> Example add user 'A' as a delegate/proxy for user 'B'.
>>>>>>>
>>>>>>> 1) In the accounts.xml, locate the user 'B' account entry.
>>>>>>>
>>>>>>> 2) Add a <proxies> element to user B entry if one is not  
>>>>>>> already present.
>>>>>>>
>>>>>>> 3) Inside the <proxies> element add an element for user 'A'  
>>>>>>> thusly:
>>>>>>>
>>>>>>> <member type="users">A</member>
>>>>>>>
>>>>>>> replace 'A' with the actual user id.
>>>>>>>
>>>>>>> 4) In your web browser, navigate to /principals/users/B  
>>>>>>> (substituting the user id for B). Copy the principal-URL value  
>>>>>>> you see there (it will start with /principals/__uids__/).
>>>>>>>
>>>>>>> 5) In iCal create a new CalDAV account. For the user id enter  
>>>>>>> user A's user id. For the password use user A's password.  
>>>>>>> Expand down the 'Server Options" section and enter the  
>>>>>>> principal-URL value for user B into the Account URL field.  
>>>>>>> Then click Add.
>>>>>>>
>>>>>>> 6) After that the calendars for user B will appear in iCal.  
>>>>>>> Note that this is being accessed by user A (i.e. using user  
>>>>>>> A's login/password). So user B's login/password is kept  
>>>>>>> private to them. User A will have full read-write access to  
>>>>>>> user B's calendar data.
>>>>>>>
>>>>>>
>>>>>> Okay, I have 3 accounts configured in iCal now:
>>>>>>
>>>>>> 1) my account (user A)
>>>>>> 2) my test account (user B)
>>>>>> 3) the account you requested me to create here using the  
>>>>>> username and password for user A, and the following server  
>>>>>> address:
>>>>>> 	
>>>>>> https://mydomain:8443/principals/__uids__/test/
>>>>>>
>>>>>> I have setup delegation for user A so that I can access user B  
>>>>>> using the delegation tab in the iCal GUI
>>>>>>
>>>>>> Here is my accounts XML file:
>>>>>>
>>>>>>
>>>>>> <user>
>>>>>> <uid>userA</uid>
>>>>>> <guid>userA</guid>
>>>>>> <password>password</password>
>>>>>> <name>user A</name>
>>>>>> </user>
>>>>>> <user>
>>>>>> <uid>userB</uid>
>>>>>> <guid>userB</guid>
>>>>>> <password>password</password>
>>>>>> <name>user B</name>
>>>>>> </user>
>>>>>> <user>
>>>>>>
>>>>>>
>>>>>> <location>
>>>>>> <uid>userA</uid>
>>>>>> <password>password</password>
>>>>>> <name>user A</name>
>>>>>> <auto-schedule/>
>>>>>> <proxies>
>>>>>> <member type="users">userB</member>
>>>>>> </proxies>
>>>>>> </location>
>>>>>>
>>>>>> <location>
>>>>>> <uid>userB</uid>
>>>>>> <password>password</password>
>>>>>> <name>user B</name>
>>>>>> <auto-schedule/>
>>>>>> <proxies>
>>>>>> <member type="users">userA</member>
>>>>>> </proxies>
>>>>>> </location>
>>>>>>
>>>>>>
>>>>>> The result: no noticeable change. I was expecting that anything  
>>>>>> I'd write to the delegate calendar would be available under  
>>>>>> user B's calendar and vice versa.
>>>>>>
>>>>>> Have I done something wrong here?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> - -----------
>>>>>> Joe Auty
>>>>>> NetMusician: web publishing software for musicians
>>>>>> http://www.netmusician.org
>>>>>> joe at netmusician.org
>>>>>>
>>>>>>
>>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>> Version: GnuPG v1.4.7 (Darwin)
>>>>>>
>>>>>> iD8DBQFHPoXFCgdfeCwsL5ERAoGCAJ4r9IFaDqsMjteygSGNlepQZt9LXQCfVfIH
>>>>>> RBp/h3FvSrQtQZkG9qTAUOM=
>>>>>> =inbp
>>>>>> -----END PGP SIGNATURE-----
>>>>>> _______________________________________________
>>>>>> calendarserver-users mailing list
>>>>>> calendarserver-users at lists.macosforge.org
>>>>>> http://lists.macosforge.org/mailman/listinfo/calendarserver-users
>>>>>
>>>>
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1.4.7 (Darwin)
>>>>
>>>> iD8DBQFHP9UwCgdfeCwsL5ERAgCqAJ9Ix1sykKweeJQ86i90D3RvO929WgCeO/dS
>>>> K4NaKE+Nbw4BwxwOWqpeFKU=
>>>> =zVN6
>>>> -----END PGP SIGNATURE-----
>>>> _______________________________________________
>>>> calendarserver-users mailing list
>>>> calendarserver-users at lists.macosforge.org
>>>> http://lists.macosforge.org/mailman/listinfo/calendarserver-users
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.7 (Darwin)
>>>
>>> iD8DBQFHP9WPCgdfeCwsL5ERAoEeAJ9tm3WGfp6q3XxoCXAjKf2k4fvR4gCeJTBY
>>> crpjuFBLjHzDtfu+r/RCaF0=
>>> =X0Md
>>> -----END PGP SIGNATURE-----
>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (Darwin)
>
> iD8DBQFHQLRKCgdfeCwsL5ERAg9sAJ42bFx/t6sNeIn1RK6/DILzU7J4mACfTD6K
> ea743KRfB0TptJ8yOS9ywTE=
> =RYU9
> -----END PGP SIGNATURE-----

More information about the calendarserver-users mailing list