Hi all, I'm getting various strange results with CalendarServer on Linux and an iCal 3.0 client. Aside from a LOT of iCal bugs, I suspect the primary problem is a lack of documentation in accounts.xml and caldavd.plist causing me to misconfigure things on my own. I'd like to post a few bugs here, and see if Mr. Sanchez and any willing volunteers could help me debug things. In return, I'd be happy to make my Linux CalendarServer install publicly available for the task, and volunteer it for future testing. Server details at bottom of this message (to tempt you to read it all!) Bugs: 1. User names are case sensitive. Not so much a bug, as counter- intuitive. -------- 2. Every login (i.e. open up iCal) generates the following in caldavd, as do any edits to events: 'No principal found for UID: david' "Attempt to create clone '/var/cache/CalendarServer/principals/ __uids__/david' of resource <DirectoryPrincipalUIDProvisioningResource: /var/cache/CalendarServer/ principals/__uids__>" followed by an iCal dialog box stating: Request Error Access to "New Event" in "calendar" in account "Home Calendars" is not permitted. The server responded: "HTTP/1.1 403 Forbidden" to operation CalDAVScheduleEventQueueableOperation. I can, however, successfully log in, post an event to my calendar, close and re-open iCal, and see the event again. -------- 3. iCal is unable to look up users or resources when entering meeting data. Resources show up just fine in "Accounts:Delegation" preference pane, as described in <proxy> lines of accounts.xml, but adding users in the "Manage access to my account" dialog does not let me look up or enter any users. An error dialog is generated stating: Cannot enable access to your account. "test" was not found. Search again for the user you want to add by typing their name, and selecting one of the resulting choices. I have two users, david and sonja, one room, testroom, and one resource, car. When I "Add Attendees" in iCal, slowly typing a name gives me a flicker of a spinning cursor, indicating it is looking up a name, but no response from the server in either the log or the ./run - v shell. However, leaving the name incomplete will (within seconds) give a spinner to the left of the name, then put a checkmark on the name. Yet, double-clicking on the name will put "sonj <invalid:nomail>" until I click elsewhere. The same behaviour can be seen if I put a correct user name ("sonja") My users and resources are set up in accounts.xml as follows: <user> <uid>david</uid> <password>password</password> <name>David Szego</name> <cuaddr>mailto:david.szego@gmail.com</cuaddr> </user> (and for Sonja) <location> <uid>testroom</uid> <password>testroom</password> <name>Test Room</name> <auto-schedule/> <proxies> <member type="users">david</member> <member type="users">sonja</member> </proxies> </location> <resource> <uid>Car</uid> <guid>Car</guid> <password>car</password> <name>Car</name> <auto-schedule/> <proxies> <member type="users">david</member> <member type="users">sonja</member> </proxies> </resource> I have tried variations on <cuaddr>, including user%20d@server.com, etc. as taken from the various included accounts-*.plist files. I have also tried various permissions on the caldavd directories, but settled on R/W root:root with ./run running as root, to eliminate permissions hassles while testing. For reference, my caldavd directories end up looking like the following (if a directory is omitted, it has no contents): /var/cache/CalendarServer/: calendars principals /var/cache/CalendarServer/calendars: locations resources users /var/cache/CalendarServer/calendars/users: admin david /var/cache/CalendarServer/calendars/users/david: calendar inbox outbox /var/cache/CalendarServer/calendars/users/david/calendar: 7CA20DE2-8005-4C9E-9290-485AA3820F2A.ics BE595426-CC09-420D- B720-6A5B817DF0EF.ics /var/cache/CalendarServer/principals: __uids__ users /var/cache/CalendarServer/principals/__uids__: 16f524a3-356e-54ab-9267-e51ce008e511 16f524a3-356e-54ab-9267-e51ce008e511#calendar-proxy-read 16f524a3-356e-54ab-9267-e51ce008e511#calendar-proxy-write 263dfdea-e764-5da9-bd69-ea8661b468be 29145634-e562-5e17-b9dd-fd5040278f27 29145634-e562-5e17-b9dd-fd5040278f27#calendar-proxy-read 29145634-e562-5e17-b9dd-fd5040278f27#calendar-proxy-write 3792b185-fa5a-5e6a-92ac-3e9d4c4b07a1 /var/cache/CalendarServer/principals/__uids__/16f524a3-356e-54ab-9267- e51ce008e511: calendar-proxy-read calendar-proxy-write /var/cache/CalendarServer/principals/__uids__/16f524a3-356e-54ab-9267- e51ce008e511#calendar-proxy-read: calendar-proxy-read /var/cache/CalendarServer/principals/users: -------- The server is available at https://www.thinkcreatesolve.com/principals/users/XXXX where XXXX is test or admin, password same as user. Please feel free to play, I can chat on iChat/MSN live while you do if you'd like me to try things or send logs, etc. Any help would be welcome, and if I can contribute to the project in any way, I would be more than happy to do so. Cheers, David Szego.
Hi David, --On November 1, 2007 7:49:31 PM -0400 David Szego <david.szego@gmail.com> wrote:
Bugs:
1. User names are case sensitive. Not so much a bug, as counter-intuitive.
Please file a bug on that and we will look at it.
2. Every login (i.e. open up iCal) generates the following in caldavd, as do any edits to events:
'No principal found for UID: david' "Attempt to create clone '/var/cache/CalendarServer/principals/__uids__/david' of resource <DirectoryPrincipalUIDProvisioningResource: /var/cache/CalendarServer/principals/__uids__>"
OK, so a while back we changed the way principal-URIs are defined so that now principal-URIs are found in /principals/__uids__/. The items in there are identified by their directory guid values. For open directory those are "real" GUID values. With the xml account directory, if the account entry does not have a <guid> element containing the GUID to use, then the server generates a "real" GUID for that account on the fly. This is probably not what you want. So, add <guid> elements in accounts.xml that have the same value as the <uid> elements (making sure you do not duplicate values anywhere across all types - users, groups, locations and resources). Once you do that, /principals/__uids__/david will exist and iCal should be able to access the account using that path in its account preferences setup. I guess we should change the example accounts.xml file to include <guid>'s on all resource. If you are wondering, the reason for using GUIDs is to make sure that if a user id is re-used (and over a period of time they could be if one user leaves and another arrives with the same name, initials etc), then the new user is not able to access any data from the old user that may still exist, since the GUID (in open directory at least) will be different.
3. iCal is unable to look up users or resources when entering meeting data. Resources show up just fine in "Accounts:Delegation" preference pane, as described in <proxy> lines of accounts.xml, but adding users in the "Manage access to my account" dialog does not let me look up or enter any users. An error dialog is generated stating:
'Manage Access to my account' only works when iCal is bound to a 10.5 open directory server.
I have two users, david and sonja, one room, testroom, and one resource, car. When I "Add Attendees" in iCal, slowly typing a name gives me a flicker of a spinning cursor, indicating it is looking up a name, but no response from the server in either the log or the ./run -v shell.
Again, iCal's auto-complete is only functional with a 10.5 open directory server. You should still be able to type in the email address as 'mailto:xyz@example.com'. -- Cyrus Daboo
Thanks for the notes, Cyrus. I'll ignore the name lookups for now (until we get an Open Directory to LDAP connector, and then get Linux's slapd to connect to CalendarServer somehow...) On the other bugs, some observations:
2. Every login (i.e. open up iCal) generates the following in caldavd, as do any edits to events:
'No principal found for UID: david' "Attempt to create clone '/var/cache/CalendarServer/principals/__uids__/david' of resource <DirectoryPrincipalUIDProvisioningResource: /var/cache/CalendarServer/principals/__uids__>"
OK, so a while back we changed the way principal-URIs are defined so that now principal-URIs are found in /principals/__uids__/. The items in there are identified by their directory guid values. For open directory those are "real" GUID values.
So, add <guid> elements in accounts.xml that have the same value as the <uid> elements (making sure you do not duplicate values anywhere across all types - users, groups, locations and resources).
Adding the <guid> tag seemed to help a bit - logins and edits do not generate that dialog any longer, but adding/editing any event with a resource or location still gives me a 403 error and a dialog. Specifically: access.log : "POST /calendars/users/david/outbox/ HTTP/1.1" 403 135 "-" "DAVKit/2.0 (10.5; wrbt) iCal 3.0" ./run -v : [CalDAV outbox POST] Originator: mailto:david.szego@gmail.com does not match authorized user: / principals/__uids__/david/ at the same time as this dialog pops up: Request Error Access to "New Event from ical on david" in "calendar" in account "Home Calendars" is not permitted. The server responded: "HTTP/1.1 403 Forbidden" to operation CalDAVScheduleEventQueueableOperation. I also noted your reply to James Hill's comments about mailto: and fixed my own accounts.xml accordingly, so it's not necessarily a URI issue. Thanks again, David Szego.
Hi David, --On November 1, 2007 11:00:44 PM -0400 David Szego <david.szego@gmail.com> wrote:
access.log : "POST /calendars/users/david/outbox/ HTTP/1.1" 403 135 "-" "DAVKit/2.0 (10.5; wrbt) iCal 3.0"
./run -v : [CalDAV outbox POST] Originator: mailto:david.szego@gmail.com does not match authorized user: /principals/__uids__/david/
at the same time as this dialog pops up:
Request Error
Access to "New Event from ical on david" in "calendar" in account "Home Calendars" is not permitted.
The server responded: "HTTP/1.1 403 Forbidden" to operation CalDAVScheduleEventQueueableOperation.
I also noted your reply to James Hill's comments about mailto: and fixed my own accounts.xml accordingly, so it's not necessarily a URI issue.
Can you privately send me your accounts.xml file (replacing the passwords with 'x's). -- Cyrus Daboo
Don't like this advice. "david" is not a valid GUID; GUIDs have a specific format (see http://en.wikipedia.org/wiki/UUID). That the server lets you put any old thing in there and get away with it isn't something one should rely on. Instead, let the server generate the GUID for you and go to / principals/users/david in Safari. You'll see your GUID (and a link to the GUID-form URL to the principal resource) there. -wsv On Nov 1, 2007, at 6:35 PM, Cyrus Daboo wrote:
So, add <guid> elements in accounts.xml that have the same value as the <uid> elements (making sure you do not duplicate values anywhere across all types - users, groups, locations and resources).
Once you do that, /principals/__uids__/david will exist and iCal should be able to access the account using that path in its account preferences setup.
participants (3)
-
Cyrus Daboo
-
David Szego
-
Wilfredo Sánchez Vega