Automating software probe creation?
I’m working on creating some Raspberry Pi-based software probes, to put in some networks that currently lack Atlas probes. I’d like to have a standard image that can come up and work wherever an individual probe lands, instead of needing to configure each one separately. As far as I can tell from the documentation, it looks like the probes are identified by the encryption keys in /var/atlas-probe/etc/probe-key* . If creating new probes from an image, is it sufficient to make each probe generate its own encryption keys, or are there other files that need to change? For registering the probes, I see a web form that requires being logged into a RIPE account, and don’t see any equivalent in the API documentation. Is there a way to register new software probes via the API? Thanks, Steve
Hi Steve, About your first question, if my memory serves well, I did it exactly that way a few months back. I ended up automating probes registration with curl and a trivial shell script. Let me know if you need assistance. Happy new year, Pierre. On Sat 2 Jan 2021 at 08:26 Steve Gibbard <scg@gibbard.org> wrote:
I’m working on creating some Raspberry Pi-based software probes, to put in some networks that currently lack Atlas probes.
I’d like to have a standard image that can come up and work wherever an individual probe lands, instead of needing to configure each one separately.
As far as I can tell from the documentation, it looks like the probes are identified by the encryption keys in /var/atlas-probe/etc/probe-key* . If creating new probes from an image, is it sufficient to make each probe generate its own encryption keys, or are there other files that need to change?
For registering the probes, I see a web form that requires being logged into a RIPE account, and don’t see any equivalent in the API documentation. Is there a way to register new software probes via the API?
Thanks, Steve
On 2021/01/02 8:25 , Steve Gibbard wrote:
As far as I can tell from the documentation, it looks like the probes are identified by the encryption keys in /var/atlas-probe/etc/probe-key* . If creating new probes from an image, is it sufficient to make each probe generate its own encryption keys, or are there other files that need to change?
If you build the debian package, then you can install that as many times as you like. Probes are indeed identified by their public keys.
For registering the probes, I see a web form that requires being logged into a RIPE account, and don’t see any equivalent in the API documentation. Is there a way to register new software probes via the API?
We are working on an API. However, the only thing the API will do is to copy the public key to the atlas backend systems. You still have go to the web size, log in, etc. We want to associate a user with each probe. Philip
Hi, Philip - a happy new year to you and everybody here on this list, first of all! On 04.01.2021 11:53, Philip Homburg wrote:
We are working on an API. However, the only thing the API will do is to copy the public key to the atlas backend systems. You still have go to the web size, log in, etc. We want to associate a user with each probe.
IANAP and therefore probably miss a crucial point here: but can't user identification, authentication and so also probe-to-user association be done via an API, too? Best, -C.
On 2021/01/04 12:57 , Carsten Schiefner wrote:
IANAP and therefore probably miss a crucial point here: but can't user identification, authentication and so also probe-to-user association be done via an API, too?
That may become too complex. RIPE NCC currently has no API that allows a user to log in. Logging in goes through a web form. What we can do (in theory) is support logging in through a web form and then creating an API key for probe registration (similar to keys we have for creating measurements). Then the user can install the API key on the probe and then register the probe using an API. However, that seems overly complex. In addition it would be nice to name a probe, give it a location. So there is a need to go to the website anyhow. Of course it can be requested as feature. If there are good use cases, we can put it on the list of things to look at. Philip
I see. Thanks for explaining the backgrounds, Philip. -- Von meinem Android-Gerät gesendet. -----Original Message----- From: Philip Homburg <philip.homburg@ripe.net> To: Carsten Schiefner <carsten@schiefner.de> Cc: ripe-atlas@ripe.net Sent: Mo., 04 Jan. 2021 13:12 Subject: Re: [atlas] Automating software probe creation? On 2021/01/04 12:57 , Carsten Schiefner wrote:
IANAP and therefore probably miss a crucial point here: but can't user identification, authentication and so also probe-to-user association be done via an API, too?
That may become too complex. RIPE NCC currently has no API that allows a user to log in. Logging in goes through a web form. What we can do (in theory) is support logging in through a web form and then creating an API key for probe registration (similar to keys we have for creating measurements). Then the user can install the API key on the probe and then register the probe using an API. However, that seems overly complex. In addition it would be nice to name a probe, give it a location. So there is a need to go to the website anyhow. Of course it can be requested as feature. If there are good use cases, we can put it on the list of things to look at. Philip
On Jan 4, 2021, at 4:11 AM, Philip Homburg <philip.homburg@ripe.net> wrote:
On 2021/01/04 12:57 , Carsten Schiefner wrote:
IANAP and therefore probably miss a crucial point here: but can't user identification, authentication and so also probe-to-user association be done via an API, too?
That may become too complex. RIPE NCC currently has no API that allows a user to log in. Logging in goes through a web form.
What we can do (in theory) is support logging in through a web form and then creating an API key for probe registration (similar to keys we have for creating measurements). Then the user can install the API key on the probe and then register the probe using an API.
However, that seems overly complex. In addition it would be nice to name a probe, give it a location. So there is a need to go to the website anyhow.
Of course it can be requested as feature. If there are good use cases, we can put it on the list of things to look at.
Thanks for the information, Philip. I think I now have this in a working state and can attempt a deployment. If I may turn my question into a feature request: I believe the API keys you have for measurement creation are already associated with user accounts, so that part seems like a solved problem. What I have running on my probe hosts so far connects to one of my servers and sends its Atlas public key, ethernet MAC address (so I can track hardware inventory), and some other information to tell me how to remotely manage it. My server then gets the IP address the probe is connecting from (the probe may not know this itself, if it’s behind a NAT), geolocates it, and puts all the information in a database. It would be nice if my server could then take that information and go auto-register the probe with Atlas. As long as the volume is low I can also do this by hand, but being able to automate it would mean the probe could start working when plugged in instead of waiting for me to pay attention to it. Thanks, Steve
And automated up probe alerting needed as well :) Yours bt techie Sent from my iPod
On 4 Jan 2021, at 11:57, Carsten Schiefner <carsten@schiefner.de> wrote:
Hi, Philip -
a happy new year to you and everybody here on this list, first of all!
On 04.01.2021 11:53, Philip Homburg wrote: We are working on an API. However, the only thing the API will do is to copy the public key to the atlas backend systems. You still have go to the web size, log in, etc. We want to associate a user with each probe.
IANAP and therefore probably miss a crucial point here: but can't user identification, authentication and so also probe-to-user association be done via an API, too?
Best,
-C.
Hi, On Mon, Jan 04, 2021 at 12:42:19PM +0000, Colin Johnston wrote:
And automated up probe alerting needed as well :)
this! Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
I'd like to see this too. Rick GÉANT -----Original Message----- From: ripe-atlas <ripe-atlas-bounces@ripe.net> On Behalf Of Gert Doering Sent: 04 January 2021 12:50 To: Colin Johnston <colinj@mx5.org.uk> Cc: Carsten Schiefner <carsten@schiefner.de>; Philip Homburg <philip.homburg@ripe.net>; ripe-atlas@ripe.net Subject: Re: [atlas] Automating software probe creation? Hi, On Mon, Jan 04, 2021 at 12:42:19PM +0000, Colin Johnston wrote:
And automated up probe alerting needed as well :)
this! Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
participants (7)
-
Carsten Schiefner -
Colin Johnston -
Gert Doering -
Philip Homburg -
Pierre Barre -
Rick Havern -
Steve Gibbard