On 04/16/2011 12:18 AM, Devin Reade wrote: > John R Pierce <pierce at hogranch.com> 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 /etc/httpd/conf.d/ 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 :D) ... 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: linux upgradeany 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 253 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20110416/e393fe5c/attachment-0005.sig>