I don't care they're gating this behind a subscription but the fact that they won't even tell you that you're missing an important security update? That's bad. I wonder how many people think they are fully up to date while being vulnerable to known bugs.
They do tell you that you are missing now. On ubuntu 24.04, apt now reports/nags me about security updates behind esm-apps.
They also publish an oval xml for use with openscap tools to get a list of unpatched CVEs. The issue is not enough people know about those tools.
https://security-metadata.canonical.com/oval/
Aha, thanks. I'm trying to look up the CVE on https://ubuntu.com/security/notices and the site's search responds with "504 Gateway Time-out" or "500: Server error". Come on Ubuntu.
They finally agreed to publish OSV data in addition to OVAL. OVAL XML files are terrible to use, and OSV is amazing in comparison, so this will get more tool adoption.
> I don't care they're gating this behind a subscription
I rather not have them push an ad to my face when I open the settings.
I had to install Ubuntu on an embedded board last week and the "Ubuntu Pro" ad is like a greyed out tab in the settings widget if I remember correctly. Worse than the Amazon ad they had some decade ago.
Most Ubuntu users don't know that Canonical only supports the main repository for free.
To my knowledge, only some comments hidden in /etc/apt/sources.list mention this, but the more honest approach would be to warn all users when they try to `apt install foo` some package from universe/multiverse. Or do it like RHEL with their EPEL repo and disable it by default.
But I guess they would have never gotten this popular if people saw that Ubuntu is only a few thousand packages compared to Debian's tens of thousands.
It used to be that Ubuntu had more resources to test against various laptop hardware. These days, it's much easier to buy hardware that just works with any kernel.
Unless you intend to pay for support, I see no reason to not prefer Debian in 2024.
The updates in universe are definitely best effort.
We were paying for Ubuntu Pro through an AWS subscription on 2k EC2 instances, and could not get Canonical to update a package with a CVSS 7.8 in the 18.04 LTS.
If I was looking for a distro with paid support (a la RHEL/Ubuntu) that's also not incredibly behind bleeding edge (maybe not as bleeding edge as Arch, but also not running patched-to-hell-and-back software like Ubuntu), what are my options?
Thankfully I'm not personally looking for this at the moment, I'm more than happy being my own sysadmin and running anything from Arch to Fedora CoreOS to OpenSUSE on my machines.
afaik, your want of relatively fresh software with few patches excludes pretty much everything there is, except for really niche stuff. All other major options with good commercial support have been mentioned by siblings; I'll add Debian + Freexian to the list.
I wish people would stop recommending Rocky. It's a ticking time bomb IMHO caused by their decision to not play nicely with Red Hat and go for questionable tactics like renting temporary RHEL instances to download premade source packages, instead of working together as RH asked them to do. Anybody reading this, do yourself a favor and use Alma, or skip the RHEL ecosystem altogether if you don't absolutely need it.
Otherwise you're building on an operating system which rebuilds a commercial upstream while explicitly refusing to follow that upstream's rules. IBM has lots of experienced lawyers, as I've heard.
It's also slower at releasing updates, including security updates.
------
Sorry SSLy, I can't reply to you directly because I'm rate limited, it's very late here, and I'm not waiting for the rate limit to expire. So here's my reply:
I think previous decisions made by IBM have shown that they're fine at burning some community goodwill for short-term profit. People were called paranoid for worrying about the future of CentOS when it was taken up by Red Hat for "improved maintenance", and look where we are now.
Maybe you're right, but I personally wouldn't want to build anything serious on top of that "maybe". If something happens, lateral migration should theoretically work, of course..
IBM suing Rocky for what they're doing means industry wide crisis about what the FOSS provisions really mean. Their competition would welcome such self sabotage with arms wide open.
Of course they could release the code just for the *GPL packages, but it's an option only slightly less bad socially.
Now, I wonder why there's no one rebuilding Ubuntu Pro like folks are rebuilding RHEL.
> ...what are my options?
> ...Maybe it is time to go back to Debian, as they seem to release these fixes to their users?
Curious if this would actually be a solution. They state that fixes in Debian are down-streamed regardless of support, so if this fix wasn't down-streamed, then why would it be in Debian ?
As for why it isn't in Ubuntu 22.04 - perhaps because the Ubuntu release schedule does not match debian's.
Debian buster was released in september 2022 - Ubuntu's April tagging is probably based off of the prior debian release which only gets critical updates.
I'd argue we wouldn't have Snap [for the better] if their LTS releases weren't visually bound to years... saving overhead they regularly create for cosmetic reasons.
Wouldn't have to create it to consolidate platforms if they stopped making them so often!
They have three concurrent LTS releases when they need one. Maybe two. 18.04 is the python2 of distributions. Let it go.
Having worked in several places that relied on it... ESM is being the bad kind of enabler.
Fedora handles "The Snap Problem" -- many target distributions -- with 'fedpkg' and 'mock'. Software and machines on the build side. Not by degrading the end user experience. They do participate with Flatpak... but that's peer pressure more than anything.
Flatpak is more well-rounded IMO. Probably from being the broader answer. Maybe this all doesn't make an argument. Just a bunch of statements. I don't know.
Back on topic: I wonder what all of this Canonical stuff in particular is for/leads to. New software isn't scary; 'just' plan/test. It becomes scary when you get lazy here... so accept your involvement.
I suppose I doubt the proposition of '10 year support' - admittedly I haven't done anyone else's job for them.
I don't know if that necessarily means stop selling the product... but tighten up the terms, I guess? Anyone choosing to stay on something that old has chosen those gremlins.
The build of systemd and firewalld on 18.04 are both categorically broken. I don't know whatever people are solving with that old release (and Canonical in support)... but it's less than what those two things do for me when working properly.
The illusion of support for something so decrepit creates more problems than it solves in my experience. Either bite the bullet and modernize/upgrade... or keep playing with the unsupported sands of time
> The build of systemd and firewalld on 18.04 are both categorically broken.
Were they categorically broken back in 2018? What would you have recommended companies do around that time frame, if they wanted to use Ubuntu?
If it was acceptable at the time, then it's not a reason to rush off onto a new release where something else might be categorically broken. Even if it sucks, you already figured out how to deal with it during the first couple years you had it deployed.
If it was completely unacceptable at the time, then what do you do? You can't not have servers.
> something so decrepit
Most server code is not going to get very out of date over the course of several years. It's not significantly more decrepit than the day it was deployed.
Node.js code would be one of the things outside this "most". Though I don't know if those users would have had the distro version of node to begin with.
> Were they categorically broken back in 2018? What would you have recommended companies do around that time frame, if they wanted to use Ubuntu?
They were and still are. The irony: the fix need not be breaking/demand a new major release.
> Most server code is not going to get very out of date over the course of several years. It's not significantly more decrepit than the day it was deployed.
That's my point. It was broken from the beginning.
Reminder: 'firewalld' is a management daemon for N firewalls. You use it exactly because you don't care about implementation details like the backend. It's not even part of the default Ubuntu install. Just offered.
Most users wouldn't see it, I don't judge that. I judge how Canonical behave{s,d}.
I would have recommended they, the integrator/procurer of the distribution, avoid the 'iptables' backend for 'firewalld'... a release or two before 18.04. Not even this one. It was well on the way out already/communicated/ignored.
If they wanted to fix it 'breaking upgrade' style, they had at least two chances. They could also avoid the rake-kickflip of the '--wait' option.
Final point being: I'm not here to do their work. A distribution is a collection of software. They chose to offer it, not me.
Just because I - the seasoned administrator can find/fix the problem - I shouldn't have to. I like a compelling experience too. This odd mixing isn't it.
I will fully admit to seeking out the problem in... asking to install firewalld. Not offering the packages at all, instead of poorly joined, would be an improvement. I'm not without options. I don't need poor ones.
To be clear: I'm not yelling into the void. This was reported to their bug tracker in at least 2019. I escalated it to them through $EMPLOYERS. Several. Canonical's support means jack to me.
"Vendor support" is largely a Bogeyman and compliance racket IMO. I've, outside this wild thread, otherwise moved on to nicer pastures!
> They already put it into production though, so that's not very relevant to deciding when they move off of it.
It's one of those "if a tree falls in the woods" scenarios, though. It's not a default-install package.
People who selected it already dealt with it or keep running into it. Changing the backend won't even affect them; config edits are preserved.
To add (one final poor point): they're a tiny minority! This production is like... nothing.
Fixing it/changing course/introducing 'breakage' (a correction) is less adversarial than leaving it broken IMO.
There were several ways to approach this, some more user visible than others...
The 'proper' thing, changing the backend, would've been felt. Patching the errant argument use was also entirely an option. They even had several actual LTS' to do this in!
The 'service life', like the cake, is a lie. While we debate best practices - they fail to execute them!
I appreciate you putting up with my rambling though
Your free personal Ubuntu Pro subscription does in fact cover as many VMs and containers as you can run on up to five personal machines, as the OP well knows. I like that we make Ubuntu Pro, including universe updates, free for anyone running at small scale.
Thanks for the reply and the correction. I've updated the post to reflect this. I'm sure it will be helpful for others, as the UI doesn't reflect that these containers do not come out of the overall allocation. As you'll see in the screenshot I've added, it looks as if these are being counted as 8 physical machines against 5 tokens.
It's possible to fix anything from the sources but I guess the Tomcat version in 22.04 didn't have a corresponding stable Debian version? (vs. the 20.04 version)
Confirmed, the tomcat 9.0.58 in Ubuntu 22.04 is not in bookworm/stable (which is on 9.0.70) or bullseye/oldstable (which is on 9.0.43), and the 9.0.31 in Ubuntu 20.04 is the same as the version in Debian buster.
Ubuntu is merely reusing apt to connect to its own repositories. You could manually install packages from Debian's repositories, but it's probably inadvisable.
At one point Ubuntu changed the EOL tables on their Wiki from 5 years to 10 with no explanation about applicability/ESM - just calling it LTS.
It is among the longest pages on our website.