[SSSD] INI validation design thoughts

Dmitri Pal dpal at redhat.com
Thu Apr 8 12:44:30 UTC 2010


Stephen Gallagher wrote:
> On 04/07/2010 08:10 PM, Dmitri Pal wrote:
> >>   
> > 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.
>
>
> I disagree.
>
> Dmitri, you're missing a fundamental piece of information here. You're
> confusing "configuration files" with "data files".
>
> Configuration files, like the sssd.conf are files that it is expected
> that an admin will need to modify for their environment to function. The
> proper approach is to have configuration files handle values that will
> be site-specific. In RPM terminology, these are config files marked as
> noreplace (in other words, RPM upgrades won't overwrite local changes,
> they will simply drop sssd.conf.rpmnew in place, so an admin can
> manually merge differences if they are necessary, which in most cases
> they won't be).
>
> Data files, on the other hand, are files that by necessity MUST be the
> same for all deployments. A schema file is one such. In order for the
> SSSD to be stable on all deployments, the bare minimum set of options
> must always be reliable. These are the files that RPM upgrades would
> INTENTIONALLY overwrite on an upgrade, to ensure that they were always
> in-sync with the project.
>
> Right now, with the SSSDConfig API, we are already following this
> approach. We have a schema file /etc/sssd.api.conf and a drop-directory,
> sssd.api.d. The sssd.api.conf contains the common options that all
> services and domains must support. The sssd.api.d/ contains separate
> files for all of the internal backends that we support: sssd-local.conf,
> sssd-ldap.conf, sssd-simple.conf, sssd-krb5.conf. Each of these
> subsequent files contains the set of options available for use by that
> particular backend.
>
> In theory, for a v1 approach, we could continue using this exact schema
> format, though it's extremely limited. Right now, it cannot describe the
> proper format of the value, it will only guarantee that it is an
> integral type, string type, or list of [int|str]
>
> I could write a module using libini_config in C to follow this exact
> behavior in about two days, without adding an actual schema validation
> into libini_config, but my real goal here is to come up with a solution
> that can be packaged with libini_config and be available for other
> projects. We can make this a later goal, if time is constrained.
>
> However, I would REALLY like to come up with the complete format now. I
> can write a custom validator JUST for the SSSD, but we need to agree on
> how the format should look.
>
> I think it is very important to get the format down right from the
> start. We can always opt to ignore certain things at first. (For
> example, maybe in the first pass we will ignore the dependency checks,
> but we'll absolutely handle the range/regex checks)
>
> Having a complete format doesn't mandate that the parser has to actually
> implement everything all at once, but it's VERY hard to change the
> format later on.
>
> So at this time, I'm recommending that we solve this format question
> immediately, and defer implementation into the libini_config itself.
>

I would not argue about the "fundamental" things.
I just know how vendors bend the rules if they need to.
IMO it is like building a house of cards in front of Godzilla. :-)
But this is more a philosophical discussion.
We can table it for now.

Defining format - sure. We can and should do it now so that we know
how it would work to avoid problems in future.
But the actual implementation should be deferred or at list done is stages.

But with Jakub's finding should we reconsider XML approach or
the XML approach con's still outweigh the pros?


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