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
[EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iD8DBQFHPoXFCgdfeCwsL5ERAoGCAJ4r9IFaDqsMjteygSGNlepQZt9LXQCfVfIH
RBp/h3FvSrQtQZkG9qTAUOM=
=inbp
-----END PGP SIGNATURE-----
_______________________________________________
calendarserver-users mailing list
calendarserver-users@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@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-----
_______________________________________________
calendarserver-users mailing list
calendarserver-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/calendarserver-users
