Previous 1 2 3 4 Next 46 Replies Latest reply: Jul 15, 2010 8:44 AM by no1tmorrow Go to original post
  • Daniel Lang Level 1 Level 1 (0 points)
    Here are some more Infos I got after some tests:

    In my iCal Settings on the 10.6.3 clients I have SSL on Port 8443 and Kerberos enabled. In the server path field I have a value like:


    This works fine.

    On the 10.6.4 client I have same settings like on the 10.6.3 clients. Only the server path has the GUID like:


    Now I have changed that GUID to the group name. Then I works fine as long I keep iCal open. As soon as I restart the 10.6.4 iCal Client, the server path in the iCal Settings is "resolved" back to:


    There seems to be a problem with resolving the calendar group name to the GUID of that group. The 10.6.3 client seems to not resolve the name to the GUID (or it is done differently).

    When I verify the group calendar settings trough the HTML Page with the URL:


    then I can see, that the displayed "Principal URL" is wrong on the server too. There it is also given like:


    And that seems to be the main problem, because the 10.6.4 iCal Client seems to pick up this value instead of keeping the groupname.

    The 10.6.3 iCal Client seems to handle that resolving differently than the 10.6.4 client. And when there is a problem with that "Principal URL" on the server (which is the case on some group calendars of mine), then the 10.6.4 client spits out these error messages.

    Now this leaves open the following questions:

    - What does the 10.6.4 client different than the older iCal Clients, while resolving the "Principal URL"

    - Why has the 10.6.3 Server the wrong "Principal URL" for some groups (which seems to be the main problem)
  • Elliot Hui Level 1 Level 1 (20 points)
    I am running Snow Leopard Server 10.6.3 (Build 10D573). I used the wiki system to set up the user and group calendars.

    The wiki group calendar is accessed on the client by setting up a user calendar and then changing the path from /principals/users/uid to /principals/wikis/group , which always seemed to me to be a bit of a hack.

    Eric, what version server and client are you using? How are you implementing group calendaring? Maybe I can copy your setup since it is working for you.
  • syncx Level 1 Level 1 (0 points)
    i updated both (clients and server) to 10.6.4 and not using ssl, but i encountered the same problems.

    the ical-client can write to the server (tested with wiki-web-frontend), but it can't read: can't find calender .... on the server.
  • Osti Level 1 Level 1 (0 points)

    I have implemented the same "hack", and I'm now getting the same problem. From reading the comments above, it seems others here have done the same thing.

    One distinct possibility is that Apple has now "fixed" the workaround that allowed us to directly access and edit wiki group calendars in iCal. The supported method, as far as I understand things, is editing of group calendars in Safari only, and access via iCal only through subscription.

    I'm not adventurous enough to find a new workaround, I'm afraid. Here's hoping that someone with more guts and brains than this soul will be able to do so!

    Message was edited by: Osti (clarification)
  • mike.habermeier Level 1 Level 1 (5 points)
    We have the same problem here. Sorry for starting another threat!!
  • stooky Level 1 Level 1 (0 points)
    to jump in one more time on the question of wiki-group-calendar or not ...

    as far as I can read now it seems a question of 10.6.4 client not server update.
    and in my case I do not run any wiki or collaborative group calendars.

    the simple normal standard caldav-user login does not work in my case, moaning on the wrong SSL cert.

    so I am not sure if it is client update only issue. as the wrong cert seems to be delivered by server.

    as mentioned in an earlier post, my workaround is to click continue on the cert popup and then refuse to accept the wrong cert and not enter the password to open the keychain for the cert. this ends up in propper user account setup ... e.g.


    with correct server and port 8443 and accepting the correct cert.
  • Random Chaos Level 1 Level 1 (0 points)
    More info: Writing to the calendars works. Reading from the calendars does not.

    Read request to server fails with server log entry: - michaelney [17/Jun/2010:08:50:58 -0400] "PROPFIND /principals/_uids_/9e65adb6-6a31-5623-8a40-7fb9da24fce3/ HTTP/1.1" 404 173 "-" "DAVKit/4.0.3 (732); CalendarStore/4.0.3 (991); iCal/4.0.3 (1388); Mac OS X/10.6.4 (10F569)" i=8444 t=8.1 or=1

    (note, why does apple not have a plain text mode for posting? Square brackets are being automatically converted to strike throughs...)

    Write request to the same account succeeds with: - "michaelney as allacgi" [17/Jun/2010:08:52:01 -0400] "PUT /calendars/_uids_/wiki-allacgi/0AC8A940-95A5-4719-9F12-7655D879BD54/F7FCD33D-1A50-4B1F-BD28-5BFC0 3CAC877.ics HTTP/1.1" 201 0 "-" "DAVKit/4.0.3 (732); CalendarStore/4.0.3 (991); iCal/4.0.3 (1388); Mac OS X/10.6.4 (10F569)" i=8444 t=196.6 or=1

    As you can see, completely different addresses.

    As others have reported, the address /principals/wikis/allacgi/ is resetting every load in iCal to /principals/_uids_/9e65adb6-6a31-5623-8a40-7fb9da24fce3/

    This is the wrong UID on the server. It should be /principals/_uids_/wiki-allacgi/ - this particular UID bug has existed since 10.6.0 and has never been fixed, but has never caused a problem before since iCal client seemed to work around it when using the /principlals/wikis/allacgi/ type address correctly being evaluated client side. Now with 10.6.4, the client is replacing a working principals address with the incorrect principles UID provided by the iCal server.

    Any suggestions? Has anyone installed OSX Server 10.6.4 to see if they changed the server behavior to fix this? (We are still running 10.6.3 Server and are hesitating to upgrade any other systems to 10.6.4 until we know this issue will not affect them.)

    Any other ideas on working around this issue?

  • mike.habermeier Level 1 Level 1 (5 points)
    Hallo Random Chaos,

    Please post to the Threat:
    it seems to me that this threat is really a SSL thing. See my post and the answer above.

    Now to your answer: Yes I have installed the server update too and it is not working..

    Any other ideas ??

    thx mike
  • syncx Level 1 Level 1 (0 points)
    as i wrote before, we have the same problems with our updated server (10.6.4)
  • syncx Level 1 Level 1 (0 points)
    i believe with or without ssl, it's the same problem.
  • mike.habermeier Level 1 Level 1 (5 points)
    i am not quite sure.. i am running with SSL certificate and have no problems with it.
    But maybe it is the same basic bug Who know!!! ???
  • stooky Level 1 Level 1 (0 points)
    Random Chaos wrote:
    More info: Writing to the calendars works. Reading from the calendars does not.

    coming back to single user accounts versus group accounts (calendars)

    once the correct settings are applied to single user accounts, everything workz fine
    SSL - r/w - share - grant substitute rights

    all fine for single users, or at least in my environment (3 clients 1 server all 10.6.4)

    for me it is only the SSL-cert prob.

    the more i read and dig the web, it looks IMHO like more than one bug
    SSL server and client
    CalDav server and client
  • Mr Beardsley Level 1 Level 1 (40 points)
    I believe the problem is with the the iCal server and specifically the calendar functionality for groups/wikis. The change to the iCal client where it switches to url to /principals/_uid_/guid/ should work fine, but either the iCal or Wiki server is broken when it creates the calendar.

    Since it is DAV you can use Safari to check stuff. In Safari:

    http://servername:8008/principals/wikis/groupname/ no ssl
    https://servername:8443/principals/wikis/groupname/ with ssl

    You should see principal details for your group. It lists the guid of the group and an alternate url. We've all been using the alternate url and that has worked so far. If you click on the principal url though you'll see that you get a not found error.

    If you do the same process for an individual user you'll see that the principal url works just fine. I believe the problem exists that the calendar server or the wiki server isn't properly setting things up and the principal url is broken leading to the trouble we see in the iCal client.
  • Random Chaos Level 1 Level 1 (0 points)
    Indeed it looks like a iCal Server issue. The server attempts to create a memcache entry for the Wiki Group's UID, gets some sort of error, deletes the entry, and returns 404 to the client. Not sure what is going on there, but definately seems server side.

    See for details on the above.
  • Mr Beardsley Level 1 Level 1 (40 points)
    I wonder if it has something to do with OpenDirectory. I have this in my logs:

    2010-06-17 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [] Memcache: checking dir|guid|wiki-travel
    2010-06-17 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [] Memcache: miss dir|guid|wiki-travel
    2010-06-17 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [] Faulting record for attribute 'guid' with value 'wiki-travel'
    2010-06-17 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [] opendirectory.queryRecordsWithAttribute_list(<PyCObject object at 0x1011b1fd0>,'dsAttrTypeStandard:GeneratedUID','wiki-travel',8193,False,['dsRec TypeStandard: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 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [] opendirectory.queryRecordsWithAttribute_list matched records: 0
    2010-06-17 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [] Failed to fault record for attribute 'guid' with value 'wiki-travel'
    2010-06-17 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [] Memcache: storing (negative) dir|guid|wiki-travel
    2010-06-17 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [] Directory service <WikiDirectoryService '/Search'> has no GUID; generating service GUID from realm name.
    2010-06-17 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [] Creating wiki record with GUID d85b017a-0663-51f4-95eb-7d3559d96c56
    2010-06-17 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [] Returning existing wiki record with UID wiki-travel
    2010-06-17 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [] Returning existing wiki record with UID wiki-travel
    2010-06-17 10:18:35-0600 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.extensions#info] PROPFIND /calendars/_uids_/wiki-travel/ HTTP/1.1

    It appears to be checking OpenDirectory for a group with the same name as the wiki and can't find one.