Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I use a configuration management system and, as I believe is common, my CM software simply copy-pastes configuration files to deploy them to my Linux servers, blindly clobbering whatever's there. But for the most part, my config files should just be simple changes or tweaks to the "base" config files that are provided by the underlying Linux distro.

Whenever the "base" config files change - perhaps the OS package manager wants to push out updated config files with more secure defaults, perhaps we're installing a new version of Ubuntu on some new hosts - we have to go through the config files to verify that they haven't changed or that we're not clobbering anything we want to keep/update our templates with, and if so "re-apply" our changes on top of the new version.

In git terms: this is akin to rebasing your own changes onto a shifting upstream master.

Simple patch can get us some distance but it does not track the common ancestry shared between upstream changes and our changes, so it does not have as robust rebasing logic, AFAICT, as well as more noisy warnings of shifting line numbers etc.

Are there any tools or CM software that manages configuration files in this manner?

share|improve this question

1 Answer 1

Puppet with augeas can do what you want, though I question the value of not simply managing the whole configuration file, possibly using a template.

I'd hope that you test upgrades in a lab environment and, if needed, modify the templated configfiles. You will need to test things anyway, even when using augeas, as whatever it does can become just as invalid as a fully templated configfile.

share|improve this answer
1  
augueas doesn't seem to track file ancestry / manage patches, does it? Even if I manage the whole config file, I'd like to ensure I'm replacing something I expect to be replacing, and that the file I'm overwriting hasn't completely changed. It can be little things like more secure defaults, which are not things we necessarily currently test for since they may take advantage of newly introduced features in the upstream software versions. –  Yang Apr 12 '13 at 23:51
    
As I said: testing is the important part there, not how you manage your customizations. –  Dennis Kaarsemaker Apr 13 '13 at 8:50

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.