Re: [CalendarServer-users] Questions regarding delegation, attachments and time errors
On May 11, 2017, at 7:46 AM, Ian Baker <ibaker@eem.ca> wrote:
On May 10, 2017, at 8:27 PM, Andre LaBranche <dre@apple.com <mailto:dre@apple.com>> wrote:
Yeah, wow. There are actually two distinct VCALENDAR objects here - both with the same UID. I've never seen this happen.
I was embarrassingly mistaken in my characterization of this. The psql output clearly indicates there are two rows, and it is not abnormal to have multiple calendar_object rows for events with the same UID; the organizer and attendees all get their own copy. Both of the events, when placed into discrete ics files, validate successfully. Anyhow, even though the pycalendar validator is OK with both of these events, the one that has no organizer / attendee information but does have a RECURRENCE-ID crashes Calendar.app if I try to import it. That's bad, and I sent a bug to Calendar to remedy that. It's unclear why this event is in the state that it's in, but it's not a good state. The easiest option for unblocking the web calendar is probably to just delete the problem event. Since it's just a (seemingly broken) cancel, there should be no harm in this. Never make changes to calendar data using direct database access; stick with HTTP to keep everything coherent. An HTTP "delete" request should work fine, the only tricky part is finding the URL to delete, since the event in question is likely returned in a batch request, in which case the individual URLs won't appear in the access.log. The first step is to find the resource_id of the event, which is another column on calendar_object. We'll use the event UID and a substring search for RECURRENCE-ID as the predicates. In the example below, use your event's UID instead (which is 040000008200E00074C5B7101A82E008000000004020622BEB7AD201000000000000000010000000C05F922AF30E4145839AF52B293ABFFB) caldav=# select resource_id, calendar_resource_id from calendar_object where icalendar_text LIKE '%RECURRENCE-ID%' and icalendar_uid = '8F98441F-3890-457E-B0E6-6875EE527951'; resource_id | calendar_resource_id -------------+---------------------- 26 | 2 (1 row) (calendar_resource_id is a reference to the calendar that contains the event. There shouldn't be multiple results for this query in your case, but if there are, this value would probably vary). With the resource_id in hand, you can compose a URL by traversing the CalendarServer resource hierarchy using something like the following, substituting your resource_id on the last line of the query, and changing 'example.com' to something correct. SELECT '"https://example.com:8443/calendars/__uids__/' || owner_uid || '/' || calendar_resource_name || '/' || resource_name || '"' as URL FROM calendar_bind JOIN calendar_home ON calendar_bind.calendar_home_resource_id = calendar_home.resource_id JOIN calendar_object ON calendar_bind.calendar_resource_id = calendar_object.calendar_resource_id WHERE calendar_object.resource_id = 26; Example: caldav=# SELECT '"https://example.com:8443/calendars/__uids__/' caldav-# || owner_uid caldav-# || '/' caldav-# || calendar_resource_name caldav-# || '/' caldav-# || resource_name caldav-# || '"' as URL caldav-# FROM calendar_bind caldav-# JOIN calendar_home caldav-# ON calendar_bind.calendar_home_resource_id = calendar_home.resource_id caldav-# JOIN calendar_object caldav-# ON calendar_bind.calendar_resource_id = caldav-# calendar_object.calendar_resource_id caldav-# WHERE calendar_object.resource_id = 26; url ------------------------------------------------------------------------------------------------------------------------------------------- "https://example.com:8443/calendars/__uids__/E1CB3592-E7BD-41C4-A27C-6E23FEFF..." (1 row) Now with an URL, you can fire a DELETE using curl. Such a request usually needs to be authenticated with the credentials of the user whose GUID is shown after the __uids__ portion of the URL (in the DB, this is calendar_home.owner_uid). To confirm that username: % dscl /Search search /Users GeneratedUID E1CB3592-E7BD-41C4-A27C-6E23FEFFD197 andre GeneratedUID = ( "E1CB3592-E7BD-41C4-A27C-6E23FEFFD197" ) Now you can run curl, supplying the password when prompted: curl -u <username> -X DELETE <url> With this seemingly invalid event out of the way, the web calendar should now load (or at least, get stuck on something else). Bonus round #1 ... but you might want to do this on behalf of your boss, without knowing his password. To do that, add yourself as an AdminPrincipal using the following CalendarServer config in the file: "/Library/Server/Calendar and Contacts/Config/caldavd-user.plist" (this file doesn't exist by default, and is read after caldavd-system.plist, overriding anything defined there) <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>AdminPrincipals</key> <array> <string>/principals/__uids__/AEB68DD7-D2B8-4D4D-A574-2A4533DF36A4/</string> </array> </dict> </plist> Specify your own GUID instead of the one shown above, which you can find with a dscl query using your username, e.g.: $ dscl /Search read /Users/andre GeneratedUID GeneratedUID: E1CB3592-E7BD-41C4-A27C-6E23FEFFD197 Finally, restart CalendarServer to activate the new config: sudo calendarserver_config --restart After doing the delete, to disable the AdminPrincipal config, either rename the caldavd-user.plist file, or comment out the array elements like this: <!-- <string>/principals/__uids__/AEB68DD7-D2B8-4D4D-A574-2A4533DF36A4/</string> --> ... then bounce the service. Bonus round #2 Also I confirmed that the validation steps included in my prior email work as written; the second 'cd' is not optional, and I was trying to do that as an alternative to 'installing' the module. But now that I remember that virtualenv <https://virtualenv.pypa.io/en/stable/> exists, here's a more standard approach: # provision a new virtualenv, use it, install pycalendar from git using pip virtualenv pycalendar-env cd pycalendar-env source bin/activate pip install git+https://github.com/apple/ccs-pycalendar.git@master # verify - this should print the path to the pycalendar module that was just installed python -c 'import pycalendar ; print pycalendar.__path__' # run the validator % python -m pycalendar.validator ~/1.ics No problems Bonus round #3 The icalendar_text returned previously by psql isn't in proper iCalendar form. Even though there are psql options for raw output, I would have to look those up, while the following vim commands flow like water onto my keyboard: :%s/+$//g :%s/\\r//g :%s/^ //g :1,2d :$-2,$d :%s/[ ]*$//g ... ok I looked it up, and it's easier than the above: just start psql like this: sudo psql -A -t -h /var/run/caldavd/PostgresSocket -U caldav caldav e.g. # psql -A -t -h /var/run/caldavd/PostgresSocket -U caldav caldav -c 'select icalendar_text from calendar_object limit 1;' BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Apple Inc.//Web Calendar Client// BEGIN:VEVENT UID:c6b8d8ac-c23b-23b1-ade0-2756d3ca8fee DTSTART;TZID=America/Los_Angeles:20150814T080000 DURATION:PT1H30M DTSTAMP:20150813T182156Z SEQUENCE:2 SUMMARY:New Event END:VEVENT BEGIN:X-CALENDARSERVER-PERUSER UID:c6b8d8ac-c23b-23b1-ade0-2756d3ca8fee X-CALENDARSERVER-PERUSER-UID:E1CB3592-E7BD-41C4-A27C-6E23FEFFD197 BEGIN:X-CALENDARSERVER-PERINSTANCE TRANSP:OPAQUE END:X-CALENDARSERVER-PERINSTANCE END:X-CALENDARSERVER-PERUSER END:VCALENDAR (and finally, the X-CALENDARSERVER-PERINSTANCE component would not be exposed to clients; this component is internal to CalendarServer and is stripped from event bodies as they leave the server) -dre
What is particularly weird is that this event was also sent to another of our users ‘Robert Cole’, and I can load his calendar in WebCal and view the event without trouble. There were no errors on Rob’s javascript console in Safari.
<PastedGraphic-1.png>
I exported Rob's calendar and found one of the 2 events. The ‘cancelled" event was not in Rob’s calendar that I could find. I’ve attached Rob's event as an .ics file. From what I could see Rob’s version didn’t have lines related to the following properties: VCALENDAR X-CALENDARSERVER-PERUSER X-CALENDARSERVER-PERINSTANCE and there seemed to be minor parsing differences (quotes around certain fields e.g. email addresses).
If these are not the source of the error on the boss’s ('Paul MacLean’) WebCal display, might it be something else that is causing the error? The event just before or the event just after this one? Or perhaps the volume of events in the boss’s calendar - he never throws anything away!
TIA
Ian 450-465-1641
<Robs Event.ics>
André, I can confirm that the problematic event doesn’t seem to crash the boss’s Calendar.app. It just doesn’t show up in his calendar, nor does the associated event wit the same UID. He is running 10.11.6, and I accessed his calendar to confirm, and I’m running 10.12.5. Again, no crash. To avoid the erroneous notifications mentioned earlier, I used the macOS Guest account with no mail accounts configured. I was able to get the event's resource_id, and then establish its URL. I even validated that the URL was correct by getting it using Safari and comparing the result with the expected event. I authenticated in Safari with both the boss’s userid/password as well as the Bonus round #1 AdminPrincipal's userid/password, so both authentications were working correctly. However, I am truly hesitant to report that when attempting the curl -X delete, and authenticating either way, I get this: <html><head><title>Unauthorized</title></head><body><h1>Unauthorized</h1><p>You are not authorized to access this resource.</p></body></html> Not sure where to go from here. TIA Ian
On May 11, 2017, at 5:10 PM, Andre LaBranche <dre@apple.com> wrote:
On May 11, 2017, at 7:46 AM, Ian Baker <ibaker@eem.ca <mailto:ibaker@eem.ca>> wrote:
On May 10, 2017, at 8:27 PM, Andre LaBranche <dre@apple.com <mailto:dre@apple.com>> wrote:
Yeah, wow. There are actually two distinct VCALENDAR objects here - both with the same UID. I've never seen this happen.
I was embarrassingly mistaken in my characterization of this. The psql output clearly indicates there are two rows, and it is not abnormal to have multiple calendar_object rows for events with the same UID; the organizer and attendees all get their own copy.
Both of the events, when placed into discrete ics files, validate successfully.
Anyhow, even though the pycalendar validator is OK with both of these events, the one that has no organizer / attendee information but does have a RECURRENCE-ID crashes Calendar.app if I try to import it. That's bad, and I sent a bug to Calendar to remedy that.
It's unclear why this event is in the state that it's in, but it's not a good state. The easiest option for unblocking the web calendar is probably to just delete the problem event. Since it's just a (seemingly broken) cancel, there should be no harm in this. Never make changes to calendar data using direct database access; stick with HTTP to keep everything coherent. An HTTP "delete" request should work fine, the only tricky part is finding the URL to delete, since the event in question is likely returned in a batch request, in which case the individual URLs won't appear in the access.log.
The first step is to find the resource_id of the event, which is another column on calendar_object. We'll use the event UID and a substring search for RECURRENCE-ID as the predicates. In the example below, use your event's UID instead (which is 040000008200E00074C5B7101A82E008000000004020622BEB7AD201000000000000000010000000C05F922AF30E4145839AF52B293ABFFB)
caldav=# select resource_id, calendar_resource_id from calendar_object where icalendar_text LIKE '%RECURRENCE-ID%' and icalendar_uid = '8F98441F-3890-457E-B0E6-6875EE527951'; resource_id | calendar_resource_id -------------+---------------------- 26 | 2 (1 row)
(calendar_resource_id is a reference to the calendar that contains the event. There shouldn't be multiple results for this query in your case, but if there are, this value would probably vary).
With the resource_id in hand, you can compose a URL by traversing the CalendarServer resource hierarchy using something like the following, substituting your resource_id on the last line of the query, and changing 'example.com <http://example.com/>' to something correct.
SELECT '"https://example.com:8443/calendars/__uids__/' <https://example.com:8443/calendars/__uids__/'> || owner_uid || '/' || calendar_resource_name || '/' || resource_name || '"' as URL FROM calendar_bind JOIN calendar_home ON calendar_bind.calendar_home_resource_id = calendar_home.resource_id JOIN calendar_object ON calendar_bind.calendar_resource_id = calendar_object.calendar_resource_id WHERE calendar_object.resource_id = 26;
Example:
caldav=# SELECT '"https://example.com:8443/calendars/__uids__/' <https://example.com:8443/calendars/__uids__/'> caldav-# || owner_uid caldav-# || '/' caldav-# || calendar_resource_name caldav-# || '/' caldav-# || resource_name caldav-# || '"' as URL caldav-# FROM calendar_bind caldav-# JOIN calendar_home caldav-# ON calendar_bind.calendar_home_resource_id = calendar_home.resource_id caldav-# JOIN calendar_object caldav-# ON calendar_bind.calendar_resource_id = caldav-# calendar_object.calendar_resource_id caldav-# WHERE calendar_object.resource_id = 26; url ------------------------------------------------------------------------------------------------------------------------------------------- "https://example.com:8443/calendars/__uids__/E1CB3592-E7BD-41C4-A27C-6E23FEFF... <https://example.com:8443/calendars/__uids__/E1CB3592-E7BD-41C4-A27C-6E23FEFFD197/calendar/8F98441F-3890-457E-B0E6-6875EE527951.ics>" (1 row)
Now with an URL, you can fire a DELETE using curl. Such a request usually needs to be authenticated with the credentials of the user whose GUID is shown after the __uids__ portion of the URL (in the DB, this is calendar_home.owner_uid). To confirm that username:
% dscl /Search search /Users GeneratedUID E1CB3592-E7BD-41C4-A27C-6E23FEFFD197 andre GeneratedUID = ( "E1CB3592-E7BD-41C4-A27C-6E23FEFFD197" )
Now you can run curl, supplying the password when prompted:
curl -u <username> -X DELETE <url>
With this seemingly invalid event out of the way, the web calendar should now load (or at least, get stuck on something else).
Bonus round #1
... but you might want to do this on behalf of your boss, without knowing his password. To do that, add yourself as an AdminPrincipal using the following CalendarServer config in the file: "/Library/Server/Calendar and Contacts/Config/caldavd-user.plist" (this file doesn't exist by default, and is read after caldavd-system.plist, overriding anything defined there)
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd <http://www.apple.com/DTDs/PropertyList-1.0.dtd>"> <plist version="1.0"> <dict>
<key>AdminPrincipals</key> <array> <string>/principals/__uids__/AEB68DD7-D2B8-4D4D-A574-2A4533DF36A4/</string> </array>
</dict> </plist>
Specify your own GUID instead of the one shown above, which you can find with a dscl query using your username, e.g.:
$ dscl /Search read /Users/andre GeneratedUID GeneratedUID: E1CB3592-E7BD-41C4-A27C-6E23FEFFD197
Finally, restart CalendarServer to activate the new config:
sudo calendarserver_config --restart
After doing the delete, to disable the AdminPrincipal config, either rename the caldavd-user.plist file, or comment out the array elements like this:
<!-- <string>/principals/__uids__/AEB68DD7-D2B8-4D4D-A574-2A4533DF36A4/</string> -->
... then bounce the service.
Bonus round #2
Also I confirmed that the validation steps included in my prior email work as written; the second 'cd' is not optional, and I was trying to do that as an alternative to 'installing' the module. But now that I remember that virtualenv <https://virtualenv.pypa.io/en/stable/> exists, here's a more standard approach:
# provision a new virtualenv, use it, install pycalendar from git using pip virtualenv pycalendar-env cd pycalendar-env source bin/activate pip install git+https://github.com/apple/ccs-pycalendar.git@master <git+https://github.com/apple/ccs-pycalendar.git@master>
# verify - this should print the path to the pycalendar module that was just installed python -c 'import pycalendar ; print pycalendar.__path__'
# run the validator % python -m pycalendar.validator ~/1.ics No problems
Bonus round #3
The icalendar_text returned previously by psql isn't in proper iCalendar form. Even though there are psql options for raw output, I would have to look those up, while the following vim commands flow like water onto my keyboard:
:%s/+$//g :%s/\\r//g :%s/^ //g :1,2d :$-2,$d :%s/[ ]*$//g
... ok I looked it up, and it's easier than the above: just start psql like this: sudo psql -A -t -h /var/run/caldavd/PostgresSocket -U caldav caldav
e.g.
# psql -A -t -h /var/run/caldavd/PostgresSocket -U caldav caldav -c 'select icalendar_text from calendar_object limit 1;' BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Apple Inc.//Web Calendar Client// BEGIN:VEVENT UID:c6b8d8ac-c23b-23b1-ade0-2756d3ca8fee DTSTART;TZID=America/Los_Angeles:20150814T080000 DURATION:PT1H30M DTSTAMP:20150813T182156Z SEQUENCE:2 SUMMARY:New Event END:VEVENT BEGIN:X-CALENDARSERVER-PERUSER UID:c6b8d8ac-c23b-23b1-ade0-2756d3ca8fee X-CALENDARSERVER-PERUSER-UID:E1CB3592-E7BD-41C4-A27C-6E23FEFFD197 BEGIN:X-CALENDARSERVER-PERINSTANCE TRANSP:OPAQUE END:X-CALENDARSERVER-PERINSTANCE END:X-CALENDARSERVER-PERUSER END:VCALENDAR
(and finally, the X-CALENDARSERVER-PERINSTANCE component would not be exposed to clients; this component is internal to CalendarServer and is stripped from event bodies as they leave the server)
-dre
What is particularly weird is that this event was also sent to another of our users ‘Robert Cole’, and I can load his calendar in WebCal and view the event without trouble. There were no errors on Rob’s javascript console in Safari.
<PastedGraphic-1.png>
I exported Rob's calendar and found one of the 2 events. The ‘cancelled" event was not in Rob’s calendar that I could find. I’ve attached Rob's event as an .ics file. From what I could see Rob’s version didn’t have lines related to the following properties: VCALENDAR X-CALENDARSERVER-PERUSER X-CALENDARSERVER-PERINSTANCE and there seemed to be minor parsing differences (quotes around certain fields e.g. email addresses).
If these are not the source of the error on the boss’s ('Paul MacLean’) WebCal display, might it be something else that is causing the error? The event just before or the event just after this one? Or perhaps the volume of events in the boss’s calendar - he never throws anything away!
TIA
Ian 450-465-1641
<Robs Event.ics>
Just wondering if there are any suggestions about this “You are not authorized to access this resource” issue wjem trying to delete this corrupt event. Thanks in advance, Ian
On May 13, 2017, at 5:19 PM, Ian Baker <ibaker@eem.ca> wrote:
André,
I can confirm that the problematic event doesn’t seem to crash the boss’s Calendar.app. It just doesn’t show up in his calendar, nor does the associated event wit the same UID. He is running 10.11.6, and I accessed his calendar to confirm, and I’m running 10.12.5. Again, no crash. To avoid the erroneous notifications mentioned earlier, I used the macOS Guest account with no mail accounts configured.
I was able to get the event's resource_id, and then establish its URL. I even validated that the URL was correct by getting it using Safari and comparing the result with the expected event. I authenticated in Safari with both the boss’s userid/password as well as the Bonus round #1 AdminPrincipal's userid/password, so both authentications were working correctly.
However, I am truly hesitant to report that when attempting the curl -X delete, and authenticating either way, I get this:
<html><head><title>Unauthorized</title></head><body><h1>Unauthorized</h1><p>You are not authorized to access this resource.</p></body></html>
Not sure where to go from here.
TIA
Ian
On May 11, 2017, at 5:10 PM, Andre LaBranche <dre@apple.com <mailto:dre@apple.com>> wrote:
On May 11, 2017, at 7:46 AM, Ian Baker <ibaker@eem.ca <mailto:ibaker@eem.ca>> wrote:
On May 10, 2017, at 8:27 PM, Andre LaBranche <dre@apple.com <mailto:dre@apple.com>> wrote:
Yeah, wow. There are actually two distinct VCALENDAR objects here - both with the same UID. I've never seen this happen.
I was embarrassingly mistaken in my characterization of this. The psql output clearly indicates there are two rows, and it is not abnormal to have multiple calendar_object rows for events with the same UID; the organizer and attendees all get their own copy.
Both of the events, when placed into discrete ics files, validate successfully.
Anyhow, even though the pycalendar validator is OK with both of these events, the one that has no organizer / attendee information but does have a RECURRENCE-ID crashes Calendar.app if I try to import it. That's bad, and I sent a bug to Calendar to remedy that.
It's unclear why this event is in the state that it's in, but it's not a good state. The easiest option for unblocking the web calendar is probably to just delete the problem event. Since it's just a (seemingly broken) cancel, there should be no harm in this. Never make changes to calendar data using direct database access; stick with HTTP to keep everything coherent. An HTTP "delete" request should work fine, the only tricky part is finding the URL to delete, since the event in question is likely returned in a batch request, in which case the individual URLs won't appear in the access.log.
The first step is to find the resource_id of the event, which is another column on calendar_object. We'll use the event UID and a substring search for RECURRENCE-ID as the predicates. In the example below, use your event's UID instead (which is 040000008200E00074C5B7101A82E008000000004020622BEB7AD201000000000000000010000000C05F922AF30E4145839AF52B293ABFFB)
caldav=# select resource_id, calendar_resource_id from calendar_object where icalendar_text LIKE '%RECURRENCE-ID%' and icalendar_uid = '8F98441F-3890-457E-B0E6-6875EE527951'; resource_id | calendar_resource_id -------------+---------------------- 26 | 2 (1 row)
(calendar_resource_id is a reference to the calendar that contains the event. There shouldn't be multiple results for this query in your case, but if there are, this value would probably vary).
With the resource_id in hand, you can compose a URL by traversing the CalendarServer resource hierarchy using something like the following, substituting your resource_id on the last line of the query, and changing 'example.com <http://example.com/>' to something correct.
SELECT '"https://example.com:8443/calendars/__uids__/' <https://example.com:8443/calendars/__uids__/'> || owner_uid || '/' || calendar_resource_name || '/' || resource_name || '"' as URL FROM calendar_bind JOIN calendar_home ON calendar_bind.calendar_home_resource_id = calendar_home.resource_id JOIN calendar_object ON calendar_bind.calendar_resource_id = calendar_object.calendar_resource_id WHERE calendar_object.resource_id = 26;
Example:
caldav=# SELECT '"https://example.com:8443/calendars/__uids__/' <https://example.com:8443/calendars/__uids__/'> caldav-# || owner_uid caldav-# || '/' caldav-# || calendar_resource_name caldav-# || '/' caldav-# || resource_name caldav-# || '"' as URL caldav-# FROM calendar_bind caldav-# JOIN calendar_home caldav-# ON calendar_bind.calendar_home_resource_id = calendar_home.resource_id caldav-# JOIN calendar_object caldav-# ON calendar_bind.calendar_resource_id = caldav-# calendar_object.calendar_resource_id caldav-# WHERE calendar_object.resource_id = 26; url ------------------------------------------------------------------------------------------------------------------------------------------- "https://example.com:8443/calendars/__uids__/E1CB3592-E7BD-41C4-A27C-6E23FEFF... <https://example.com:8443/calendars/__uids__/E1CB3592-E7BD-41C4-A27C-6E23FEFFD197/calendar/8F98441F-3890-457E-B0E6-6875EE527951.ics>" (1 row)
Now with an URL, you can fire a DELETE using curl. Such a request usually needs to be authenticated with the credentials of the user whose GUID is shown after the __uids__ portion of the URL (in the DB, this is calendar_home.owner_uid). To confirm that username:
% dscl /Search search /Users GeneratedUID E1CB3592-E7BD-41C4-A27C-6E23FEFFD197 andre GeneratedUID = ( "E1CB3592-E7BD-41C4-A27C-6E23FEFFD197" )
Now you can run curl, supplying the password when prompted:
curl -u <username> -X DELETE <url>
With this seemingly invalid event out of the way, the web calendar should now load (or at least, get stuck on something else).
Bonus round #1
... but you might want to do this on behalf of your boss, without knowing his password. To do that, add yourself as an AdminPrincipal using the following CalendarServer config in the file: "/Library/Server/Calendar and Contacts/Config/caldavd-user.plist" (this file doesn't exist by default, and is read after caldavd-system.plist, overriding anything defined there)
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd <http://www.apple.com/DTDs/PropertyList-1.0.dtd>"> <plist version="1.0"> <dict>
<key>AdminPrincipals</key> <array> <string>/principals/__uids__/AEB68DD7-D2B8-4D4D-A574-2A4533DF36A4/</string> </array>
</dict> </plist>
Specify your own GUID instead of the one shown above, which you can find with a dscl query using your username, e.g.:
$ dscl /Search read /Users/andre GeneratedUID GeneratedUID: E1CB3592-E7BD-41C4-A27C-6E23FEFFD197
Finally, restart CalendarServer to activate the new config:
sudo calendarserver_config --restart
After doing the delete, to disable the AdminPrincipal config, either rename the caldavd-user.plist file, or comment out the array elements like this:
<!-- <string>/principals/__uids__/AEB68DD7-D2B8-4D4D-A574-2A4533DF36A4/</string> -->
... then bounce the service.
Bonus round #2
Also I confirmed that the validation steps included in my prior email work as written; the second 'cd' is not optional, and I was trying to do that as an alternative to 'installing' the module. But now that I remember that virtualenv <https://virtualenv.pypa.io/en/stable/> exists, here's a more standard approach:
# provision a new virtualenv, use it, install pycalendar from git using pip virtualenv pycalendar-env cd pycalendar-env source bin/activate pip install git+https://github.com/apple/ccs-pycalendar.git@master <git+https://github.com/apple/ccs-pycalendar.git@master>
# verify - this should print the path to the pycalendar module that was just installed python -c 'import pycalendar ; print pycalendar.__path__'
# run the validator % python -m pycalendar.validator ~/1.ics No problems
Bonus round #3
The icalendar_text returned previously by psql isn't in proper iCalendar form. Even though there are psql options for raw output, I would have to look those up, while the following vim commands flow like water onto my keyboard:
:%s/+$//g :%s/\\r//g :%s/^ //g :1,2d :$-2,$d :%s/[ ]*$//g
... ok I looked it up, and it's easier than the above: just start psql like this: sudo psql -A -t -h /var/run/caldavd/PostgresSocket -U caldav caldav
e.g.
# psql -A -t -h /var/run/caldavd/PostgresSocket -U caldav caldav -c 'select icalendar_text from calendar_object limit 1;' BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Apple Inc.//Web Calendar Client// BEGIN:VEVENT UID:c6b8d8ac-c23b-23b1-ade0-2756d3ca8fee DTSTART;TZID=America/Los_Angeles:20150814T080000 DURATION:PT1H30M DTSTAMP:20150813T182156Z SEQUENCE:2 SUMMARY:New Event END:VEVENT BEGIN:X-CALENDARSERVER-PERUSER UID:c6b8d8ac-c23b-23b1-ade0-2756d3ca8fee X-CALENDARSERVER-PERUSER-UID:E1CB3592-E7BD-41C4-A27C-6E23FEFFD197 BEGIN:X-CALENDARSERVER-PERINSTANCE TRANSP:OPAQUE END:X-CALENDARSERVER-PERINSTANCE END:X-CALENDARSERVER-PERUSER END:VCALENDAR
(and finally, the X-CALENDARSERVER-PERINSTANCE component would not be exposed to clients; this component is internal to CalendarServer and is stripped from event bodies as they leave the server)
-dre
What is particularly weird is that this event was also sent to another of our users ‘Robert Cole’, and I can load his calendar in WebCal and view the event without trouble. There were no errors on Rob’s javascript console in Safari.
<PastedGraphic-1.png>
I exported Rob's calendar and found one of the 2 events. The ‘cancelled" event was not in Rob’s calendar that I could find. I’ve attached Rob's event as an .ics file. From what I could see Rob’s version didn’t have lines related to the following properties: VCALENDAR X-CALENDARSERVER-PERUSER X-CALENDARSERVER-PERINSTANCE and there seemed to be minor parsing differences (quotes around certain fields e.g. email addresses).
If these are not the source of the error on the boss’s ('Paul MacLean’) WebCal display, might it be something else that is causing the error? The event just before or the event just after this one? Or perhaps the volume of events in the boss’s calendar - he never throws anything away!
TIA
Ian 450-465-1641
<Robs Event.ics>
On May 29, 2017, at 12:44 PM, Ian Baker <ibaker@eem.ca> wrote:
Just wondering if there are any suggestions about this “You are not authorized to access this resource” issue wjem trying to delete this corrupt event.
Hi, I guess my next suggestion would be to try doing that kind of curl delete on a newly test event in the same calendar as the problem event. That should validate that this curl approach can work. If that test succeeds, this suggests there is something about the event itself that is making it not deletable at the HTTP / CalDAV layer. In this case, you could try calendarserver_verify_data's "nuke" option, which supports three different methods for identifying the target. ╭─ andre@zomg ~/work/ccs-calendarserver ╰─ $ ./bin/calendarserver_verify_data --help Usage: calendarserver_verify_data [options] Version: 13 This tool scans the calendar store to look for and correct any problems. OPTIONS: Modes of operation: -h : print help and exit. --ical : verify iCalendar data. --mismatch : verify scheduling state. --missing : display orphaned calendar homes - can be used. with either --ical or --mismatch. --double : detect double-bookings. --dark-purge : purge room/resource events with invalid organizer --split : split recurring event --upgrade : upgrade iCalendar data. --nuke PATH|UID|RID : remove specific calendar resources - can only be used by itself. PATH is the full /calendars/__uids__/XXX/YYY/ZZZ.ics object resource path. UID is the iCalendar UID, prefixed with "uid:", of the resources to remove. RID is the SQL DB resource-id. ... [truncated] -dre
Thanks Andre, I’ll have a poke at your suggestions and follow-up shortly. Just wondering - would exporting the entire calendar to a .ics file, deleting the current calendar, then removing the problematic event before importing the .ics file into a new calendar be an option here? Would there be any undesirable side effects of the export/import? Thanks again for your time, Ian
On May 30, 2017, at 9:46 PM, Andre LaBranche <dre@apple.com> wrote:
On May 29, 2017, at 12:44 PM, Ian Baker <ibaker@eem.ca <mailto:ibaker@eem.ca>> wrote:
Just wondering if there are any suggestions about this “You are not authorized to access this resource” issue wjem trying to delete this corrupt event.
Hi,
I guess my next suggestion would be to try doing that kind of curl delete on a newly test event in the same calendar as the problem event. That should validate that this curl approach can work.
If that test succeeds, this suggests there is something about the event itself that is making it not deletable at the HTTP / CalDAV layer. In this case, you could try calendarserver_verify_data's "nuke" option, which supports three different methods for identifying the target.
╭─ andre@zomg ~/work/ccs-calendarserver ╰─ $ ./bin/calendarserver_verify_data --help
Usage: calendarserver_verify_data [options] Version: 13
This tool scans the calendar store to look for and correct any problems.
OPTIONS:
Modes of operation:
-h : print help and exit. --ical : verify iCalendar data. --mismatch : verify scheduling state. --missing : display orphaned calendar homes - can be used. with either --ical or --mismatch. --double : detect double-bookings. --dark-purge : purge room/resource events with invalid organizer --split : split recurring event --upgrade : upgrade iCalendar data.
--nuke PATH|UID|RID : remove specific calendar resources - can only be used by itself. PATH is the full /calendars/__uids__/XXX/YYY/ZZZ.ics object resource path. UID is the iCalendar UID, prefixed with "uid:", of the resources to remove. RID is the SQL DB resource-id. ... [truncated]
-dre
On May 31, 2017, at 10:09 AM, Ian Baker <ibaker@eem.ca> wrote:
Thanks Andre, I’ll have a poke at your suggestions and follow-up shortly.
Just wondering - would exporting the entire calendar to a .ics file, deleting the current calendar, then removing the problematic event before importing the .ics file into a new calendar be an option here?
(sorry for the late reply) It is an option, but shouldn't be needed to fix whatever is wrong.
Would there be any undesirable side effects of the export/import?
If there are any events with attendees, then yes there would be undesirable side effects. Specifically, attendee status will be reset to 'needs action' upon reimporting the event, which would then send notifications to attendees, etc. This is because you're not allowed to force the attendee status of others. -dre
Thanks again for your time,
Ian
On May 30, 2017, at 9:46 PM, Andre LaBranche <dre@apple.com <mailto:dre@apple.com>> wrote:
On May 29, 2017, at 12:44 PM, Ian Baker <ibaker@eem.ca <mailto:ibaker@eem.ca>> wrote:
Just wondering if there are any suggestions about this “You are not authorized to access this resource” issue wjem trying to delete this corrupt event.
Hi,
I guess my next suggestion would be to try doing that kind of curl delete on a newly test event in the same calendar as the problem event. That should validate that this curl approach can work.
If that test succeeds, this suggests there is something about the event itself that is making it not deletable at the HTTP / CalDAV layer. In this case, you could try calendarserver_verify_data's "nuke" option, which supports three different methods for identifying the target.
╭─ andre@zomg ~/work/ccs-calendarserver ╰─ $ ./bin/calendarserver_verify_data --help
Usage: calendarserver_verify_data [options] Version: 13
This tool scans the calendar store to look for and correct any problems.
OPTIONS:
Modes of operation:
-h : print help and exit. --ical : verify iCalendar data. --mismatch : verify scheduling state. --missing : display orphaned calendar homes - can be used. with either --ical or --mismatch. --double : detect double-bookings. --dark-purge : purge room/resource events with invalid organizer --split : split recurring event --upgrade : upgrade iCalendar data.
--nuke PATH|UID|RID : remove specific calendar resources - can only be used by itself. PATH is the full /calendars/__uids__/XXX/YYY/ZZZ.ics object resource path. UID is the iCalendar UID, prefixed with "uid:", of the resources to remove. RID is the SQL DB resource-id. ... [truncated]
-dre
participants (2)
-
Andre LaBranche
-
Ian Baker