[atlas] Encouraging people to upgrade software probe versions

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