On 04/16/2011 12:18 AM, Devin Reade wrote:
> John R Pierce <firstname.lastname@example.org> wrote:
>> have all your configuration under a change management system, with an at
>> least semi-automated installation procedure, such as kickstart.
> Or have the self discipline to keep a text file (or other record) of
> *all* changes you make to a system as root or other role account.
> I always keep a running log, complete with dates and who makes the
> change, as /root/`hostname`-mods. Trivial operations (that any junior
> sysadmin would be expected to know) get described. Anything more complex
> gets the actual commands entered (minus passwords).
> It's extra work, however not only has it saved my bacon a lot over the
> years in figuring out, after the fact, what caused something to break
> but even more often it has been invaluable in recreating a system or
> quickly implementing similar functions on other systems.
> Yes, this is a form of a change management system, just with little
> overhead. It is also more suited to server environments where each
> one might be slightly different as opposed to (for example) corporate
> workstation environments where you can have a large number of homogeneous
> machines. In that case, there are many other tools more suitable,
> with higher setup costs, but the amortized cost is lower.
I guess this depends on what you need to accomplish.
If I am running the machine, I normally know what it is doing. You can
do some things up front to make it easy to upgrade a machine.
Lets take, as an example, a web server.
You can change ONLY the things that are necessary inside httpd.conf (and
then only remark out things that are in httpd.conf) and instead try to
make all your changes to new config files that you place in
By doing this, it is easy to move your new config files to a new machine
and start with a default httpd.conf on the new server.
Another technique I use is to do a "diff" between a new config file and
the original. Then I can then incorporate the diff into the original on
the other server ... something like this:
diff -uNrp my.conf.orig my.conf > my.conf.diff
if you did not save the unmodified config file before you modified it
(shame on you
) ... then you can just download the applicable RPM and
use the rpm2cpio command to extract the file from the original RPM
(after placing it in a directory by itself) like this:
rpm2cpio mysql-server-5.0.77-4.el5_5.4.x86_64.rpm | cpio -idv
You can then got to <your_directory>/etc/ and get the original my.conf file.
The real issue with upgrades between major branches is that things that
are within a branch (that is, the EL4 branch or the EL5 branch) are
designed to work together for the entire lifetime of that branch by the
upstream provider. They do not release items where you have to make
major changes in the config files, etc. However when moving between
major versions (from EL4 TO EL5 or EL5 to EL6) that is not the case.
There can be (and usually is) major changes required because of the
major bumps in things. For example, mysql-server in EL 4 goes from
mysql-server-4.1.7 in the 4.0 release to mysql-server-4.1.22 currently
in 4.9 ... no major changes. For CentOS-5 it went from
mysql-server-5.0.22 in the 5.0 release to mysql-server-5.0.77 currently
in 5.6, still no major changes. But if you move from mysql-server-4.1.7
to mysql-server-5.0.77 (CentOS-4.0 to CentOS-5.6) then there would
likely be major changes required in the configuration options.
The bottom line is this ... no it will not be "easy" to upgrade between
main branches because there is no ABI or configuration compatibility
between main branches as there is inside a particular branch.
Can you try to "UPGRADE" from 5.x (or even 4.x) to 6.x ... sure. If you
were to type this at the boot screen:
Then it would allow you to try an upgrade. I would never do this to a
machine that I cared about though ... bite the bullet and create a VM or
buy a machine to upgrade into, then once working you can move it back to
the original machine if required.
CentOS mailing list