[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