Lukas, Keep in mind that - as I experienced - any VM or Docker container introduces some problems, such as higher latency. My CentOS VM has 2 ms. higher latency in the first hop compared to a v5 probe on the same fiber. And a bug in Docker causes traceroute to fail. So a hardware or a native install of a software probe is the best way to go. Regards, Ernst J. Oud
On 30 Jan 2023, at 14:07, Lukas Tribus <lukas@ltri.eu> wrote:
On Mon, 30 Jan 2023 at 13:34, Robert Kisteleki <robert@ripe.net> wrote:
Hi,
To me it seems that there are oh-so-many ways of packaging and distributing this software to the match the multitude of needs (RPMs, DEBs, openwrt, docker, VMs, ...) and us giving support to multitude of these stretches our resources thin.
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.
What's worse? A lot of outdated, unhandled probes without upgrade instructions or a slight decrease in the number of probes?
As I wrote before, such packaging would be preferably achieved via professional maintainers.
This is really not that realistic.
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.
The "number of probes" can't be the only benchmark here, we need to benchmark "the number of probes properly handled running supported software".
Lukas
Is there an actual reason, why it was decided to let users manage the software probe installation?
The intention here is/was that many users already have their own machine (VM or server or home router or such) that can be used as the platform. One can also easily spin up and dedicate a new HW, like a lingering Raspberry Pi, to this.
Cheers, Robert
On 2023-01-27 10:43, Simon Brandt via ripe-atlas wrote: Hi Robert,
The existence of software probes is great, but instead (or besides) of providing packages or source code, why not distribute a prebuild VM as OVF file?
Advantages: - The RIPE Atlas team manages the whole OS, like it's doing for the hardware probes. Thus, updates can be deployed whenever needed. - You can even use OpenWRT as VM operatingsystem. This means all the same premises/conditions as for hardware probes. - an OVF file is easier to deploy, for the community - RXTXRPT switch is obsolete - No more false RXTXRPT data, since the report counts all traffic of the host, not only the traffic that is generated by the SW probe application.
Is there an actual reason, why it was decided to let users manage the software probe installation? Please consider to distribute a prebuild VM *additionally* to the existing ways and see what happens. I'm sure, most new users will choose a prebuild VM.
BR, Simon
On 19.01.23 12:48, Robert Kisteleki wrote:
That is reasonable; the difference is that we are not in control; the host OS is. Redhat/Fedora/derivatives as well as Debian/derivatives have an official solution to this via their package management services and I believe this is the standard way (surely with exceptions :-) ) of handling these matters. We are in the process of adopting these.
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas