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