I was searching tonight how to update OLD systems. I have C5 and C6 systems that need updating and they are remote systems.
I followed the paths and ended up at DNF.
Is this a valid option for updating C5 and C6 to take them to C7?
DNF is a replacement for Yum that will probably be in a future RHEL
release, but is not used by any RHEL/CentOS yet.
the only sane way to upgrade C5 or C6 systems is to bring up a clean install of C7, configure new packages to suit your requirements, and import your data. I prefer doing this with a new server or VM, rather than trying to do it on the existing server, once the applications are migrated, then I’ll redeploy or retire the old server.
And while dnf has a system-upgrade feature in Fedora, I don’t know how well it’d work in the RHEL world. Upgrading between releases that branches every 6 months (Fedora) to a upgrading an OS that branches every 3 or 4 years (RHEL) is a significantly different job. It would have to deal with a lot of corner cases, particularly when you’re changing init systems and executable layout.
First, a bit of nomeclature clarification is in order. To me, and to most in the RHEL-derived world, an ‘update’ means staying within the major release that you already have but bringing the packages up-to-date. This is easily done with ‘yum update’ on CentOS 5 and 6
systems, which are both still supported (CentOS 5 support is going away soon, though. See the CentOS or upstream version roadmaps for details of the end of support dates for EL5).
What you seem to be talking about is a major version upgrade. Now, how easy or how hard this will be totally depends on what those C5 and C6
systems are and what they do.
What they are is important, in that you would basically be installing a C7 system from scratch remotely, and so those systems will need full remote console capability, including the install boot media.
Virtualized systems are the easiest in this regard.
What they do is important, in that different services running on those systems may need different procedures for major version upgrades
(PostgreSQL, for instance, will need a pg_dump or pg_dumpall and then an initdb and reload after the upgrade, and, depending upon whether you have compiled C functions in the backend you might need to do more work to get the database back up).
Those things are not reasonably automated at the CentOS distribution level. In other words, if you want to try that route of using an auto-upgrading tool you will either need to fix the one in CentOS 7
yourself or you will need to pay for a contract for upstream RHEL 7
where that tool is supported (but only for certain very limited circumstances; see https://access.redhat.com/solutions/637583 for details of that tool as it exists in RHEL 7 and note that the ‘Database Server’ set where PostgreSQL, my example above, is NOT supported….).
Or you could pay for someone to fix that tool for CentOS; there has been talk about that tool for a while, and it needs a lot of work. But it will still only work for a very small set of circumstances for server installs. Desktops need not even try.
The best thing to do is to migrate what those C5 and C6 systems are doing to a new, fresh, C7 system, and then recycle the hardware that C%
and C6 are running on (either for new C7 systems, or actual hardware recycling). I am doing this now with an owncloud instance that is running on C6. I’m getting ready to migrate it over to C7. The owncloud instance is backed by PostgreSQL, so the automated upgrade wouldn’t help me anyway….. the new C7 server is set up and everything is installed, and the C6 owncloud is fully upgraded to owncloud 9.1 in preparation
(the C6 server uses the SCL PHP54, which works perfectly with OC, since at least OC 8.0). The process is pretty simple: put oc in maintenance mode, backup the database, rsync the data tree to the new server, restore the database on the new server, take the new server out of maintenance mode (that’s the concise version).
And if anyone were to think that the Debian-style ‘apt-get dist-upgrade’
is the cure-all, there is a thread in the owncloud user mailing list that you may want to read, about an admin who locked up (and ended up losing) his owncloud instance after doing a dist-upgrade to Ubuntu 16.04
(he didn’t specify the source version)…..
You will always find examples of release upgrades going wrong. The Debian release notes are very clear about the pitfalls of performing out such upgrades remotely in particular. My own experience has been more fortunate, as I have carried out multiple release upgrades over the years on many different machines. But I wouldn’t dream of attempting the equivalent on a CentOS installation.
I think it should be called YUM. Nothing wrong with having a new version of Yum, especially when we have a new version of CentOS with many strange differences (if not alien concepts) called C7.
Keep it simple, besides Yum is a nice and very familiar name which we all trust and appreciate.
DNF is a fork of yum that involves a nearly total rewrite. yum development continues.
In any single version of CentOS there is only one YUM. Having multiple and incompatible versions of Yum in the same software release is bonkers. Forget Dandies and be simply pragmatic. Everyone knows Yum but DNF (something to do with DNS ?) or Dandies or another load of weird ideas from Fedora people desperate to emulate M$ ?
DNF = Dandified yum ? and not a single ‘Y’ in the name.
Nein danke. Nee takk. Alstublieft niet voor mij,
Staying with excellent C6 until the end.
Wonderful news from Santa Cruz, USA :-)
Fedora is the place to try out bonkers stuff. If RedHat is satisfied with dnf then they will include it and not yum in RHELN. Maybe they will make yum an alias to dnf, who knows. But whatever they do it’s much less likely to be bonkers.
Who knew yum before Yellow Dog Linux?
CentOS 7 is yum based, not dnf.
“Always Learning” seems to have a distaste for anything new or different than what he already knows.
My mind is never ever automatically closed to new ‘things’.
I continually embrace new and existing aspects of a range of topics including law, Linux including CentOS, and journalism.
Once something works well, and is customised to be highly efficient and productive, I am adverse to re-learning an alternative method of effectively doing the same task. Time wasted on the ‘new’ method is time unavailable for the existing workload.
Perceptions based on incomplete knowledge (idle speculation?) may be inaccurate.
An abundance of free idle time will obviously assist those wishing to learn contentious Fedora and C7 “improvements”.
Have a very nice day.
Your, comment is probably correct: with this long frustration Mr. Always Learning experiences, yet he is not fleeing from Linux to one of the systems that do not change at this tremendous pace… (One doesn’t need to mention alternatives as everybody cat list named of UNIXes on one’s own
PS Sorry, folks, if the above hurts: sometimes whatever hurts helps you most in a long run..
Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
i.e.: that which does not kill us makes us stronger …. Preach it
*LOUD*, brother !!!!
Don’t we all? I’m not really all that excited about learning systemd, for example. But I’ll certainly give it a fair chance before proclaiming that they can pry CentOS 6 out of my cold dead hands.
–csebuP7u6xHdx73LVQQ0vUObScap1sfea Content-Type: text/plain; charset=windows-1252
Under Fedora23 issuing a yum command gets you a warning, then it automatically runs the appropriate dnf command.
Hopefully my hands will be warm and (probably) FreeBSD will be my next major leaning experience when C6 fades away …. unless C8 surprises everyone.
Can you tell us the DNF for:-
yum update yum groupinstall yum reinstall yum erase
Get ready to take notes, because this gets complex:
DNF isn’t used on CentOS. Stop.
If you want to learn about things that aren’t part of CentOS, please do feel free, there’s excellent documentation online.
On Fedora 24
$ dnf list dnf*
dnf.noarch 1.1.10-1.fc24 @@commandline dnf-conf.noarch 1.1.10-1.fc24 @@commandline dnf-langpacks.noarch 0.15.1-4.fc24 @@commandline dnf-langpacks-conf.noarch 0.15.1-4.fc24 @@commandline dnf-plugins-core.noarch 0.1.21-3.fc24 @@commandline dnf-automatic.noarch 1.1.10-1.fc24 updates
dnf-yum.noarch 1.1.10-1.fc24 @@commandline dnfdaemon.noarch 0.3.16-1.fc24 @@commandline dnf-plugin-system-upgrade.noarch 0.7.1-2.fc24 @@commandline dnf-plugin-spacewalk.noarch 2.4.15-3.fc24 fedora
dnf-plugin-subscription-manager.x86_64 1.18.1-1.fc24 updates
dnf-plugins-extras.noarch 0.0.12-3.fc24 updates
On CentOS 7.2
$ yum list dnf*
dnf.noarch 0.6.4-2.el7 epel dnf-conf.noarch 0.6.4-2.el7 epel dnf-langpacks.noarch 0.15.1-1.el7 epel dnf-langpacks-conf.noarch 0.15.1-1.el7 epel dnf-plugins-core.noarch 0.1.5-3.el7 epel dnf-automatic.noarch 0.6.4-2.el7 epel dnf-yum.noarch 0.6.4-2.el7 epel
Maybe not used much, but its available.
It may not work as expected:
It seems that libsolv (a dnf dependency) might appear in RHEL 7.3 so dnf might work once CentOS has rebuilt it, but I wouldn’t count on using dnf any time soon.