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