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