19 thoughts on - Upgrade Path From CentOS 7 To Future Versions

• –r2L8WSvxAkRGMDI2TLPK1sjeJNnwG36WN
  Content-Type: text/plain; charset=windows-1252
  Content-Transfer-Encoding: quoted-printable

  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.

  –r2L8WSvxAkRGMDI2TLPK1sjeJNnwG36WN

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

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

• I tend to keep all server content in /srv and all user content in /home

  Upgrading from one major version to another then is pretty simple – but not on the same machine.

  I do a fresh install of the new version in a new vm, make sure all the services are in place, and all the user and group ids match.

  I can then rsync the old /home and /srv to the new system.

  Yes there are server migration files that need to be migrated but what I
  like about this approach is I can keep serving from the old server until this is done and tested in the new server, and then it is just a simple DNS change and the new server is used.

  Migrating configuration files to me means starting with the defaults in the new version and modifying them to match the needs of the service, not replacing them with the old files.

  I have tried updating between major versions in Fedora before and there were always too many glitches, it really is better to clean install and migrate the data. In my opinion. Especially if you skip a release like I
  tend to do.

• Alice Wonder wrote:
  
  I had an article published in the late, lamented SysAdmin magazine about
  10 years ago, where I recommended having a three of spare partitions, doing an install using those for /, /usr and /boot – though now you could get away with / and /boot. Then, if you had show-stopper issues, you could always boot back via the old partitions.

  Where I work, I don’t think we have a handful of VMs… because in a lot of cases, we need every bloody CPU cycle. For example, we have an SGI
  UV2000, a small, true supercomputer, 512 cores, 2TB RAM…and I see top telling me that one of my users’s multithreaded parallel job has a load of it of 467 (and no, I’m not misplacing the decimal point….)

  mark

• Ah – yes, different perspective I suppose. Vast majority of servers I
  manage are VMs purchased for a monthly fee from a service provider like linode. If you run the physical hardware yourself that is a completely different set of circumstances, point taken.

• *Almost*. exception was 6.5->6.6 upgrade.

  https://bugs.CentOS.org/view.php?idy72

  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.

  Bill

• Alice Wonder wrote:

  Yup. I’m 0ne of 3.5 sysadmins, and we run better than 170 servers and workstations. (.5, because she’s at another Institute the other half of her time.)

  mark

• 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

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

• This would be a good question for the ubuntu users list . . .

  Ubuntu user technical support,
  not for general discussions

  Do they just freeze major version, no matter what (it

• –wQCBmUqhwFoe3sBT4FvJFucDUKPcHRxCJ
  Content-Type: text/plain; charset=windows-1252
  Content-Transfer-Encoding: quoted-printable

  I agree :)

  –wQCBmUqhwFoe3sBT4FvJFucDUKPcHRxCJ

• Others have complained that this is not the place for an extended discussion on Debian, so I’ll just direct you here:

  https://wiki.debian.org/LTS/

  If you have any questions, I suggest you post them to debian-user. I am subscribed to that list, and will be happy to resume the conversation there.

• “LTS” is an Ubuntu term, not a Debian term. Debian and Ubuntu are very much not the same thing. I point this out not to be pedantic but instead because there are *two* OSes here that both manage to have straightforward automatic upgrades between major releases.

  And in fact, more than two. This isn’t just about RHEL vs Debian and derivatives of same. Several major non-Linux OSes also manage to do automatic upgrades between major releases: Windows, OS X, FreeBSD…

  Take FreeBSD for example. Its freebsd-update tool will do this, and it’s mostly automatic, even in the face of changes to core OS files. (e.g. /etc/services) It can even merge changes to a core OS configuration file with your local version in certain cases. Or, it can just open both versions in a text editor and wait for you to merge them manually. Why can’t there be a rhel-update tool that does the same?

  Your point about the 10 year support cycle for RHEL is also invalid. The time spacing between major releases is only about every 3 years, and that is the period that matters here.

  That is to say, I would not expect an automatic major upgrade tool for RHEL to let me jump straight from version 5 to version 7 just because RHEL 5 is still receiving security updates. The tool only has to be able to upgrade from the prior major release.

  This is a solvable problem. Red Hat just doesn’t want to solve it. Why?

  The upgrade doesn’t have to be perfect. It could break everything except the filesystem and SSH and still allow manual recovery. Even in that extreme, you’re still no worse off than today, where you have to migrate everything by hand.

  It is actually an uncommonly good time to make such a tool, with the shift to systemd behind us. Unit files are far less likely to cause problems in an automatic upgrade than Bourne shell scripts that source piles of other Bourne shell scripts. An automatic upgrade from RHEL 7 to RHEL 8 should be much safer than RHEL 5 to RHEL 6.

  Another big shift also plays into this: VMs everywhere.

  In the past, an automatic major OS version upgrade wasn’t as useful because by the time you wanted to do a major OS upgrade, the hardware was ready to be replaced, too. RHEL’s policy of keeping the past two major versions under support helped, a lot: if the hardware is still doing what you need it to, you could skip a major version, after which the hardware is probably about ready to fall over, if only because the CPU fan is about to seize up.

  In that world, you could do the OS upgrade and the hardware upgrade together, since you need to migrate the data and services over manually anyway.

  VMs are changing that. The longer that shift continues, the bigger a problem this missing feature will cause for EL shops.

  And that probably takes us to the real reason Red Hat doesn’t want to solve this problem: the requirement to support automatic major version migration wouldn’t have allowed them to throw Xen into RHEL 6 and then pull it right back out for RHEL 7. I think Red Hat *wants* the freedom to break core OS facilities between major versions.

• Warren Young wrote:
  

  I was under the impression that all the releases of OS X were more like what we call subreleases (6.6->6.7). But I don’t know, and don’t really care – I don’t do WinDoze, I don’t do (or like) Macs.
  

  No, it’s not invalid, nor is it what matters. For example, here at work, we have clusters, and a small supercomputer, all running 6.x (in the case of the supercomputer, it’s an SGI-modified RHEL 6.x), and they’ll go to 7
  probably when they’re surplused replaced.

  Or take me, personally, at home – I dislike systemd, and have zero intention of going up until I have to, and that won’t come for a good number of years yet, when support for 6.x stops. And, btw, no, you cannot tell me I’m “wrong” to dislike it, that I should “Embrace Change!!!”, because a) I don’t need anyone’s opinion to justify how I feel about how I
  deal with something, and b) just because you *can* do something doesn’t mean you *should*. For one example, I do *not* embrace change in the form of, say, Web-enabled thermostats (and they do security updates exactly
  *when*?, or Web-connected cars (are you out of your friggin’ alleged mind?). So, why should I go to something NEW! SHINY! when what I have works well, and is comfortable?
  
  And automatic upgrades are *NOT* always a Good Idea. For example, just last year, EPEL just upgraded the torque packages that we use to run our clusters… from 2.5 to 4.2(?!?!?!), which broke the test cluster instantly, and took a lot of research and work to make work on the test system by the admin I work with, and on our two big clusters, we’re not upgrading – our users would be down for a while… and these are several folks running jobs on the (24, 25) node clusters whose jobs can run a week or two straight.

  mark, down in the trenches, not in a hosting environment

• You can’t transfer meaning between different version number systems. There is no global standard for the meaning of version numbers. The only thing that matters is that there is internal consistency.

  (Which is why Windows version numbering is a joke.)

  OS X treats changes to the ‘x’ component of their OS X 10.x.y version numbering system about the same way as EL does in its x.y system. The only difference is that major OS X versions have been coming out yearly in recent years, so that there is less cumulative difference between major versions than in CentOS major versions. But there’s probably at least as much change every 3 major OS X versions, as you’d expect since CentOS major versions are also about 3 years apart.

  And, in fact, OS X will allow itself to be upgraded across major OS versions. It doesn’t demand that you upgrade to each intermediate version separately.

  Calling OS X major releases “subversions” is just as fallacious as the opposite problem we see here in the CentOS world, where some people believe that CentOS 7.1 is incompatible with CentOS 7.2. A change to y in these two x.y system means something very different, yet both are correct because both systems are internally consistent.

  Yes, and…? Just because you have one use case where a major version upgrade does not make sense does not mean that major version upgrades don’t make sense everywhere.

  I already covered that case in my previous post, and the counterargument remains the same: not all OS upgrades can be coupled with hardware upgrades. VMs are only one reason, though a big one.

  As for all the rest of your post, yes, I get it: nothing should ever change, nothing should ever break. You just go and live live that dream. Meanwhile, in my world, change happens. Your unwillingness to cope with it does not prevent me from doing so.

• And there was a joke about them. When RedHat started pacing fast with their CD version releases: 7.3 –> 8 –> 9 in very short time, someone said: they try to catch up with others in major version number. And someone else pointed: they cant: MS already has Windows 2000 ;-)

  MacOS 10 server (sorry about using Arabic number, I hate using Roman numbers written with Latin letters, makes any search useless) breaks things between 10.x versions consistently. They change the way authentication is done, add, then drop Apache modules, and so on. No, I do not run any of my servers under MacOS (FreeBSD is current choice, hopefully for long time to come). But some of Professors I work for do it, and I have to help them by doing dirty part that comes with it. So: nobody is perfect (meaning MacOS 10 here ;-)

  Valeri

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

• Nothing here. I responded to him on this offlist.

  mark