Managing configuration file changes during RHEL release updates

Associate
Joined
12 Oct 2005
Posts
1,511
Location
Surrey
How do you manage configuration changes during your RHEL upgrades? I have only had to upgrade individual systems on an ad-hoc basis in the past and have simply searched for *.rpmnew files to ascertain if there are any important changes.

How would you go about managing these upgrades for larger environments (e.g. 20 servers from 5.2 -> 5.4) ? I am unable to go for configuration management tools like puppet that install agents on the servers.
 
In a larger environment you would normally install the patches onto a subset of test systems first.

You can then look at the list of patches which have been installed along with the .rpmnew files generated and decide on the impact the changes may have when rolling across the larger estate. A large number of systems normally means that you have multiple systems doing the same tasks which have been configured in a standard way so decisions don't have to be made on an individual host basis.

You may well decide that no changes are necessary and keep with your existing configuration files in most cases.
 
I just do a diff between blabla.conf.rpmnew and blabla.conf to see if there are any big changes.

This is what I do currently.

We will be rolling it through a testbox -> test environment -> onwards, I was just wondering if there was something a bit more elegant.

I might look into writing something to help analyse changes - fingers crossed the Squid conf file hasn't changed much.
 
Also keep in mind that Red Hat are typically very conservative when it comes to this stuff - they actively try to avoid a massive change in config file behaviour (even so far as to implement some sort of legacy options). This comes straight from the horses mouth so to speak :)
 
Back
Top Bottom