CentOS - May 2016 - Upgrade path from CentOS 7 to future versions

On Tue, May 10, 2016 2:19 am, Johnny Hughes wrote:
> On 05/10/2016 02:08 AM, Venkateswara Rao Dokku wrote:
>> Hi,
>>
>> I would like to know whether the valid upgrade path will be present
from
>> CentOS 7 to future versions like we get for Ubuntu or some other
>> operating
>> systems.
>>
>> Right now, I am sure that we do not have proper update path in CentOS
to
>> move from one version to another.
>>
>
> If you mean upgrade to all CentOS-7 point releases, yes (from source
> code for RHEL-7.0 to RHEL-7.1, to RHEL-7.2).  If you mean from CentOS-7
> to CentOS-8, there is no way to know.  There is no RHEL-8 to look at.
>
> Red Hat has source code for preupgrade-assistant and
> redhat-upgrade-tool.  That is created for inplace upgrades from one
> major version to another.  Currently those tools are community and
> maintained and they are several updates behind because currently no one
> in the community has stepped up to maintain them.
>
> But, CentOS-7 has an EOL of June 30, 2024 .. so there is security
> updates for 8 more years.
I would add to nice Johnny's explanation one more thing.

"Other systems" you mention I bet are Debian and its clones (Ubuntu
being
one of them). These systems have different update philosophy than that of
RedHat Enterprise Linux (and hence what CentOS is, which is derived from
RHEL). Namely, these "other systems" do constant micro-upgrades of
components installed on the system to latest release, whenever new release
of given piece of software happens. To the contrary, RHEL mostly backports
important security fixes to a version that was included in original system
release (but occasionally does make upgrades). Hence the differences:

1. Debian (and clones): you keep the components of the system pretty much
on the level of latest release of each of components. Therefore
"upgrade"
to new release of the system is pretty close to just a regular routine
update. This apparent advantage comes with a disadvantage, namely: every
update has a potential to break something on your machine, as new release
may have different internals, then you will need to work on migration to
them, and this can come as a surprise with any of routine updates.

2. RHEL (and derivatives): you do routine updates, and all is guaranteed
to keep working as it did when you originally configured your machine.
This is great advantage for those of us who prefer stability. It comes at
some price, namely: more work of the side of RedHat team (backporting
important patches), and you have to live with slightly outdated
components. The last can be seen differently, as slightly outdated is the
same as being used by many, so all trouble in them are already discovered
and fixed. (Yes, there are upgrades occasionally, still...). Now, when you
upgrade to new system version, very many of the components go versions up,
thus the safe way to deal with them is to have everything freshly
installed, freshly configured, and then migrate your custom configurations
to this new level.

Now to comment of what one can choose, I would say about Debian (and
clones) what I would say about Fedora, which definitely is "bleeding
edge". If you want "bleeding edge", be ready for some bleeding
sometimes.

All in all it is your choice. If you are to maintain solid server and can
not tolerate 10 min outage in anything happen out of blue, CentOS is for
you. If you don't care about that, then Debian or one of its clones may be
more convenient for your way of system maintenance.

I hope, this helps.

Valeri

++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++

On 05/10/2016 06:44 PM, Valeri Galtsev wrote:
>
> "Other systems" you mention I bet are Debian and its clones
(Ubuntu being
> one of them). These systems have different update philosophy than that of
> RedHat Enterprise Linux (and hence what CentOS is, which is derived from
> RHEL). Namely, these "other systems" do constant micro-upgrades
of
> components installed on the system to latest release, whenever new release
> of given piece of software happens. To the contrary, RHEL mostly backports
> important security fixes to a version that was included in original system
> release (but occasionally does make upgrades). Hence the differences:
>
> 1. Debian (and clones): you keep the components of the system pretty much
> on the level of latest release of each of components. Therefore
"upgrade"
> to new release of the system is pretty close to just a regular routine
> update. This apparent advantage comes with a disadvantage, namely: every
> update has a potential to break something on your machine, as new release
> may have different internals, then you will need to work on migration to
> them, and this can come as a surprise with any of routine updates.
>
This is so flat out wrong that I don't know where to begin, and this is 
not the place to give a lecture about Debian stable or Ubuntu LTS 
release process anyway.

Not knowing something is perfectly normal and it is nothing to be 
ashamed of, spreading misinformation about a topic you have no knowledge 
of and doing it in a public list *and* when nobody asked you about it, 
on the other hand...

On Tue, May 10, 2016 2:22 pm, Hakan Peker wrote:
> On 05/10/2016 06:44 PM, Valeri Galtsev wrote:
>>
>> "Other systems" you mention I bet are Debian and its clones
(Ubuntu
>> being
>> one of them). These systems have different update philosophy than that
>> of
>> RedHat Enterprise Linux (and hence what CentOS is, which is derived
from
>> RHEL). Namely, these "other systems" do constant
micro-upgrades of
>> components installed on the system to latest release, whenever new
>> release
>> of given piece of software happens. To the contrary, RHEL mostly
>> backports
>> important security fixes to a version that was included in original
>> system
>> release (but occasionally does make upgrades). Hence the differences:
>>
>> 1. Debian (and clones): you keep the components of the system pretty
>> much
>> on the level of latest release of each of components. Therefore
>> "upgrade"
>> to new release of the system is pretty close to just a regular routine
>> update. This apparent advantage comes with a disadvantage, namely:
every
>> update has a potential to break something on your machine, as new
>> release
>> may have different internals, then you will need to work on migration
to
>> them, and this can come as a surprise with any of routine updates.
>>
>
> This is so flat out wrong that I don't know where to begin, and this is
> not the place to give a lecture about Debian stable or Ubuntu LTS
> release process anyway.
>
> Not knowing something is perfectly normal and it is nothing to be
> ashamed of, spreading misinformation about a topic you have no knowledge
> of and doing it in a public list *and* when nobody asked you about it,
> on the other hand...
Smashing! ;-)

You can begin by describing what the differences are, or by making the
statement that there are no differences whatsoever. Both will be helpful
to everybody. Another option would be e-mail privately to list moderators
and suggest to moderate an idiot (yours truly), - whoever does more damage
than help does deserve to be moderated. Either of the above suggestions
will be more productive than this post IMHO.

Thanks.

Valeri

++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++

On Tue, 2016-05-10 at 10:44 -0500, Valeri Galtsev wrote:
> <snip>
> 2. RHEL (and derivatives): you do routine updates, and all is guaranteed
> to keep working as it did when you originally configured your machine.
*Almost*. exception was 6.5->6.6 upgrade.

https://bugs.centos.org/view.php?id=7972

Caveat: my assessment may be wrong in that it all works, but not the way
it used to, meaning things broke when I tried to use it the way I used
to use it, and I spent a great deal of time discovering some of the
underlying causes and my eventual work-around.

There was also a couple "not the way it used to" regarding X start-up
and an extra instance of Firefox being started, which I posted
"corrections" for in the form of patches to the scripts.

Based on my memory, as you may have seen in another thread, this was a
change from the past.
> <snip>
> Valeri
> <snip>
Bill

On 2016-05-10, Valeri Galtsev
<galtsev at kicp.uchicago.edu> wrote:
>
> 1. Debian (and clones): you keep the components of the system pretty
> much on the level of latest release of each of components. Therefore
> "upgrade" to new release of the system is pretty close to just a
> regular routine update.
You are describing Debian sid/unstable, which is contunuously updated,
and where there are no releases in the usual sense of the word. Debian
stable releases are a different matter, and correspond very closely to
major releases of RHEL/CentOS. There is always an upgrade path between
consecutive releases of Debian stable.

-- 

Liam

On Tue, May 10, 2016 3:57 pm, Liam O'Toole wrote:
> On 2016-05-10, Valeri Galtsev
> <galtsev at kicp.uchicago.edu> wrote:
>>
>> 1. Debian (and clones): you keep the components of the system pretty
>> much on the level of latest release of each of components. Therefore
>> "upgrade" to new release of the system is pretty close to
just a
>> regular routine update.
>
> You are describing Debian sid/unstable, which is contunuously updated,
> and where there are no releases in the usual sense of the word. Debian
> stable releases are a different matter, and correspond very closely to
> major releases of RHEL/CentOS. There is always an upgrade path between
> consecutive releases of Debian stable.
>
Yes, LTS, thanks Liam. Only LTS has life cycle of mere 2 years, whereas
RHEL (hence CentOS) is what, 10 years? I was pretty sure Debian does not
backport patches (of Linuxes no one except RH, as far as I know). How do
they do it with LTS? Do they just freeze major version, no matter what (it
is only 2 years the need)?

Thanks.
Valeri
>
> Liam
>
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos
>

++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++