[SSSD] Collapsing LDAP attribute name options into one

Simo Sorce simo at redhat.com
Tue Dec 16 17:58:07 UTC 2014


On Tue, 16 Dec 2014 17:20:18 +0200
Nikolai Kondrashov <Nikolai.Kondrashov at redhat.com> wrote:

> On 12/16/2014 05:14 PM, Lukas Slebodnik wrote:
> > On (16/12/14 16:32), Nikolai Kondrashov wrote:
> >> On 12/16/2014 03:55 PM, Lukas Slebodnik wrote:
> >>> On (16/12/14 15:49), Nikolai Kondrashov wrote:
> >>>> Hi everyone,
> >>>>
> >>>> Reading the sssd-ldap manpage I was struck by how many of the
> >>>> options deal with setting various LDAP attribute names. This
> >>>> really makes the manpage crowded and hard to navigate.
> >>>>
> >>>> What if we replace all these options with a single option,
> >>>> accepting a list of mappings (e.g. "ldap_attr_map")? We can then
> >>>> put the descriptions and default mappings in a nice table under
> >>>> that single option in the manpage and deprecate the separate
> >>>> options.
> >>>>
> >>> It might be good to see a small example.
> >>> Then it would be easier to choose better solution.
> >>
> >> How about having space or comma-separated pairs, where former
> >> option suffix would be separated from the attribute name by, say,
> >> a colon.
> >>
> >> Like this:
> >>
> >>     ldap_attr_map = user_name:uid user_uid_number:uidNumber
> >> group_name:cn
> >>
> >> I.e. have "ldap_" suffix removed from attribute mapping option
> >> names and the rest used as key in the map.
> > With this change you will break old configuration files. And I'm
> > not sure whether it will worth to maintain old style and new style.
> 
> Well, I thought we should have the typical "deprecation", or
> "transition" period to allow users to move to the new option. So, yes
> configuration would break, but not without warning and a time to
> convert.
> 
> I'm not sure if it's worth it, but I think we shouldn't discount the
> need to add more such mappings and the growing number of options in
> the future.

If there were a good reason sure, but making something neater is not a
good reason to break configuration files, or make it hard to manage
config files on different versions of the various OSs that adopt SSSD.

So we would have to maintain backwards compat.
I am ok to *add* this method if we think we'll need future mappings,
and support the new mappings only through the new method.

> > Should it be implemented in sssd or ding-libs?

Clearly sssd, how would ding-libs know how to deal with older options ?

Simo.


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



More information about the sssd-devel mailing list