[SSSD] DESIGN: Multiple LDAP search bases

Dmitri Pal dpal at redhat.com
Mon Sep 12 18:02:40 UTC 2011


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.

>> 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.
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/






More information about the sssd-devel mailing list