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
pgph0IlOCxiX_.pgp
Description: PGP signature
-- ripe-atlas mailing list [email protected] https://lists.ripe.net/mailman/listinfo/ripe-atlas
