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?
Thanks,
Jerry
On 9/6/2016 5:57 PM, Jerry Geis wrote:
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.
On Sep 6, 2016, at 9:03 PM, John R Pierce pierce@hogranch.com wrote:
DNF is a replacement for Yum that will probably be in a future RHEL release, but is not used by any RHEL/CentOS yet.
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.
-- Jonathan Billings billings@negate.org
On Tue, 2016-09-06 at 18:03 -0700, John R Pierce wrote:
DNF is a replacement for Yum that will probably be in a future RHEL release, but is not used by any RHEL/CentOS yet.
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.
On Wed, 2016-09-07 at 23:40 +0000, Joseph L. Casale wrote:
I think it should be called YUM.
DNF stands for Dandified yum. Since DNF is a tech preview in Fedora 18 the Python module names can not be 'yum.*' as that would clash with yum itself.
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.
On 2016-09-08, Always Learning centos@u68.u22.net wrote:
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.
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.
Everyone knows Yum but DNF (something to do with DNS ?)
Who knew yum before Yellow Dog Linux?
Nein danke. Nee takk. Alstublieft niet voor mij,
Staying with excellent C6 until the end.
CentOS 7 is yum based, not dnf.
--keith
On Wed, 2016-09-07 at 19:59 -0700, John R Pierce wrote:
Staying with excellent C6 until the end.
"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.
On Wed, September 7, 2016 9:59 pm, John R Pierce wrote:
On 9/7/2016 7:02 PM, Keith Keller wrote:
Staying with excellent C6 until the end.
CentOS 7 is yum based, not dnf.
"Always Learning" seems to have a distaste for anything new or different than what he already knows.
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 ;-)
Valeri
PS Sorry, folks, if the above hurts: sometimes whatever hurts helps you most in a long run..
-- john r pierce, recycling bits in santa cruz
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 09/08/16 09:51, Valeri Galtsev wrote:
On Wed, September 7, 2016 9:59 pm, John R Pierce wrote:
On 9/7/2016 7:02 PM, Keith Keller wrote:
Staying with excellent C6 until the end.
CentOS 7 is yum based, not dnf.
"Always Learning" seems to have a distaste for anything new or different than what he already knows.
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 ;-)
Valeri
PS Sorry, folks, if the above hurts: sometimes whatever hurts helps you most in a long run..
i.e.: that which does not kill us makes us stronger .... Preach it *LOUD*, brother !!!!
On 2016-09-08, John R Pierce pierce@hogranch.com wrote:
On 9/7/2016 7:02 PM, Keith Keller wrote:
Staying with excellent C6 until the end.
CentOS 7 is yum based, not dnf.
"Always Learning" seems to have a distaste for anything new or different than what he already knows.
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.
--keith
On Thu, 2016-09-08 at 14:12 -0700, Keith Keller wrote:
On 2016-09-08, John R Pierce pierce@hogranch.com wrote:
On 9/7/2016 7:02 PM, Keith Keller wrote:
Staying with excellent C6 until the end.
CentOS 7 is yum based, not dnf.
"Always Learning" seems to have a distaste for anything new or different than what he already knows.
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.
Hopefully my hands will be warm and (probably) FreeBSD will be my next major leaning experience when C6 fades away .... unless C8 surprises everyone.
On 08/09/16 03:02, Keith Keller wrote:
On 2016-09-08, Always Learning centos@u68.u22.net wrote:
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.
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.
<snip> Under Fedora23 issuing a yum command gets you a warning, then it automatically runs the appropriate dnf command.
On Thu, 2016-09-08 at 23:22 +0100, J Martin Rushton wrote:
Under Fedora23 issuing a yum command gets you a warning, then it automatically runs the appropriate dnf command.
Can you tell us the DNF for:-
yum update yum groupinstall yum reinstall yum erase
?
Thanks,
On Sep 8, 2016, at 10:01 PM, Always Learning centos@u68.u22.net wrote:
Can you tell us the DNF for:-
Get ready to take notes, because this gets complex:
yum update
dnf update
yum groupinstall
dnf groupinstall
yum reinstall
dnf reinstall
yum erase
dnf erase
-- Jonathan Billings billings@negate.org
On Fri, 9 Sep 2016, Always Learning wrote:
On Thu, 2016-09-08 at 23:22 +0100, J Martin Rushton wrote:
Under Fedora23 issuing a yum command gets you a warning, then it automatically runs the appropriate dnf command.
Can you tell us the DNF for:-
yum update yum groupinstall yum reinstall yum erase
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.
jh
On Fri, Sep 09, 2016 at 09:28:09AM +0100, John Hodrien wrote:
On Fri, 9 Sep 2016, Always Learning wrote:
On Thu, 2016-09-08 at 23:22 +0100, J Martin Rushton wrote:
Under Fedora23 issuing a yum command gets you a warning, then it automatically runs the appropriate dnf command.
Can you tell us the DNF for:-
yum update yum groupinstall yum reinstall yum erase
DNF isn't used on CentOS. Stop.
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.
jl
On Sep 9, 2016, at 10:42 PM, Jon LaBadie jcu@labadie.us wrote:
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:
https://bugzilla.redhat.com/show_bug.cgi?id=1258416#c15
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.
-- Jonathan Billings billings@negate.org
On 9/7/2016 4:33 PM, Always Learning wrote:
On Tue, 2016-09-06 at 18:03 -0700, John R Pierce wrote:
DNF is a replacement for Yum that will probably be in a future RHEL release, but is not used by any RHEL/CentOS yet.
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.
On 09/06/2016 08:57 PM, Jerry Geis wrote:
I was searching tonight how to update OLD systems. I have C5 and C6 systems that need updating and they are remote systems. ... Is this a valid option for updating C5 and C6 to take them to C7?
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).....
On 2016-09-07, Lamar Owen lowen@pari.edu wrote:
[...]
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[1] 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.
1: https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.h...
-
Always Learning -
J Martin Rushton -
Jerry Geis -
John Hodrien -
John R Pierce -
Jon LaBadie -
Jonathan Billings -
Joseph L. Casale -
Keith Keller -
Lamar Owen -
Liam O'Toole -
Valeri Galtsev -
William A. Mahaffey III