On 2/5/21 2:03 PM, Warren Young wrote:
On Feb 5, 2021, at 9:03 AM, Lamar Owen <lowen@xxxxxxxx> 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
instead.
...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).
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
