Which openldap directoryservice to use?
Which is preferable to use from the CalendarServer trunk? This is for a CalDAV server, with users/groups/etc in an OpenDirectory server (accessed through DirectoryServices) twistedcaldav/directory/appleopendirectory.py or twistedcaldav/directory/cachingappleopendirectory.py Eli
On Apr 14, 2009, at 1:45 PM, Eli Bach wrote:
Which is preferable to use from the CalendarServer trunk?
This is for a CalDAV server, with users/groups/etc in an OpenDirectory server (accessed through DirectoryServices)
twistedcaldav/directory/appleopendirectory.py or twistedcaldav/directory/cachingappleopendirectory.py
Eli
The appleopendirectory version is the one that's been around for a while, so it's potentially more stable, but the startup time can be long if your directory has a large number of users/groups (because this code reads all directory records in from the OD server -- and actually does this *per* calendar server "slave" process). The cachingappleopendirectory version not only faults records in only as needed, but uses memcache to share those records amongst the calendar server processes. We are still evaluating the performance benefits of this new version. Note also that resource delegation (being able to specify which users are allowed to be delegates for a resource or location) is not yet supported in cachingappleopendirectory yet. ~morgen
On Apr 15, 2009, at 9:57 AM, Morgen Sagen wrote:
On Apr 14, 2009, at 1:45 PM, Eli Bach wrote:
Which is preferable to use from the CalendarServer trunk?
This is for a CalDAV server, with users/groups/etc in an OpenDirectory server (accessed through DirectoryServices)
twistedcaldav/directory/appleopendirectory.py or twistedcaldav/directory/cachingappleopendirectory.py
Eli
The appleopendirectory version is the one that's been around for a while, so it's potentially more stable, but the startup time can be long if your directory has a large number of users/groups (because this code reads all directory records in from the OD server -- and actually does this *per* calendar server "slave" process). The cachingappleopendirectory version not only faults records in only as needed, but uses memcache to share those records amongst the calendar server processes. We are still evaluating the performance benefits of this new version. Note also that resource delegation (being able to specify which users are allowed to be delegates for a resource or location) is not yet supported in cachingappleopendirectory yet.
~morgen
Does the trunk support (using appleopendirectory) support everything that the /branches/release/CalendarServer-1.4-dev version does, or should I switch to the release/1.4 code? This is for a server that I'm putting into production for primarily Leopard/iCal and eventually Snow Leopard clients. Eli
On Apr 15, 2009, at 10:30 AM, Eli Bach wrote:
Does the trunk support (using appleopendirectory) support everything that the /branches/release/CalendarServer-1.4-dev version does, or should I switch to the release/1.4 code? This is for a server that I'm putting into production for primarily Leopard/iCal and eventually Snow Leopard clients.
In trunk we got rid of the need for the weird schema extensions that were needed in 1.x (the SericesLocator stuff). So I think that's a lot better. That said, "trunk" and "production" isn't usually a good combination, and trunk will not always be very stable. I've recently made a 2.2-dev branch which should remain at least as stable as it is now until we cut our first 2.x release[1], so if you want 2.x, I'd go with that. -wsv [1] Should be relatively soon; I think we're functionally pretty stable right now.
On Apr 29, 2009, at 9:39 AM, Wilfredo Sánchez Vega wrote:
In trunk we got rid of the need for the weird schema extensions that were needed in 1.x (the SericesLocator stuff). So I think that's a lot better.
But these will still be needed for 10.5 clients...(which throws off Directory.app for enabling/disabling calendaring entries). Will resources and locations also use 'groups' for being enabled/ disabled for DCS (which seems to also need a schema extension...)? Eli
On Apr 29, 2009, at 11:01 AM, Eli Bach wrote:
Will resources and locations also use 'groups' for being enabled/ disabled for DCS (which seems to also need a schema extension...)?
That's not a schema extension in OpenDirectory; not sure about LDAP. In OD, adding resource GUIDs into a group is OK (though they don't need short names or UIDs, which is, I guess, different). The provisioning group thing is a bit of an… advanced feature. :-) -wsv
participants (3)
-
Eli Bach
-
Morgen Sagen
-
Wilfredo Sánchez Vega