[SSSD] DESIGN: Multiple LDAP search bases

Stephen Gallagher sgallagh at redhat.com
Mon Sep 12 18:33:35 UTC 2011


On Mon, 2011-09-12 at 14:23 -0400, Simo Sorce wrote:
> 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.


Actually, Dmitri was right with 'ldap_user_search_base', since this is
the option we currently have. But Simo is correct that for
backwards-compatibility it needs to reduce to:

ldap_user_search_base = cn=Users,cn=Accounts,dc=my,dc=suffix
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20110912/a67c6241/attachment.sig>


More information about the sssd-devel mailing list