I have a situation where a client (administration team within the company) wants to use BSA for configuration management (think puppet). We are deploying compliance content at the moment but that runs into issues.
Here is the example:
In compliance we create a template with a rule. For example, all RHEL6 servers have XXX configuration, all RHEL5 servers have YYY configuration. In this simple world, compliance templates work fine.
Additionally, we need to monitor files on targets and compare them to files in an on-disk repository. Currently the only way to do this is via checksum. However compliance rules do not have the ability to compare the checksum of a file on a target to the checksum of a file 'elsewhere'. Somewhere, this checksum needs to be hard-coded. This mean maintenance every time the master file is updated.
However, in the environment, this compliance rule is not a hard and fast rule. *Some* RHEL6 servers may have setting YYY. We cannot use a compliance exception as the client wishes to monitor this server's configuration as well.
Essentially we need to create 'per server' configuration management. To do this in config templates would require a large number of templates and subsequent components. When we multiply the number of servers X the number of rules X the number of permutations, it becomes essentially unmanageable.
We can't use snapshots/audits as the server will not be compared to itself, nor a master server. Each servers monitored configuration is a mix up of standard settings, configuration files, custom content, etc. The design needs to be fluid where a change in the configuration requirements = a change in monitored content. In other words, if the server changes, we need to know, if the standard changes (such as a master file is updated) we need to know.
Here are a few things I have considered:
1. Create server properties with the various options. For the example above the XXX and YYY values could be configured per server via the property. In this manner the compliance template remains relatively static. This also provides the admin team an easy way to adjust compliance analysis by merely setting the property for a given server / servers.
Unfortunately, this would require creation of an extremely large number of server properties, which we would never be able to get rid of. Over time the operating systems will evolve, new properties will be required and old ones no longer used. They will remain, polluting the namespace.
2. Create some configuration file with the per server setting rules in it. This would, essentially, mimic the properties method above but provide us the ability to add / delete without the problem associated with server property persistence.
Has anybody found a way to do this, or have recommendations?