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.
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.
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:
- 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:
- 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>
- 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@kicp.uchicago.edu wrote:
- 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.
On Tue, May 10, 2016 3:57 pm, Liam O'Toole wrote:
On 2016-05-10, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
- 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@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 ++++++++++++++++++++++++++++++++++++++++
On 11/05/2016 8:12 AM, Valeri Galtsev wrote:
On Tue, May 10, 2016 3:57 pm, Liam O'Toole wrote:
On 2016-05-10, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
- 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?
This would be a good question for the ubuntu users list . . .
Ubuntu user technical support, not for general discussions ubuntu-users@lists.ubuntu.com
Do they just freeze major version, no matter what (it
is only 2 years the need)?
Thanks. Valeri
Liam
CentOS mailing list CentOS@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 ++++++++++++++++++++++++++++++++++++++++ _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 05/10/2016 05:15 PM, phil wrote:
<snip>
This would be a good question for the ubuntu users list . . .
Ubuntu user technical support, not for general discussions ubuntu-users@lists.ubuntu.com
I agree :)
<snip>
On 2016-05-10, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
On Tue, May 10, 2016 3:57 pm, Liam O'Toole wrote:
On 2016-05-10, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
- 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)?
Others have complained that this is not the place for an extended discussion on Debian, so I'll just direct you here:
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.
On May 10, 2016, at 4:12 PM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
On Tue, May 10, 2016 3:57 pm, Liam O'Toole wrote:
On 2016-05-10, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
- 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?
“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:
On May 10, 2016, at 4:12 PM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
On Tue, May 10, 2016 3:57 pm, Liam O'Toole wrote:
On 2016-05-10, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
<snip>
Yes, LTS, thanks Liam. Only LTS has life cycle of mere 2 years, whereas RHEL (hence CentOS) is what, 10 years?
<snip>
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...
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. <snip>
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.
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? <MVNCH> 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
On May 11, 2016, at 9:38 AM, m.roth@5-cent.us wrote:
Warren Young wrote:
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...
I was under the impression that all the releases of OS X were more like what we call subreleases (6.6->6.7).
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.
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.
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.
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.
On Wed, May 11, 2016 11:10 am, Warren Young wrote:
On May 11, 2016, at 9:38 AM, m.roth@5-cent.us wrote:
Warren Young wrote:
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...
I was under the impression that all the releases of OS X were more like what we call subreleases (6.6->6.7).
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.)
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 ;-)
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.
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
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.
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.
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.
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. _______________________________________________ CentOS mailing list CentOS@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 ++++++++++++++++++++++++++++++++++++++++
On 05/10/2016 12: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 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:
On 05/10/2016 12:19 AM, Johnny Hughes wrote:
On 05/10/2016 02:08 AM, Venkateswara Rao Dokku wrote:
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.
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.
<snip> 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
On 05/10/2016 01:29 PM, m.roth@5-cent.us wrote:
Alice Wonder wrote:
On 05/10/2016 12:19 AM, Johnny Hughes wrote:
On 05/10/2016 02:08 AM, Venkateswara Rao Dokku wrote:
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.
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.
<snip> 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....)
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.
Alice Wonder wrote:
On 05/10/2016 01:29 PM, m.roth@5-cent.us wrote:
Alice Wonder wrote:
On 05/10/2016 12:19 AM, Johnny Hughes wrote:
On 05/10/2016 02:08 AM, Venkateswara Rao Dokku wrote:
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.
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.
<snip> 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....)
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.
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
-
Alice Wonder -
Bill Maltby (C4B) -
Hakan Peker -
Johnny Hughes -
Liam O'Toole -
m.roth＠5-cent.us -
phil -
Valeri Galtsev -
Venkateswara Rao Dokku -
Warren Young