By editing the repository-dev.xml file I was able to create more users. The principals are created. When I attempt to publish a calendar as one of the new users the /calendars/users/<newuser> folder is created with the inbox and outbox folder. But the calendar fails to publish with "Access to the calendar <server url> is not permitted.." If I use the admin name and password I can publish the test calendar. I saw this comment on the Quick Start page of the site "This principal is also set up with "all" permissions on the server." and I am guessing that my problem is in there, just don't know where there is. ;-) Do I need to give my new users or principals "all" permissions. If so, how would I do that? Any and all suggestions greatly appreciated. Rick Davis
Hi Rick, FYI I just added a wiki page for the repository.xml file: <http://svn.macosforge.org/projects/calendarserver/wiki/RepositoryXML> --On September 5, 2006 12:25:28 AM -0400 Rick Davis <roodavis@mac.com> wrote:
By editing the repository-dev.xml file I was able to create more users. The principals are created. When I attempt to publish a calendar as one of the new users the /calendars/users/<newuser> folder is created with the inbox and outbox folder.
What are you using to 'publish' a calendar?
But the calendar fails to publish with "Access to the calendar <server url> is not permitted.." If I use the admin name and password I can publish the test calendar.
Can you provide the relevant portion of the server log?
I saw this comment on the Quick Start page of the site "This principal is also set up with "all" permissions on the server." and I am guessing that my problem is in there, just don't know where there is. ;-) Do I need to give my new users or principals "all" permissions. If so, how would I do that?
Any and all suggestions greatly appreciated.
As described on the wiki page, each user should be given <DAV:all> privileges to their own calendar home collection. So it should be possible to do anything in that collection once authenticated. -- Cyrus Daboo
Hi Cyrus, I'm also struggling with that using Mulberry ... --On 5. September 2006 10:25:59 -0400 Cyrus Daboo <cdaboo@apple.com> wrote:
FYI I just added a wiki page for the repository.xml file:
<http://svn.macosforge.org/projects/calendarserver/wiki/RepositoryXML>
Thanks ...
--On September 5, 2006 12:25:28 AM -0400 Rick Davis <roodavis@mac.com> wrote:
By editing the repository-dev.xml file I was able to create more users. The principals are created.
Same here: 2006/09/05 16:37 CEST [-] Created principal: /principals/users/a0620 I can see it in ~/Developer/Collaboration/CalendarServer/twistedcaldav/test/data/principals/users. Is that path to be expected?
When I attempt to publish a calendar as one of the new users the /calendars/users/<newuser> folder is created with the inbox and outbox folder.
That doesn't even work for me, but the folders seem to be cerated while creating the principal. They are in ~/Developer/Collaboration/CalendarServer/twistedcaldav/test/data/calendars/users/a0620
But the calendar fails to publish with "Access to the calendar <server url> is not permitted.." If I use the admin name and password I can publish the test calendar.
Can you provide the relevant portion of the server log?
Here it reads: 2006/09/05 16:39 CEST [HTTPChannel,0,134.95.128.1] OPTIONS /calendars/users/a0620/ HTTP/1.1 2006/09/05 16:39 CEST [HTTPChannel,0,134.95.128.1] 'Invalid privileges with no authentication details: <OPTIONS /calendars/users/a0620/ (1, 1)>' 2006/09/05 16:39 CEST [HTTPChannel,0,134.95.128.1] OPTIONS /calendars/users/a0620/ HTTP/1.1 2006/09/05 16:39 CEST [HTTPChannel,0,134.95.128.1] 'Invalid privileges with valid authentication details: <OPTIONS /calendars/users/a0620/ (1, 1)>'
As described on the wiki page, each user should be given <DAV:all> privileges to their own calendar home collection. So it should be possible to do anything in that collection once authenticated.
That doesn't seem to work. Perhaps the implicit rights don't work? Could you give us an example how to set the privileges explicitly? In the example file I see: <acl> <ace> <principal><all/></principal> <grant><privilege><all/></privilege></grant> <protected/> <inheritable/> </ace> </acl> But I don't really understand how that's supposed to work. -- .:.Sebastian Hagedorn - RZKR-R1 (Gebäude 52), Zimmer 18.:. Zentrum für angewandte Informatik - Universitätsweiter Service RRZK .:.Universität zu Köln / Cologne University - ✆ +49-221-478-5587.:. .:.:.:.Skype: shagedorn.:.:.:.
Hi Sebastian, --On September 5, 2006 4:54:24 PM +0200 Sebastian Hagedorn <Hagedorn@uni-koeln.de> wrote:
By editing the repository-dev.xml file I was able to create more users. The principals are created.
Same here:
2006/09/05 16:37 CEST [-] Created principal: /principals/users/a0620
I can see it in ~/Developer/Collaboration/CalendarServer/twistedcaldav/test/data/principa ls/users. Is that path to be expected?
Yes. The 'document root' is specified in the .plist file. The default run script is set to use caldav-dev.plist and repository-dev.plist, both of which have to be in the server's conf directory.
When I attempt to publish a calendar as one of the new users the /calendars/users/<newuser> folder is created with the inbox and outbox folder.
That doesn't even work for me, but the folders seem to be cerated while creating the principal. They are in ~/Developer/Collaboration/CalendarServer/twistedcaldav/test/data/calendar s/users/a0620
Correct - with the -static repository file user accounts and calendar homes are auto-created when the server starts up. (The process is slightly different with OpenDirectory.)
But the calendar fails to publish with "Access to the calendar <server url> is not permitted.." If I use the admin name and password I can publish the test calendar.
Can you provide the relevant portion of the server log?
Here it reads:
2006/09/05 16:39 CEST [HTTPChannel,0,134.95.128.1] OPTIONS /calendars/users/a0620/ HTTP/1.1 2006/09/05 16:39 CEST [HTTPChannel,0,134.95.128.1] 'Invalid privileges with no authentication details: <OPTIONS /calendars/users/a0620/ (1, 1)>' 2006/09/05 16:39 CEST [HTTPChannel,0,134.95.128.1] OPTIONS /calendars/users/a0620/ HTTP/1.1 2006/09/05 16:39 CEST [HTTPChannel,0,134.95.128.1] 'Invalid privileges with valid authentication details: <OPTIONS /calendars/users/a0620/ (1, 1)>'
If you use the 'admin' user can you login? What OS/system/version are you running this on?
As described on the wiki page, each user should be given <DAV:all> privileges to their own calendar home collection. So it should be possible to do anything in that collection once authenticated.
That doesn't seem to work. Perhaps the implicit rights don't work? Could you give us an example how to set the privileges explicitly? In the example file I see:
<acl> <ace> <principal><all/></principal> <grant><privilege><all/></privilege></grant> <protected/> <inheritable/> </ace> </acl>
But I don't really understand how that's supposed to work.
The above acl is in the commented out section of -static, and is used to create some 'users' that have a publicly accessible calendar (hence use of <DAV:all> as the principal). For 'regular' users you should not use that - use the <user> element with 'repeat=99' as the guide for those. -- Cyrus Daboo
Hi Cyrus, --On 5. September 2006 11:11:52 -0400 Cyrus Daboo <cdaboo@apple.com> wrote:
Is that path to be expected?
Yes. The 'document root' is specified in the .plist file.
ah, got it.
If you use the 'admin' user can you login?
Yes. If I do so the log lines read: 2006/09/05 17:23 CEST [HTTPChannel,2,134.95.128.1] OPTIONS /calendars/users/a0620/ HTTP/1.1 2006/09/05 17:23 CEST [HTTPChannel,2,134.95.128.1] PROPFIND /calendars/users/a0620/ HTTP/1.1 I can also creat calendars. Things still appear strange to me, though. The "Details" view in Mulberry gives me: Twisted/2.3.0+r17097 TwistedWeb/[twisted.web2, version 0.1.0 (SVN r17097)] TwistedCalDAV/? The Capability only reads: Content-Length: 0 That can't be right!? The Access button is greyed out. Shouldn't I be able to view or set ACLs?
What OS/system/version are you running this on?
OS X 10.4.7
But I don't really understand how that's supposed to work.
The above acl is in the commented out section of -static, and is used to create some 'users' that have a publicly accessible calendar (hence use of <DAV:all> as the principal).
So <principal><all/></principal> refers to <DAV:all>? I'm not sure I get that, but I suppose I don't need to at this point :-)
For 'regular' users you should not use that - use the <user> element with 'repeat=99' as the guide for those.
I did, but I didn't specify a calendar. Should I? -- .:.Sebastian Hagedorn - RZKR-R1 (Gebäude 52), Zimmer 18.:. Zentrum für angewandte Informatik - Universitätsweiter Service RRZK .:.Universität zu Köln / Cologne University - ✆ +49-221-478-5587.:. .:.:.:.Skype: shagedorn.:.:.:.
Hi Sebastian, --On September 5, 2006 5:34:35 PM +0200 Sebastian Hagedorn <Hagedorn@uni-koeln.de> wrote:
If you use the 'admin' user can you login?
Yes. If I do so the log lines read:
2006/09/05 17:23 CEST [HTTPChannel,2,134.95.128.1] OPTIONS /calendars/users/a0620/ HTTP/1.1 2006/09/05 17:23 CEST [HTTPChannel,2,134.95.128.1] PROPFIND /calendars/users/a0620/ HTTP/1.1
Ok, that at least proves that ACL is working to some extent.
I can also creat calendars. Things still appear strange to me, though. The "Details" view in Mulberry gives me:
Twisted/2.3.0+r17097 TwistedWeb/[twisted.web2, version 0.1.0 (SVN r17097)] TwistedCalDAV/?
The Capability only reads:
Content-Length: 0
That can't be right!?
No - that display is currently broken in Mulberry.
The Access button is greyed out. Shouldn't I be able to view or set ACLs?
Try details on a calendar or a collection within the server hierarchy - Access should then be enabled.
But I don't really understand how that's supposed to work.
The above acl is in the commented out section of -static, and is used to create some 'users' that have a publicly accessible calendar (hence use of <DAV:all> as the principal).
So <principal><all/></principal> refers to <DAV:all>? I'm not sure I get that, but I suppose I don't need to at this point :-)
The <acl> element in repository.xml 'mirrors' the WebDAV <DAV:acl> element and its child elements. So what you seen in the XML file is basically what would appear in the body of a WebDAV ACL method request when a client tries to set ACLs, though with DAV: as the namespace for the elements. So to know really what that element does in repository.xml you need to read the WebDAV ACL spec.
For 'regular' users you should not use that - use the <user> element with 'repeat=99' as the guide for those.
I did, but I didn't specify a calendar. Should I?
You should setup at least one default calendar for each user just to make things easier. Can you send me your repository.xml file for analysis? -- Cyrus Daboo
Hi Cyrus, -- Cyrus Daboo <cdaboo@apple.com> is rumored to have mumbled on 5. September 2006 11:58:59 -0400 regarding Re: [CalendarServer-users] Adding principals:
The Capability only reads:
Content-Length: 0
That can't be right!?
No - that display is currently broken in Mulberry.
OK.
The Access button is greyed out. Shouldn't I be able to view or set ACLs?
Try details on a calendar or a collection within the server hierarchy - Access should then be enabled.
D'oh! The egg on my face is all mine ;-)
So <principal><all/></principal> refers to <DAV:all>? I'm not sure I get that, but I suppose I don't need to at this point :-)
The <acl> element in repository.xml 'mirrors' the WebDAV <DAV:acl> element and its child elements. So what you seen in the XML file is basically what would appear in the body of a WebDAV ACL method request when a client tries to set ACLs, though with DAV: as the namespace for the elements. So to know really what that element does in repository.xml you need to read the WebDAV ACL spec.
Thanks for the explanation. I will read up on that at some point.
For 'regular' users you should not use that - use the <user> element with 'repeat=99' as the guide for those.
I did, but I didn't specify a calendar. Should I?
You should setup at least one default calendar for each user just to make things easier.
Not only that, it appears. Now that I added default calendars everything is peachy! This is the logging I just got from logging in as a non-admin user: 2006/09/05 22:00 CEST [HTTPChannel,0,87.78.106.73] OPTIONS /calendars/users/a0620/ HTTP/1.1 2006/09/05 22:00 CEST [HTTPChannel,0,87.78.106.73] 'Invalid privileges with no authentication details: <OPTIONS /calendars/users/a0620/ (1, 1)>' 2006/09/05 22:00 CEST [HTTPChannel,0,87.78.106.73] OPTIONS /calendars/users/a0620/ HTTP/1.1 2006/09/05 22:00 CEST [HTTPChannel,0,87.78.106.73] PROPFIND /calendars/users/a0620/ HTTP/1.1 2006/09/05 22:00 CEST [HTTPChannel,1,87.78.106.73] PROPFIND /calendars/users/a0620/calendar/ HTTP/1.1 2006/09/05 22:00 CEST [HTTPChannel,2,87.78.106.73] PROPFIND /calendars/users/a0620/calendar/ HTTP/1.1 2006/09/05 22:01 CEST [HTTPChannel,3,87.78.106.73] PROPFIND /calendars/users/a0620/inbox/ HTTP/1.1 So all is well for now ... thanks for your help! -- Sebastian Hagedorn - RZKR-R1 (Flachbau), Zi. 18, Robert-Koch-Str. 10 Zentrum für angewandte Informatik - Universitätsweiter Service RRZK Universität zu Köln / Cologne University - Tel. +49-221-478-5587
On 06/09/2006, at 2:54 AM, Sebastian Hagedorn wrote:
FYI I just added a wiki page for the repository.xml file:
<http://svn.macosforge.org/projects/calendarserver/wiki/ RepositoryXML>
Hi On the linked "Open Directory" page to this it says ... "To provision calendar principals the calendar server requires that all users, groups, and resources that should have calendars have the CalendarPrincipalURI attribute" Could someone give me some pointers as to the easiest (and safest) way to add this attribute to the LDAP used by Open Directory? I am trying to get this working on Tiger ... I must be to impatient to wait for Joshs #2 article on Calender Server :-) Thanks Stephen
On Sep 5, 2006, at 10:25 AM, Cyrus Daboo wrote:
As described on the wiki page, each user should be given <DAV:all> privileges to their own calendar home collection. So it should be possible to do anything in that collection once authenticated.
Can you give me an example of a user set up with all privileges to his calendar collection, all privileges to a shared calendar folder and read only or no access to other users calendars. I was able to get all users the ability to publish calendars, but unfortunately they were allowed to publish to any users folder. Not just their own. So far all changes I have tried result in all or nothing. I'm hoping to set this up for a school in the next week or two with about forty teachers (and possibly for the 900+ students). Before they run out and buy Now-Up-To-Date. I wrote a small app a couple of summers ago to create an XML file for importing users into OS X server using fields from a tab-delimited file of users first and last name. It generates the shortname and password according to selections made and then writes the xml file. I was able to modify it last night to generate a properly formatted repository-dev.xml. If I can get the privileges worked out I should be able to generate the repository-dev.xml for 100+ users in just a few minutes. Also, is there a graceful way to quit iCalServer or reload the repository-dev.xml file? Right now when I want to make changes I terminate the shell. Delete the previous principals, users and calendars then ./run again. Thanks and Have A Great Day. Rick Davis thePRIMAXgroup http://applehelp.org
On Sep 5, 2006, at 10:08 PM, Rick Davis wrote:
On Sep 5, 2006, at 10:25 AM, Cyrus Daboo wrote:
As described on the wiki page, each user should be given <DAV:all> privileges to their own calendar home collection. So it should be possible to do anything in that collection once authenticated.
Can you give me an example of a user set up with all privileges to his calendar collection, all privileges to a shared calendar folder and read only or no access to other users calendars. I was able to get all users the ability to publish calendars, but unfortunately they were allowed to publish to any users folder. Not just their own. So far all changes I have tried result in all or nothing.
I'm hoping to set this up for a school in the next week or two with about forty teachers (and possibly for the 900+ students). Before they run out and buy Now-Up-To-Date.
I wrote a small app a couple of summers ago to create an XML file for importing users into OS X server using fields from a tab- delimited file of users first and last name. It generates the shortname and password according to selections made and then writes the xml file. I was able to modify it last night to generate a properly formatted repository-dev.xml. If I can get the privileges worked out I should be able to generate the repository-dev.xml for 100+ users in just a few minutes.
Also, is there a graceful way to quit iCalServer or reload the repository-dev.xml file? Right now when I want to make changes I terminate the shell. Delete the previous principals, users and calendars then ./run again.
Thanks and Have A Great Day.
Rick Davis thePRIMAXgroup http://applehelp.org
This is a follow-up for the archives. Got the privileges worked out. I did have to change a couple of things in the section of the repository-dev.xml file listed below. I am also using phpicalendar to publish these calendars on the web. So I moved the "shared" calendars location to the shared folder inside the users folder. Also had to change the authenticated privilege from "read" to "all" to allow all users to publish to this folder. Now <url>/phpicalendar?cpath=shared works as well as <url>/ phpicalendar?cpath=<username> Still not sure if there is a more graceful way to stop and start or reload the repository-dev.xml file. The only way I know to quit or reload is to exit the shell. Then open a new shell and execute the ./ run command. Now I will get back to working with Chandler on multiple users writing to the shared calendars. Thanks and Have A Great Day Rick Davis thePRIMAXgroup http://applehelp.org ------------ <collection name="users" tag="shared"> --changed this line to move the shared folder inside the "users" folder <properties> <acl> <ace> <principal><unauthenticated/></principal> <grant><privilege><read/></privilege></grant> <protected/> <inheritable/> </ace> <ace> <principal><authenticated/></principal> <grant><privilege><all/></privilege></grant> -- changed this line from "read" to "all" <protected/> <inheritable/> </ace> </acl> </properties> <members/> </collection>
participants (4)
-
Cyrus Daboo
-
Rick Davis
-
Sebastian Hagedorn
-
Stephen Baugh