On 2020/05/24 13:04 , Bernd Strehhuber wrote:
> with newer Linux Dists / glibc Versions (tested on Ubuntu 20.04 LTS)
> stime() has been deprecated and replaced with clock_settime().
> Busybox got the following commit back in 11/2019:
>
>
Hi Bernd,
On 2020/05/24 13:04 , Bernd Strehhuber wrote:
> with newer Linux Dists / glibc Versions (tested on Ubuntu 20.04 LTS)
> stime() has been deprecated and replaced with clock_settime().
> Busybox got the following commit back in 11/2019:
>
>
Il giorno gio 5 mar 2020 alle ore 16:08 Philip Homburg <
philip.homb...@ripe.net> ha scritto:
I pushed v5010.3 which fixes the prerm script. Unfortuantely, during an
> upgrade it runs the old script, so upgrading to 5010-3 will still remove
> the keys.
>
Just copy the new prerm script over
On 2020/03/04 11:14 , Enrico Ardizzoni wrote:
> This is the "prerm" script ( a little bit overkill :) )
I pushed v5010.3 which fixes the prerm script. Unfortuantely, during an
upgrade it runs the old script, so upgrading to 5010-3 will still remove
the keys.
Philip
On 2020/03/04 11:14 , Enrico Ardizzoni wrote:
> This is the "prerm" script ( a little bit overkill :) )
I'm not an expert in debian packaging. Does the prerm get executed
during an upgrade?
What I remember is that upgrading the debian package works, but maybe I
remember wrong.
Philip
Il giorno mar 3 mar 2020 alle ore 11:26 ha scritto:
Hi,
> You can update you new SSH Key on your probe's page such as
> https://atlas.ripe.net/probes/100/ on the bottom you see "Update SSH
> Key"
> Otherwise you can backup your two key files
> [/var/atlas-probe/etc/probe_key and
stallation, and
overwrite them back after new installation and reboot.
Cheers
Jiri
__
> Od: "Enrico Ardizzoni"
> Komu: "Philip Homburg"
> Datum: 02.03.2020 12:57
> Předmět: Re: [atlas] RIPE Atlas Software
Il giorno mer 12 feb 2020 alle ore 10:53 Philip Homburg <
philip.homb...@ripe.net> ha scritto:
For more details, see our new article on RIPE Labs:
>
> https://labs.ripe.net/Members/alun_davies/ripe-atlas-software-probes
What about upgrading a software probe?
I just do a "git pull", make a new
On 2020/02/16 16:23 , Jacques Lavignotte wrote:
> *Connection & Traffic* is firmly showing *No data available for Probe #
> 1000165 for this time period* since start.
>
> Do I have something to do more ?
Hi,
There are two issues:
The first is that by default, the software probe does not report
On Sun, 16 Feb 2020 at 17:00, Jared Mauch wrote:
> Wondering if it makes sense to have a Debian and raspbian repo stood up for
> this. I could easily add this to my clusters of raspi to make the coverage
> broader.
Even if the RIPE NCC team only provided pre-compiled binaries as
downloadable
Wondering if it makes sense to have a Debian and raspbian repo stood up for
this. I could easily add this to my clusters of raspi to make the coverage
broader.
Sent from my iCar
> On Feb 12, 2020, at 6:03 AM, Paul Eagles wrote:
>
> Great news!
>
> I'm having a few issues getting the
Dear Colleagues,
Probe #1000165 is up for about 3 days.
https://atlas.ripe.net/probes/1000165/#!tab-network
*Connection & Traffic* is firmly showing *No data available for Probe #
1000165 for this time period* since start.
Do I have something to do more ?
Rgds, Jacques
--
GnuPg :
On 2020/02/14 10:50 , Jaap Akkerhuis wrote:
> When the software probe projects started I offered to make a FreeBSD
> port version. The developers said that that was a good idea and
> they would come back to me.
A FreeBSD port would be nice, but may be a significant amount of work.
Philip
"Philip Paeps" writes:
> It should be fairly straightforward to run the software probe on FreeBSD
> under the Linux binary compatibility layer ("Linux personality
> disorder"). I've been meaning to poke at this but so many projects ...
> so little time.
When the software probe projects
On 2020-02-12 21:11:31 (+1100), Borja Marcos wrote:
On 12 Feb 2020, at 10:53, Philip Homburg
wrote:
For more details, see our new article on RIPE Labs:
https://labs.ripe.net/Members/alun_davies/ripe-atlas-software-probes
I am wondering, is the RIPE Atlas probe software fully Linux centric
Dear colleagues,
Probe #1000165 is up and running.
Le 12/02/2020 à 10:53, Philip Homburg a écrit :
Dear colleagues,
We are glad to announce that, after several months of development and
testing, we are now accepting applications for RIPE Atlas software
probes. With several different
On 2020/02/12 11:11 , Borja Marcos wrote:
> I am wondering, is the RIPE Atlas probe software fully Linux centric or can
> it run
> on other modern *IX derviatives?
The sort answer is yes, it is fully Linux centric.
The longer answer is that the code consists of two parts. One part is a
On 2020/02/12 12:42 , Philip Homburg wrote:
> On 2020/02/12 12:03 , Paul Eagles wrote:
>
>> fatal: reference is not a tree: 0615d3803b7b68cf85f959957b433f1c9fe2f3e6
>> Unable to checkout '0615d3803b7b68cf85f959957b433f1c9fe2f3e6' in submodule
>> path 'probe-busybox'
>> [pauleagles@dns2 ~]$
>
>
Hi,
> SW probes have tag "system-Software" and ID > 100
Technically, as of today, that's a good indicator and indeed can be used
to quickly judge whether a probe is software or not.
However, it's possible that in the future the probe ID allocation will
not strictly reflect the
Hi,
> Do you have interest in people having actual hardware probes in
> places where they also host VMs, to install also the software probes,
> in order to be able to "compare" them? I mean for your own stats, or
> to be able to debug issues, etc.
There are some deployments like that already.
Hi,
> Will these be tagged and de-selectable for new measurements?
Yes, the all have the tag "system-software".
> IOW, I've had enough bad experience with hypervisor packet loss and
> weird jitter for "anything that is not TCP based" that I wouldn't want
> to run anything where I'm interested
On 2020/02/12 12:03 , Paul Eagles wrote:
> fatal: reference is not a tree: 0615d3803b7b68cf85f959957b433f1c9fe2f3e6
> Unable to checkout '0615d3803b7b68cf85f959957b433f1c9fe2f3e6' in submodule
> path 'probe-busybox'
> [pauleagles@dns2 ~]$
Weird. It seems that the two repos are out of sync. I'll
Cheers
Jiri
__
> Od: "Baptiste Jonglez"
> Komu: "JORDI PALET MARTINEZ"
> Datum: 12.02.2020 11:15
> Předmět: Re: [atlas] RIPE Atlas Software Probes
>
> CC:
>Hi Jordi,
>
>On Wed, Feb 12, 2020 at 11:02:36AM +0100, JORDI PAL
Great news!
I'm having a few issues getting the Debian .deb file to build, I don't know if
it's something specific to my environment (though I've tried it on a few
different boxes) or an issue with the git repository, but:
[pauleagles@dns2 ~]$ git clone --recursive
I have a hardware probe on an LTE router at home, and my Ubuntu box
(with a galmon [1] probe connected) next to it is on another AS, so
maybe I'll try this :-)-O
I'd also love a version for the mac, by the way.
[1] https://galmon.EU
greetings, el
On 12/02/2020 12:02, JORDI PALET MARTINEZ
Hi Jordi,
On Wed, Feb 12, 2020 at 11:02:36AM +0100, JORDI PALET MARTINEZ wrote:
> Nice, thanks a lot for this!
>
> Do you have interest in people having actual hardware probes in places where
> they also host VMs, to install also the software probes, in order to be able
> to "compare" them? I
> On 12 Feb 2020, at 10:53, Philip Homburg wrote:
>
> For more details, see our new article on RIPE Labs:
>
> https://labs.ripe.net/Members/alun_davies/ripe-atlas-software-probes
I am wondering, is the RIPE Atlas probe software fully Linux centric or can it
run
on other modern *IX
Hi Philip,
Nice, thanks a lot for this!
Do you have interest in people having actual hardware probes in places where
they also host VMs, to install also the software probes, in order to be able to
"compare" them? I mean for your own stats, or to be able to debug issues, etc.
Do you also have
Hi,
On Wed, Feb 12, 2020 at 10:53:47AM +0100, Philip Homburg wrote:
> We are glad to announce that, after several months of development and
> testing, we are now accepting applications for RIPE Atlas software
> probes. With several different installation options to choose from,
> software probes
29 matches
Mail list logo
