[CalendarServer-users] Debugging caldavd on Linux
david.szego at gmail.com
Thu Nov 1 20:00:44 PDT 2007
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
> 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.
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 at gmail.com does not match authorized user: /
at the same time as this dialog pops up:
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
More information about the calendarserver-users