[CentOS-devel] Wireguard and c8S headache - ?

Fri Jul 22 15:53:04 UTC 2022
Josh Boyer <jwboyer at redhat.com>

On Thu, Jul 21, 2022 at 3:51 PM Phil Perry <pperry at elrepo.org> wrote:
> On 21/07/2022 14:37, Josh Boyer wrote:
> > On Thu, Jul 21, 2022 at 9:25 AM Phil Perry <pperry at elrepo.org> wrote:
> >>
> >> It is a shame that RH/Stream are unable to support the WireGuard CI.
> >>
> >> In addition to Oracle, you could also use RHEL or Alma or Rocky or any
> >> other supported distro/kernel.
> >
> > In this case, I think CentOS Stream is actually catching things as we
> > expect.  The next RHEL release (and therefore Alma, Rocky, or any
> > other rebuild) will have the same issues if the changes aren't made
> > before then.  There's a bug reported for this and the resolution was
> > that the out of tree Wireguard module for EL8 needs to stop defining a
> > particular function in a header.
> >
> The issue is that the C8S kernel will not run on the WireGuard CI [1],
> so WireGuard are unable/unwilling to address these issues upstream as
> part of their continuous development (as they do for every other kernel
> they backport to), _before_ they become an issue. If the C8S kernel ran
> on the WireGuard CI, these issues would get fixed at source and you
> would never see these filed bugs or mailing list threads.

Thanks for the link to that post.  I hadn't seen it.  I think Jason
did a good job of explaining the situation and was fair to all

> WireGuard filed numerous bugs [2,3] with patches with Red Hat to get the
> Stream kernel running on the their CI, which Red Hat eventually declined
> to accept (and I totally get the reasons why), so WireGuard eventually
> gave up and dropped support for CentOS Stream.
> The next best solution (other than getting Stream running on WireGuard's
> CI) would be for the kmod SIG (or some other 3rd party provider) to fix
> the code and ship kmods for Stream, but obviously that takes time and
> users are potentially left with a broken VPN each time a new kernel
> update is pushed. But it looks like upstream have lost interest in
> supporting Stream which is a shame.

I do think it would be great if we could get more participation in the
kmod SIG here.  Building kmods for RHEL is indeed different than
building for older upstream kernels as Jason highlighted, and it seems
like handling that difference is exactly what the kmod SIG would be
well positioned to do.

Given that the recent build issue is something I already briefly
looked at, I figured I'd go ahead and fix it.