[CentOS] DNF update

Wed Sep 7 13:07:38 UTC 2016
Lamar Owen <lowen at pari.edu>

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).....