[SSSD] DESIGN: Multiple LDAP search bases

Simo Sorce simo at redhat.com
Mon Sep 12 18:23:36 UTC 2011


On Mon, 2011-09-12 at 14:02 -0400, Dmitri Pal wrote:
> On 09/12/2011 01:50 PM, Simo Sorce wrote:
> > On Mon, 2011-09-12 at 11:51 -0400, Dmitri Pal wrote:
> >> On 09/12/2011 11:00 AM, Simo Sorce wrote:
> >>> I do not like this approach, especially if done for a single option
> >>> among many other similar one, it makes the configuration file very odd.
> >>>
> >>> Besides this is for feature parity with nss_ldap and there admins are
> >>> already use to something like ldap_<map>_search_base = a?b?c
> >>> I think we should maintain the convetion (I do not like it too much, but
> >>> it is a convention).
> >>>
> >> This is ugly. I do not like it. And it creates a bad presence of the
> >> unpredictable key names that can't be described in grammar or will make
> >> grammar for validation extremely complex.
> > Key names are not at all unpredicatble. The * or <map> where used just
> > to avoid listing all the key names as there a re a few. But there is no
> > magic, either a specific map related key exist or it does not, we do not
> > pull key names out of the hat.
> >
> > (read: we do not generate ldap_<map>_search_base automatically for any
> > new <map>, it will have to be explicitly listed in our set of valid
> > options to be available).
> >
> > Using sections instead would cause exactly this behavior, as section
> > names are free form.
> >
> >> We have streamlined a lot of things and changed a lot of options to make
> >> them more usable. I do not see why we should follow the old style. It is
> >> a one time operation and creating additional search sections seems
> >> logical to me.
> > Additional sections is simply out of the question imho. We didn't use
> > them for the various providers, it makes even less sense to use a
> > subsection for a specific option of a specific provider.
> >
> > It makes the configuration a lot more heavyweight, and makes parsing out
> > config file by other tools (I am thinking puppet/cfengine kind of
> > parsers) a lot more difficult, and because it is a relatively rare
> > configuration generally will go unnoticed and will be unexpected and
> > will easily break tools when it occurs.
> >
> > It is also very anti-intuitive and would require a lot of verbiage to
> > explain how to use this stuff in the documentation, unnecessarily.
> >
> > As for the syntax, people that want this kind of configurability already
> > are used to this convention as it is widespread in ldap related tools.
> > It is not particularly nice indeed, but it keeps the confiuguration
> > compact in the common cases (ie: when you only want to set different
> > base dn per map, and nothing else.)
> 
> I did not realize that "*" represents a map name like "user" or "group".
> I thought it is some kind of user defined name that we need to parse out
> a recognize.
> This them makes more sense. Then yes I agree, my structured approach
> would be too complex as each map would have to have several subsections.
> 
> So the format is
> ldap_user_search_base=base?scope?filter?base?scope?filter
> 
> And if filter is skipped it will be like this?
> ldap_user_search_base=base?scope??base?scope?filter
> 
> If so I am fine.

Actually ldap_passwd_search_base as the map is called "passwd", but yeah
this is what it would be.

The most common form in use being:

ldap_passwd_search_base = cn=other,cn=subtree,dc=my,dc=suffix

when you only one to set 1 different base, scope and filter can be
omitted, and this is generally what most people need. I think.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list