[atlas] Encouraging people to upgrade software probe versions

Hello Lukas,

On Mon, 30 Jan 2023, Lukas Tribus wrote:
> Which is why a unified approach is needed.
> 
> Drop all SW support and do dedicated VMs only for SW probes?
> Drop all SW support and do Docker only for SW probes?
> 
> I don't think doing everything with questionable quality is a desired outcome.

similar like with RPM packages for software probes, Docker/OCI container
based software probes have issues as well, which might lead to questionable
quality: The typical standalone Docker (or Podman) setup does not update
any container images. And while performing some runtime-based updates
inside the container might work (IMHO only partially, less on long-term),
it has to be repeated after host reboots and/or Docker/Podman updates, if
nobody updates the container image on the host itself. This also requires,
for runtime-based updates inside the container, an endless upgrade path
from oldest to latest versions be kept on an update server, otherwise you
could end up with a poorly outdated (or defunct) container-based software
probe, too.

From my point of view, any non-hardware probe might lead to questionable
quality, if the administrator doesn't maintain its environment properly.
But maybe that's just an obligation for software probes that needs to be
accepted? Because even administrators of hardware probes have obligations:
Connect the probe (and, at least historically, handle the USB flash drive
issues after some time).

> Debian and Red Hat repositories are not all designed for this: they
> don't update their packages in stable releases, they backport changes
> eligible based on their backporting policy, which doesn't address this
> problem at all. Vendoring (shipping your own libssl for example) is
> also not allowed at least in Debian, I doubt it is in RedHat.

As the Fedora and EPEL packager who came up with the idea to finally ship a
policy-compliant RPM of the current software probe RPM in Fedora and EPEL
repositories, I would like to clarify that: The software probe would not be
in the official RHEL repositories itself (would require coordination of
updates with Red Hat regarding release cycles, freezes etc., there can be
rebases instead of only backports, usually in the first 5 of 10 years of
the RHEL lifecycle), but in Fedora and EPEL repositories. EPEL is a Fedora-
driven add-on repository, commonly used, which IMHO adds the real value to
RHEL/clones. Updates to EPEL packages can also happen at any time, updates
are landing after 7 days in testing repository in stable repository, if no
negative karma has been added (practically it's 1-2 days more, depending on
when the update was exactly submitted and the signing/pushing cronjobs are
run).

EPEL permits package updates/rebases during the full RHEL lifecycle with
the expectation of compatibility, but that's anyway targeted for probes,
especially for the hardware probes.

A realworld example for package updates/rebases is OpenBSD rpki-client,
which I walked over time from 0.2.0 to (currently) 8.2 in EPEL 7. Similar
is BIRD, from 2.0.2 to 2.0.12 in the last 5 years in EPEL 7. While these
packages are mostly trivial, there are also soname version bumps (changed
ABIs) with coordinated rebuilds of dependent packages.

Vendoring in EPEL is not excluded, but also not liked (sometimes it's just
needed; Red Hat's security team also nicely files bug reports for security
flaws on a best effort base for these bundled libraries, requires however
packagers to mark such bundled libraries according to the packaging policy
properly).

And to catch up your specific libssl example: I am maintaining OpenSSL 1.1
(taken from RHEL 8) in EPEL 7 to provide e.g. TLSv1.3 support to other RPM
packages in EPEL. There is also OpenSSL 3 (taken from RHEL 9) in EPEL 8 to
provide OpenSSL 3 APIs to other RPM packages in EPEL (this works because
RHEL 7 reaches EOL before RHEL 8, RHEL 8 reaches EOL before RHEL 9). I am
maintaining it in EPEL 7 for about 3 years now, because OpenBSD rpki-client
requires OpenSSL >= 1.1 rather than OpenSSL 1.0.x as shipped in RHEL 7.

I can not speak for Debian, but as a system administrator also using Debian
here and there...their releases and updates are IMHO not that flexible and
agile.

Last but not least: An RPM package of a software probe could IMHO allow a
virtual machine image preconfigured for DHCP/SLAAC etc. with auto-updates
from a RHEL clone. Should reduce the administrator's maintenance work quite
a lot, no?

Finally: I see usecases for hardware probes and software probes (and there
for at least RPM packages, containers and virtual machines). And it leaves
some responsibilities to their administrators depending on their decision
of the type - even for hardware probes.


Regards,
  Robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: </ripe/mail/archives/ripe-atlas/attachments/20230131/6650ed13/attachment-0001.sig>