Alva Couch wrote:

This dismisses an important kind of validation, sanity checks, which
can occur *without* declaring policies in advance. E.g., are your
settings reasonable? Do your mx records point to mail servers? Do your
filesystem mounts point at fileservers? Etc. This kind of tool could be
used by anyone, but we are too busy solving our own problems to provide
something "practical" for people with less expertise than us, that might
not be "practical" for us because we need more functionality than that.

You have two choices in how to implement such a tool: Integrate it with whatever is generating your configurations, or have it check the live system configurations.

If you integrate it with the configuration generator, then you've got to have a tight semantic bond between the validator and the generator (i.e., it's not enough that the box be a mail server, it must specifically listen for smtp requests on the port we plan on using); this means that the generator has to have clear semantics here and then have hooks for some other tool to use them.

Yes, you could specifically add this functionality to a given tool, but could you create it as a generic component that could be added to any tool? Could you see a single validator that could work with Puppet, cfengine, and BCFG2?

I expect Puppet's semantics aren't clear enough right now that you could do this, although I don't know much about the validation research, so I could easily be wrong.

If you check the system state itself, then you have to deal with heterogeneity -- am I using Postfix, exim, or sendmail? Where's the config file? What format is it? Is the smtp server set in multiple places (e.g., a java app somewhere)? This is even worse, in my opinion, because your tool is doomed to only have limited coverage and it will never work for custom apps.

I never did give anybody hell. I just told the truth, and they thought
it was hell.       -- Harry S Truman
Luke Kanies | |

lssconf-discuss mailing list

Reply via email to