62 thoughts on - CentOS Stream Suitability As A Production Webserver

• Hi Jamie,

  Unfortunately no one can advise you as to what may be a suitable operating system for your business needs.

  One thing is clear, the operating system you are currently running
  (CentOS Linux) is being brought to end of life, version 7 in 2024 and version 8 in 2021.

  That gives you at least a year (for 8) if not longer to consider and evaluate alternatives. As your current OS will no longer exist, I would start with a blank sheet, look at the OSes that do exist and evaluate each based on it’s merits and suitability for your business needs and requirements.

  Cheers, Phil

• If you decide to go with Stream, you will need to test carefully each version and use some kind of repository management – as there will be no older version of the packages. Thankfully the ‘Boom boot manager’ is now fully working, so you can easily roll back an OS update.

  If you decide that you don’t want to fight with updates and the short life cycle of Stream, you got plenty of clones that are available:
  – Springdale Linux
  – Oracle Enterprise Linux

  And 2 more expected to come:
  – Rocky Linux (founder of the original CentOS -> Gregory Kurtzer)
  – Lenix (backed by CloudLinux)

  I would prefer the full lifecycle of a RHEL clone instead of Stream.

  Best Regards, Strahil Nikolov

• The question for me, too is going to be, what will the VPS providers do? Digital Ocean, Vultur, etc. I’ll be at their mercy, without trying to create my own image, if that’s even possible.

  Hopefully something emerges as the popular replacement (e.g. “Rocky”), and they support spinning up with the replacement.

  Anyone have agues/opinion on the most popular emerging path those providers will use, I’m all ears.

  Scott

• I guess we need to wait and see how the dust settles. For those lucky enough to still be on CentOS 7, there’s a bit of breathing space although these things take time to plan and implement of course. Those unlucky enough to have updated to CentOS 8 have less than a year to decide to move to stream or another distro. It’s a good job that there’s not a global pandemic disrupting work commitments so we have plenty of time to deal with these decisions from above!

  I’m sure it’s my lack of understanding, but there feels too much hope pinned on “Rocky”, which seems like one person (albeit a key person) going it alone with the hope of a community following of disgruntled people. I
  see a single readme file in the repo. I think I’d feel more comfortable using Stream at this point.

  The uncertainty is frustrating and unsettling.

• If you still think Rocky is one guy going it alone then you haven’t been paying any attention to it at all. The slack that it started on is so active that messages were falling off the 10k scroll back limit in a matter of days. It’s quieted down some since they have been making use of their forums and working on moving to Mattermost, but that sure isn’t the activity of one person.

  The repo you refer to is just a holding one, with the readme in many translations. Go up one level and you’ll see the 17 repos thay have for infrastructure and other needs. https://github.com/rocky-linux

• Consider me firmly schooled and I apologise if I have caused any upset with my comment. My understanding of the situation was the result of pouring over countless threads where it’s difficult to filter out the facts and reality. It’s encouraging for sure that there’s potentially at least one ship to jump to.

• I certainly agree with you on this point!

  Personally, while I haven’t made an actual decision on which way I’m going with my own projects, I’m currently leaning toward Oracle Linux. I installed it on a laptop a couple of days ago and what I got was exactly what I get when I install CentOS on a laptop. Even my little script to convert a stock installation into my custom setup worked as-is, and what I ended up with was exactly what I was expecting to see.

  I don’t have any particular love for Oracle, but since they pay X number of people to keep Oracle Linux current with RHEL and updated, they shouldn’t have any problems with burn-out or a lack of long-term interest on the part of volunteers that may (or may not) become an issue over the course of time with a community-driven distribution like Rocky.

  But for the moment I’m more-or-less just sitting on my hands, waiting to see how all of this shakes out over the course of the next few months before I take any action to change anything.

  Frankly, I’m kind of hoping that Rocky turns out to be “the new CentOS”, but it seems too early in the game to make the decision to depend on it. That may change over the course of the next few months.

• it. That may change over the course of the next few months.

  Yes this is how I feel but conveyed badly in my last. It’s currently a concept and not a viable distro to move to and in some cases there is only a year to make the move.

  At this stage I’m not totally dismissive of Stream either. We already automatically update our systems with yum-cron / dnf automatic and I’m reading that if we’re already doing that, Stream isn’t going to be a departure i.e. minor version bumps – but I’m still trying to make sense of the impact in real-terms i.e. what actually changes if we move to Stream.

• I’d have said the same:  If you trust CentOS enough to update automatically, then Stream will be an easy migration for you. You’ll get a distribution that’s just as trustworthy, with the added benefit that you’ll get security fixes much sooner than CentOS did.

  You’ll get updated versions of software when they’re ready, rather than once every 6-8 months.  They’ll be roughly the same versions that RHEL
  will get later.

• Probably.  For a lot of users, Stream is a drop-in replacement that’s better than CentOS was, because it gets updates consistently and doesn’t suffer from periods in which no updates are available, including security updates.

  If security was a priority for you, as it was for me, then CentOS wasn’t really suitable for public-facing services, but CentOS Stream might be.

  If you’re building software that you intend to deploy on RHEL, Stream might not be a suitable build root for you.  Compiling software in a Stream build root may result in a binary that has dependencies which aren’t yet available in RHEL.  And if you’re building kernel modules
  (like Phil @elrepo), then there is the issue that the kernel isn’t subject to RHEL’s ABI policy, but Red Hat developers have expressed interest in making the kernel interfaces more stable and using external kernel module builds as a test to flag interfaces that have changed.  So that situation may improve…

• In that case, it sounds like a non-issue for the way we currently use CentOS.

  As there’s a simple migration from CentOS 8 to Stream and Digital Ocean currently provide CentOS 8 images, it’ll be interesting to see what they do moving forward.

• really suitable for public-facing services

  You mean in terms of security patch release time presumably?

  We’re not building or compiling software.

• Le 05/01/2021 à 22:59, Frank Cox a écrit :

  Similar situation here. Carefully maintaining my servers running CentOS 7, slowly moving to Oracle Linux while keeping an eye on Rocky Linux.

  Glad I based my last two Linux books on CentOS 7 and not 8. When volume 1 was still a manuscript, someone on this list made fun about it not being based on CentOS 8 and therefore reflecting Linux in the past. As things are, all 40
  chapters are now valid until 2024 instead of 2021.

  Cheers,

  Niki

  —
  Microlinux – Solutions informatiques durables
  7, place de l’église – 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32
  Mob. : 06 51 80 12 12

• better than CentOS was

  We will need to (manually) migrate to Stream 9.x after 5 years instead of
  10 though?

• Well that’s the part that hasn’t fully been laid out, stream to me just becomes like another disto lts release, at least with Debian flavors I
  feel confident in the upgrade path but the 10 year cycle is what makes RHEL
  nice. Stream is not an option for me, I will move to Springdale or Rocky if it matures. For what I need Springdale has been around long enough that I know they will continue and it also looks like Fermilab may be doing something also maybe they will get behind one of the new entries.

• Yes.  CentOS Stream has a lifecycle comparable with other LTS distributions.

• Off topic for sure, but it’s a shame this has to be a manual process of destroying and rebuilding every X years. Even Microsoft has gone the Apple way and just perpetually updates Windows 10 now.

• There’s been a lot of information and mis-information being bandied around on websites from people who don’t really quite understand what’s going on. I hope I don’t contribute to the confusion! It wasn’t helped by the, frankly, heavy-handed way it was handled by RH.

  One of the problems is that people are trying to put a label on what 8-
  stream is – such as development version, or RC, or beta version or whatever. To be honest all we can do is to try and understand what RH
  want. As far as I understand it, 8-stream accumulates new versions of packages that will collectively go to make up the next point release of RHEL8. We have been told, and we can only take it at face value, that the versions that go into 8-stream will be final, QC’d packages: they are not test, development or beta versions, nor are they “work in progress”. 8-stream will be a complete and functioning, stable distro. So rather than waiting to get the new versions of things once every 6
  months, 8-stream gets them when they are ready.

  The confusion about the “development” label is that RH said that 8-
  stream will be the distro used for their development process. So internally things will be developed and compiled in an 8-stream environment. They have never said that the development packages will ever be visible or available in 8-stream itself until they are ready to be set free.

  TBH I would have thought that this exactly how RH operate internally at the moment – they must have, say, a pre-8.3 environment that they put packages in so that when new packages are developed that can be compiled and everything is compatible. I really can’t imagine that packages are developed in isolation until there’s a big 8.3 compile time. All they are doing is making that internal system a public thing.

  Now it’s certainly possible that from RH point of view, releasing the packages into the wild is a very good way of finding bugs that might have slipped through QC – there is after all already a steady stream of updates between point releases. So the benefit for RH is that paying customers get potentially fewer updates between releases, but the implication is that 8-stream will be no less stable than CentOS 8
  currently is.

  The rhetoric from RH is that the tooling of the 8-stream system is not fully in place yet, but should be soon. Again, we can only take them at their word and watch what happens. And I must stress that I am no RH
  apologist: I think it was all handled incredibly badly by them and they desperately need to get some change management experience!!

  If you are considering using 8-stream then you need to understand that there is no specific point-release configuration that you can base things on – you cann’t say that this is “equivalent to RHEL 8.5” or whatever; this is important if you need to use 3rd party drivers during install as they are based on specific configurations (but hey, install CentOS 8.2 and move to 8-stream from there and upgrade). Also the lifetime of 8-stream is half what you’ve been used to – so come 2024, it will die; but 9-stream will have existed for at least a couple of years by then, so there is a roadmap.

  As for what you should do, than no one can really tell you. My advice to others has been to watch, evaluate, test. If you are running bog standard web servers with nothing exotic, then I have a feeling that 8-
  stream will work; if you are running 3rd party apps on a web service where versions matter, then you need to think carefully and consider switching to one of the rebuild distros.

  I suspect that as more and more things become containerised (and boy do I dislike containers), the actual underlying OS will become considerably less important.

  P.

• And as someone mentioned, these other distributions have long great record of system upgrade from one release to another. CentOS has no record (and probably no upgrade engineered yet). In that respect CentOS
  Stream is way behind Debian (and clones) LTS. Not to mention other potentially problematic areas as no package version rollback, compatibility (potential) with EPEL, and other things I don’t what to attempt to think about. As everything with newly architectured distribution which hasn’t proven itself during long time suitable for specific things.

  No disrespect intended. To the contrary: GREAT THANKS to hard working CentOS team for all your past work! And best wished to establish viability of absolutely new – and different – distribution: CentOS Stream.

  And while people still ask and the list still tolerates, I will mention the system I fled my servers from Linux 6 or 7 years ago to:

  FreeBSD

  On average update requiring FreeBSD reboot happens as rarely as once 7-8
  Months (Linux on average every 45 days: kernel or glibc security update
  –> reboot).

  Good luck everybody who didn’t arrive at final decision yet to find you way for the future.

  Thanks again, CentOS team for the great system you gave us for decades up until now!

  Valeri

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

• In that respect, CentOS Stream is identical to CentOS.

  CentOS Stream will be compatible with EPEL to the same extent that new point releases are compatible with EPEL.

  The vast majority of interfaces in RHEL (and Stream) are guaranteed stable within a major release, and only a small number of interfaces that aren’t.  It’s possible that one of the latter interfaces might change, in which case you’d expect yum to not update the dependency until EPEL’s packages have been rebuilt:

  https://access.redhat.com/articles/rhel-abi-compatibility#Appendix

• Most probably after 3 years. Currently stream should be equal to RHEL
  8.4 .

  Best Regards, Strahil Nikolov

• I’m not sure how it will go. Fedora now has a very good upgrade tool that has worked for me through a few versions. So, hopefully, RH, and CentOS
  will have one too, who knows, maybe in time to migrate to Stream-9.

• I do not like “creative editing” that changes what I said, this is the only reason I reply. Here is my original full phrase:

  And as someone mentioned, these other distributions have long great record of system upgrade from one release to another. CentOS has no record (and probably no upgrade engineered yet). In that respect CentOS Stream is way behind Debian (and clones) LTS.

  I was not comparing CentOS Stream with CentOS (former 10 year life cycle system), I was comparing CentOS Stream with Debian (and clones) LTS. And my comparison was about the fact that Debian (and clones) LTS have proven known to work through several releases easy way to in place upgrade from one release version to next one (for that matter FreeBSD is the same and too has since forever known trouble free way to in place upgrade to next major release version).

  CentOS never had in place upgrade, and I for one would insist it will be improper to expect that. CentOS Stream, that didn’t go through even a single in place major release upgrade, can not sport having that, and only after two such upgrades happen trouble free for the whole community of CentOS Stream users, only then CentOS Stream will be on the same level with Debian and clones. This is regular simple truth of life: if you want, psychology is such that only after this NEW, DIFFERENT, system: CentOS Stream, goes through a couple of releases, with easy in place upgrades, only then the trust of common folk like humble sysadmin (meaning here myself), who does not consider oneself any sort of expert is operating systems, only then the trust will be of the same level as trust currently is to Debian (LTS or regular, and clones), or to FreeBSD, as far as easy in place upgrade to next release is concerned.

  I know, CentOS team are great bright people, so knowing that and writing what I had to write above gives me extra pain. But that is the reality, and how users will value CentOS Stream couple of release cycles down the road when compared to Debian LTS, we will see. After long good record of trouble free upgrading (and other things that may rightfully or wrongfully trouble people now) there may be another factor, like huge collection of software Debian has in their repository, which may put some weight after all other comparison factors become equal. CentOS did beat all (excluding commercial MS Windows) by 10 year life cycle. Now that that is gone, CentOS (with Stream in name) stopped being unique, and people will mention huge choice of software collections in Debian and clones, comparably huge macports for MacOS (sorry about mentioning commercial system) and same huge FreeBSD port collection.

  I understand that your hard work will insure it WILL be compatible, trouble free etc. But the same psychology factor is why I mentioned that. Trust will come only a couple of releases down the road.

  We are sure CentOS team will keep doing great job on this absolutely different system CentOS Stream is, and if this new system couple of release down the road will be in similar demand as Debian (and clones) will be, – we will see. As I perceive it now, Debian (and clones), all other factors equal, will have much larger collection of packages that they have in their repositories as additional comparison factor.

  And once again:

  Huge thanks to brilliant hard working CentOS team for all you gave us during last couple of decades.

  Valeri

  – CentOS user for almost decade and a half, who moved servers (but only servers) to FreeBSD about 8 years ago.

• Le 06/01/2021 à 01:22, Gordon Messmer a écrit :

  And in the past, things have been known to break. Activate the CR repository, and suddenly libmagick is broken because it hasn’t been rebuilt yet against the new version.

  This is the kind of thing you *hate* when you’re a server admin. And this is exactly where CentOS Stream is heading.

  —
  Microlinux – Solutions informatiques durables
  7, place de l’église – 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32
  Mob. : 06 51 80 12 12

• The original message came from a CentOS user who asked “is the change a non-issue for my use-case?”

  So, I’d have to ask you how Debian is relevant to that question.

  As I said, in terms of upgrade from one major version to another, CentOS
  Stream and CentOS are identical.  If CentOS was suitable, then the change to CentOS Stream is a non-issue in the context of major version upgrades, because the change to CentOS Stream has no material impact on that concern.

  The question being asked is not “what operating system should I use”, to which discussion of Debian or FreeBSD might be relevant, it’s “will the change to CentOS Stream impact my current processes?”  Comparisons to Debian or FreeBSD are non-sequiturs in the context of this conversation.

• Are you describing an actual problem, right now, or is that an invented example?  Can you provide the specifics of what yum does, or what the application does after updates?

• Le 06/01/2021 à 08:06, Gordon Messmer a écrit :

  No, this was an actual problem I had back in April 2020. Upgrading from CR
  broke imagemagick, so I couldn’t use the corresponding PHP modules, so my Roundcube installation was broken for a few weeks.

  One of the things I like about Oracle Linux is that they maintain their own EPEL repo, most probably to prevent these things from happening.

  —
  Microlinux – Solutions informatiques durables
  7, place de l’église – 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32
  Mob. : 06 51 80 12 12

• To be fair it was only broken because you kept it broken; you could have backed out the CR updates and waited for the point release to go GA and be on ABI parity with EPEL.

  I would be careful of expectations around that partial EPEL rebuild;
  it’s not complete and some of the builds are quite dated.

  John

• Le 06/01/2021

• No, definitely not. With CentOS you need to perform this exercise every ten years. With Stream every five years. This is a 100% effort/ costs difference which becomes a significant factor when you run more than a static web server.

  Kind regards Thomas

• Am 05.01.21 um 23:51 schrieb Gordon Messmer:

  I often read this statement here that it “is better” because of not having “periods of missing updates” like in CentOS Linux.

  Is it maybe more worsed? Some one said that security updates will be ASAP in Stream because the rolling process is build on top of such fixes. But what about leaf packages?

  C8S: firefox-78.3.0-1.el8_2.x86_64.rpm C8: firefox-78.5.0-1.el8_3.x86_64.rpm RHEL8: firefox-78.6.0-1.el8_3.x86_64

  The divergence exits because the C8->C8S migration process is not completed and we have still C8 as the base for the distrosync to C8S
  (and the compose process uses both repos).

  The time after EOL of C8 will show that priorities will be on development – as it was stated. I would expect that Stream will diverged in two directions …

• Am 06.01.21 um 03:01 schrieb Scott Robbins:

  Fedora’s package set is quite “stable”. You can expect that a package is in the next release. This is not so valid for EL. Deprecated packages
  (ImageMagick in EL7 but not in EL8) make such upgrade path difficult …

• It’s anyway hard to understand how an enterprise grade Linux can be shipped without things like ImageMagick or Tomcat. For quite some time now it gives me the impression that we’re not the targeted audience anymore.

  That’s really sad because the competitors still include such important software as first class citizens. Maybe our requirements are just too old school?

  Simon

• Hmm, I see a relation here.

  C7Linux – 2024
  C8Linux – 2021

  So I assume:
  C6Linux – 2027
  C5Linux – 2030
  C4Linux – 2033
  …

  Interesting.

• Do you use tools like ansible/chef? If you can put the time in, you can make your webservers rather distro agnostic. I would even put terraform on the table. It is not like your customers will know the difference.

• We use Ansible “to a point” in that it sets up what we consider to be our preferred server (Droplet) for a specific purpose, then we deploy projects on them and tweak non-Ansible managed project configs. It’s not old-school scripts and it’s not quite a one-liner to deploy everything. It’s somewhere in the middle. So in reality, providing we have control over a customer’s DNS or we use floating IPs, migrating to another major release isn’t as time consuming as doing everything from scratch.

• The issue is that ‘Enterprise’ is an overloaded term without the nuance it needs. In the ‘small’ enterprise you have a lot of use of ImageMagick and TomCat. In the large enterprise of 100,000+ servers.. it isn’t. As more of the large enterprises moved into RHEL, the amount of usage for a lot of
  ‘leaf’ programs became rounding errors without enough usage to justify the bug-fixing needed when compared to the load of bugfixing/enhancements/etc in the 100k customers.

  An additional problem is a generational one. We have a lot of programs which do various things ‘well’ enough written 10-30 years ago, and we of a certain age use them for the hammers to every nail problem. However, the problems fleets of 100k systems have are more welding versus hammering. So we are in a situation where we do need to retrain some of our hammers to be rivet guns. There is also a similar industry problem that anything older than 2 years ago is not sexy anymore because VC and investors aren’t going to dump money into it. [You see a similar issue in the various ‘popular mechanics’ press that all homes in the next generation will only be built with metal and hammers and wood are a thing of the past. What you see instead is a wave of it and then a realization that you end up needing to do a little of each.]

• Thanks for confirming that RHEL is the wrong OS for SME businesses these days. It’s not really good for SME servers and not really good for SME
  clients. Something between Fedora and RHEL could be it but it doesn’t exist.

  BTW, servers? Who needs servers in the days of clouds and serverless computing :-)

  Simon

• Yes, my apologies, I did miss the word “Stream” in my phrase (no excuse even though I obviously spoke about NEW type of CentOS system).

  Yes, indeed, if CentOS Stream is identical to CentOS as far as “in place upgrade” is concerned, which is not possible in case of both CentOS incarnations, then the comparison to other systems with comparable 5 year life cycle insists to be mentioned.

  This only comes as I do care about CentOS at least recognizing benefits we had (I for one for about decade and a half). So, caring about CentOS, one imminently has to mention:

  1. 5 year life cycle (of Stream): unique 10 year life cycle (not mentioning MS Windows which is commercial) is gone

  2. same life cycle Debian and clones (LTS): have easy in place upgrade. Not Stream (as far as I know). If it will be, then only 2 releases down the road people will trust in place upgrade (pure psychology)

  3. [continuing comparison with similar LTS alternatives]: Debian and clones have much larger package collections than CentOS + EPEL (and so do FreeBSD and clones: meaning their ports)

  4. By the moment people will know CentOS Stream exists for decently long time, so can be trusted, quite some userbase will be lost. But looking at the comparisons above, there also is no obvious advantage over alternatives, who beat CentOS Stream in several respects.

  This is not to annoy anyone, just to express sadness of the loss, and though for me it was like stating obvious, it still looks like not everyone considers it that obvious. If I didn’t care [what I run on my machines], then I wouldn’t care to write this. But as I do… there it is.

  Well, in my book whenever one is trying to access future usability of something newly changed, it is always advantageous to step up above it, look at a wider picture and other possibilities. Not locking oneself into what one used (but changed forcing you to re-evaluate). I know, the existence of alternatives annoys, and it really hurts when they have advantages, especially once the advantage CentOS had (10 year life cycle) is gone…

  And again, GREAT THANKS to brilliant CentOS team for great work you did for last couple of decades. With sadness of the loss (even if CentOS team does not perceive it as loss),

  Valeri

• Red Hat is working on this with a tool called “Leapp” for RHEL 7 to 8
  upgrades. I have no idea if this or something similar is going to be available for the Stream 8 to 9 transition, but it’d definitely be useful and I think in everyone’s interest (because Red Hat wants as many Stream users as possible on the latest release).

  https://www.redhat.com/en/blog/upgrading-rhel-7-rhel-8-leapp-and-boom

• At the time, you described that problem as:

  I don’t have enough information to say why imagemagick or php would be broken, as you said it was.

  What I do see is that the sclo-php72-php-pecl-imagick has a dependency on libMagickCore.so.5()(64bit), which is recorded in the rpm package. 
  If you have a package from a third party repository (either EPEL or SCLO, or others), and it depends on one of the few packages in CentOS
  Stream (or CentOS, or RHEL) that aren’t guaranteed to be stable, and which Red Hat changes, then yum will warn you that the update would result in unresolvable dependencies, and it won’t upgrade the package. 
  Your system will keep the old imagemagick package and the old php-imagick package until the dependencies are resolved in the two repositories, and it’ll update them after that.

  Stream doesn’t change that.

• I didn’t say or mean that. My answer is that it is complicated and more meant that the software you expect requires more than the industry in general is willing to pay to keep going. 10-20 years ago they were and so the software was able to be ‘mainstream’. As less people use it, and less people are willing to pay for its maintenance the harder it is to keep
  ‘running safely’. Tomcat and Imagemagick have had a LOT of severe security problems over the years and the general way the software is written makes anyone who does work on them say it will have it for years in the future. As less of the industry uses that software, the cost to keep the software running is going to cost more.

  So please don’t take my statement to confirm your preconceived notion.

  Simon

• Le 06/01/2021 à 18:08, Gordon Messmer a écrit :

  On the contrary. Stream will ensure that your systems are perpetual moving targets so that situations like the one described will keep your blood pressure high.

  Broken packages explained away are still broken packages.

  —
  Microlinux – Solutions informatiques durables
  7, place de l’église – 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32
  Mob. : 06 51 80 12 12

• I’m not sure how your system got in to a broken state, though. If you have a working system, and one repo updates a package to remove a dependency of a currently working package, those packages will normally continue working.  rpm typically knows (as it did in the warning that you posted) when applying updates would break a system, and it won’t apply them.  Working systems will continue working, even in the rare case that one of the unsupported ABIs changes.

• I’d like to correct myself, ImageMagick was not simply removed but replaced by GraphicsMagick. From what I read it should be a usable solution as it’s a fork from IM.

  For the Tomcat thing, I don’t agree. Tomcat is widely used and I think the security concerns are not the real reason to remove it. It more likely that RedHat simply likes to sell more JBoss EAP. It’s their right to do so but it’s a removal of important functionality of the base RHEL package.

  Regards, Simon

• systems — DNS, mail, my hardware test environment — so I can then do the clever — decide how I want to run my experiments for instance —
  stuff. Without going over my opinions — I am very opinionated —
  about the CentOS thingie, I think you having your playbooks will allow you to wait and see how this unfolds. If it goes horribly wrong you can still switch.

  With that said, I think your real concern is you can’t afford CentOS
  stream going boink on you. Your customers may not be as understanding as Darth Vader if that happens.

  Here is my opinion: Redhat said you have normal CentOS 8 until the end of the year. I would stick to it until, say, October, while keeping an eye on how CentOS stream unfolds. Maybe even running a test CentOS
  stream to replicate production (or have it in production where it is ok if it goes boink). If by then your confidence on stream is high, switch to it (*should* be easy). If not, plan to move your customers. In the meantime, slowly ensure your ansible playbooks can handle the other usual suspects (at least debian and one of the other RH-derived distros). And plan the order you will move your customers if you have to.

• I honestly have no idea how much Tomcat is used anymore. The various places that I worked previously or have contacts with have killed it off by moving whatever used it to external cloud services versus JBOSS or anything else. That is just an anecdata but it is all I have on the subject.

• Red Hat still has one of its offering based on Apache and Tomcat, named JBoss Web Server:
  https://www.redhat.com/en/technologies/jboss-middleware/web-server

  and the latest update available (5.4, based on upstream Tomcat 9) in November 2020, had the bits for RH EL 6, 7 and 8. See also docs entry page here:
  https://access.redhat.com/documentation/en-us/red_hat_jboss_web_server/5.4/

  So it is non considered a dead technology, even for business use cases….

  Gianluca

• OK it looks like whatever I say is going to be taken to extremes so this will be my last email on this.

  I am not saying Tomcat is a dead technology. It is a technology which has certain use cases and deployments which the people I knew who used it are replacing with a different technology/service.

  EOF

• I’ll be the first to admit I don’t like change and arguably I’m in the wrong industry for that, but that’s another matter. However I don’t want to throw away years of experience with CentOS/Fedora and time invested (mine personally and my company’s) learning and perfecting setups of which I have now around 50. A fair few of my Ansible setup are EL only, both from Galaxy and custom. I’m used to the layout, the packages, and what you’d expect after ~10 years of working with it.

  At the moment my question possibly would have been better phrased “Why isn’t Streama suitable platform for a production web server”.

  I get that everyone including myself is frustrated by the situation and so I’m trying to filter out the doomsayers and those who want to annoy RH by saying they are jumping to another distro like Debian. To me, I’m thinking at least for my situation and has already been said, Stream might actually be a positive but I shall wait and see what happens. And as for the 5 years LTS, that will be the same for every distro anyway.

  Cheers Jamie

• Or you could move today to Springdale linux or Oracle or one of the new RHEL clones that will still be based on RHEL and have the same 10 year release cycle. Springdale and Oracle are options today and there are a couple more that are supposedly going to come online 1st or 2nd quarter, there are options.

• My considerations were only to balance the phrase “The various places that I worked previously or have contacts with have killed it off” and to enforce that Tomcat could still have its place nowadays; no intention to contrast you personally. Sorry if they gave this impression. And in fact you correctly wrote down “I honestly have no idea how much Tomcat is used anymore.” and “That is just an anecdata”.

  Gianluca

• It is , but expect rough edges. The differences will be :
  – Shorter lifetime .If you skip the first 2 minor releases -it will be shorter
  – No chance to “yum history undo last” as there are no older packages . You have to use Boom boot manager to rollback OS updates
  – More testing is needed as the chance that someone broke something is bigger

  Best Regards, Strahil Nikolov

• I’ve seen that mentioned as a change pretty frequently, but I don’t think it is in any meaningful sense.

  In CentOS Stream, package versions may be rebased periodically, and the public repos will no longer have older packages to install when using
  “undo” or “rollback”.

  In CentOS, package versions may be rebased at minor releases, and the public repos will no longer have older packages to install when using
  “undo” or “rollback”.

  It’s true that you might be able to roll back a simple patch in CentOS
  in between minor releases, but those are the updates that everyone seems to regard as being the safest, and least likely to cause problems, and therefore the least likely to need undo/rollback.  The only rational conclusion I can come to is that it doesn’t matter if you’re talking about CentOS today or Stream in the future: If you want to be able to roll back, you need a private mirror that keeps the package versions that you use.  If you don’t want a mirror, then you need to build, test, and deploy complete images rather than making incremental changes to mutable systems.  None of this is new, it’s always been this way and people have just accepted it.

• Didn’t the CentOS Vault repo ensure that every package ever published was still available?

• You should come to realizing that things changed. They are not what they were. With all fairness no one can say what will be true in a short future to come.

  Valeri

• Yes, it did, but that is not the intention for CentOS Stream moving forward. Only packages in CentOS Linux are moved to the vault at point release time. CentOS Stream only ever has the LATEST package version and nothing else.

  There is a bug filed for this issue here:

  https://bugzilla.redhat.com/show_bug.cgi?id=1908047

  If it is likely to be an issue for you, please make that known. The more people this affects, the more likely it may be addressed.

• 
  

  Well, let me just quickly chime in this thread … If you have already automated things (or not btw) for CentOS 8, current Stream (8-stream) will continue to just work.

  For CentOS Infra, I started to deploy Stream nodes and it continues to work fine.

  Fun fact : new coming Stream buildsystem infra *is* build exclusively on top of CentOS Stream … hopefully that would give people confidence about platform (dog fooding) :)

  Will there be some changes suddenly happening faster than in usual major.minor releases lifecyles ? yes

  Will it differ really ? well, it’s what coming in the same major.minor version that people *are* waiting for ..

  Is it perfect *now* ? probably not, but there is a chance to look at it and it’s up to (and not tied to Stream vs Linux effect imho)
  sysadmin/devops engineers/$pick-your-title-here in charge of infra to have validation platform before rolling out versions/updates/etc …
  (nothing *should* change here, except if one still manage single box like in the 90’s) ;-)

  With my SysAdmin hat on, I’d say that the only real impacting bit is the shorter lifetime (5y instead of 10), but with overlap between stream versions, so one would have time to have a look, reflect in automation, reinstall/migrate, enjoy

  Just my 0.02$ here

• Il 2021-01-08 10:01 Fabian Arrotin ha scritto:

  One key question, which seems to be somewhat unresolved, is if a clear in-place upgrading path from Stream-8 to Stream-9 will exist. Any news about it?

  Thanks.

• With my sysadmin hat on, I’d say wait for a bit of time for Rocky Linux
  (or whatever will be finally called) or Lenix to mature and check adoption, and if not satisfied (which I consider unlikely) move to Oracle Linux.

  Just forget all this cooking with Stream.

  If you wear another hat, you can see things differently, but as a sysadmin, to me the above course of action is clear.

  Cheers, Nick

• Le 08/01/2021 à 10:01, Fabian Arrotin a écrit :

  10 years of support instead of 5 has been the main argument here for using CentOS instead of Debian with the LTS repositories.

  —
  Microlinux – Solutions informatiques durables
  7, place de l’église – 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32
  Mob. : 06 51 80 12 12

• This exists:

  https://composes.CentOS.org/

  I think at some point there is a plan to make builds from koji also available, though we can’t right nwo (only the production instance is available and we can’t open it to alld/l because of bandwidth).