Transition Test Report Going From CentOS8 To Debian 10.

Home » CentOS » Transition Test Report Going From CentOS8 To Debian 10.
CentOS 22 Comments

Sorry for the length….

I’m posting this here since this particular transition has been mentioned on-list as one possibility for a path forward for current CentOS Linux users.

22 thoughts on - Transition Test Report Going From CentOS8 To Debian 10.

  • Thank you, Lamar, for your post. I second what you said about strengths. I converted a few machines to Debian myself (number cruncher that is wen server and samba file server simultaneously, and a couple of workstations). Oh, I forgot this: laptop I set up for my wife quite a wile ago also runs Debian. I would add one thing (some may consider it extra strength, others may think otherwise). Debian doesn’t make any decisions for you, so you really have to do your own thinking and decide, say, which firewall to install. And choices are plentiful.

    And as Lamar said, you will have some learning curve with which commands to use, several will be different commands from what usually are in rpm based distro. But that is minor thing IMHO.

    And while they tolerate it, I will once again mention: Consider FreeBSD
    (or any of BSD descendants) for servers. Once you are there, you will never regret that. I do not.

    Thanks again, Lamar, for detailed and very encouraging post!

    Valeri

    —
    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Link?

    That’s not my experience.

    I keep several of my packages running on CentOS and Debian (and more) and I keep running into several common problems:

    1. The package names are often different, and not always differing by an obvious translation rule. For instance, it’s “openLDAP-devel” on CentOS but “libldap2-dev” on Debian, where the normal rule would make it “libopenLDAP-dev”. Why the difference? Dunno, but I have to track such things down when setting up scripts that do cross-distro builds. If I automate that translation, now I’m setting myself up for a future breakage when the package names change again. (libldap3-dev?)

    2. Some packages simply won’t be available. Most often this happens in the Debian → CentOS direction, but I’ve run into cases going the other way. Just for one, I currently have to install NPM from source on Debian because the platform version won’t work properly with the platform version of Node, last time I tested it. Why? Same answer as above.

    3. Debian adopted systemd, but it didn’t adopt the rest of the Red Hat userland tooling. For instance, it’s firewalld on CentOS, UFW on Ubuntu, and raw kernel firewall manipulation on Debian unless you install one of those two. And then, which?

    4. Network configuration is almost entirely different unless you turn off all the automation on all platforms, in which case you might as well switch to macOS or FreeBSD for all the good your muscle memory and training will do you.

    I’m not saying “don’t do it,” but to say it’s as smooth as from CentOS 7 to 8? Hard sell.

    I’ll give you one mulligan: the changes to the security rules in CentOS 8 caused a huge upheaval for one of my applications, since it basically stopped it from running, being naughty in Red Hat’s omnisciently beneficent eyes. We spent about a year fixing breakages due to 25 years of built-up assumptions about what was correct and sensible, which don’t affect us on other Linuxes because they didn’t implement the same SELinux rules.

    The details aren’t super-important, because the real take-away is this: it’s always *something.*

    (For those that must know, the biggie was that our systemd-based service used to run from /home/$APPNAME but that’s a no-no on C8 now. Moving it all under /opt/$APPNAME and rearranging it all according to LFS rules, then finding and fixing all the places we depended on such paths was *painful*.)

  • If you primarily use CentOS for web hosting with Apache, the Apache configuration for Debian is a whole new world. You will not be able to just copy the CentOS config to Debian.

    Todd Merriman Software Toolz, Inc.

  • It is different, but whoever ever configured apache web server will easily port configuration files. Simple copy and paste task. I just moved two web servers (with couple of virtual hosts == cnames each) from CentOS to Debian, no sweat. Takes much shorter ride than when you configure apache for the first time in your life.

    Just my $0.02

    Valeri

  • Thanks for the big fat warning, now I know exactly what I’ll have to do sooner or later :)

    Part of the problem is this: there was FHS 2.x and all was good. Then some devs started with new tools like systemd and didn’t care about FHS and reinvented some new wheels. Later, after the new facts were established, the FHS was adjusted to the new taste of things and people like you and me were left with the mess :)

    Simon

  • Yeah, I forgot to post the link… sorry about that.  Akemi beat me to it, so I’ll not repost.  Thanks, Akemi!

    I thought long and hard about it before posting to the CentOS lists, because I don’t want to be perceived as advocating for a particular transition path.  I am exploring different paths, and I started with my own workstation.  Of course workstation needs are going to be some different than server needs; and thus I posted here to sincerely see others’ experiences.  Thanks for the great information!

    This one I’ve run across, and yes the package name differences are annoying.  I did some cross-packaging myself back in the day, all on RPM
    systems, and I had to do special cases for SuSE since the package names are quite different there, too.  Why are they different?  Different naming standards developed at different times by different people with different ideas; I would consider it very odd if different distributions had identical package naming after going through such different paths.  
    I consider this to be very minor in comparison to other items.

    Yes, true.  True going from C7 to C8, too, especially if you rely on third-party repositories for packages.

    That one is more serious for the server than the other two, for sure. 
    If migrating from CentOS I would probably go with firewalld.  I haven’t decided yet in my evaluations.  But I put an ACL on the Cisco 7609’s here on all server-bound traffic, so not yet an important consideration for me.  But it will be soon enough.

    Again I started with my workstation, and since I chose a GNOME install I
    got all the NetworkManager tooling; once NM is in control there aren’t too many differences.  Red Hat and Debian chose different paths for system configuration information, that much is for sure.  But I try to not EVER use strict muscle memory in a sysadmin role, since that is guaranteed to break on CentOS version upgrades too, and I have too many different systems to rely on muscle memory, although I do find myself using that out of habit.  Constantly doing things differently keeps me sharp, hopefully, at least.  YMMV.

    On my workstation with my workload it hasn’t so far been that big of a deal and was less of a hassle than what C7 to C8 was; that is my specific workstation and my specific workloads, of course.  I am getting ready to take an older internal server that is on CentOS 6 (yes, I know, EOL etc etc) to Debian 10 as a test; I had planned to take to CentOS 8
    in early December, at least until the news hit, causing me to hold it up until I had a better idea of the issues.  I’ll know a whole lot more after that is done.

    True that.

    I will say that thus far my experience is mostly on the workstation, although I did set up a couple of test servers.  One is an old Dell PE1950; had no issues with the Red Hat-unsupported Dell PERC RAID
    controller and the C8-removed PCI IDs from the megaraid_sas driver.  The other one is……. well, INTERESTING: for grins and giggles I installed the 32-bit version on an ancient IBM eSeries x330 rocking dual Pentium III-S  1.4GHz Tualatins with a full 4GB of RAM and dual 146GB U320 SCSI
    drives – maximum performance you’ll get from a Pentium III (and almost as good as a much newer 64-bit Netburst-based Xeon at 3.2GHz; Byte Unixbench on the Tualatins at 324.6; on the Noconas 491.4, at over twice the clock speed, too). And it’s fun to just be able to say I have one of the most maxxed-out Pentium III-S systems you’ll find, at least without overclocking or going past a dually.  YMMV, and you might not think it so much fun, but you’ll see my idea of computer fun in my SL-users list post when you get down to the paragraph about the TRS-80 emulators…..

  • Hi,

    Yep!! It is a pita when trying to get things running for the first time. I started this journey on a couple samba DC’s before the Red Hat announcement. Libraries are almost always different names but even common packages like dhcp and bind have different names, configuration files and commands to do the same thing. Most of it is not that hard to figure out but it does take time to do it and it is a lot more work than going from CentOS 7 to CentOS 8.

    Their systemd implementation is my biggest problem with Debian based systems. Debian moved to systemd but only partially. Apparently Debian decided to only kind of move to systemd. Tab completion on systemd commands does not work. If you look in /etc/init.d there are a bunch of sysv init scripts. Converting to systemd is a big enough pita without having a system that is half sysv and half systemd. It would be nice if they would make up their minds. Either bite the bullet and convert everything to systemd or stay with sysv :-(

    Before somebody brings it up, yes, I know there is Devuan. I do not wish to go even further back in time.

    +1 It is a whole different process. It takes me back about 15 years.

    Agreed!!

    Regards,

  • Am 05.02.21 um 17:21 schrieb Nicolas Kovacs:

    Hi Niki, as you did that move. I have a question: Comparing C8 with OL8
    (rpmlist) I noticed that a lot of OL8 packages have a different NVR
    especially the “Release” is bumped up (e.g .0.1 added). I wonder how much the OL8 distro diverges from upstream. It seems that such altered packages are passing the rebranding package count. What’s your impression?

    —
    Leon

  • I’m not Niki but I try to answer anyway :)

    I did the move and also looked at several source RPMs. One thing to note is that by default, you’ll end up with packages replaced by updated packages from UEK repository. I’ve removed the UEK repo and replaced all packages with the corresponding base packages. That brings you very close to what you have with RHEL/CentOS. Additionally what I found in the source RPMs is that Oracle decided to add some patches/changes fixings issues tracked in Oracle tracking system.

    I don’t think these changes are a problem because they mostly fix things which maybe RedHat voted not to fix. At least that’s my impression.

    Regards, Simon

  • Am 05.02.21 um 18:20 schrieb Lamar Owen:

    There is a small peak around 437+-2nm that has an impact on your eyes (photochemical risk). I would take care of this 5nm band!

    —
    Leon :-)

  • Am 05.02.21 um 18:22 schrieb Simon Matter:

    Ok, thanks. This lead me to do following:

    Download all OL8 rpms and

    $ find . |grep rpm$ | xargs -n1 rpm -q –changelog |grep Orabug |wc -l
    3852

    quite a lot that got fixed?! Good to known.

    —

    Leon

  • If you’re making a wholesale transition, sure, but when you’re maintaining a mix of systems and you know what you’re trying to accomplish but can’t remember the exact one of six different incantations for accomplishing that on the platforms you maintain, it’s enough to frost one’s cookies.

    It’s gotten bad enough for me that I now maintain a private wiki listing instructions for how to set up a new system, alternate top-level sections giving translations of the primary platform’s instructions for each platform I have to manage. Bleah!

    (I mined that wiki to compose my prior reply. Real-world experience here.)

    Yes, I lost many packages moving from C7 to C8, too. However, I’d prefer to hold tight to *one* bag of problems rather than gather several bags of problems unto my bosom. :)

    And realize that firewalld is just an example, not the full scope of the problem. Solve that one across platforms, and you’ve got several more to deal with next.

    How does fobbing the problem off on Cisco help in today’s “deny everything by default” world? Unless you’re lucky enough to be using binary packages that take care of all of this for you, you’re still going to have to manually punch a hole in the firewall for some service or other, which means you’ve now got to learn to do that on every platform you’re supporting, because it probably won’t be the same way on any two of them.

    Good in winter for an under-desk system, exhaust fan pointed at your frozies toesies. :)

  • Not doubting your experience with your workloads, but my experience with my workloads is different.  I have had three CentOS major versions running in parallel; as an example, our three internal recursive resolver DNS servers were running three different CentOS versions for a little while: one was C6, one is C7, and the newest is C8.  The different BIND versions are enough, but the {service|systemctl}
    parameter order is the one that has caught me before.  I too have notes, and visual cues, and in the absence of those I’ll look for unique qualifiers; internal system names will typically have a version cue as part of the name.

    There are more than one set of issues going from C7 to C8, too. The biggest for me was the removal of hardware support for older but very serviceable servers (no, I’m NOT talking about the x330 P-III-S system!)
    where Red Hat decreed by fiat that certain PCI IDs would not be supported by their kernel even though the supporting driver IS in the kernel (megaraid_sas is one of these); ELrepo to the rescue.    But, sure, having the smallest set of surprises is a good thing.  Documenting the surprises I found is part of the reason I posted this in case someone else were to try this same transition.  But I am NOT saying that this will be the best choice for everyone.

    Of course I know firewalld is just one example; there’s always something new to deal with; I just found the switch to not be as hard as I feared it would be, that’s all.  I found it to be comparable for my workloads so far to the C7->C8 transition, and not as difficult as going from C6
    -> C8, especially on a workstation.

    The Cisco ACLs were already there, pretransition, deny by default; I’ve been doing ‘deny by default’ for right now 25 years since the days of IOS 10 on 2500-series gear.  It’s not something I put in place because I
    didn’t have a host-side firewall in place; but I can see the way I wrote my statement could imply that I just threw an ACL up on a handy Cisco instead.

    Already happening; pfSense and Cisco IOS are both involved, and have different ways of doing the same thing. Six of one; half a dozen of another; there’s no ‘probably’ to it, it is guaranteed to be different, even on two products from the same company like Cisco (like the difference between ‘show mac-address-table ….’ on one platform and
    ‘show mac address-table’ on another; Cisco IOS dialectal differences can be much much worse than Linux distributions’ dialectal differences).

  • If you mean that Oracle has patched the base packages, then surely it is then no longer a RHEL clone. The whole point of CentOS was that it was a RHEL clone, warts and all. In that context it doesn’t matter how close you get to RHEL, it still isn’t the same.

    P.

  • Sure, it’s truly not 100% the same. But, whenever we found an issue in CentOS, the first thing was to verify if the upstream Red Hat package has the same issue. The procedure is exactly the same now with OL or any other close relative and nothing changes in the way to handle bugs.

    Simon

  • Lamar,

    Were these deployed on bare metal or as virtual machines?  If Virtual were they on vmware?

    Can anyone else chime in on their experience with these platforms in a vmware environment?  Are there any special network card / controller card settings that have worked best?

    Can anyone speak to how well a virtual machine will perform when being given 1 socket 1 core, vs. 1 socket 2 cores vs 2 sockets 1 core?

    Chris

    —
    Christopher Wensink IS Administrator Five Star Plastics, Inc
    1339 Continental Drive Eau Claire, WI 54701
    Office: 715-831-1682
    Mobile: 715-563-3112
    Fax: 715-831-6075
    cwensink@five-star-plastics.com http://www.five-star-plastics.com

  • I have a mix of bare metal and virtual, but I am slowly migrating almost all of the bare-metal servers to virtualization.