[SSSD] [DESIGN DISCUSSION] Configuring SSSD

Petr Spacek pspacek at redhat.com
Fri Jun 6 11:33:20 UTC 2014


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

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.

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

-- 
Petr^2 Spacek (FreeIPA developer)



More information about the sssd-devel mailing list