Environmental Configuration Data

Environmental configuration data is data on disk whose content is predominantly influenced by external business, political, procedural, or economic factors, and whose function is critical to security of other data or the operation of the change management tool. Examples include files containing IP addresses, domain names, and other information which, if out of date, will expose data to risk of loss or unwanted disclosure, or break the ability of the tool to work at all. See also the environmental data glossary entry in the ISconf man page.

Environmental data can't be managed the same way as executables. In the case of environmental data, we only want the latest version, but only if post-install interoperability tests pass.

Examples of Environmental Data

For example, we only want the latest version of /etc/gateways, but we first want to take a snapshot of the old file, then replace it with the new one, then do some basic connectivity tests, and if they fail then revert back to the old file. (This "rollback" is only safe to do if we know we can get the original file back verbatim, and if the operation is otherwise idempotent.)

Another example is /etc/is/hmac_keys -- again we only want the latest version, we need to make sure isconf can still "see" its neighbors after we update this file, and if not we revert.

A slightly different case is /etc/aliases -- we only want the latest version, so this is environmental data, but after replacing it we need to also run /usr/bin/newaliases. Again, this only works if running newaliases is idempotent (it is, in this case). While there aren't any post-replacement connectivity tests we need to do, we still want to handle this file in isconf so that we can take advantage of the rollback ability.

The common thread here is that, in each case, we want to be able to replace the file, run a command, test the return code, and if non-zero then revert.

Some configuration files need to be different on otherwise-identical hosts. For example, /etc/ntp.conf might need to be different within a cluster, so that some hosts can be stratum 2, 3, and so on. This case is probably best managed by naming the file e.g. /etc/ntp.conf.$hostname, and then having the rc script select the right one, so for now we aren't going to try to solve this in isconf.

A complex example would be a need to replace several files at the same time, running post-install commands, then a final connectivity test, followed by a revert if needed, but running different post-install commands, perhaps due to differing file layouts.

Possible Approach

A mechanism which covers all of these cases might look something like this (subcommand names likely to change):

isconf begin  # begin transaction
isconf config /etc/gateways  
isconf src /tmp/gateways    # replace /etc/gateways with what's currently in /tmp
isconf test ping 10.2.3.4   # make sure we can still get out
isconf end  # end transaction  (or just use ci?)

XXX describe "global transaction" barrier sync/rollback as in http://mailman.terraluna.org/pipermail/infrastructures/2005-March/001535.html

XXX can we use the above 'config' workflow to manage multiple files in one transaction?

XXX should we try to do more complex rollbacks as isconf subcommands, or bump that up to higher-level 'test' scripts? I think the latter...