[SSSD] INI validation design thoughts

Stephen Gallagher sgallagh at redhat.com
Thu Apr 8 12:08:45 UTC 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAku9x00ACgkQeiVVYja6o6NmwQCdGHEb8Uh0FmMyQhVQcQVT0wGD
BgAAoJEauDKMlsUxgzmPVHjlLZ7wy8mQ
=uNAn
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list