# Correct approach to manage a config file

**URL:** <https://forum.ansible.com/t/correct-approach-to-manage-a-config-file/34524>\
**Category:** Ansible Project\
**Created:** [January 27, 2021, 3:48pm UTC](https://forum.ansible.com/t/correct-approach-to-manage-a-config-file/34524 "2021-01-27T15:48:38Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![mimmus](https://avatars.discourse-cdn.com/v4/letter/m/9de053/32.png) [@mimmus](https://forum.ansible.com/u/mimmus)\
**Post date:** [January 27, 2021, 3:48pm UTC](https://forum.ansible.com/t/correct-approach-to-manage-a-config-file/34524/1 "2021-01-27T15:48:38Z")

</div>

Hi,  
I’m a pretty seasoned sysadmin and I’m used to carefully manage config files modifying:

- only minimum needed on main “service.conf” file under /etc (commenting in/out lines, editing values, etc but without upsetting it); preferably, I don’t modify this file at all, but instead…

- adding snippets under /etc/service.d, when possible.

In this way:

- main config file can be overriden during package upgrades, without need of “merging” new file with older one, and I enjoy new options eventually introduced during upgrade.

Now, approaching to Ansible (but question is common to any configuration management system), I see that:

- many create a template for main config file, not respecting original structure and preventing the adding/removal of options, during pkg upgrades

- others, if possible, add lines or snippets,

- others, use search-and-replace or ini-file modules (when suitable)

Could someone with advanced experience in Ansible and “manual” systems management provide me some guidance about correct approach?

Sorry for “philosophical question” and for my bad english.

---

<div class="post-metadata">

**Author:** ![Michael\_Stroder](https://avatars.discourse-cdn.com/v4/letter/m/7ea924/32.png) [@Michael\_Stroder](https://forum.ansible.com/u/Michael_Stroder)\
**Post date:** [January 27, 2021, 4:21pm UTC](https://forum.ansible.com/t/correct-approach-to-manage-a-config-file/34524/2 "2021-01-27T16:21:38Z")

</div>

> Now, approaching to Ansible (but question is common to any configuration  
> management system), I see that:  
> - many create a template for main config file, not respecting original  
> structure and preventing the adding/removal of options, during pkg upgrades  
> - others, if possible, add lines or snippets,  
> - others, use search-and-replace or ini-file modules (when suitable)

Personally I'm member of the  
always-create-whole-config-file-based-on-template camp.

Reasons:

1. I want to always reach a fully well-defined state. If OS package  
default/main configs change I don't care until something's broken.

2. Speaking of package default configs: E.g. I also usually generate  
monolithic configs instead of using the half-baken pseudo config  
management buried in packages' post-install scripts and spread across  
myriads of config snippets (yuck!).

Yes, things can break, e.g. a new software release does not know about  
an obsolete config option anymore. But this can always happen. IMHO  
there's no silver bullet for dealing with change. The usual risk  
mitigation strategies like staging, testing, and monitoring have to be  
applied.

> Sorry for "philosophical question"

I think this question is valid and you will probably see differing opinions.

Ciao, Michael.

---

<div class="post-metadata">

**Author:** ![mimmus](https://avatars.discourse-cdn.com/v4/letter/m/9de053/32.png) [@mimmus](https://forum.ansible.com/u/mimmus)\
**Post date:** [January 27, 2021, 4:38pm UTC](https://forum.ansible.com/t/correct-approach-to-manage-a-config-file/34524/3 "2021-01-27T16:38:53Z")

</div>

Instead I prefer to lean on package defaults:

if an obscure default setting is removed during a package upgrade because a new CVE is discovered, only the package mantainer can know it and I down’t want to be “flagged” as insecure because I hardcoded it in my config template.

In old times, when we used shell script to automatize some tasks, we always used “sed” or “awk” to modify config files inline.

Obviosly, the concept of ‘state’ is right and config files has no breaking changes during the life of a main OS release (for instance, Red Hat has a very conservative approach within a release cycle).

Thanks for your opinion.

---

<div class="post-metadata">

**Author:** ![Michael\_Stroder](https://avatars.discourse-cdn.com/v4/letter/m/7ea924/32.png) [@Michael\_Stroder](https://forum.ansible.com/u/Michael_Stroder)\
**Post date:** [January 27, 2021, 4:47pm UTC](https://forum.ansible.com/t/correct-approach-to-manage-a-config-file/34524/4 "2021-01-27T16:47:28Z")

</div>

I'd argue that if you're the admin of a service you're also responsible  
to fully understand all the config options in effect at any time.

Ciao, Michael.