Re: LDAP Change Log

[Rich Graves <rgraves@carleton.edu>]

I'm a mostly one-man shop with only 3500 users on one server.

The original poster mentioned false negatives. I wonder if there's a race condition due to buffering -- ModifyPrefsRequest logged and redolog data flushed before actually changing LDAP. If that's the case, then there are two ways around it: polling all of LDAP every time, as I do, or taking care to use zmprov ga, which unlike ldapsearch would access the write cache.

Polling down all of LDAP is surely an inefficient use of CPU, but we usually have spare; I/O is the limiting factor. Modern versions of OpenLDAP shouldn't have locking issues. If they did, or if you need multiple passes, then slapcat piped to something like Net::LDAP::LDIF would offload the searching from slapd (at the expense of needing to de-base64 some strings). I don't feel bad about keeping all of LDAP in RAM, where it should be anyway. Finallyandmostimportantly, fewer lines of code means more efficient use of me!