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 <[email protected]> wrote: > > On Mon, 30 Jan 2023 at 13:34, Robert Kisteleki <[email protected]> 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 >> [email protected] >> https://lists.ripe.net/mailman/listinfo/ripe-atlas > > -- > ripe-atlas mailing list > [email protected] > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list [email protected] https://lists.ripe.net/mailman/listinfo/ripe-atlas
