nss_ldap and openldap on the same server.
jonathan at hst.org.za
Tue Mar 13 09:12:05 UTC 2007
On Tuesday 13 March 2007 10:26, Gerhard Schmidt wrote:
> > It's a well-known problem rather than a bug, and it arises when looking
> > up group information for a user. The system needs a list of all the
> > groups the user is a member of. Since it's a list, not a single answer,
> > you can't short-circuit the process with ``success'' after finding a
> > single result: initgroups(3) must work through all possible sources of
> > group information to build the list.
> I think its still a bug. You are right that all groups should be found so
> the default for groups should be success=continue to have this done. But
> when I explicily specify that on success the process should abort, it
> should be done exacly this way.
You've now had responses from me and Joerg Pulz, and given us essentially the
same reply. I'm not sure success means what you think it means: group
information is a complete list, not ``first item found'' like a user account.
You have told the system to check for group information in files and ldap. You
have, therefore, not succeeded in listing all groups until you have both
searched the files *and* received a response from nss_ldap, either group
information or NSS_STATUS_NOTFOUND.
It looks as though you can instruct nss_ldap to unconditionally return
NSS_STATUS_NOTFOUND for a user, by adding
in nss_ldap.conf. I'd be interested to hear whether it works, having not
tested it myself, but at the moment you're banging your head against the wall
and shouting about how much it hurts. It will hurt less if you stop.
More information about the freebsd-questions