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