I read in http://wiki.centos.org/TipsAndTricks/CentOSUpgradeTool
"Warning: use of this tool is currently not recommended as several system- critical packages are of a higher version number in CentOS 6.6 than they are in CentOS 7 so those do not get upgraded correctly. This renders yum and several other system tools non-functional."
Does this still hold? It seems to me a bit pointless to offer a tool with the warning that it does not work.
On 05/19/2015 07:43 AM, Timothy Murphy wrote:
I read in http://wiki.centos.org/TipsAndTricks/CentOSUpgradeTool
"Warning: use of this tool is currently not recommended as several system- critical packages are of a higher version number in CentOS 6.6 than they are in CentOS 7 so those do not get upgraded correctly. This renders yum and several other system tools non-functional."
Does this still hold? It seems to me a bit pointless to offer a tool with the warning that it does not work.
It is not pointless, some people want to do it.
I would not use it.
To each their own.
The best way to do any major update is to backup your data, install the OS, bring back your data and make all the newer services (if you are moving things like databases or web directories, etc.).
Some people want to take shortcuts to this procedure, and with enough effort, that tool can work. But to me, there is too much effort and there are too many older packages left around as clutter, so I would never do it.
It can be done, however.
Red Hat released this, so we rebuilt it .. that does not mean one should use it.
Thanks, Johnny Hughes
Johnny Hughes wrote:
On 05/19/2015 07:43 AM, Timothy Murphy wrote:
I read in http://wiki.centos.org/TipsAndTricks/CentOSUpgradeTool
"Warning: use of this tool is currently not recommended as several system- critical packages are of a higher version number in CentOS 6.6 than they are in CentOS 7 so those do not get upgraded correctly. This renders yum and several other system tools non-functional."
Does this still hold? It seems to me a bit pointless to offer a tool with the warning that it does not work.
It is not pointless, some people want to do it.
I would not use it.
First of all, thank you very much, Johnny, for all your work. You are doing a fantastic job.
However, I find your answer here a little odd. It's a bit like the surgeon saying, "I wouldn't have this operation, but if you want it just lie back."
The best way to do any major update is to backup your data, install the OS, bring back your data and make all the newer services (if you are moving things like databases or web directories, etc.).
Some people want to take shortcuts to this procedure, and with enough effort, that tool can work. But to me, there is too much effort and there are too many older packages left around as clutter, so I would never do it.
If it would take you a lot of time and effort to clean up after the upgrade I can't imagine how long it would take me.
Red Hat released this, so we rebuilt it .. that does not mean one should use it.
Strange.
On 05/19/2015 09:12 AM, Timothy Murphy wrote:
Johnny Hughes wrote:
On 05/19/2015 07:43 AM, Timothy Murphy wrote:
I read in http://wiki.centos.org/TipsAndTricks/CentOSUpgradeTool
"Warning: use of this tool is currently not recommended as several system- critical packages are of a higher version number in CentOS 6.6 than they are in CentOS 7 so those do not get upgraded correctly. This renders yum and several other system tools non-functional."
Does this still hold? It seems to me a bit pointless to offer a tool with the warning that it does not work.
It is not pointless, some people want to do it.
I would not use it.
First of all, thank you very much, Johnny, for all your work. You are doing a fantastic job.
However, I find your answer here a little odd. It's a bit like the surgeon saying, "I wouldn't have this operation, but if you want it just lie back."
That's not far from the truth. Upstream, this tool supports a very limited scope, and has a rather substantial pre-upgrade test to determine how feasible it is. Since we don't differentiate between Server, Workstation, etc it's a bit more interesting for us to say "yeah sure you can totally run this". If you add 3rd party packages into the mix, it gets even crazier.
The best way to do any major update is to backup your data, install the OS, bring back your data and make all the newer services (if you are moving things like databases or web directories, etc.).
Some people want to take shortcuts to this procedure, and with enough effort, that tool can work. But to me, there is too much effort and there are too many older packages left around as clutter, so I would never do it.
If it would take you a lot of time and effort to clean up after the upgrade I can't imagine how long it would take me.
If you have a good config management environment set up, rolling out a new build to replace older systems is much easier than walking through an update on each system. I really recommend people use ansible, chef, puppet.. whatever they're comfortable with to do some basic automation.
Red Hat released this, so we rebuilt it .. that does not mean one should use it.
Strange.
It's a feature people have wanted/demanded for years. It doesn't make it sane, just popular.
On Tue, May 19, 2015 at 09:25:30AM -0500, Jim Perrin wrote:
If you have a good config management environment set up, rolling out a new build to replace older systems is much easier than walking through an update on each system. I really recommend people use ansible, chef, puppet.. whatever they're comfortable with to do some basic automation.
Just do lots of testing, first :-) There are sufficient differences between major OS releases (5, 6, 7) that you may need different rules for each type.
For example, postfix is different version on each so main.cf and master.cf are different and have version specific differences. Apache is sufficiently the same between 5 and 6, but 7 has a totally new way of doing things And, of course, sysvinit vs upstart vs systemd!
Config managementis a great way of rebuilding a new copy of an existing version, but it's not a panacea when changing versions.
On 19.05.2015 16:37, Stephen Harris wrote:
On Tue, May 19, 2015 at 09:25:30AM -0500, Jim Perrin wrote:
If you have a good config management environment set up, rolling out a new build to replace older systems is much easier than walking through an update on each system. I really recommend people use ansible, chef, puppet.. whatever they're comfortable with to do some basic automation.
Just do lots of testing, first :-) There are sufficient differences between major OS releases (5, 6, 7) that you may need different rules for each type.
For example, postfix is different version on each so main.cf and master.cf are different and have version specific differences. Apache is sufficiently the same between 5 and 6, but 7 has a totally new way of doing things And, of course, sysvinit vs upstart vs systemd!
Config managementis a great way of rebuilding a new copy of an existing version, but it's not a panacea when changing versions.
It's a good way to keep track of what makes your system unique though. Kind off a diff between the core installation and the final production system.
For a lot of people it seems the biggest problem is to identify what they need to migrate to get things running again and adapting that to new versions is actually that that big an issue. Sure you remember to copy /etc/httpd but did you also copy that script you wrote that tweaks some queue settings in /sys or that maintenance script that you stored under /usr/local or /opt or wherever that you haven't had to use in a year? If you have the discipline to put all that into a configuration management system then you don't have to search for these things.
Regards, Dennis
On 05/19/2015 09:12 AM, Timothy Murphy wrote:
Johnny Hughes wrote:
On 05/19/2015 07:43 AM, Timothy Murphy wrote:
I read in http://wiki.centos.org/TipsAndTricks/CentOSUpgradeTool
"Warning: use of this tool is currently not recommended as several system- critical packages are of a higher version number in CentOS 6.6 than they are in CentOS 7 so those do not get upgraded correctly. This renders yum and several other system tools non-functional."
Does this still hold? It seems to me a bit pointless to offer a tool with the warning that it does not work.
It is not pointless, some people want to do it.
I would not use it.
First of all, thank you very much, Johnny, for all your work. You are doing a fantastic job.
Thank you.
However, I find your answer here a little odd. It's a bit like the surgeon saying, "I wouldn't have this operation, but if you want it just lie back."
The best way to do any major update is to backup your data, install the OS, bring back your data and make all the newer services (if you are moving things like databases or web directories, etc.).
Some people want to take shortcuts to this procedure, and with enough effort, that tool can work. But to me, there is too much effort and there are too many older packages left around as clutter, so I would never do it.
If it would take you a lot of time and effort to clean up after the upgrade I can't imagine how long it would take me.
It is going to take a long time to fix issues in any Major upgrade. Most of your apache config files will not work, many times you need to run an upgrade on database system schemas, maybe new LDAP schema's etc.
That in itself is hard.
Add on top of that, if using the update tool, a bunch of packages that are running using the compat-glibc from the previous release. You not only have to figure out how to do all the updated stuff from above .. you now have to figure out which of the cruft that exists from the previous version (which is still on your system as there was no upgrade for it, etc.) that is needed and what is not.
This problem is not unique to CentOS or even Linux. Anyone ever upgrade a domain controller from WinNT-4 to Windows Server 2000 .. or Server 2003 to Server 2008, etc. Stuff never works like it is supposed to on in-place upgrades. You will be, IMHO, fighting problems for the lifetime of that setup after that. Much cleaner to upgrade without cruft from the old OS.
Red Hat released this, so we rebuilt it .. that does not mean one should use it.
Strange.
Not at all .. CentOS is a rebuild of RHEL source code. I do not agree with all the package selections they make. If it were up to me, some things would be newer or older in many releases .. but it is not up to me. If Red Hat releases the Source Code, we build it.
Thanks, Johnny HUghes
-
Dennis Jacobfeuerborn -
Jim Perrin -
Johnny Hughes -
Stephen Harris -
Timothy Murphy