Many of you contribute to RIPE Atlas by running one or more software probes. Thank you for doing so!
In the case of software probes you, the host, are in control of the installation and upgrade process. We noticed that there are many probes that have been installed, but not upgraded over time.
We’d like to inform you that early next week we’ll activate a feature in the system where we’ll periodically remind software probe hosts with non-newest versions to upgrade their probes. We expect that at some point later we’ll also start enforcing the use of newer versions.
Please note that since we provide multiple binary releases, it’s also possible to set up automatic package updates for the popular platforms (Debian, RHEL, Raspberry). We’d recommend using this feature (in general, not necessarily just for the probe package).
Ahoy, I’m running Atlas Probe on Turris Omnia as provided by Turris team. Not finding any relevant information, so I think update will need to be provided by Turris developers.
Hi, I’m running Atlas Probe on an OpenWrt router. However, the package atlas-sw-probe is very outdated, and we can’t find any useful infomation. Maybe think update will need to be provided by OpenWrt developers.
An official, tiny, self-updating VM image might improve the situation significantly. Just like a hardware probe, but as a VM. Set up once, then forget. Could be based on OpenWrt.
Many probe hosts, myself included, rely on community-maintained ports like the OpenWrt package, which aren’t always up-to-date. The official packages require a full Debian or RHEL installation which is overkill in terms of system requirements, especially if you run multiple instances.
I currently host four software probes, each in its own OpenWrt VM. Migrating them to Debian would require gigabytes of additional RAM, for no good reason.
In my opinion, that “someone” should be the RIPE Atlas team (or someone contracted by them). Letting third parties maintain stuff on a voluntary basis contributes to outdated probes.
If there is no funding for maintaining a VM appliance, at least taking ownership of the OpenWrt package might improve the situation significantly. It would be interesting to know what percentage of outdated software probes comes back to the outdated OpenWrt package.
I was considering the container option, but the network configuration seems to be rather complex when running multiple probes (for multiple ASNs) on the same physical machine.
In contrast, with VMs, just assign the vNICs to the correct VLANs or physical NICs, done. The host OS doesn’t have to get involved in layer 3 stuff at all.
I fully support the goal of keeping probes in the field up-to-date and reminding probe hosts to do so is a good idea. But it should be easier to keep probes up-to-date.
In general the Atlas team has only so much capacity to support the various platforms; OpenWrt and Docker are community efforts today, and both seem to be actively supported (if only with some nudging ).
If you’re using 5080 on OpenWrt 25.12.x and want to try 5130 on OpenWrt snapshot, this is what worked for me:
owut upgrade -V SNAPSHOT -a ripe-atlas-probe -r atlas-sw-probe --force
Since the current snapshot doesn’t include the migration feature yet, I did let it create a new ssh key and updated it on the probe’s page. Seems to work.
Look, yeah, the migration was the hardest nut to crack, which is why it took so long. Anyone could have pitched in and taken a look at it. Unfortunately, I was tied up with a bunch of other things.
I can’t really see users or the RIPE Atlas SW probe community regenerating their SSH keys and replacing them somewhere. That would be more of an exception.
Anyway, the latest version of the RIPE Atlas SW probe is available across all OpenWrt releases (daily snapshots, OpenWrt 25.12, and OpenWrt 24.10).
Thank you for the timely update and reminder! Running a software probe is a great way to contribute to the RIPE Atlas network, and keeping them up-to-date is definitely important for stability and security.
Thanks for pointing out the automatic package update option for platforms like Debian, RHEL, and Raspberry Pi—setting that up will definitely make maintenance much easier for hosts.
Appreciate all the hard work the RIPE NCC team puts into keeping the network running smoothly!
