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 02-07-2012, 05:04 AM
Mihamina Rakotomandimby
 
Default about major version upgrades

Hi all,

In http://goo.gl/Krjfh I read:

+++++++++++++++++++++++
Upgrading from CentOS-4 or CentOS-5:
We recommend everyone run through a reinstall rather than attempt an
inplace upgrade from CentOS-4 or CentOS-5
+++++++++++++++++++++++

Do you ever now if that advice will be up to date for the 6 to 7 upgrade?

What is the preferred upgrade process if some want to upgrade inplace?
I mostly run virtual guest in a one-VM-per-service (MySQL, php, Mail,
DNS, NFS/SMB) basis, with a main + spare physical machine.

I'm installing 6.2 on our dev servers and try to pre-evaluate the amount
of work when 7 will be released.

--
RMA.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-07-2012, 11:39 AM
Ljubomir Ljubojevic
 
Default about major version upgrades

On 02/07/2012 07:04 AM, Mihamina Rakotomandimby wrote:
> Hi all,
>
> In http://goo.gl/Krjfh I read:
>
> +++++++++++++++++++++++
> Upgrading from CentOS-4 or CentOS-5:
> We recommend everyone run through a reinstall rather than attempt an
> inplace upgrade from CentOS-4 or CentOS-5
> +++++++++++++++++++++++
>
> Do you ever now if that advice will be up to date for the 6 to 7 upgrade?
>
> What is the preferred upgrade process if some want to upgrade inplace?
> I mostly run virtual guest in a one-VM-per-service (MySQL, php, Mail,
> DNS, NFS/SMB) basis, with a main + spare physical machine.
>
> I'm installing 6.2 on our dev servers and try to pre-evaluate the amount
> of work when 7 will be released.
>

6.x will be supported until 2020. Reinstalling once in 10 years should
not be the problem.

Reinstall is ALWAYS advised, since probably many packages will be either
depreciated or heavily changed in version 7.0.

That being said, there will always be unsupported way to upgrade from
one version to the next.

It is Your choice in the end.


--

Ljubomir Ljubojevic
(Love is in the Air)
PL Computers
Serbia, Europe

Google is the Mother, Google is the Father, and traceroute is your
trusty Spiderman...
StarOS, Mikrotik and CentOS/RHEL/Linux consultant
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-07-2012, 11:58 AM
Johnny Hughes
 
Default about major version upgrades

On 02/07/2012 06:39 AM, Ljubomir Ljubojevic wrote:
> On 02/07/2012 07:04 AM, Mihamina Rakotomandimby wrote:
>> Hi all,
>>
>> In http://goo.gl/Krjfh I read:
>>
>> +++++++++++++++++++++++
>> Upgrading from CentOS-4 or CentOS-5:
>> We recommend everyone run through a reinstall rather than attempt an
>> inplace upgrade from CentOS-4 or CentOS-5
>> +++++++++++++++++++++++
>>
>> Do you ever now if that advice will be up to date for the 6 to 7 upgrade?
>>
>> What is the preferred upgrade process if some want to upgrade inplace?
>> I mostly run virtual guest in a one-VM-per-service (MySQL, php, Mail,
>> DNS, NFS/SMB) basis, with a main + spare physical machine.
>>
>> I'm installing 6.2 on our dev servers and try to pre-evaluate the amount
>> of work when 7 will be released.
>>
> 6.x will be supported until 2020. Reinstalling once in 10 years should
> not be the problem.
>
> Reinstall is ALWAYS advised, since probably many packages will be either
> depreciated or heavily changed in version 7.0.
>
> That being said, there will always be unsupported way to upgrade from
> one version to the next.
>
> It is Your choice in the end.
>
>

It is also a MAJORLY big deal to move from one major version to another
(ie a move from CentOS-5.x to CentOS-6.x). This is because there is no
API/ABI compatibility between major versions like there is for minor
versions.

The php is going to be much newer, the samba is going to me much newer,
the httpd is going to be much newer, the kernel is going to much newer,
ldap is going to much newer, etc.

For example, I recently upgraded a CentOS-4 box to CentOS-5 and I went
from the CentOS-4 php to a CentOS-5 version ... I had to re-code my
applications written for the php-4.3.9 in CentOS-4 to instead work with
the php-5.1.6 in CentOS-5. I had to rework all the mod_auth files from
httpd-2.0.x to work with mod_authz from httpd-2.2.x ... etc.

The purpose for having enterprise software is so that you can get a
return on your investment and use your code for 7 years (for CentOS
versions before CentOS-4 ... now 10 years in post CentOS-5). But
keeping things for that period of time means that when you do need to
upgrade, the "differences" are much harder and the changes are usually
much bigger for a given package.

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-07-2012, 02:07 PM
Ross Walker
 
Default about major version upgrades

On Feb 7, 2012, at 7:58 AM, Johnny Hughes <johnny@centos.org> wrote:

> The purpose for having enterprise software is so that you can get a
> return on your investment and use your code for 7 years (for CentOS
> versions before CentOS-4 ... now 10 years in post CentOS-5). But
> keeping things for that period of time means that when you do need to
> upgrade, the "differences" are much harder and the changes are usually
> much bigger for a given package.

For this reason it is often better to upgrade more frequently then every 7-10 years. Personally I have a 5 year max lifetime for my systems. Even then upgrades are painful and we try to stagger these so they all aren't due to upgrade at once.

-Ross

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-07-2012, 03:02 PM
Craig White
 
Default about major version upgrades

On Feb 7, 2012, at 8:07 AM, Ross Walker wrote:

> On Feb 7, 2012, at 7:58 AM, Johnny Hughes <johnny@centos.org> wrote:
>
>> The purpose for having enterprise software is so that you can get a
>> return on your investment and use your code for 7 years (for CentOS
>> versions before CentOS-4 ... now 10 years in post CentOS-5). But
>> keeping things for that period of time means that when you do need to
>> upgrade, the "differences" are much harder and the changes are usually
>> much bigger for a given package.
>
> For this reason it is often better to upgrade more frequently then every 7-10 years. Personally I have a 5 year max lifetime for my systems. Even then upgrades are painful and we try to stagger these so they all aren't due to upgrade at once.
----
if you think about it, perhaps you are making the case for using a configuration management system like puppet where the configuration details are more or less abstracted from the underlying OS itself. Thus once running (and I'm not suggesting that it is a simple task), migrating servers from CentOS 5.x to 6.x or perhaps to Debian or Ubuntu becomes a relatively simple task as the configuration details come from the puppet server.

This becomes more evident when you stop looking at a server being a single OS install on a single box and start running virtualized servers.

Craig
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-07-2012, 04:38 PM
Les Mikesell
 
Default about major version upgrades

On Tue, Feb 7, 2012 at 10:02 AM, Craig White <craig.white@ttiltd.com> wrote:
>
>> For this reason it is often better to upgrade more frequently then every 7-10 years. Personally I have a 5 year max lifetime for my systems. Even then upgrades are painful and we try to stagger these so they all aren't due to upgrade at once.
> ----
> if you think about it, perhaps you are making the case for using a configuration management system like puppet where the configuration details are more or less abstracted from the underlying OS itself. Thus once running (and I'm not suggesting that it is a simple task), migrating servers from CentOS 5.x to 6.x or perhaps to Debian or Ubuntu becomes a relatively simple task as the configuration details come from the puppet server.

If it is possible to abstract the differences, perhaps you aren't
using all the new features and didn't have to upgrade after all...

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-07-2012, 06:11 PM
Craig White
 
Default about major version upgrades

On Feb 7, 2012, at 10:38 AM, Les Mikesell wrote:

> On Tue, Feb 7, 2012 at 10:02 AM, Craig White <craig.white@ttiltd.com> wrote:
>>
>>> For this reason it is often better to upgrade more frequently then every 7-10 years. Personally I have a 5 year max lifetime for my systems. Even then upgrades are painful and we try to stagger these so they all aren't due to upgrade at once.
>> ----
>> if you think about it, perhaps you are making the case for using a configuration management system like puppet where the configuration details are more or less abstracted from the underlying OS itself. Thus once running (and I'm not suggesting that it is a simple task), migrating servers from CentOS 5.x to 6.x or perhaps to Debian or Ubuntu becomes a relatively simple task as the configuration details come from the puppet server.
>
> If it is possible to abstract the differences, perhaps you aren't
> using all the new features and didn't have to upgrade after all...
----
I suppose that if you believe that, then you are suffering from a lack of imagination. I can deploy LDAP authentication setups to either Ubuntu or CentOS with the various pam, nss, padl files which are vastly different in no time.

some of the differences can be accounted for from within puppet itself but others - and I'm talking about actual config files - the differences can be handled from within the templated config files which have enough business logic to change the output to various needs or simply use different templates altogether.

Of course there is an investment to get to this stage and if you've only got a handful of servers to upgrade, it may not be worth it but there is the satisfaction of knowing the configuration files are ensured to be what you intended them to be - to the point of if someone makes changes by hand, they are automatically changed back.

I'm only expressing the notion that it is entirely possible to get beyond the paradigm of locked in server installs on iron that takes a lot of effort to maintain (ie, update/upgrade X number_of_servers). There are some very sophisticated configuration management system, chef looked good, I chose to go with puppet and I've been very pleased with the depth and scope of puppet.

Craig
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-07-2012, 06:38 PM
Les Mikesell
 
Default about major version upgrades

On Tue, Feb 7, 2012 at 1:11 PM, Craig White <craig.white@ttiltd.com> wrote:
>
>>
>> If it is possible to abstract the differences, perhaps you aren't
>> using all the new features and didn't have to upgrade after all...
> ----
> I suppose that if you believe that, then you are suffering from a lack of imagination. I can deploy LDAP authentication setups to either Ubuntu or CentOS with the various pam, nss, padl files which are vastly different in no time.

How well does it handle windows?

> I'm only expressing the notion that it is entirely possible to get beyond the paradigm of locked in server installs on iron that takes a lot of effort to maintain (ie, update/upgrade X number_of_servers). There are some very sophisticated configuration management system, chef looked good, I chose to go with puppet and I've been very pleased with the depth and scope of puppet.

I'm actually very interested in this, but puppet did not look like the
right architecture. http://saltstack.org/ might not be quite ready
for prime time but it looks like a very reasonable design. The python
dependencies are probably going going to be painful for cross platform
installs but at least someone on its mail list has it working on
windows and there are already epel packages.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-07-2012, 07:36 PM
Craig White
 
Default about major version upgrades

On Feb 7, 2012, at 12:38 PM, Les Mikesell wrote:

> On Tue, Feb 7, 2012 at 1:11 PM, Craig White <craig.white@ttiltd.com> wrote:
>>
>>>
>>> If it is possible to abstract the differences, perhaps you aren't
>>> using all the new features and didn't have to upgrade after all...
>> ----
>> I suppose that if you believe that, then you are suffering from a lack of imagination. I can deploy LDAP authentication setups to either Ubuntu or CentOS with the various pam, nss, padl files which are vastly different in no time.
>
> How well does it handle windows?
----
I haven't tried but I gather that at this stage, only a subset of features are working on Windows at this point. It does seem that they are committed to the platform though and have been adding features with each release.
----
>
>> I'm only expressing the notion that it is entirely possible to get beyond the paradigm of locked in server installs on iron that takes a lot of effort to maintain (ie, update/upgrade X number_of_servers). There are some very sophisticated configuration management system, chef looked good, I chose to go with puppet and I've been very pleased with the depth and scope of puppet.
>
> I'm actually very interested in this, but puppet did not look like the
> right architecture. http://saltstack.org/ might not be quite ready
> for prime time but it looks like a very reasonable design. The python
> dependencies are probably going going to be painful for cross platform
> installs but at least someone on its mail list has it working on
> windows and there are already epel packages.
----
a different type of management system. Puppet & Chef are simply about configuration management.

Puppet architecture is pretty awesome - but the puppet master itself can't be a stock CentOS 5.x system because ruby 1.8.5 is too ancient. I suppose you can use Karanbir's ruby-1.8.7 packages (or better yet, enterprise ruby packages) if you insist on running the server on CentOS 5.x. The thing about puppet is that the barrier to entry is rather high - it takes some time before you get to something useful whereas Chef is more adept at putting other people's recipes into service fairly quickly. Then again, you will run into barriers with Chef that don't exist with puppet so it seemed that the ramp up investment had long term benefits.

Craig
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 02-07-2012, 08:00 PM
Les Mikesell
 
Default about major version upgrades

On Tue, Feb 7, 2012 at 2:36 PM, Craig White <craig.white@ttiltd.com> wrote:
>
>>
>> I'm actually very interested in this, but puppet did not look like the
>> right architecture. * http://saltstack.org/ might not be quite ready
>> for prime time but it looks like a very reasonable design. *The python
>> dependencies are probably going going to be painful for cross platform
>> installs but at least someone on its mail list has it working on
>> windows and there are already epel packages.
> ----
> a different type of management system. Puppet & Chef are simply about configuration management.

So is salt, but scalable, and with the ability to make decisions based
on client state in more or less real time. And even though it is
mostly or all python now, it really passes around data structures that
should allow other languages to be used. It is still in early stages
but they claim to have converted some puppet installs easily.

> Puppet architecture is pretty awesome - but the puppet master itself can't be a stock CentOS 5.x system because ruby 1.8.5 is too ancient. I suppose you can use Karanbir's ruby-1.8.7 packages (or better yet, enterprise ruby packages) if you insist on running the server on CentOS 5.x. The thing about puppet is that the barrier to entry is rather high - it takes some time before you get to something useful whereas Chef is more adept at putting other people's recipes into service fairly quickly. Then again, you will run into barriers with Chef that don't exist with puppet so it seemed that the ramp up investment had long term benefits.

Ruby seems like the only thing that might be worse than python in
terms of long-term version incompatibilities and installation
problems, although python is sort-of a special case on RH systems
since the install tools need it. I think something I wrote 20 years
ago should still run today, but maybe that's just me. And I didn't
see any way to tier puppet masters or keep it from falling over with a
large number of clients.

--
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:49 PM.

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