Previous 1 2 3 Next 91 Replies Latest reply: Sep 20, 2010 2:23 AM by 1000TC
hmolina Level 1 Level 1 (0 points)
Hi,

After upgrade my clients to 10.6.4 we are not be able to connect to our Wiki calendars using iCal client.

The original path was:
/principals/wikis/WIKI-NAME/
But now it says the client is not able to connect to:
/principals/_uids_/8a8be0fd-f969-5760-bef6-a73ad4ae3aa1/

If we recreate the subscription, the first time iCal is able to access to the calendar data, using the original path, but after close and restart the client, it modifies the path and uses the new path value (/principals/_uids_/8a8be0fd-f969-5760-bef6-a73ad4ae3aa1/)
In the caldavd error log says:

[AMP,client] [twistedcaldav.directory.principal#error] No principal found for UID: 8a8be0fd-f969-5760-bef6-a73ad4ae3aa1

We do not have this kind of problems with our Leopard (10.5.8) iCal clients or using the web page.

Thanks in advance for any help.

H.

MacBook Pro, PowerBook G4, iMac Core Duo, iMac Core 2 Duo, Mac OS X (10.6.3)
  • John Maisey Level 5 Level 5 (6,895 points)
    Hi,

    This is a user to user forum.

    You could notify Apple by making report on their feedback form for iCal (which they have overhauled recently, but still does not have iCal version 4 as an option!!).

    You could also make a report to Apple by their Bug Reporter system. You need an ADC account, but they do offer a free one.

    You could also join the CalDAV user's list and see if anyone there can give you some pointers. http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users

    It might also be worth looking at http://trac.calendarserver.org, to see if they have anything on your problem.

    Best wishes

    John M
  • mike.habermeier Level 1 Level 1 (5 points)
    Hi,

    I know it will not help you but you are not alone.
    The same happens to me and I will now dive into the problem.
    I will upgrade the server to 10.6.4 now and i hope that this will help.

    I will come back later and post my results.
    Mike
  • hmolina Level 1 Level 1 (0 points)
    Hi Mike,

    Thanks for your reply, it is good known we are not alone in this problematic universe, jejejeje

    I upgraded the server before post this issue, and it do not solve the problem :-s

    I will follow the instructions from John Maisey to report the problem to apple directly.

    If I have any solution, I will post it in this forum.

    Best regards

    H.
  • mike.habermeier Level 1 Level 1 (5 points)
    so.. we are completely not alone. another topic:
    http://discussions.apple.com/thread.jspa?messageID=11685843

    The threat name is different but it is the same issue.
  • mike.habermeier Level 1 Level 1 (5 points)
    so. i installed the server update and it is not working.
    tried to copy the ical.app to the 10.6.4 computer and it is not working.

    so... i dont know what to do know. it seems like a bug to me
  • Random Chaos Level 1 Level 1 (0 points)
    A followup from my post here: http://discussions.apple.com/messageview.jspa?messageID=11686666&stqc=true


    Looking at server debug error logs in Info mode, it appears that when querying for the group's HEX UID, the server does the following process:

    - Creates a wiki record for the GUID in Memcache; the correct data appears to be passed from the wiki entry
    - Checks state of GUID, fails to find it
    - Removes memcache data
    - Returns "Not Found" to the client

    Anyone know why the Twisted is failing to successfully create the Memcache entry?


    This is the log of the events dealing with the targetted UID:


    2010-06-17 11:00:40-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.wiki.WikiDirectoryService#info] Creating wiki record with GUID 4946e8b4-dbee-59aa-9064-37bc5ae59154
    2010-06-17 11:01:01-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.cache.MemcacheResponseCache#debug] Adding to cache: '04a59fceaad709e7fcbbe8a1a846fa43' = '((I0\nNtp1\nI5849565769670424107\n(I0\nNtp2\n(I207\n(dp3\nS\'Last-Modified\'\n p4\n(lp5\nS\'Thu, 17 Jun 2010 15:01:01 GMT\'\np6\nasS\'DAV\'\np7\n(lp8\nS\'1, access-control, calendar-access, calendar-schedule, calendar-auto-schedule, calendar-availability, inbox-availability, calendar-proxy, calendarserver-private-events, calendarserver-private-comments, calendarserver-principal-property-search\'\np9\nasS\'Content-Type\'\np10\n(lp11 \nS\'text/xml\'\np12\nasS"<?xml version=\'1.0\' encoding=\'UTF-8\'?><multistatus xmlns=\'DAV:\'>\\r\\n <response>\\r\\n <href>/principals/wikis/acgiit/</href>\\r\\n <propstat>\\r\\n <prop>\\r\\n <principal-collection-set>\\r\\n <href>/principals/</href>\\r\\n </principal-collection-set>\\r\\n <calendar-home-set xmlns=\'urn:ietf:params:xml:ns:caldav\'>\\r\\n <href xmlns=\'DAV:\'>/calendars/_uids_/wiki-acgiit</href>\\r\\n </calendar-home-set>\\r\\n <calendar-user-address-set xmlns=\'urn:ietf:params:xml:ns:caldav\'>\\r\\n <href xmlns=\'DAV:\'>/principals/wikis/acgiit/</href>\\r\\n <href xmlns=\'DAV:\'>urn:uuid:4946e8b4-dbee-59aa-9064-37bc5ae59154</href>\\r\\n <href xmlns=\'DAV:\'>https://server.redacted.tld:8443/principals/_uids_/4946e8b4-dbee-59aa-9064-37bc5ae59154/</href>\\r\\n <href xmlns=\'DAV:\'>https://server.redacted.tld:8443/principals/wikis/acgiit/</href>\\r\\n <href xmlns=\'DAV:\'>/principals/_uids_/4946e8b4-dbee-59aa-9064-37bc5ae59154/</href>\\r\\n <href xmlns=\'DAV:\'>http://server.redacted.tld:8008/principals/wikis/acgiit/</href>\\r\\n <href xmlns=\'DAV:\'>http://server.redacted.tld:8008/principals/_uids_/4946e8b4-dbee-59aa-9064-37bc5ae59154/</href>\\r\\n </calendar-user-address-set>\\r\\n <schedule-inbox-URL xmlns=\'urn:ietf:params:xml:ns:caldav\'>\\r\\n <href xmlns=\'DAV:\'>/calendars/_uids_/wiki-acgiit/inbox/</href>\\r\\n </schedule-inbox-URL>\\r\\n <schedule-outbox-URL xmlns=\'urn:ietf:params:xml:ns:caldav\'>\\r\\n <href xmlns=\'DAV:\'>/calendars/_uids_/wiki-acgiit/outbox/</href>\\r\\n </schedule-outbox-URL>\\r\\n <dropbox-home-URL xmlns=\'http://calendarserver.org/ns/\'>\\r\\n <href xmlns=\'DAV:\'>/calendars/_uids_/wiki-acgiit/dropbox/</href>\\r\\n </dropbox-home-URL>\\r\\n <displayname>acgiit</displayname>\\r\\n <principal-URL>\\r\\n <href>/principals/_uids_/4946e8b4-dbee-59aa-9064-37bc5ae59154/</href>\\r\\n </principal-URL>\\r\\n <supported-report-set>\\r\\n <supported-report>\\r\\n <report>\\r\\n <acl-principal-prop-set/>\\r\\n </report>\\r\\n </supported-report>\\r\\n <supported-report>\\r\\n <report>\\r\\n <principal-match/>\\r\\n </report>\\r\\n </supported-report>\\r\\n <supported-report>\\r\\n <report>\\r\\n <principal-property-search/>\\r\\n </report>\\r\\n </supported-report>\\r\\n <supported-report>\\r\\n <report>\\r\\n <expand-property/>\\r\\n </report>\\r\\n </supported-report>\\r\\n </supported-report-set>\\r\\n </prop>\\r\\n <status>HTTP/1.1 200 OK</status>\\r\\n </propstat>\\r\\n <propstat>\\r\\n <prop>\\r\\n <xmpp-uri xmlns=\'http://calendarserver.org/ns/\'/>\\r\\n <notification-URL xmlns=\'http://calendarserver.org/ns/\'/>\\r\\n </prop>\\r\\n <status>HTTP/1.1 404 Not Found</status>\\r\\n </propstat>\\r\\n </response>\\r\\n</multistatus>"\np13\ntt.'
    2010-06-17 11:01:07-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] Memcache: checking dir|guid|4946e8b4-dbee-59aa-9064-37bc5ae59154
    2010-06-17 11:01:07-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] Memcache: miss dir|guid|4946e8b4-dbee-59aa-9064-37bc5ae59154
    2010-06-17 11:01:07-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] Faulting record for attribute 'guid' with value '4946e8b4-dbee-59aa-9064-37bc5ae59154'
    2010-06-17 11:01:07-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] opendirectory.queryRecordsWithAttribute_list(<PyCObject object at 0x101b47670>,'dsAttrTypeStandard:GeneratedUID','4946e8b4-dbee-59aa-9064-37bc5ae 59154',8193,False,['dsRecTypeStandard:Users', 'dsRecTypeStandard:Groups', 'dsRecTypeStandard:Places', 'dsRecTypeStandard:Resources'],['dsAttrTypeStandard:GeneratedUID', 'dsAttrTypeStandard:RecordName', 'dsAttrTypeStandard:AltSecurityIdentities', 'dsAttrTypeStandard:RecordType', 'dsAttrTypeStandard:RealName', 'dsAttrTypeStandard:FirstName', 'dsAttrTypeStandard:LastName', 'dsAttrTypeStandard:EMailAddress', 'dsAttrTypeStandard:AppleMetaNodeLocation', 'dsAttrTypeStandard:GroupMembers', 'dsAttrTypeStandard:NestedGroups', 'dsAttrTypeStandard:ResourceInfo', 'dsAttrTypeStandard:ResourceInfo'])
    2010-06-17 11:01:07-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] Failed to fault record for attribute 'guid' with value '4946e8b4-dbee-59aa-9064-37bc5ae59154'
    2010-06-17 11:01:07-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.appleopendirectory.OpenDirectoryService#debug] Memcache: storing (negative) dir|guid|4946e8b4-dbee-59aa-9064-37bc5ae59154
    2010-06-17 11:01:07-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.principal#error] No principal found for UID: 4946e8b4-dbee-59aa-9064-37bc5ae59154
  • CS8 Level 1 Level 1 (0 points)
    I'm reporting the same problem here. Although I don't think it's a server issue. This morning one of the clients on my network updated to 10.6.4 and that immediately killed it's connection to the group calendar on iCal Server running on a mini with Snow Leopard Server 10.6.3.

    I figured it could have been a problem with the client having a higher version than the server so I went on and run the update on the server too. I did not update my MacBook Pro or other mac client.
    Indeed after server rebooted the 10.6.4 client still couldn't access the group calendar, but the other clients who were left at 10.6.3 had no problems in reading iCal Server (which is now running 10.6.4)

    So this in my view should exclude a server-side bug.

    The only workaround I found is to open iCal, discard the error messages, go on accounts, change the calendar URL back to its original format of

    /principals/_uids_/wiki-groupname/

    then close the account window, right click on the calendar menu and hit "refresh all".

    Group calendar will work until you quit iCal and restart it, in that case you need to repeat the process.

    I hope this is fixed very soon
  • Random Chaos Level 1 Level 1 (0 points)
    I am not finding even that work around fixes it. The moment I click "Refresh All" the server paths revert to the hex GUID which cannot be found.

    We have two separate issues, fixing either will solve the problem:
    1. The server actually responds to the GUID for the wiki calendar groups
    2. The client uses the Wiki path rather than the GUID path


    What was changed was the behaviour of #2. It broke because of the bug #1. Technically, the bug is #1, not #2, but the change to #2 caused the breaking of the calendar lookups.
  • CS8 Level 1 Level 1 (0 points)
    Try to do it twice in rapid succession. Sounds ridiculous but after a reboot the workaround starts to work from the second try on. For me at least.

    And I agree with you, although bug #1 is much older than the current update. I hope Apple will not state that we've all been using an unsupported feature of iCal and that we should only subscribe to group calendars from iCal, which would defeat the entire purpose of group calendaring IMHO.
  • Andre LaBranche1 Level 1 Level 1 (10 points)
    CS8 wrote:
    ... I hope Apple will not state that we've all been using an unsupported feature of iCal and that we should only subscribe to group calendars from iCal, which would defeat the entire purpose of group calendaring IMHO.


    Sorry to be the bearer of unfortunate news, but the above is true. Your intuition that this is unsupported was correct. True group calendaring is not a supported feature in Snow Leopard, and if it were, there would probably be a better user experience that didn't require you to manually hack paths around in the iCal prefs. In general, if you are relying on a behavior that is not documented, there is a good chance that it is unsupported / incidental behavior, as in this case.

    The closest supported path for 'group calendaring' is to use delegation. We realize that group calendaring is an important feature, and has already been implemented for a good while in our trunk codebase, on macosforge. Please note that running trunk code is also not supported; I mention it only to indicate that we understand the importance of the feature.

    -dre
  • DurocShark Level 1 Level 1 (10 points)
    This happened to us too. Maybe it's Apple's way of saying to go to Exchange? I hope not, but that's what'll happen here if I can't get this solved.
  • Mr Beardsley Level 1 Level 1 (40 points)
    Andre LaBranche1 wrote:
    CS8 wrote:
    ... I hope Apple will not state that we've all been using an unsupported feature of iCal and that we should only subscribe to group calendars from iCal, which would defeat the entire purpose of group calendaring IMHO.


    Sorry to be the bearer of unfortunate news, but the above is true. Your intuition that this is unsupported was correct. True group calendaring is not a supported feature in Snow Leopard, and if it were, there would probably be a better user experience that didn't require you to manually hack paths around in the iCal prefs. In general, if you are relying on a behavior that is not documented, there is a good chance that it is unsupported / incidental behavior, as in this case.

    The closest supported path for 'group calendaring' is to use delegation. We realize that group calendaring is an important feature, and has already been implemented for a good while in our trunk codebase, on macosforge. Please note that running trunk code is also not supported; I mention it only to indicate that we understand the importance of the feature.

    -dre


    Well that's kind of garbage. Between no support for binding Windows 7 clients and now breaking a functionality that worked fine until the latest patch, I have to wonder why go through the pain of sticking with Snow Leopard Server. Obviously group calendaring works fine as you can do it through the wiki. The fact that Apple's own iCal client won't work when Sunbird or emClient will seems ridiculous.
  • ericc56 Level 1 Level 1 (120 points)
    Looks like you can still subscribe to group calendars using the iCal app.
  • DurocShark Level 1 Level 1 (10 points)
    I don't know about everybody else, but subscribing isn't enough for our organization.

    We moved from Now Up To Date to iCal server with the introduction of 10.5, with the expectation of group calendar support continuing. When 10.6 came along, and we had to change the method used to utilize group calendars, we were still ok. But if Apple has permanently closed that door on us, we and I suspect a lot of other people, will be looking at non-Apple solutions.

    Exchange is dirt cheap for education. And we need to replace our old QMail server anyway...
Previous 1 2 3 Next