[SSSD] [PATCH] sss_config: alter configuration file

Pavel Březina pbrezina at redhat.com
Thu Apr 24 09:02:54 UTC 2014


On 04/23/2014 09:32 PM, Dmitri Pal wrote:
> On 04/22/2014 04:29 AM, Pavel Březina wrote:
>> Hi,
>> I'm sending some patches that I'll use for OpenLMI provider. It
>> supports few modifications of sssd.conf through augeas.
>>
>> For the moment, I think we should not bound to any particular API so
>> even though I made it a separate object, I don't have any intentions
>> to make it publicly usable library.
>>
>> This code will be used from D-Bus responder. I may extend the API if
>> needed.

I'm moving the discussion to internal list, since I will provide links 
to our internal mailing list.

Hi Dmitry,

> I have a conceptual problem with this approach. Sorry to throw the
> wrench when a lot of work has been done. But I have not seen this
> coming. I read there thesis and there was nothing about augeas there,
> actually there was nothing about the architecture of the actual
> management at all. That was one of the parts of my feedback.

Architecture was mentioned several times, although there wasn't much 
discussion about it.
OpenLMI provider will only communicate with D-Bus responder which will 
provide data and tools to alter configuration.

I will write implementation chapter this weekend.

> So why augeas?

There maybe wasn't a formal decision (not on mailing list anyway, it was 
discussed a lot amongst Brno folks), however I got the idea of using 
augeas directly from you. So why do you fight against it now?

See:
http://post-office.corp.redhat.com/archives/rhel-sysmgt/2013-September/msg00088.html 
point d

http://post-office.corp.redhat.com/archives/ipa-and-samba-team-list/2012-December/msg00071.html

> I thought that we will use the python API instead of doing it in C. That
> was the whole reason why i have not added this same capability to
> manipulate the configuration and save it.

OpenLMI provider is in C, D-Bus responder is in C, thus C API is 
required here.

> In general I think that if we want to do changes in C we should stick to
> libini_config and use it to make the modifications.
> I see several reasons for that approach:
> * we want one place to merge files and make modifications, if there are
> two unrelated pieces of code that do that we will have problems. We
> already have two we actually adding third: python, ding-libs merge code
> and now augeas

I'm sorry but:
* I don't want to call Python code from C.
* Ding-libs doesn't provide needed functionality.
* Augeas contains sssd lenses, make sure the syntax is correct and 
supports config modification in a way that it does not alter its 
formatting. For free.

> * we want to rely on the syntax checking in future. When this part is
> added you can not only validate the data coming from the config file but
> would also prevent modifications that can potentially lead to
> misconfiguration because you are sticking a logical value instead of
> string or number and vice verse.

Augeas makes sure the syntax is correct. The API I created makes sure 
the types will be correct. Besides it's not supposed to be publicly 
available API at the moment.

> So I am strongly against bringing augeas without a higher level strategy
> here. I can see bringing augeas only if we try to consolidate on it in
> the long run but I am not sure it is the idea due to the two points above.

> I would say that adding the functionality to ding-libs is pretty
> trivial. I can tun around a patch pretty quickly if we decide to do it
> this way.
> Something to discuss first though...

If you will provide this functionality till Monday I can go this way. Or 
if you will give me some guidance so I can implement it by my own. 
Otherwise I'm risking that I won't finish the thesis in time.

My alternative is to bring the augeas dependency to OpenLMI side, if you 
strictly don't want to have it on SSSD side. Or parse the configuration 
by myself - since there are not lots of changes I need to do, it would 
be simple. But both ways are stupid IMHO.

Best regards,
Pavel.




More information about the sssd-devel mailing list