web-dev-qa-db-ja.com

Snow Leopard Serverにアップグレードした後、iCal / CalDAVサーバーからの「HTTP / 1.1403Forbidden」エラーを解決するにはどうすればよいですか？

最近、Open DirectoryマスターとレプリカをMacOS X 10.6.4 Snow LeopardServerにアップグレードしました。サーバーのFQDNとLDAP検索ベース/ Kerberosレルムが一致しなかったため、すべてのユーザーとグループをエクスポートし、FQDNと検索ベース/レルムが一致する新しいOpen Directoryマスターを作成し、ユーザーとグループを再インポートして、すべてのサーバーとを再バインドしました。新しいODマスターへのワークステーション。

これらすべてと同時に、iCal/CalDAVサーバーをMacOS X 10.6.4 SnowLeopardサーバーにアップグレードしました。それ以来、Mac OS X 10.5LeopardとMacOS X10.6の両方のiCal/CalDAVサーバーとiCalクライアントで次の問題が発生しています。

  • ユーザーが10.6サーバーへのアップグレード前に作成されたイベント（単一または繰り返し）を移動または削除しようとすると、次のエラーが発生します。

    アカウント「blah」の「blah」の「blah」へのアクセスは許可されていません。

    サーバーは、CalDAVWriteEntityQueueableOperation操作に対して「HTTP/1.1403Forbidden」と応答しました。

  • ディレクトリに追加された新しいユーザーは、iCalの設定でアカウントを追加しようとすると、次のエラーが発生します。

    ユーザー「blah」には構成済みのプリンシパルがありません。

    アカウントに少なくとも1つのCalDAVプリンシパルが構成されていることをネットワーク管理者に確認してください。

興味深いことに、ユーザーは古い繰り返しイベントから個々のイベントをエラーなしで削除できるように見えることがわかりましたが、それは繰り返しイベントを取り除くための膨大な作業です。

ICal_Server_Admin_v10.6.pdfの19ページで説明されているように、notがまだDNSにSRVレコードを追加していることに注意してください。

さらなる調査：

この特定のケースでは、ユーザーはSnow LeopardServerへのアップグレード前に作成された繰り返しイベントを拒否しようとしています。 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.

イベントの1つを削除しようとすると、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>

私が気づいたことの1つは、これが実際の効果があるかどうかはわかりませんが、これらのSnow Leopard Server以前の移行イベントの多くで、ORGANIZERが次のように指定されていることです。

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

しかし、新しいものは、次の2つのうちの1つに似ています。

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」ファイルは完全に使い捨てであり、単なるパフォーマンスキャッシュであり、その場で再構築されるため、安全に削除できると述べています。主催者のカレンダー用のものを削除しました。データベースを再構築している間、試行されたイベント削除の処理に時間がかかりましたが、最終的にはエラーになりました。

FWIWエラーはこのコードによってスローされます：

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

さらに提案はありますか？私のGoogle検索ではこれについて多くの質問がありますが、解決策はありません。これはiCalサーバーで広く見られる問題です。現在、私たちは主にユーザーにそれらを無視させようとしています（したがって、この質問が開かれている時間の長さ）が、時々私は犯人や解決策を見つけるために深く掘り下げます。

mac-osx-serverosx-snow-leopardopendirectoryicalcaldav
2
morgant

私の場合、@ googlemail.comアドレスではなく@ gmail.comアドレスを選択したときに、GoogleカレンダーでiCalを使用すると問題が発生しました。カレンダーをiCalから削除し、... @ googlemail.comで再度追加すると、すべて正常に機能します。

2
guessitsaguest

まったく同じ問題が発生し、iCal Server Admin 10.6のp.42で説明されているように、カレンダーデータストアの所有者を修正することで解決しました。ターミナルで以下を発行しました。

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

私の「ドキュメント」フォルダには正しい権限がありましたが、いくつかのディレクトリの下のいくつかのファイルまたはフォルダには所有者として「ルート」があったため、上記のコマンドで修正され、エラーが発生しなくなりました。

Chmodでも権限を変更する必要があるかもしれませんが、私の場合は問題ありませんでした。

1
Daniel Mare