[SSSD] Collapsing LDAP attribute name options into one

Nikolai Kondrashov Nikolai.Kondrashov at redhat.com
Tue Dec 16 21:04:51 UTC 2014


On 12/16/2014 07:58 PM, Simo Sorce wrote:
> 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.

Well, sometimes neater is a way to reduce support costs / questions / bug
reports.

> So we would have to maintain backwards compat.

Yes, we can support old configuration approach for longer, but perhaps
"forever" won't be necessary.

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

Understood. Thank you, Simo.

I'm still not qualified to support this firmly and I'm worried about value
length. Otherwise, I like it.

Nick



More information about the sssd-devel mailing list