As we begin to prepare for the 3.1 release, we’ve decided to drop support for EL7 (Enterprise Linux 7) which will be officially end of life in June of 2024.
We made this decision because Open OnDemand version 3.1 will - in all likelihood - be supported past that date June 2024. This means we are likely to continue to patch 3.1 past June of 2024.
So to provide updates to 3.1 to all platforms (and not have to pull support after the release) we’ve decided to drop support for EL7 for this upcoming release. Meaning, in sum, centers running EL7 will not be able to upgrade past 3.0.x until they upgrade their operating systems.
This is mostly due to how we build packages. Our continuous integration uses Centos:7 to build RPMs. We can’t build these packages using ELS licenses on RHEL7 containers. So once the Centos Repositories become inaccessible, we’ll be unable to build packages. We could technically build against the archive repos but that’s asking us to support an operating system that the vendor no longer supports without paying for ELS licenses, which we don’t have the bandwidth to handle.
Beyond our ability to build packages (or lack thereof) we have concerns about continued support for dependencies for that platform. We (OSC) builds RPMs all the time, but I’m weary of the prospect of rebuilding and distributing packages like ruby, nodejs or httpd24-httpd as I can imagine we’d need to at some point for some package.
el7 is supported until end of June 2024, 8 months from now. Extended support will be offered for 4 more years, until June 30, 2028.
But even besides that, there are probably a number of sites that will continue running it on existing systems, especially those which are on their downhill phase and were a full OS upgrade or a transition to an entirely different OS is not really worth the effort.
Isn’t the decision to drop el7 support a bit premature?
I think this makes sense. It’s not unreasonable to expect a site to spin up something rhel8 based even if it ends up just being for the OOD host. Actual workflows are assumed to run on the compute resources so there is no issue of modules not working etc. Even if you weren’t to move your whole compute infrastructure to a newer OS, what’s the problem of just updating your OOD host?
what’s the problem of just updating your OOD host?
We don’t have just one OOD host, we run many. But more importantly, one does not just update one server, pets vs cattle and all that
My point was just that el7 is still supported today, and will continue to be used for some time. So I just wanted to give some feedback from the trenches regarding this announcement.
Well, this comes just as we were considering upgrading the OOD host anyway, in order to address vulnerability issues (or is there a simple way of upgrading httpd24-httpd beyond the last version supported by el7 scl, in order to keep using el7 for a while longer?)
is there a simple way of upgrading httpd24-httpd beyond the last version supported by el7 scl, in order to keep using el7 for a while longer?
Short answer no. Long answer, there are really ugly ways to get newer versions. You could always take the SRPM from RHEL or CentOS and extract the SPEC and sources and bump the version and strip some of the patches that might no longer be valid. I wouldn’t recommend this but it’s possible.
Though I’d always be wary of security scans telling you you’re vulnerable if all the scan looks for is version. RedHat back ports countless security fixes into things like Apache and the Kernel and even Python 2.7 well past the end of upstream support from the authors of that software. I don’t recall if I’ve seen updates into the SCL Apache in a while but if the CVE is critical or important then I’m fairly certain RedHat will back port into httpd24-httpd.
Short answer no. Long answer, there are really ugly ways to get newer versions. You could always take the SRPM from RHEL or CentOS and extract the SPEC and sources and bump the version and strip some of the patches that might no longer be valid. I wouldn’t recommend this but it’s possible.
Yeah, I started doing that but didn’t get very far
Though I’d always be wary of security scans telling you you’re vulnerable if all the scan looks for is version
I agree, but that’s above my pay grade
RedHat back ports countless security fixes into things like Apache and the Kernel and even Python 2.7 well past the end of upstream support from the authors of that software. I don’t recall if I’ve seen updates into the SCL Apache in a while but if the CVE is critical or important then I’m fairly certain RedHat will back port into httpd24-httpd.
Hm, last update to httpd24-httpd for el7 will be one year old tomorrow…
Feedback is always welcome! I appreciate you hopping on here and giving your concerns. I’ve updated the original comment a little to provide a little more reasoning (and a link to a NIST vulnerability!)
The TLDR is basically that basically I think OnDemand 3.1 will be supported past the Centos:7 EOL (June of 2024) and it’ll be very hard to build Centos:7 packages after that time. Not to mention all the headaches that come with dependencies.
I get the point, no worries, thanks for providing that context and rationale.
And I fully understand the concern about future updates as well, but I just wanted to point out that CVE-2023-25690 has been patched in el7’s SCL back in May, and that the fix is included in httpd24-httpd-2.4.34-23.el7.6.
Thanks for that heads up - I’ll update the comment for the same. It’s hard for me to read all this errata, especially when the version remains the same.
@kilian I don’t see httpd24-httpd-2.4.34-23.el7.6 in the CentOS mirrors, latest version there is httpd24-httpd-2.4.34-23.el7.5 from a year ago - is it the case that the one patched in May is only available with a RHEL subscription, or am I missing something?
