On Fri, 2008-05-16 at 10:01 +0200, Bas van der Vlies wrote: > Just a thought i have read the changelog and news for version 0.6.2 > and it says it has a fix for groups with a lot members. but is that > for groupOfUniqueNames with uniqueMembers?
Some of the fixes are for both uniqueMember and memberUid attributes (some general improvements) but most of the improvements were for the uniqueMember attribute. > On Fri, 2008-05-16 at 13:28 +0200, Petter Reinholdtsen wrote: > I have a similar problem, and this patch bring the read buffer in nss > up to the same size as the write buffer in nslcd. No idea why it > helps. The reason that the read buffer in the NSS part needs to be so big is because it has to be able to contain one whole group entry (with all members). This is because of the retry mechanism in NSS (if the read buffer is full, retries will fail). The default buffer size in 0.6.2 is 32k, enough for about 2500 members (not having too many too long usernames). I had thought that this was a good enough upper limit but apparently there are environments out there with many more users per group. What would be a reasonable upper limit? On Fri, 2008-05-16 at 10:01 +0200, Bas van der Vlies wrote: > I also get a lot of these messages in my slapd.log: > - May 16 09:57:50 slave2 slapd[32681]: <= bdb_equality_candidates: > (uniqueMember) not indexed > > That is strange because i do not use this attribute at all. By default nss-ldapd will try to look up both the uniqueMember and memberUid attributes and use those in searches. To disable the uniqueMember attribute in nss-ldapd, currently the best solution is to map it to something unknown, e.g.: map group uniqueMember disabled Another solution would be to just create the index in slapd.conf: index groupOfUniqueNames uniqueMember (rerun slapdindex and fix ownership of database files) -- -- arthur - [EMAIL PROTECTED] - http://people.debian.org/~adejong --
signature.asc
Description: This is a digitally signed message part
