[CentOS-devel] Before You Get Mad About The CentOS Stream Change, Think About…

On Mon, Dec 28, 2020 at 4:06 AM Japheth Cleaver <cleaver at terabithia.org> wrote:
>
> On 12/24/2020 11:21 PM, Ljubomir Ljubojevic wrote:
> > On 12/23/20 11:43 PM, Gordon Messmer wrote:
> >> It's pretty close, with one significant caveat: for (roughly) two months
> >> out of the year, CentOS doesn't get any updates at all, including
> >> security patches.  For me, that's an awfully big risk. I would much
> >> rather get features on a regular basis than go without security patches
> >> for a month, twice per year.
> > Every CentOS user accepts this as part of the "free" offering. Anyone
> > that has problem with this gap has bought RHEL subscription, as would
> > have I if it was important enough for me.
> >
> > But I would not have said there are no security for entire 2 months
> > because CentOS devs have been pushing important security updates into CR
> > repooitory for instance, if I remember correctly. But again, you are
> > either OK with the wait or you buy RHEL subscription, that was the deal
> > everyone accept.
>
> It's also worth pointing out that in cases where we're known to be in a
> delay period (such as just after a point release) or where there's a
> critical CVE and neither RHEL nor the CentOS updates have dropped, it's
> not uncommon for a critical update to just be rolled internally.
>
> Take the existing SRPM, apply patch, call it N-V-R.1+ test the fix, sign
> and insert into your private yum repo that you inevitably have. Done.
> When the upstream and/or vendor fix is released, it will silently
> upgrade in place over yours with the official version. Large CentOS
> installs have teams of Linux systems engineers capable of doing this if
> a relevant security fix needs to go out.

Unless, of course, internal '%{name}-%{version}-%{release}" number
exceeds that of the published release. Been there, done that. It
requires careful control of versions and release numbering, with no
use of "Epoch" settings, to avoid your internal kernel being
considered more "recent" than whatever version and release number the
next upstream kernel provides. Large CentOS installs typically have
one or two engineers who might handle both kernel integration and
release integration. especially because it crosses departments with
hardware testing, QA, and resource management for the reboots. In a
bunch of places I've worked, it's been *me*.

> But this depends on having a predictable upstream, and a stable
> foundation on which to build on top of. I.e., coherent OS release
> management with /updates/ layered over it. CentOS CR/Stream does not
> have this, which is why it is not generally suitable for production use
> on actual, persistent boxes.

Yeah. We're going to wind up with people declining the update to
CentOS 8, or maintaining internal "snapshot" repos, probably
timestamped. You could actually do it with "rsnapshot" and more sane
snapshot numbering scheme.