Correct approach to manage a config file

Archives Ansible Project
1

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.

2

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.

3

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.

4

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.