如何在升级到Snow Leopard Server后解决来自iCal / CalDAV服务器的“HTTP / 1.1 403 Forbidden”错误？

我们最近将Open Directory Master＆Replica升级到了Mac OS X 10.6.4 Snow Leopard Server。 我们有一个不匹配的服务器FQDN和LDAPsearch基地/ Kerberos领域，所以我们导出所有用户和组，创build新的开放目录主机与匹配的FQDN和search基地/领域，重新导入用户和组，重新绑定所有服务器＆工作站到新的OD Master。

与此同时，我们将iCal / CalDAV服务器升级到了Mac OS X 10.6.4 Snow Leopard Server。 自从这样做以来，我们在Mac OS X 10.5 Leopard和Mac OS X 10.6上看到了以下iCal / CalDAV服务器和iCal客户端的问题：

• 如果用户尝试移动或删除在升级到10.6 Server之前创build的事件（单个或重复），则会出现以下错误：

  在账户“blah”中的“blah”中访问“blah”是不允许的。

  • Mac地址过滤radius服务器
  • 在安全性方面使用ipfw和hosts.deny有什么区别？
  • 如何更改NFS导出Mac OS X Server（Tiger）上允许的IP地址？
  • Mac OS X Web服务器内存耗尽问题
  • 从OS X Server 10.6.6迁移到10.7（Lion） – 有什么问题吗？

  服务器响应：“HTTP / 1.1 403 Forbidden”来操作CalDAVWriteEntityQueueableOperation。

• 添加到该目录的新用户在尝试将其帐户添加到iCal的首选项时出现以下错误：

  用户“blah”没有configurationpricipals。

  向您的networkingpipe理员确认您的帐户至lessconfiguration了一个CalDAV主体。

有趣的是，我们后来发现用户似乎能够从一个旧的重复事件中删除单个事件而没有错误，但是这是摆脱重复事件的大量工作。

我会注意到，我们还没有在iCal_Server_Admin_v10.6.pdf的第19页指示的DNS中添加SRVlogging。

进一步的调查：

在这种特殊情况下，用户正试图拒绝在升级到Snow Leopard Server之前创build的重复事件。 通过sudo calendarserver_manage_principals --add-write-proxy users:user1 users:user2授予用户完全写入权限sudo calendarserver_manage_principals --add-write-proxy users:user1 users:user2 （它的工作）不允许删除事件。 仍然得到通常的错误：

 Access to "blah blah" in "blah blah" in account "blah blah" is not permitted. The server responded: "HTTP/1.1 403 Forbidden" to operation CalDAVWriteEntityQueueableOperation. 

iCal服务器上/var/log/caldavd/error.log中显示的错误，当试图删除其中一个事件是：

 2011-03-17 15:14:30-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.extensions#info] PUT /calendars/__uids__/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/calendar/XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.ics HTTP/1.1 2011-03-17 15:14:30-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.scheduling.implicit#error] Cannot change ORGANIZER: UID:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX 

而客户端上的/var/log/system.log中的错误是：

 Mar 17 15:14:30 192-168-21-169-dhcp iCal[33509]: CalDAV CalDAVWriteEntityQueueableOperation failed: status 'HTTP/1.1 403 Forbidden' request:\n\nBEGIN:VCALENDAR^M\nVERSION:2.0^M\nPRODID:-//Apple Inc.//iCal 3.0//EN^M\nCALSCALE:GREGORIAN^M\nBEGIN:VTIMEZONE^M\nTZID:US/Eastern^M\nBEGIN:DAYLIGHT^M\nTZOFFSETFROM:-0500^M\nTZOFFSETTO:-0400^M\nDTSTART:20070311T020000^M\nRRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU^M\nTZNAME:EDT^M\nEND:DAYLIGHT^M\nBEGIN:STANDARD^M\nTZOFFSETFROM:-0400^M\nTZOFFSETTO:-0500^M\nDTSTART:20071104T020000^M\nRRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU^M\nTZNAME:EST^M\nEND:STANDARD^M\nEND:VTIMEZONE^M\nBEGIN:VEVENT^M\nSEQUENCE:5^M\nDTSTART;TZID=US/Eastern:20090117T094500^M\nDTSTAMP:20081227T143043Z^M\nSUMMARY:blah blah^M\nATTENDEE;CN="First Last";CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT:urn:uuid^M\n :XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX^M\nATTENDEE;CN="First Last";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:user@d^M\n omain.tld^M\nEXDATE;TZID=US/Eastern:20110319T094500^M\nDTEND;TZID=US/Eastern:20090117T183000^M\nRRULE:FREQ=WEEKLY;INTERVAL=1^M\nTRANSP:OPAQUE^M\nUID:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX^M\nORGANIZER;CN="First Last":mailto:[email protected]^M\nX-WR-ITIPSTATUSML:UNCLEAN^M\nCREATED:20110317T191348Z^M\nEND:VEVENT^M\nEND:VCALENDAR^M\n\n\n... response:\nHTTP/1.1 403 Forbidden^M\nDate: Thu, 17 Mar 2011 19:14:30 GMT^M\nDav: 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^M\nContent-Type: text/xml^M\nContent-Length: 134^M\nServer: Twisted/8.2.0 TwistedWeb/8.2.0 TwistedCalDAV/2.5 (iCal Server v12.56.21)^M\n^M\n<?xml version='1.0' encoding='UTF-8'?><error xmlns='DAV:'>^M\n <valid-attendee-change xmlns='urn:ietf:params:xml:ns:caldav'/>^M\n</error> 

有一件事我注意到了，我不确定这是否有真正的效果，在许多这些Snow Leopard Server之前的迁移事件中，ORGANIZER指定如下：

 ORGANIZER;CN=First Last:mailto:[email protected] 

但是更新的更像下面两个之一：

 ORGANIZER;CN=First Last;[email protected];SCHEDULE-STATUS=1 ORGANIZER;CN=First Last;[email protected]:urn:uuid:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX 

iCal_Server_Admin_v10.6.pdf注意到“.db.sqlite”文件是完全一次性的，它们只是一个性能caching，并且可以随时重新构build，所以可以安全地删除。 我没有删除组织者的日历，并且在重build数据库时处理尝试的事件删除花了更长的时间，但最后还是出错了。

FWIW错误是由这个代码引发的：

https://trac.calendarserver.org/browser/CalendarServer/trunk/twistedcaldav/scheduling/implicit.py

还有什么build议？ 我在Googlesearch中看到很多关于这个问题的问题，但是没有解决scheme，这是iCal服务器上的一个普遍问题。 现在，我们主要是试图让用户忽略它们（因此这个问题已经被打开了），但是我偶尔会深入地尝试find罪魁祸首和/或解决scheme。

 sudo chown -R _calendar:_calendar /Library/CalendarServer/Documents