FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 04-15-2011, 03:03 AM
"Michel Donais"
 
Default cents 5.6 ..... futur

To pass from Centos 5.5 to 5.6 it was easy as an
upgrade.
*
Will it be the same from 5.6 to 6.0 or a full
install will be better.
*
---
Michel Donais
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-15-2011, 06:19 AM
Eero Volotinen
 
Default cents 5.6 ..... futur

2011/4/15 Michel Donais <donais@telupton.com>:
> To pass from Centos 5.5 to 5.6 it was easy as an upgrade.
>
> Will it be the same from 5.6 to 6.0 or a full install will be better.

well, usually upgrading major version is not easy or preferred method.
use full install instead.

--
Eero
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-15-2011, 06:41 AM
Barry Brimer
 
Default cents 5.6 ..... futur

> 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.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-15-2011, 08:36 AM
Ljubomir Ljubojevic
 
Default cents 5.6 ..... futur

Michel Donais wrote:
> To pass from Centos 5.5 to 5.6 it was easy as an upgrade.
>
> Will it be the same from 5.6 to 6.0 or a full install will be better.
>
> ---
There is so big difference between them (base packages, package and
system design, dependencies) that full install will be necessary, not
only recommended. I think upgrade might be even impossible.

Ljubomir
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-16-2011, 02:40 AM
"Michel Donais"
 
Default cents 5.6 ..... futur

>> 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

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-16-2011, 02:53 AM
John R Pierce
 
Default cents 5.6 ..... futur

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, with an at
least semi-automated installation procedure, such as kickstart.


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-16-2011, 04:20 AM
"Michel Donais"
 
Default cents 5.6 ..... futur

> 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


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-16-2011, 05:18 AM
Devin Reade
 
Default cents 5.6 ..... futur

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.

Devin
--
When I was little, my grandfather used to make me stand in a closet for
five minutes without moving. He said it was elevator practice.
- Stephen Wright

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-16-2011, 01:31 PM
Johnny Hughes
 
Default cents 5.6 ..... futur

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 ) ... 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.


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-16-2011, 03:32 PM
Les Mikesell
 
Default cents 5.6 ..... futur

On 4/16/11 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.

This is all good advice, but you really should be able to figure things out if
you know what services the old system was running and you have a backup of your
old /etc directory. At least for the rpm-packaged programs in the base and most
3rd party repos, all of the configuration files will be under /etc, and most
will have the part where you make local changes abstracted out into a file under
/etc/sysconfig. Having a better change management system would let you diff
your current files against the original distribution copies to easily see the
specific changes you made. This may be a little harder if there are big changes
in the distribution versions but still not impossible to figure out.

If you have compiled anything yourself it probably installed under /usr/local
and you are on your own at reproducing that, but if it is old enough to forget
you probably want to see if RPM packaged versions are available now that would
be easier to maintain.

--
Les Mikesell
lesmikesell@gmail.com




_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 06:41 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org