September 2008 - calendarserver-dev

[CalendarServer] FAQ modified
by CalendarServer 16 Sep '08

16 Sep '08

Changed page "FAQ" by cdaboo(a)apple.com from 17.101.32.44* Page URL: <http://trac.calendarserver.org/wiki/FAQ> Diff URL: <http://trac.calendarserver.org/wiki/FAQ?action=diff&version=3> Revision 3 -------8<------8<------8<------8<------8<------8<------8<------8<-------- Index: FAQ ========================================================================= --- FAQ (version: 2) +++ FAQ (version: 3) @@ -18,5 +18,5 @@ Server logs show lots of: "Unable to find any record with GUID XXX" errors after deleting users from the directory. What's up? - The problem here is that the deleted users were referenced as proxy for some other users and the proxy database is not part of the directory but separately maintained by the calendar server (since that behavior is specific to the server). Since proxies are managed via access control on the calendar server, often when someone makes a request of the server, the access control list has to be evaluated and the list of users in the proxy list expanded. That is when the missing GUIDs show up. You can run a special "proxy cleanup" tool to remove the deleted GUIDs from the proxy db and stop these errors from occurring. + The problem here is that the deleted users were referenced as proxy for some other users and the proxy database is not part of the directory but separately maintained by the calendar server (since that behavior is specific to the server). Since proxies are managed via access control on the calendar server, often when someone makes a request of the server, the access control list has to be evaluated and the list of users in the proxy list expanded. That is when the missing GUIDs show up. You can run a special "[wiki:ProxyCleanup proxy cleanup]" tool to remove the deleted GUIDs from the proxy db and stop these errors from occurring. -------8<------8<------8<------8<------8<------8<------8<------8<-------- * The IP shown here might not mean anything if the user or the server is behind a proxy. -- CalendarServer </> HTTP/WebDAV/CalDAV Server This is an automated message. Someone at / added your email address to be notified of changes on FAQ. If it was not you, please report to .

1 0

[CalendarServer] FAQ modified
by CalendarServer 16 Sep '08

16 Sep '08

Changed page "FAQ" by cdaboo(a)apple.com from 17.101.32.44* Page URL: <http://trac.calendarserver.org/wiki/FAQ> Diff URL: <http://trac.calendarserver.org/wiki/FAQ?action=diff&version=2> Revision 2 -------8<------8<------8<------8<------8<------8<------8<------8<-------- Index: FAQ ========================================================================= --- FAQ (version: 1) +++ FAQ (version: 2) @@ -15,3 +15,8 @@ The Rosetta PowerPC emulator on Intel-based Macs can actually confuse users with it's magic because a PowerPC Python will run on an Intel Mac, but then fail to load a plugin built for Intel. Most Python modules are written in Python, and therefore platform-independant, but the Calendar Server uses several C extension modules. Make sure that your Python and all C extension modules are built for the same architecture. + +Server logs show lots of: "Unable to find any record with GUID XXX" errors after deleting users from the directory. What's up? + + The problem here is that the deleted users were referenced as proxy for some other users and the proxy database is not part of the directory but separately maintained by the calendar server (since that behavior is specific to the server). Since proxies are managed via access control on the calendar server, often when someone makes a request of the server, the access control list has to be evaluated and the list of users in the proxy list expanded. That is when the missing GUIDs show up. You can run a special "proxy cleanup" tool to remove the deleted GUIDs from the proxy db and stop these errors from occurring. + -------8<------8<------8<------8<------8<------8<------8<------8<-------- * The IP shown here might not mean anything if the user or the server is behind a proxy. -- CalendarServer </> HTTP/WebDAV/CalDAV Server This is an automated message. Someone at / added your email address to be notified of changes on FAQ. If it was not you, please report to .

1 0

Re: [CalendarServer-dev] [CalendarServer] #207: Recurring events do not appear to extend beyond November 2008
by CalendarServer 15 Sep '08

15 Sep '08

#207: Recurring events do not appear to extend beyond November 2008 ------------------------------------+--------------------------------------- Reporter: dekkerdreyer(a)gmail.com | Owner: sagen(a)apple.com Type: Defect | Status: reopened Priority: 1: Blocker | Milestone: 2.x Component: Calendar Server | Version: Severity: Serious | Resolution: Keywords: | ------------------------------------+--------------------------------------- Comment(by wsanchez(a)apple.com) At a glance, this looks OK, though we will need some unit tests. Coding guidelines are here: source:CalendarServer/trunk/HACKING. -- Ticket URL: <http://trac.calendarserver.org/ticket/207#comment:10> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Groups and membership
by Wilfredo Sánchez Vega 08 Sep '08

08 Sep '08

What I'd like us to achieve going forward (ideally in Snow Leopard) with regards to our uses of groups in iCal Server. 1- It's OK for location and resource GUIDs to be members of groups. It's not exactly normal, but it's valid and OK, so let's not worry about that. So for the "enabled for calendaring" group, feel free to throw these objects into the group. 2- We need to limit our use of groups to "is X a member of Y", which is an operation we can make against DS very quickly and very frequently. We needn't cache this, on the expectation that it should be fast enough. 3- Which means we need to get rid of cases where we try to enumerate all members of a group, or the groups a principal is a member of. This one is tough due to the current delegate model. It means the DAV:group-memberships and DAV:groups should generally be deprecated. I think that's doable for principals other than the delegate sub-principals without breaking current functionality, and for delegate sub-principals, we can keep flattened lists cached. If we do this, we should be able to do all group membership checks via DS and without needing an in-memory cache. -wsv

2 2