[SSSD] [DESIGN DISCUSSION] Configuring SSSD

Dmitri Pal dpal at redhat.com
Fri Jun 6 15:47:18 UTC 2014


On 06/06/2014 07:33 AM, Petr Spacek wrote:
> On 6.6.2014 12:46, Petr Viktorin wrote:
>> On 06/06/2014 04:09 AM, Dmitri Pal wrote:
>>> Hello,
>>>
>>> Over the time multiple tools have been developed and used to address
>>> different use cases around SSSD configuration.
>>> We now have:
>>> 1) SSSD that needs to read a configuration. It uses ding-libs
>>> libini_config for that purpose.
>>> libini_config was historically developed to read configuration from C
>>> services like SSSD.
>>> It is currently used by SSSD and GSS proxy
>>> It is not capable of modifying and saving the configuration. To be fair
>>> it is capable but the interfaces are not exposed at the high level API.
>>> It will take some (couple days or so to close this gap).
>>> 2) SSSD also needed to create sssd.conf at the installation time. It is
>>> ueasy to do it from Python this is why an SSSD config python script 
>>> have
>>> been created. It is good at modifying the configuration and setting
>>> specific values at the beginning of the sssd.conf's life. It is not
>>> suited well (at least yet) for long term maintenance of the
>>> configuration file. It is also SSSD specific.
>>> 3) Over the time there were RFEs that suggested that sssd configuration
>>> should be extensible or overwritable.
>>> The following ticket cover that: 
>>> https://fedorahosted.org/sssd/ticket/2247
>>> The design has been published here
>>> https://fedorahosted.org/sssd/wiki/DesignDocs/ding-libs/INIConfigMerge
>>> 4) There is a desire to manage SSSD over OpenLMI a cockpit in an object
>>> oriented way. To do that (following the standard LMI model) the
>>> following layring has been suggested and implemented:
>>>
>>> Consumer (OpenLMI/Cockpit) -> D-Bus interface -> ifp service 
>>> (responder)
>>> -> augeas c api
>>>
>>> More details are here:
>>> https://fedorahosted.org/sssd/wiki/DesignDocs/OpenLMIProvider
>>>
>>> 5) In the absence of the good configuration solution for the 
>>> integration
>>> purposes, i.e. to integrate applications running on top of the system
>>> with SSSD as a short term solution a puppet-augeas based way of
>>> configuring sssd.conf was introduced the other day. The main
>>> requirements are to be able to modify existing configuration and more
>>> specifically change the values that represent a list of values.
>>>
>>> 6) From the very beginning we were hoping that there would be a way to
>>> be able to define the grammar of the configuration file and check it to
>>> be able to diagnose the config files and prevent their corruption. The
>>> idea was to add this capability to libini as it provides a set of nice
>>> convenience capabilities in comparison to Augeas. Also Augeas until not
>>> long ago was not included in some distors.
>>
>> Could you elaborate on the convenience capabilities? Is it more work to
>> complete libini, or add convenience capabilities to/on top of Augeas?
>> Another factor is how many projects will benefit from SSSD devs 
>> working on
>> libini vs. on Augeas.
> That's the open-source spirit!
>
>>> The list above presents a spectrum of use cases and solution to those
>>> use cases.
>>> The goal of this email is to try to enumerate the use cases and
>>> constraints and understand how the solution for those use cases can be
>>> consolidated and unified and where it makes sense todo and where 
>>> not. It
>>> is a goal to define a reasonable alignment between the technologies and
>>> provide a path forward to a reusable and maintanable stack.
>>>
>>> So we have the needs:
> Let me make one step back. All these requirements can be divided to 
> two main groups:
>
>>> 1) Read config files at run time from C (daemons and D-BUS provider)
>>> 2) Write config files from C (configuration interface over LMI)
>>> 3) Create and modify files at installation and upgade using some simple
>>> mean/API which can be C, python or anything else
> First three requirements can be fulfilled with any general purpose 
> parser/generator. It can be Augeas, libini, or anything else.
>
>>> 4) Be able to manage configuration files in a object oriented manner
>>> with or without D-BUS running
>>> 5) Be able to augment the code file without touching it
>>
>> I don't understand this sentence, could you clarify?
>>
>>> 6) Provide a  way to validate the file
> Points 4) and 6) have to have application-specific implementation 
> because they depends on application-specific knowledge. It is sort of 
> semantic analysis (how valid configuration looks like etc.).
>
> For this reason, this second group of requirements cannot be 
> reasonably implemented inside general-purpose *parser*.
>
> Implementing all those requirements in one library sounds like 
> layering violation (bad design) to me.
>
>
> In my opinion, we should solve these two groups of requirements 
> separately:
> 1) Pick an existing parser (and do not re-invent it).

EWe already have libini and it works pretty well. The is nothing to 
re-invent. It is already there.

> 2) Implement application-specific code on top of it (config validation 
> + any APIs we want).
>
> Having said that, I think it is much better to join group of Augeas 
> users and solve step (1). First step doesn't offer any real value, it 
> is "just a parser". Why should we spend any time on it?

We do not. We already spent the time due to earlier decisions.

>
> Real value is hidden in step (2) - config validation etc. Benefit from 
> selecting Augeas over home-grown solution is that we can re-use 
> existing, already tested code, so we can focus on providing real value.


Same with libini it is already tested and stable code and we are talking 
about the code here on either base so augeas does not have any pluses on 
that front.

>
>>> So I see the following layering
>>>
>>> +------------------+
>>> | High level tools |
>>> +------------------+
>>>       |
>>>      \/
>>> +---------------------------+
>>> | Object oriented interface |
>>> +---------------------------+
>>>       |                    |
>>>       \/                   \/
>>> +-----------------+  +------------------+
>>> | D-BUS responder |  | D-BUS shim layer |
>>> +-----------------+  +------------------+
>>>       |   --------------------|
>>>       |   |
>>>       \/ \/
>>> +-------+              +----------------+
>>> | C API |<-------------| File validator |
>>> +-------+              +----------------+
>>>     /\  \
>>>      |   \               +--------------+
>>>      |    -------------->| Config file  |
>>>      |                   +--------------+
>>>      |                        /\
>>> +----------------+          |
>>> | SSSD/GSS proxy |          |
>>> +----------------+          |
>>>                               |
>>>                      +------------------+
>>>                      | SSSD Coinfig API |
>>>                      +------------------+
>>>                              /\
>>>                              |
>>>                      +--------------+
>>>                      | Simple tools |
>>>                      +--------------+
>>>
>>>
>>> This layout shows three distinct paths towards config file:
>>> 1) Old python API and tools on top (does authconfig use this path?)
>>> 2) Top level D-BUS api and advanced object oriented tools
>>> 3) C API
>>>
>>>
>>> We need to make several decisions at this point:
>>> a) How much we enhance-update-improve existing python API instead of
>>> using new D-BUS interface.
>>> IMO we should leave python API alone for foreseeable future but any new
>>> changes should go via the new D-BUS interface
>>>
>>> b) How we make sure that the D-BUS interface is really usable. It is 
>>> not
>>> that light weight.
>>> Would be nice to be able to have a shim layer for the cases like docker
>>> where there might not be D-BUS or systemd. This however might not be a
>>> problem for us to solve. It might be a generic problem for all LMI 
>>> style
>>> providers. A lot in D-BUS world is autogenerated so I suggest that we
>>> ask to be able to generate a mini D-BUS interface that would go 
>>> directly
>>> from the interface to the logic implemented in responder. I do not know
>>> what is best. But I think it is a discussion to have with D-BUS guys 
>>> and
>>> should be more general.
>>> For now we can assume that D-BUS is there and docker use case will be
>>> solved in some generic way.
>>>
>>> c) If we assume D-BUS and systemd it really makes sense to separate the
>>> responder in charge of configuration from other responders and make it
>>> started on demand when there is a real call over the D-BUS to make a
>>> config change. IMO this work for splitting ifp into data ifp and config
>>> ifp should be filed as a ticket and done as a part of 1.13 release.
>>>
>>> d) What is going to be the low level C library? We have two candidates
>>> libini and augeas.
>>> I definitely have a preference towards libini but this does not mean I
>>> am right. I do not have a lot of time to maintain libini. I do not 
>>> see a
>>> reason to rip it out and replace with augeas yet. But I also do not see
>>> a reason why we should rely on augeas. Right now IMO it would be more
>>> work to rip libini and switch to augeas but over time if we do more and
>>> more augeas work it might be much less. I feel people are more
>>> comfortable with augeas than using libini and adding to it as they 
>>> go. I
>>> do not know why but suspect it is because augeas has appeal of a more
>>> commonly used tool/interface. It is all about what we think is the 
>>> right
>>> path. If we decide that augeas is the way to go then we should not
>>> invest into enhancing libini and start building our improvements in
>>> augeas or around augeas. If we think that libini is the right path
>>> because it fill give us more features, flexibility and control then let
>>> us make it so that I am not the only contributor to it and people would
>>> not have problems throwing patches at it on as needed basis.
>>> For me this is a very important decision. Right now I feel I am on hook
>>> to continue investing my scares time into libini. I think I am holding
>>> people back with this so I would rather come to terms and move forward
>>> whatever we think is best for SSSD, GSS proxy and potential other
>>> daemons that need to read and deal with config files.
>>
>> It seems the SSSD devs here in Red Hat's Brno office don't have the 
>> courage to
>> say this, so let me convey the general idea floating around here: 
>> continuing
>> with libini is a bad idea.
>>
>> We're in the business of collaboration, not writing our own little 
>> libraries
>> where the main advantage is having control over the project.
>> Contributing to Augeas will help many more people than playing in our 
>> own
>> sandbox. And it'll also be better for us -- I don't think libini is 
>> getting
>> Ruby bindings or a big tool ecosystem any time soon.
>> If there is anything missing in Augeas then we should extend Augeas, 
>> instead
>> of trying to make another implementation.
>
> I fully agree.
>

So let me summarize pros and cons:

Pros of libini
- already working and stable parser for INI files
- already integrated with SSSD and GSS proxy
- has advanced convenience features
- can be turn around and delivered very fast because of control

Cons of libini
- zero community
- INI files only
- main developer does not have time to work on it

Pros of augeas
- has parser
- has community
- contributing to it will have general benefit

Cons of augeas
- not integrated into SSSD and GSS proxy
- does not have advanced features (to be verified)
- less control and thus slower turn around


So when I look at it for me it makes perfect sense to continue investing 
into libini to address its cons, i.e. if we contribute to it we will 
foster a community for it.
Then we already leverage the functionality we have, work for greater 
good, do not waste cycles and show leadership. It also allows us to be 
focused on the use cases we really care about.


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.




More information about the sssd-devel mailing list