1

When managing the state of a server using a configuration management tool (e.g. salt, puppet, ansible), one can quite easily develop 'unmanaged' state through application of successive versions of the configuration. For example, one could go through the following steps:

  1. Apply a configuration that creates the file /etc/a
  2. Edit the configuration so that it no longer creates the file /etc/a, or references it.
  3. Apply the new configuration.

This means that the file /etc/a remains hanging-around on the server. My instinct is that a truly declarative tool should delete the file in step 3, but my experience is that the tools do not. This seems like it could be dangerous -- for example if the file is in /etc/ssh/ssh_config.d.

How can one avoid this sort of state appearing, or indeed even detect that it is present?

Rob Gilton
  • 111
  • 1
  • The obvious first problem is: how do you know if it's unmanaged? – Michael Hampton Nov 28 '20 at 20:23
  • Well, I assume that there should be some kind of way of declaring this to the configuration management system. For example by listing the set of system packages that one wants installed, along with the rest of the target system state. – Rob Gilton Nov 29 '20 at 16:43
  • Your CMS can help with this, by specifying which files to remove, or including configuration to ignore for example all but certain files in ssh_config.d. But in general, it's a hard problem to specify everything that *should not* exist on a host. – Andrew Schulman Dec 12 '20 at 11:14

0 Answers0