...

Will it be the same from 5.6 to 6.0 or a full install will be better.

Full installs are always recommended between major versions.

Thank's all for the advise; but is there any easy way to install a newer version while keeping all configuration changes that have been made on a previous one as for 'sendmail', 'sshd.conf','firewalls', etc...

--- Michel Donais

have all your configuration under a change management system, with an at least semi-automated installation procedure, such as kickstart.

I nerver think kikstart was I need. I will check what it is and how it work.

Thank's for the info.

--- Michel Donais

On 04/16/2011 12:18 AM, Devin Reade wrote:

John R Pierce pierce@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.

On 04/16/11 8:32 AM, Les Mikesell wrote:

At least for the rpm-packaged programs in the base and most 3rd party repos, all of the configuration files will be under /etc

one notable exception to that is postgresql, its config files are normally in the postgres data directory, nominally /var/lib/postgresql/data

since its config is quite closely tied to its data files and its datafiles are very version specific, you really need to pg_dumpall the old and restore it to the new.

now, I do note that debian/ubuntu move these conf files to /etc/postgresql/$version/... but we have to mimic upstream

On Fri, Apr 15, 2011 at 07:53:34PM -0700, John R Pierce wrote:

On 04/15/11 7:40 PM, Michel Donais wrote:

...

...

...

Will it be the same from 5.6 to 6.0 or a full install will be better.

Full installs are always recommended between major versions.

Thank's all for the advise; but is there any easy way to install a newer version while keeping all configuration changes that have been made on a previous one as for 'sendmail', 'sshd.conf','firewalls', etc...

have all your configuration under a change management system, [...] ^^^^^^^^^^^^^^^^^^^^^^^^

Any recommendations ?

Regards Przemek

------------------------------------------------------------ Jak zdobyc 2766 zl dofinansowania na obsługe ksiegowa firmy? http://linkint.pl/f2969