How do configuration management tools deal with someone messing up configuration files manually?

Question

I'm researching a bunch of configuration management tools, like, Salt, Chef, Puppet, Ansible, etc. and am trying to understand how they deal with someone manually changing a config file on the server directly:

1. A config file that is being directly managed by the CM tool, eg. the nginx/apache/Postgres config file
2. A config file that the system implicitly depends on, but is not being directly managed by the CM tool (i.e. it uses whatever defaults the underlying OS provides), eg. the rsyslog config file.

Do these tools snapshot / checksum all files in /etc (and similar) folders and alert the sysadmin whenever something has been changed behind their backs?

PS: My mental model right now is that of immutable config files & infra, like nix

Answer 1

If the file is marked as being managed by a configuration management tool, it deals with someone messing up a configuration file manually being messed up by a hapless admin by clobbering the configuration file using something like Jinja or ERB templates

While this can often feel frustrating to an old-school UNIX admin when their change is clobbered in minutes or hours by a configuration management tool, (and I have seen some use things like extended file attributes to hack around this) it is far superior in that it 1) enforces a cattle-not-pets mentality and 2) self-documents a deployment - a factor which is vastly undervalued considering that 5-10 years later when an upgrade of a system is needed, hundreds of config files may need to be scoured such as a host file, limits files, logrotate files, syslog files, systemctl defaults files, firewalld/iptables config files, selinux files, cron files, and much, much more may need to be considered using the "pets" deployment philosophy.

9 times out of 10 this comes from a lazyness/unwillingness to learn a newfangled configuration management technology. That being said, I highly recommend that if you are going to manage a config file using a configuration management tool, you use Salt, Chef, Puppet, Ansible, etc to flag the fact that you have taken over management of said config file so that the admin is not completely blindsided whenever possible and as often as possible.

You can also support additive configuration - EG, I have used salt to manage rsyslog.conf and some files in /etc/rsyslog.d/ but not all files. This allows for a baseline set of defaults, while still supporting some customization without (barf) using a configuration management tool - thus allowing you to "have your cake and eat it too".

Answer 2

For Ansible, it does not manage this for you and you have the following options.

Config files that you depend on, but where default are fine you will have to add to your configuration.

Files whose presence interferes you will have to ad a rule: state=absent For example I use Ansible to configure a Lamp server and need to manage a list of deleted sites.

For where you are changing lines in files, you may also need to add lines to remove