Newly Migrated From SL7 to Centos7

[jbkt23]

I have just done a clone and lateral migration from Scientific Linux to Centos. I loosely followed the Migration Howto on the wiki and after resolving a couple conflicts I was able to distro-sync and migrate my clone to Centos7.7. The machine is my samba and backuppc server. So far I've only tested samba and that service is running fine. I still have to weed out sl7 packages and test for glitches before I go live with my network.
I didn't see posts of others doing the same, it may be that I just haven't discovered the right search terms.

[TrevorH]

Why? SL 7 have announced support until the EOL of RHEL 7 in 2024 and that's when CentOS 7 will go EOL too. I don't see any point in migrating.

[jbkt23]

Because I can and also to prepare to upgrade to 8. I like to be in the actively maintained cycle of a distro. It hones my trouble shooting skills. Centos7 may never get into active service as it is only a stepping stone to 8.

[TrevorH]

There is no upgrade to 8. There is only reinstall.

[jbkt23]

Trevor,
Why do you believe there is no upgrade to 8.
It is systemd just like 7. It may use BLScfg but I can deal with that. I've been continuously upgrading my Fedora distro since 18 and I'm up to 31 now. Going from centos 6 to 7 was not doable because that was when it switched from sysv to systemd. I'll read the release notes for 8 just so I don't waste to much time on 7.

[jlehtone]

Why do you believe that "duct tape the duct tape" is a sustainable strategy?


CentOS does not provide any (config) data conversion tools for major version hopping.

Yum keeps track of what it has done. Yum of 7 and yum of 8 do not share that database; different schema. No information transfer. No cleanup of what the other guy did.

Co-dependencies affect both build and install of packages. The yums depend on different python; 2.7 and 3.6, respectively. What if the package manager fails to manage the install of package manager?


What I have done:
* Machine has YY installed
* Create new filesystem for ZZ's root [1]. (Fresh) install ZZ
* (Auto)mount YY's root somewhere in ZZ for read access
* Replicate account data from YY to ZZ (real easy, if it is in external NIS/LDAP/KRB/IPA/AD)
* Create configuration in ZZ that is logically equivalent (or more up to date) to YY [2]
* Mount user data volumes to ZZ like they were mounted to YY

[1] Unallocated disk is required, but I (almost) always leave some (on install of YY).
[2] That hones the skill of "How it is done now?" rather than the "How to shoehorn accumulated legacy?"


What I might use more:
* Have logical configuration in external repository, as ansible play
* Augment the play to cover new OS(s)
* Make fresh install
* Run ansible

[TrevorH]

Why do you believe there is no upgrade to 8.

Because... there is no upgrade perhaps?

[jbkt23]

Those are the same unsaid arguments when Fedora switched from yum to DNF. The repositories don't know which version of yum is used, so during the distro-sync the packages will be upgraded with the old yum python base and once that is completed the new python-dnf libraries will be in place.
The great thing about cloning is that I can do this all without worry if it fails. I'll post the results of my attempts even if it goes bad.
Before Fedora 18 I used to do as you describe. My issue with fresh installs is the anaconda installer is so un intuitive, I have to do a minimal install system w/o graphics so that I can get what I want and not have to deal with the dependencies of unwanted packages.