[SSSD] INI validation design thoughts

Stephen Gallagher sgallagh at redhat.com
Thu Apr 8 13:27:41 UTC 2010


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

On 04/08/2010 08:44 AM, Dmitri Pal wrote:
> 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?
> 

The more I have been thinking about it, the more I think that XML would
be a bad idea for the schema. It's a difficult format to use correctly,
and I think it would introduce more headaches than it solves.



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

iEYEARECAAYFAku92cwACgkQeiVVYja6o6NwDgCglrDOdXp5P2Jv5P4YCPmNfO40
qtQAn2pFTz5wZHTXH7hLU8jHE6GBEOsg
=JUoc
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list