[SSSD] INI validation design thoughts

Jeff Schroeder jeffschroeder at computer.org
Wed Apr 7 22:23:42 UTC 2010


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 Schroeder

Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com



More information about the sssd-devel mailing list