[SSSD] DESIGN: Multiple LDAP search bases

Simo Sorce simo at redhat.com
Mon Sep 12 17:50:03 UTC 2011


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 would suggest presenting the two options to the user community on
> FreeIPA list and asking for their opinion.  

The FreeIPA community would rarely needs these options due to the fact
the ipa provider self-configures all of this stuff. So not sure that the
results would be relevant. But I have no objection about getting more
input.

Simo.

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




More information about the sssd-devel mailing list