Недавно мы обновили наш Open Directory Master & Replica до Mac OS X 10.6.4 Snow Leopard Server. У нас было несоответствующее полное доменное имя сервера и база поиска LDAP / область Kerberos, поэтому мы экспортировали всех пользователей и группы, создали новый Open Directory Master с соответствующим полным доменным именем и поисковой базой / областью, повторно импортировали пользователей и группы и повторно связали все серверы и рабочие станции к новому OD Master.
Одновременно со всем этим мы обновили наш сервер iCal / CalDAV до Mac OS X 10.6.4 Snow Leopard Server. С тех пор мы наблюдали следующие проблемы с нашим сервером iCal / CalDAV и клиентами iCal в Mac OS X 10.5 Leopard и Mac OS X 10.6:
Если пользователь пытается переместить или удалить событие (одиночное или повторяющееся), созданное до обновления до 10.6 Server, он получает следующую ошибку:
Доступ к «бла» в «бла» в аккаунте «бла» не разрешен.
Сервер ответил: «HTTP / 1.1 403 Forbidden» на операцию CalDAVWriteEntityQueueableOperation.
Новые пользователи, добавленные в каталог, получают следующую ошибку при попытке добавить свою учетную запись в настройках iCal:
У пользователя "blah" нет сконфигурированных начальных классов.
Уточните у сетевого администратора, что в вашей учетной записи настроен хотя бы один субъект CalDAV.
Интересно, что с тех пор мы обнаружили, что пользователи, похоже, могут без ошибок удалять отдельные события из старого повторяющегося события, но это огромный объем работы, чтобы избавиться от повторяющегося события.
Замечу что у нас есть не тем не менее, добавил SRV-запись в DNS, как указано на стр. 19 iCal_Server_Admin_v10.6.pdf.
Дальнейшее расследование:
В этом конкретном случае пользователь пытается отклонить повторяющиеся события, созданные до обновления до Snow Leopard Server. Предоставление пользователю полного доступа на запись с 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.
Ошибка, которая появляется в /var/log/caldavd/error.log на сервере iCal при попытке удалить одно из событий:
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:user@domain.tld^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:user@domain.tld
Но более новые больше похожи на одну из двух следующих:
ORGANIZER;CN=First Last;EMAIL=user@domain.tld;SCHEDULE-STATUS=1
ORGANIZER;CN=First Last;EMAIL=user@domain.tld: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. Сейчас мы в основном пытаемся заставить пользователей игнорировать их (отсюда и время, в течение которого этот вопрос был открытым), но время от времени я копаюсь глубже, пытаясь найти виновника и / или решение.
Что касается меня, проблема возникла при использовании iCal с Календарем Google, когда я выбрал свой адрес @ gmail.com вместо адреса @ googlemail.com. После удаления календаря из iCal и его повторного добавления с помощью ... @ googlemail.com все работает нормально.
У меня были точно такие же проблемы, и я решил их, исправив владельца хранилища данных календаря, как описано на стр. 42 iCal Server Admin 10.6. Я выдал в Терминале:
sudo chown -R _calendar:_calendar /Library/CalendarServer/Documents
Моя папка «Документы» имела правильные разрешения, но некоторые файлы или папки, находящиеся в нескольких каталогах ниже, имели «root» в качестве владельца, поэтому приведенная выше команда исправила это, и больше у пользователей не было ошибок.
Возможно, вам также придется изменить разрешения с помощью chmod, но в моем случае они были в порядке.