<p>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 <a href="https://en.wikipedia.org/wiki/Jinja_(template_engine)" rel="nofollow noreferrer">Jinja</a> or <a href="https://puppet.com/docs/puppet/5.3/lang_template_erb.html" rel="nofollow noreferrer">ERB templates</a></p>

<p>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 <a href="https://wiki.archlinux.org/index.php/File_permissions_and_attributes#Extended_attributes" rel="nofollow noreferrer">extended file attributes to hack around this</a>) it is far superior in that it 1) enforces a <a href="https://devops.stackexchange.com/questions/653/what-is-the-definition-of-cattle-not-pets">cattle-not-pets</a> 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.</p>

<p>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.</p>

<p>You can also support additive configuration - EG, I have used salt to manage rsyslog.conf and <em>some</em> 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 <a href="https://en.wikipedia.org/wiki/You_can%27t_have_your_cake_and_eat_it" rel="nofollow noreferrer">"have your cake and eat it too"</a>.</p>

CC BY-SA 4.0
2018-12-31T03:18:33.603Z
2018-12-31T03:25:25.333Z
2018-12-31T03:25:25.333Z
James Shewey
<p>For Ansible, it does not manage this for you and you have the following options.</p>

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

<p>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.</p>

<p>For where you are changing lines in files, you may also need to add lines to remove </p>

CC BY-SA 4.0
2018-12-30T21:43:31.847Z
2018-12-30T21:43:31.847Z
jdog
<p>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:</p>

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

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

<p>PS: My mental model right now is that of immutable config files &amp; infra, like <code>nix</code></p>

<configuration-management>
How do configuration management tools deal with someone messing up configuration files manually?
Saurabh Nanda
# How do configuration management tools deal with someone messing up configuration files manually?

(Asked by: username_0 on 2018-12-30)

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`

**Tags:** configuration-management


---

## 2 answers

### Answer by username_1 on 2018-12-31. Score: 4

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](https://en.wikipedia.org/wiki/Jinja_(template_engine)) or [ERB templates](https://puppet.com/docs/puppet/5.3/lang_template_erb.html)

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](https://wiki.archlinux.org/index.php/File_permissions_and_attributes#Extended_attributes)) it is far superior in that it 1) enforces a [cattle-not-pets](https://devops.stackexchange.com/questions/653/what-is-the-definition-of-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"](https://en.wikipedia.org/wiki/You_can%27t_have_your_cake_and_eat_it).


---

### Answer by username_2 on 2018-12-30. Score: 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


---

