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