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. AlmaLinux, the Developer Subscription RHEL, Rocky, CentOS Stream, Springdale, upgrading to full RHEL; all these are also possibilities, too, and all have different strengths and weaknesses. The transition to Debian has a lot of strengths, including a long track-record of support (even if the support time for a particular release is shorter), a fully-open development model with no 'corporate overlord' that I know of, a large set of supported packages, and a huge community of developers and users. For the CentOS user the main weakness is having to learn a few areas of difference in the way the system is setup and maintained; of course, if a ten-year 'stable' timeframe is really that important to you the lack of that is also a weakness.
So, last week I transitioned, as a test of sorts, my working CentOS 8 main laptop to Debian 10. I kept a complete backup of the C8 install should I wish to go back to it, and installed Buster to a new mSATA SSD, but ported the two SATA drives (Dell Precision M6700 - has an mSATA slot plus two SATA bays) straight over after making full backups.
I posted a pretty complete rundown on the scientific linux users mailing list, so I won't recap it all here. The bottom line was the the transition was not any more difficult, really, than moving from CentOS 7 to CentOS 8. The software versions in Buster are pretty close to what is in CentOS 8, although I have yet to need any third-party repository (PPA) for anything I've needed to install.
All the packages I have worked with so far have worked fine with a little bit of massaging. These include commercial (and costly) software such as Harrison Consoles' Mixbus32C, Qoppa's PDFStudio2019 Professional, and others.
So if you were to decide that this is the route for you to take, it does work and I found it to be not nearly as hard as I had thought it might be. If you install GNOME 3 you get GNOME 3; it feels pretty much the same as a non-Classic CentOS GNOME 3, just with a different set of extensions installed by default.
That's on the workstation.
On the server side, I'm evaluating Proxmox for the virtualization solution, and so far I'm finding it to be a pretty easy migration. I'm using the 'non-subscription' repository, so this is a no-cost option. Even getting the box registered to our EMC Clariion SAN was relatively easy; EMC provides the Unisphere Server Utility for Linux x64 in RPM form; the latest I have is "ServerUtil-Linux-64-x86-en_US-1.0.55.1.0044-1.x86_64.rpm" (which is fairly old, but I did say Clariion arrays, so they're pretty old, too). Debian has provided the 'alien' tool for some time; after installing alien, a simple 'alien -i ServerUtil-Linux-64-x86-en_US-1.0.55.1.0044-1.x86_64.rpm' installed the EMC RPM in the correct place. Proxmox already included everything that serverutilcli requires; on a plain Buster install I had to install dm-multipath and the device mapper libraries and tools before serverutilcli would find the arrays; but it ran just like it did on CentOS 8 (and 7).
I haven't decided whether to stay on Debian or not; too early to tell. I have time to test and evaluate. My CentOS 7 installs aren't goin anywhere, though, at least until late 2023. And I've registered for a Developer subscription of RHEL so that I can properly evaluate that option, too.
This is the beauty of open source: we have OPTIONS.
On 2/4/21 9:39 AM, Lamar Owen wrote:
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. AlmaLinux, the Developer Subscription RHEL, Rocky, CentOS Stream, Springdale, upgrading to full RHEL; all these are also possibilities, too, and all have different strengths and weaknesses. The transition to Debian has a lot of strengths, including a long track-record of support (even if the support time for a particular release is shorter), a fully-open development model with no 'corporate overlord' that I know of, a large set of supported packages, and a huge community of developers and users. For the CentOS user the main weakness is having to learn a few areas of difference in the way the system is setup and maintained; of course, if a ten-year 'stable' timeframe is really that important to you the lack of that is also a weakness.
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
So, last week I transitioned, as a test of sorts, my working CentOS 8 main laptop to Debian 10. I kept a complete backup of the C8 install should I wish to go back to it, and installed Buster to a new mSATA SSD, but ported the two SATA drives (Dell Precision M6700 - has an mSATA slot plus two SATA bays) straight over after making full backups.
I posted a pretty complete rundown on the scientific linux users mailing list, so I won't recap it all here. The bottom line was the the transition was not any more difficult, really, than moving from CentOS 7 to CentOS 8. The software versions in Buster are pretty close to what is in CentOS 8, although I have yet to need any third-party repository (PPA) for anything I've needed to install.
All the packages I have worked with so far have worked fine with a little bit of massaging. These include commercial (and costly) software such as Harrison Consoles' Mixbus32C, Qoppa's PDFStudio2019 Professional, and others.
So if you were to decide that this is the route for you to take, it does work and I found it to be not nearly as hard as I had thought it might be. If you install GNOME 3 you get GNOME 3; it feels pretty much the same as a non-Classic CentOS GNOME 3, just with a different set of extensions installed by default.
That's on the workstation.
On the server side, I'm evaluating Proxmox for the virtualization solution, and so far I'm finding it to be a pretty easy migration. I'm using the 'non-subscription' repository, so this is a no-cost option. Even getting the box registered to our EMC Clariion SAN was relatively easy; EMC provides the Unisphere Server Utility for Linux x64 in RPM form; the latest I have is "ServerUtil-Linux-64-x86-en_US-1.0.55.1.0044-1.x86_64.rpm" (which is fairly old, but I did say Clariion arrays, so they're pretty old, too). Debian has provided the 'alien' tool for some time; after installing alien, a simple 'alien -i ServerUtil-Linux-64-x86-en_US-1.0.55.1.0044-1.x86_64.rpm' installed the EMC RPM in the correct place. Proxmox already included everything that serverutilcli requires; on a plain Buster install I had to install dm-multipath and the device mapper libraries and tools before serverutilcli would find the arrays; but it ran just like it did on CentOS 8 (and 7).
I haven't decided whether to stay on Debian or not; too early to tell. I have time to test and evaluate. My CentOS 7 installs aren't goin anywhere, though, at least until late 2023. And I've registered for a Developer subscription of RHEL so that I can properly evaluate that option, too.
This is the beauty of open source: we have OPTIONS. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Feb 4, 2021, at 8:39 AM, Lamar Owen lowen@pari.edu wrote:
I posted a pretty complete rundown on the scientific linux users mailing list, so I won't recap it all here.
Link?
the transition was not any more difficult, really, than moving from CentOS 7 to CentOS 8.
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*.)
On Thu, Feb 4, 2021 at 10:23 AM Warren Young warren@etr-usa.com wrote:
On Feb 4, 2021, at 8:39 AM, Lamar Owen lowen@pari.edu wrote:
I posted a pretty complete rundown on the scientific linux users mailing list, so I won't recap it all here.
Link?
https://listserv.fnal.gov/scripts/wa.exe?A2=ind2102&L=SCIENTIFIC-LINUX-U...
Akemi
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.
On Feb 4, 2021, at 12:56 PM, mailist mailist@toolz.com wrote:
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.
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
Todd Merriman Software Toolz, Inc. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Feb 4, 2021, at 8:39 AM, Lamar Owen lowen@pari.edu wrote:
I posted a pretty complete rundown on the scientific linux users mailing list, so I won't recap it all here.
Link?
the transition was not any more difficult, really, than moving from CentOS 7 to CentOS 8.
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:
- 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?)
- 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.
- 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?
- 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*.)
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
On 2/4/21 1:23 PM, Warren Young wrote:
On Feb 4, 2021, at 8:39 AM, Lamar Owen lowen@pari.edu wrote:
I posted a pretty complete rundown on the scientific linux users mailing list, so I won't recap it all here.
Link?
Yeah, I forgot to post the link... sorry about that. Akemi beat me to it, so I'll not repost. Thanks, Akemi!
the transition was not any more difficult, really, than moving from CentOS 7 to CentOS 8.
That’s not my experience.
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!
I keep several of my packages running on CentOS and Debian (and more) and I keep running into several common problems:
- The package names are often different, and not always differing by an obvious translation rule. ...
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.
- 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. ...
Yes, true. True going from C7 to C8, too, especially if you rely on third-party repositories for packages.
- 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?
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.
- 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.
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.
I’m not saying “don’t do it,” but to say it’s as smooth as from CentOS 7 to 8? Hard sell.
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.
... it’s always *something.*
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.....
Le 05/02/2021 à 17:03, Lamar Owen a écrit :
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 found your post highly interesting, even though I chose a different path:
https://blog.microlinux.fr/migration-centos-oracle-linux-cas-pratique/
Cheers,
Niki
On 2/5/21 11:21 AM, Nicolas Kovacs wrote:
Le 05/02/2021 à 17:03, Lamar Owen a écrit :
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 found your post highly interesting, even though I chose a different path:
https://blog.microlinux.fr/migration-centos-oracle-linux-cas-pratique/
Thanks. I am a firm believer in having options, and for CentOS 8 early adopters there are options available; each user just needs to get informed about them and make the informed choice that is necessary.
Am 05.02.21 um 17:21 schrieb Nicolas Kovacs:
Le 05/02/2021 à 17:03, Lamar Owen a écrit :
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 found your post highly interesting, even though I chose a different path:
https://blog.microlinux.fr/migration-centos-oracle-linux-cas-pratique/
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
Am 05.02.21 um 17:21 schrieb Nicolas Kovacs:
Le 05/02/2021 à 17:03, Lamar Owen a écrit :
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 found your post highly interesting, even though I chose a different path:
https://blog.microlinux.fr/migration-centos-oracle-linux-cas-pratique/
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?
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:22 schrieb Simon Matter:
Am 05.02.21 um 17:21 schrieb Nicolas Kovacs:
Le 05/02/2021 à 17:03, Lamar Owen a écrit :
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 found your post highly interesting, even though I chose a different path:
https://blog.microlinux.fr/migration-centos-oracle-linux-cas-pratique/
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?
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.
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
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.
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.
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.
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.
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
On Feb 5, 2021, at 9:03 AM, Lamar Owen lowen@pari.edu wrote:
- The package names are often different, and not always differing by an obvious translation rule. ...
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.
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.)
- 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. ...
Yes, true. True going from C7 to C8, too, especially if you rely on third-party repositories for packages.
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. :)
- 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?
That one is more serious for the server than the other two, for sure.
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.
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? 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.
I have one of the most maxxed-out Pentium III-S systems you'll find
Good in winter for an under-desk system, exhaust fan pointed at your frozies toesies. :)
On 2/5/21 2:03 PM, Warren Young wrote:
On Feb 5, 2021, at 9:03 AM, Lamar Owen lowen@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).
Hi,
On Thu, 4 Feb 2021, Warren Young wrote:
On Feb 4, 2021, at 8:39 AM, Lamar Owen lowen@pari.edu wrote:
I posted a pretty complete rundown on the scientific linux users mailing list, so I won't recap it all here.
Link?
the transition was not any more difficult, really, than moving from CentOS 7 to CentOS 8.
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:
- 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?)
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.
- Some packages simply won't??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.
- 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?
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.
- 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.
+1 It is a whole different process. It takes me back about 15 years.
I'm not saying don't do it, but to say it's as smooth as from CentOS 7 to 8? Hard sell.
Agreed!!
Regards,
On 2/5/21 11:32 AM, me@tdiehl.org wrote:
Hi,
On Thu, 4 Feb 2021, Warren Young wrote:
...
- The package names are often different, and not always differing by an
obvious translation rule. ...
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. ...
Maybe I'm just weird, but I don't find naming differences to be big differences. Like I keep telling optical astronomers, radio astronomy is just observing at another wavelength; I get a lot of mean looks when I say that, too. It's all light, why are humans so special that our three sensory passbands centered around 450nm, 540nm, and 575nm should be so important? Why is the 400nm-700nm band more important than say 1000nm to 1700nm other than human eyes' sensitivities? Package naming is syntactic sugar, no more and no less, IMHO.
Their systemd implementation is my biggest problem with Debian based systems. ... It would be nice if they would make up their minds. Either bite the bullet and convert everything to systemd or stay with sysv :-(
One of the contrasts between Debian and many others is the complete governance transparency. In December 2019 they (where 'they' is the collective group of Debian Developers only, not users) voted on this issue; the process and results are documented here: https://www.debian.org/vote/2019/vote_002%C2%A0 In a nutshell, Debian moved closer to focusing entirely on systemd; people interested in alternatives have to provide the tooling and work themselves. Looking in unstable should show the current state of the systemd integration; stable is too old to reflect this vote. So I would expect Bullseye (Debian 11) to have a more integrated systemd.
THIS IS OT comment
On 2/5/21 11:20 AM, Lamar Owen wrote:
On 2/5/21 11:32 AM, me@tdiehl.org wrote:
Maybe I'm just weird, but I don't find naming differences to be big differences. Like I keep telling optical astronomers, radio astronomy is just observing at another wavelength; I get a lot of mean looks when I say that, too. It's all light, why are humans so special that our three sensory passbands centered around 450nm, 540nm, and 575nm should be so important? Why is the 400nm-700nm band more important than say 1000nm to 1700nm other than human eyes' sensitivities? Package naming is syntactic sugar, no more and no less, IMHO.
Agree in general, but there may be huge difference physics wise. One example; at very low frequencies you finally will hit huge 1/f noise (1/f noise is fundamental property of the nature). But in general, observation frequencies are defined more by for which frequency you can get cheap equipment. Which ends up being military radio location and radio navigation ones (a lot of stuff is produced for military, hence less unique equipment == cheaper prices).
Valeri
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Am 05.02.21 um 18:20 schrieb Lamar Owen:
On 2/5/21 11:32 AM, me@tdiehl.org wrote:
Hi,
On Thu, 4 Feb 2021, Warren Young wrote:
...
- The package names are often different, and not always differing by an
obvious translation rule. ...
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. ...
Maybe I'm just weird, but I don't find naming differences to be big differences. Like I keep telling optical astronomers, radio astronomy is just observing at another wavelength; I get a lot of mean looks when I say that, too. It's all light, why are humans so special that our three sensory passbands centered around 450nm, 540nm, and 575nm should be so important? Why is the 400nm-700nm band more important than say 1000nm to 1700nm other than human eyes' sensitivities? Package naming is syntactic sugar, no more and no less, IMHO.
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 :-)
On 2/4/21 10:39 AM, Lamar Owen wrote:
... I haven't decided whether to stay on Debian or not; too early to tell. .....
Six months on, and no longer too early to tell. I have found Debian to be minimally different from CentOS, in all actuality; much less different than transitioning to a *BSD would be. I've transitioned already deployed and configured production CentOS 8 machines to either Alma or Rocky (path of least resistance), keeping CentOS 7 machines on 7 until I need to revisit in 2023, and CentOS 6 machines went to Debian 10. Now, I'm going to say that the availability of both Rocky and Alma is a very good thing, and that availability made things a lot easier for a few already deployed production systems that needed to stay stable through the end of the year.
New servers are being deployed on Debian 10; new virtualization hosts on Proxmox 6.4, although I am testing the Proxmox 6 to 7 upgrade path at one site and on my development hosts at the main site. Proxmox is SLICK. The upgrade path for simple servers from Debian 10 to Debian 11 is relatively simple, with a few caveats (no python 2.x in 11, so no Mailman 2.x, for instance). I have upgraded a few development servers from 10 to 11, and no issues were noted.
Your mileage may vary, of course, but I've had a reasonably good experience with this transition. Thought I'd never say that; I've been a Red Hat user (partisan, even) for a very long time.
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
On 8/4/2021 12:03 PM, Lamar Owen wrote:
On 2/4/21 10:39 AM, Lamar Owen wrote:
... I haven't decided whether to stay on Debian or not; too early to tell. .....
Six months on, and no longer too early to tell. I have found Debian to be minimally different from CentOS, in all actuality; much less different than transitioning to a *BSD would be. I've transitioned already deployed and configured production CentOS 8 machines to either Alma or Rocky (path of least resistance), keeping CentOS 7 machines on 7 until I need to revisit in 2023, and CentOS 6 machines went to Debian 10. Now, I'm going to say that the availability of both Rocky and Alma is a very good thing, and that availability made things a lot easier for a few already deployed production systems that needed to stay stable through the end of the year.
New servers are being deployed on Debian 10; new virtualization hosts on Proxmox 6.4, although I am testing the Proxmox 6 to 7 upgrade path at one site and on my development hosts at the main site. Proxmox is SLICK. The upgrade path for simple servers from Debian 10 to Debian 11 is relatively simple, with a few caveats (no python 2.x in 11, so no Mailman 2.x, for instance). I have upgraded a few development servers from 10 to 11, and no issues were noted.
Your mileage may vary, of course, but I've had a reasonably good experience with this transition. Thought I'd never say that; I've been a Red Hat user (partisan, even) for a very long time.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 8/4/21 1:10 PM, Christopher Wensink wrote:
Were these deployed on bare metal or as virtual machines? If Virtual were they on vmware?
I have a mix of bare metal and virtual, but I am slowly migrating almost all of the bare-metal servers to virtualization. All of my production virtualization hosts here are now on Proxmox and are running the CentOS/Debian version mix guests in KVM. Still learning the tuning of Proxmox.
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?
I have not found any noticeable difference in whether a CPU is in a separate socket or just another core in one socket when using KVM virtualization. But I've also not done a deep-dive into benchmarking it, either, so I reserve the right to be wrong. This is with a mix of CentOS versions on a Proxmox host; all CentOS versions I've tried there have run well (and I have tried ALL major CentOS versions on Proxmox, including CentOS 2.1 through 5.....)
-
Akemi Yagi -
Christopher Wensink -
Lamar Owen -
Leon Fauster -
mailist -
me＠tdiehl.org -
Nicolas Kovacs -
Pete Biggs -
Simon Matter -
Valeri Galtsev -
Warren Young