[SSSD] INI validation design thoughts

Dmitri Pal dpal at redhat.com
Thu Apr 8 00:10:11 UTC 2010


Jeff Schroeder wrote:
> On Wed, Apr 7, 2010 at 2:48 PM, Dmitri Pal <dpal at redhat.com> wrote:
> ... snip ...
>   
>> I am not arguing against it. I am arguing against it as a v1 requirement.
>> pam.conf, nsswitch.conf are the files that are touched by multiple
>> different components
>> and by admins. So how it is different?
>> Plus the back ends are not possible now and it will be for some time
>> and there will be some time after it till someone would actually start
>> doing
>> a back end.
>> So why this complexity should be supported day one?
>> I think it is right feature but does not need to be delivered now.
>> It can easily be delivered 9 months from now.
>> This is my only point.
>> You know "start small" sort of thing.
>> Do not try to boil an ocean :-)
>> The question of prioritization, that is all.
>>     
>
> The timeline stuff is on you and your team. It isn't necessary in the
> technical discussion about the future. I was just saying you're going
> about it wrong by thinking running grep/sed/whatever nifty shiney tool
> on a schema file is the best way forward.
>
> What tools do you know of that automatically touch the nsswitch.conf?
> If they exist they break Fedora Packaging Policy and general packaging
> best-practices. Sure on fedora/rhel you could say anaconda edits the
> nsswitch.conf at install time or manually when authconfig is ran via
> the admin, but nothing should magically edit the critical system
> configurations. We're talking about something doing this at install
> time completely unattended. If there is a package that edits your
> nsswitch.conf or changes things with augeas in %post it is a bug.
> Thats what *.rpmnew are for. Ditto for the pam config. Nothing should
> magically edit the existing pam config ever. The pam config also seems
> like a perfect example of your software as the functionality for ie:
> an rsa backend is similar to a secureid pam file under /etc/pam.d.
> However, that argument is the opposite of what you're proposing so it
> seems strange why you brought it up.
>
> Something says we might not be comparing apples to apples here. I
> value your input on this but think this conversation might be better
> off restarted when the technical aspects start being implemented.
>
>   
Jeff,  I value your input too.
But for me it is just a non starter even if it is generally a right
thing do in a long run.
I have some time to do some dev work on the project.
I can't commit myself to doing it if I do not see that I can actually do
it in
a reasonable amount of time. This is the constraint on my contributions
to the project.

But back to the technical part of the discussion.
Here is my thinking about the whole file editing situation.
The editing of the files is prohibited by the Fedora guidelines at the
install time.
But did I say anything about the install time?

Would it be fine if an admin comes and manually edits the file?
The answer is yes, this is what admins do.
It can be sssd.conf, pam.conf or any other file. They can edit it
(assuming they know what they are doing).
Ok but if I am a smart admin I will probably create a script to do so.
If I also have some sort of the central  config management solution
I will create a puppet or cfengine module that would do this editing
centrally, right? Have I violated anything? Even if I did this is a
natural thing people do and if it is against any guidelines then the
guidelines
should be considered for a re-review.

So as a third party vendor (and I worked for one for 10 years)
I would just include a puppet module into my solution and say:
* Install this package
* Edit the files this way, here are the scripts an modules that would
help you
to do so.
And this would fly fine with everybody.

So the whole discussion boils down to making things work nicer together
and letting 3rd party vendors to do less work.
Since there are no third party vendors lined up for their life to be
made easier
I come to conclusion that the requirement can be deferred in the first
implementation of the INI validation library and can be added as we
get 3rd party vendors lined up to build the plugins.
 
I agree that there is no sense to continue this discussion.


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/




More information about the sssd-devel mailing list