[CentOS] Transition test report going from CentOS8 to Debian 10.

Fri Feb 5 20:40:51 UTC 2021
Lamar Owen <lowen at pari.edu>

On 2/5/21 2:03 PM, Warren Young wrote:
> On Feb 5, 2021, at 9:03 AM, Lamar Owen <lowen at pari.edu> wrote:
>> I consider this to be very minor in comparison to other items.
> 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.
> ...
> (I mined that wiki to compose my prior reply.  Real-world experience here.)

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.

> However, I’d prefer to hold tight to *one* bag of problems rather than gather several bags of problems unto my bosom. :)

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.

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

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.

>> 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
> How does fobbing the problem off on Cisco help in today’s “deny everything by default” world?

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 

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

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