Home / server / Questions / 821165
In Process
iconoclast
Asked: 2016-12-17 07:41:06 +0800 CST

Do any configuration management systems explicitly support config changes made directly on a server?

  • 772

In general (as far as I can see) the main infrastructure/configuration management systems (Puppet, Chef, Ansible, and SaltStack) are based on the philosophy that your servers are "cattle" and not "pets", and it seems that they can be antagonistic to the idea that you would ever make a configuration change directly to a server.

Although I've worked with Chef and Puppet and Salt, it has always been from the point of view of a developer working with Vagrant to get individual boxes set up for development, so my experience doesn't help answer this question.

The question is: do any of these systems support the use case where you make a change directly to a server, and leave it there for a time without worrying that a local daemon is going to overwrite it with the official configuration? You should be able to make the change (and ideally set the time window during which it is protected from overwriting) without any significant changes to (e.g.) Chef recipes or Salt states. The whole purpose of this use case is to avoid letting a five-minute configuration change be bogged down by corporate friction and the complications of finding the right (e.g.) salt state and making sure there are no side effects and going through the release/deployment cycle and testing to make sure you didn't bork anything in the process.

If you want a more concrete example, suppose you want to adjust your logrotate settings for a number of logs, to balance saving drive space and access to historical data. You have an idea of how much data you'll save at any given setting, and how much data you think you need to keep, but you're not 100% sure. It would be nice to start out just making the change, and seeing (1) anyone complains that they need more historical data for some debugging task, or (2) you're not saving as much drive space as you expected and need to save.

A five-minute change can actually be a five minute change, if your configuration mangagement system allows it to be one, and then once you're positive that you want those changes on all of your boxes that fulfill a particular role, you can letting Chef/Puppet/Salt/Ansible manage that for you.

Note: I'm not asking about a use case where the config management system is not yet managing a certain type of config file, but a case where it is already managing a certain type of config file, but you want to make local changes and have them take precedence on that given machine, and not get overwritten.

Do any of these systems support my use case? (Without requiring me to fight with the system or do backflips to make it work.)

puppet ansible saltstack chef

3 Answers

  1. Config management systems support this use-case by disabling them on the target host for the duration of the change. Using chef as an example, you would disable chef-client on the node. This would cause the node to show up as 'stale' in the Chef server, but that is a helpful reminder that the node is out of compliance and that the change should either be rolled forward or rolled back.

    For individual files you could do a chattr +i, which no tool I've seen knows how to bypass.

    One extra thought for chef -- for file templates, where the file did not exist prior to the original chef run, you can tell chef to :create_if_missing such that it will only touch the file once.

    • 4

  2. You didn't mention PowerShell DSC, but I'll throw a couple methods out for that - particularly as PowerShell is coming to other systems than Windows. Some of these methods may have equivalents in the other options.

    I can think of four methods of handling your case with DSC:

    1. If you change something not tested by any of the resources, it'll simply never get caught. I expect this applies to other recipe based choices as well.
    2. Set the LCM to Apply and Monitor, then make your change by any means you want. You can test whether your system is still in compliance, but it won't attempt to fix it.

    The following choices have an advantage of making your change "part of the recipe" and recreatable.

    1. Deploy your system with an explicit set up of partial configurations where your "extra" settings aren't initially published but can be added later. This assumes that any setting you plan to "temporarily" set isn't in conflict with a setting in another configuration. This actually gives you the opportunity to make your change "part of the recipe" without needing to completely regenerate the configuration.
    2. Publish an entirely new configuration incorporating your change, and start the configuration. Like the previous option, the configuration will idempotently apply (only new changes are made without affecting anything previously set.)

    Regardless of whether you use DSC push or pull models, you can make these changes for a single machine or multiple.

    • 2

  3. Disregarding for the moment the possible incongruity of the concept of both managing the configuration of a system from a CM system and not doing it at the same time that commenters have already noted...

    It should be mentioned that for this use case it's usually possible to make use of what has become a convention with modern-day server software - .d configuration directories which allow insertion of extra config snippets in the right places.

    That way you may be able to have your CM manage the config for you via e.g. /etc/logrotate.d/local-whatever, while at the same time you're still able to fiddle with a particular machine by adding /etc/logrotate.d/local-aaa-whatever or similar, which would then cause the software to process your overridden settings.

    Obviously if CM has recipes that aim to control the entirety of /etc/logrotate.d/ you still have no recourse other than to do things within CM.

    • 0