-----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----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
