Hi: I'm currently testing the API to get a list of my own measurements. The API here reports ----------- Querying for Your Own Measurements In order to limit the results to your measurements only, just add a mine=true argument. For example: /api/v1/measurement/?mine=true Note that this only works if you're logged in, otherwise the result is the same as for any unauthenticated user. ----------- This seems to imply you need to manage a session within your code to get your own measurements, which I think violates the principle of a REST API. If you have the API key that provides you with access, shouldn't be reasonable to run the call as /api/v1/measurement/?mine=true&key=API_KEY and get a list of your own measurements? Thoughts? Am I reading the documentation in the wrong way? Thanks in advance -- Sebastian Castro Technical Research Manager NZRS Ltd. desk: +64 4 495 2337 mobile: +64 21 400535
On 2016-01-26 0:41, Sebastian Castro wrote:
Hi:
I'm currently testing the API to get a list of my own measurements. The API here reports
----------- Querying for Your Own Measurements
In order to limit the results to your measurements only, just add a mine=true argument. For example:
/api/v1/measurement/?mine=true Note that this only works if you're logged in, otherwise the result is the same as for any unauthenticated user. -----------
This seems to imply you need to manage a session within your code to get your own measurements, which I think violates the principle of a REST API. If you have the API key that provides you with access, shouldn't be reasonable to run the call as
/api/v1/measurement/?mine=true&key=API_KEY
and get a list of your own measurements?
Thoughts? Am I reading the documentation in the wrong way?
Thanks in advance
Hi, Can you provide your use case here? What's the purpose for getting a list of your on measurements from a script? Shouldn't your scripts already know about the measurements they started? :-) Cheers, Robert
Hi Robert, On 27/01/16 1:11 AM, Robert Kisteleki wrote:
On 2016-01-26 0:41, Sebastian Castro wrote:
Hi:
I'm currently testing the API to get a list of my own measurements. The API here reports
----------- Querying for Your Own Measurements
In order to limit the results to your measurements only, just add a mine=true argument. For example:
/api/v1/measurement/?mine=true Note that this only works if you're logged in, otherwise the result is the same as for any unauthenticated user. -----------
This seems to imply you need to manage a session within your code to get your own measurements, which I think violates the principle of a REST API. If you have the API key that provides you with access, shouldn't be reasonable to run the call as
/api/v1/measurement/?mine=true&key=API_KEY
and get a list of your own measurements?
Thoughts? Am I reading the documentation in the wrong way?
Thanks in advance
Hi,
Can you provide your use case here? What's the purpose for getting a list of your on measurements from a script? Shouldn't your scripts already know about the measurements they started? :-)
That's usually the case, except when a there is a user interruption of the script, a strange failure case or any other that prevents the script to save the list of measurements at the right time :) Cheers,
Cheers, Robert
-- Sebastian Castro Technical Research Manager NZRS Ltd. desk: +64 4 495 2337 mobile: +64 21 400535
Hi,
Can you provide your use case here? What's the purpose for getting a list of your on measurements from a script? Shouldn't your scripts already know about the measurements they started? :-)
That's usually the case, except when a there is a user interruption of the script, a strange failure case or any other that prevents the script to save the list of measurements at the right time :)
That can indeed happen -- though one would hope it is really an exception. We have two other kinds of API keys requested earlier and in the pipeline, so adding this third one is probably a minor increment in effort needed :-) However, since we're about to make the v2 API official and eventually remove v1, we'll most likely do this in the new version. Cheers, Robert
On 27/01/16 9:37 PM, Robert Kisteleki wrote:
Hi,
Can you provide your use case here? What's the purpose for getting a list of your on measurements from a script? Shouldn't your scripts already know about the measurements they started? :-)
That's usually the case, except when a there is a user interruption of the script, a strange failure case or any other that prevents the script to save the list of measurements at the right time :)
That can indeed happen -- though one would hope it is really an exception.
We have two other kinds of API keys requested earlier and in the pipeline, so adding this third one is probably a minor increment in effort needed :-) However, since we're about to make the v2 API official and eventually remove v1, we'll most likely do this in the new version.
Thanks, that's sensible. Will wait for v2 API then :) Cheers,
Cheers, Robert
-- Sebastian Castro Technical Research Manager NZRS Ltd. desk: +64 4 495 2337 mobile: +64 21 400535
Hi Sebastian, Hi List, I would like to inform you that we’ve created an API endpoint with a key= query parameter on the (stil in progress) v2 API. You can get a listing of your own measurements if you include a key - with sufficient permissions - that was created by you: https://atlas.ripe.net/api/v2/measurements/my/?key= <https://atlas.ripe.net/api/v2/measurements/my/?key=><YOURKEY> The key has to to have either ‘create measurement’ or ‘download results of measurements’ permissions. The listing will return ALL measurements belonging to the user who created the given key, not only the measurements created with that key. The resource https://atlas.ripe.net/api/v2/measurements/my/ <https://atlas.ripe.net/api/v2/measurements/my/> also gives a listing of you measurements if you’re logged in and will replace the ?mine=true query parameter. The query parameter will be deprecated in v2. greetings, Jasper
On 2016-01-26 0:41, Sebastian Castro wrote:
Hi:
I'm currently testing the API to get a list of my own measurements. The API here reports
----------- Querying for Your Own Measurements
In order to limit the results to your measurements only, just add a mine=true argument. For example:
/api/v1/measurement/?mine=true Note that this only works if you're logged in, otherwise the result is the same as for any unauthenticated user. -----------
This seems to imply you need to manage a session within your code to get your own measurements, which I think violates the principle of a REST API. If you have the API key that provides you with access, shouldn't be reasonable to run the call as
/api/v1/measurement/?mine=true&key=API_KEY
and get a list of your own measurements?
Thoughts? Am I reading the documentation in the wrong way?
Thanks in advance
On 17/02/2016 15:54, Jasper den Hertog wrote: Thanks. Can this documentation update be included in: https://atlas.ripe.net/docs/rest/ Under the last topic of "Querying for Your Own Measurements" Thanks, Hank
Hi Sebastian, Hi List,
I would like to inform you that we’ve created an API endpoint with a key= query parameter on the (stil in progress) v2 API.
You can get a listing of your own measurements if you include a key - with sufficient permissions - that was created by you:
https://atlas.ripe.net/api/v2/measurements/my/?key=<YOURKEY>
The key has to to have either ‘create measurement’ or ‘download results of measurements’ permissions. The listing will return ALL measurements belonging to the user who created the given key, not only the measurements created with that key.
The resource
https://atlas.ripe.net/api/v2/measurements/my/
also gives a listing of you measurements if you’re logged in and will replace the ?mine=true query parameter. The query parameter will be deprecated in v2.
greetings,
Jasper
On 2016-01-26 0:41, Sebastian Castro wrote:
Hi:
I'm currently testing the API to get a list of my own measurements. The API here reports
----------- Querying for Your Own Measurements
In order to limit the results to your measurements only, just add a mine=true argument. For example:
/api/v1/measurement/?mine=true Note that this only works if you're logged in, otherwise the result is the same as for any unauthenticated user. -----------
This seems to imply you need to manage a session within your code to get your own measurements, which I think violates the principle of a REST API. If you have the API key that provides you with access, shouldn't be reasonable to run the call as
/api/v1/measurement/?mine=true&key=API_KEY
and get a list of your own measurements?
Thoughts? Am I reading the documentation in the wrong way?
Thanks in advance
I too have a probe that won't come online after being online for months: https://atlas.ripe.net/probes/17879/#!tab-general I did the reset trick: I've stopped the probe, removed the USB drive, started the probe, waited 5 minutes and inserted the USB stick again. The probe comes up but via the WebGUI it shows offline. The IP is pingable so I am at a loss of what I should now do to get it back into the on-line mode. Any help appreciated. Thanks, Hank
Can you send the SOS DNS packets? On 7 Mar 2016 07:37, "Hank Nussbacher" <hank@efes.iucc.ac.il> wrote:
I too have a probe that won't come online after being online for months: https://atlas.ripe.net/probes/17879/#!tab-general
I did the reset trick: I've stopped the probe, removed the USB drive, started the probe, waited 5 minutes and inserted the USB stick again. The probe comes up but via the WebGUI it shows offline. The IP is pingable so I am at a loss of what I should now do to get it back into the on-line mode.
Any help appreciated.
Thanks, Hank
On 07/03/2016 09:45, Alistair Mackenzie wrote: Resolver Time (UTC) Query Type Power-up Time Info 2001:bf8:900:5:20c:29ff:fe79:3b51 2016-03-07 08:37:54 A 1h 50m NO-USB 128.139.227.250 2016-03-07 08:37:54 AAAA 1h 50m NO-USB What does that mean? I can try reseating the USB again, but if that doesn't work, it could be the USB is fried? -Hank
Can you send the SOS DNS packets?
On 7 Mar 2016 07:37, "Hank Nussbacher" <hank@efes.iucc.ac.il <mailto:hank@efes.iucc.ac.il>> wrote:
I too have a probe that won't come online after being online for months: https://atlas.ripe.net/probes/17879/#!tab-general <https://atlas.ripe.net/probes/17879/#%21tab-general>
I did the reset trick: I've stopped the probe, removed the USB drive, started the probe, waited 5 minutes and inserted the USB stick again. The probe comes up but via the WebGUI it shows offline. The IP is pingable so I am at a loss of what I should now do to get it back into the on-line mode.
Any help appreciated.
Thanks, Hank
Hi, On Mon, Mar 07, 2016 at 10:39:47AM +0200, Hank Nussbacher wrote:
What does that mean? I can try reseating the USB again, but if that doesn't work, it could be the USB is fried?
Try the USB stick in a "normal" PC and see whether it can be formatted there. I recently had one of mine completely break - the stick could be seen, but it was empty and all write access failed. I'm not sure what the Atlas v3 does with its USB stick, but this is the number one problem issue... maybe a new firmware version could be designed that has more advanced flash handling (like, ubifs instead of "normal" filesystems) and falls back to "not use flash if the flash is broken". What I see with my probes is that the aim of the flash buffer ("we can store measurement results if we can't upload them to the control server due to network outages etc." -> less probability of result loss) is actually backfiring into "extended downtimes of probes due to USB breakage of probes in locations where you can't just-so swap the USB flash"... (two of my 3 v3 probes have had virtually no network outages since they are operating, and the central servers also had few outages - but both have been down for weeks because I just had no time to go out, buy a new flash drive, and *drive over* to replace it - once again) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 07/03/2016 10:49, Gert Doering wrote:
Hi,
What does that mean? I can try reseating the USB again, but if that doesn't work, it could be the USB is fried? Try the USB stick in a "normal" PC and see whether it can be formatted
On Mon, Mar 07, 2016 at 10:39:47AM +0200, Hank Nussbacher wrote: there. I recently had one of mine completely break - the stick could be seen, but it was empty and all write access failed.
I pulled the USB stick and tried formatting it. Even though it says 4GB Sandisk, I could only get it to 1GB. So I opened a new probe, extracted its USB stick and stuck it into the probe as well (unformatted). Still off-line. I went to our "lights out" facility 3x today - a 15 minute brisk walk across campus and don't have time to go there again. At home it is far easier to play with these things then it is when the probe is installed as close to your network core as possible (which is usually at a LO facility). I know exactly how you feel! -Hank
I'm not sure what the Atlas v3 does with its USB stick, but this is the number one problem issue... maybe a new firmware version could be designed that has more advanced flash handling (like, ubifs instead of "normal" filesystems) and falls back to "not use flash if the flash is broken".
What I see with my probes is that the aim of the flash buffer ("we can store measurement results if we can't upload them to the control server due to network outages etc." -> less probability of result loss) is actually backfiring into "extended downtimes of probes due to USB breakage of probes in locations where you can't just-so swap the USB flash"... (two of my 3 v3 probes have had virtually no network outages since they are operating, and the central servers also had few outages - but both have been down for weeks because I just had no time to go out, buy a new flash drive, and *drive over* to replace it - once again)
Gert Doering -- NetMaster
Hi Hank, On https://www.youtube.com/watch?v=Y8oF0MaoUlQ I saw that you can use an new clean USB disk. When the usb disk is FAT formated, the probe will use that new usb stick. Kind regards, Michiel Piscaer On 07-03-16 14:09, Hank Nussbacher wrote:
On 07/03/2016 10:49, Gert Doering wrote:
Hi,
What does that mean? I can try reseating the USB again, but if that doesn't work, it could be the USB is fried? Try the USB stick in a "normal" PC and see whether it can be formatted
On Mon, Mar 07, 2016 at 10:39:47AM +0200, Hank Nussbacher wrote: there. I recently had one of mine completely break - the stick could be seen, but it was empty and all write access failed.
I pulled the USB stick and tried formatting it. Even though it says 4GB Sandisk, I could only get it to 1GB. So I opened a new probe, extracted its USB stick and stuck it into the probe as well (unformatted). Still off-line.
I went to our "lights out" facility 3x today - a 15 minute brisk walk across campus and don't have time to go there again.
At home it is far easier to play with these things then it is when the probe is installed as close to your network core as possible (which is usually at a LO facility). I know exactly how you feel!
-Hank
I'm not sure what the Atlas v3 does with its USB stick, but this is the number one problem issue... maybe a new firmware version could be designed that has more advanced flash handling (like, ubifs instead of "normal" filesystems) and falls back to "not use flash if the flash is broken".
What I see with my probes is that the aim of the flash buffer ("we can store measurement results if we can't upload them to the control server due to network outages etc." -> less probability of result loss) is actually backfiring into "extended downtimes of probes due to USB breakage of probes in locations where you can't just-so swap the USB flash"... (two of my 3 v3 probes have had virtually no network outages since they are operating, and the central servers also had few outages - but both have been down for weeks because I just had no time to go out, buy a new flash drive, and *drive over* to replace it - once again)
Gert Doering -- NetMaster
-- Network / System Engineer Security Officer E-mail: m.piscaer@edutel.nl Telefoon: +31 88 787 0209 Fax: +31 88 787 0502 Mobiel: +31 6 16048782 Threema: PBPCM9X3 PGP: 0x592097DB W3: www.edutel.nl
On 07/03/2016 15:24, M. Piscaer wrote: Thanks. I will try that on Wed when I am back next to our LO site. -Hank
Hi Hank,
On https://www.youtube.com/watch?v=Y8oF0MaoUlQ I saw that you can use an new clean USB disk. When the usb disk is FAT formated, the probe will use that new usb stick.
Kind regards,
Michiel Piscaer
On 07-03-16 14:09, Hank Nussbacher wrote:
Hi,
What does that mean? I can try reseating the USB again, but if that doesn't work, it could be the USB is fried? Try the USB stick in a "normal" PC and see whether it can be formatted
On Mon, Mar 07, 2016 at 10:39:47AM +0200, Hank Nussbacher wrote: there. I recently had one of mine completely break - the stick could be seen, but it was empty and all write access failed. I pulled the USB stick and tried formatting it. Even though it says 4GB Sandisk, I could only get it to 1GB. So I opened a new probe, extracted its USB stick and stuck it into the
On 07/03/2016 10:49, Gert Doering wrote: probe as well (unformatted). Still off-line.
I went to our "lights out" facility 3x today - a 15 minute brisk walk across campus and don't have time to go there again.
At home it is far easier to play with these things then it is when the probe is installed as close to your network core as possible (which is usually at a LO facility). I know exactly how you feel!
-Hank
I'm not sure what the Atlas v3 does with its USB stick, but this is the number one problem issue... maybe a new firmware version could be designed that has more advanced flash handling (like, ubifs instead of "normal" filesystems) and falls back to "not use flash if the flash is broken".
What I see with my probes is that the aim of the flash buffer ("we can store measurement results if we can't upload them to the control server due to network outages etc." -> less probability of result loss) is actually backfiring into "extended downtimes of probes due to USB breakage of probes in locations where you can't just-so swap the USB flash"... (two of my 3 v3 probes have had virtually no network outages since they are operating, and the central servers also had few outages - but both have been down for weeks because I just had no time to go out, buy a new flash drive, and *drive over* to replace it - once again)
Gert Doering -- NetMaster
On 07/03/2016 15:24, M. Piscaer wrote: Finally got it up. USB was fired. Threw it away. Thanks to all, Hank
Hi Hank,
On https://www.youtube.com/watch?v=Y8oF0MaoUlQ I saw that you can use an new clean USB disk. When the usb disk is FAT formated, the probe will use that new usb stick.
Kind regards,
Michiel Piscaer
On 07-03-16 14:09, Hank Nussbacher wrote:
Hi,
What does that mean? I can try reseating the USB again, but if that doesn't work, it could be the USB is fried? Try the USB stick in a "normal" PC and see whether it can be formatted
On Mon, Mar 07, 2016 at 10:39:47AM +0200, Hank Nussbacher wrote: there. I recently had one of mine completely break - the stick could be seen, but it was empty and all write access failed. I pulled the USB stick and tried formatting it. Even though it says 4GB Sandisk, I could only get it to 1GB. So I opened a new probe, extracted its USB stick and stuck it into the
On 07/03/2016 10:49, Gert Doering wrote: probe as well (unformatted). Still off-line.
I went to our "lights out" facility 3x today - a 15 minute brisk walk across campus and don't have time to go there again.
At home it is far easier to play with these things then it is when the probe is installed as close to your network core as possible (which is usually at a LO facility). I know exactly how you feel!
-Hank
I'm not sure what the Atlas v3 does with its USB stick, but this is the number one problem issue... maybe a new firmware version could be designed that has more advanced flash handling (like, ubifs instead of "normal" filesystems) and falls back to "not use flash if the flash is broken".
What I see with my probes is that the aim of the flash buffer ("we can store measurement results if we can't upload them to the control server due to network outages etc." -> less probability of result loss) is actually backfiring into "extended downtimes of probes due to USB breakage of probes in locations where you can't just-so swap the USB flash"... (two of my 3 v3 probes have had virtually no network outages since they are operating, and the central servers also had few outages - but both have been down for weeks because I just had no time to go out, buy a new flash drive, and *drive over* to replace it - once again)
Gert Doering -- NetMaster
I've had 2 probes that died recently, around the same time, USB seems to be dead. I saw a thread a while back about these SanDisk drives being known faulty and going into read-only mode. Replacing the USB seems to have sorted them anyway. On 9 March 2016 at 08:46, Hank Nussbacher <hank@efes.iucc.ac.il> wrote:
On 07/03/2016 15:24, M. Piscaer wrote:
Finally got it up. USB was fired. Threw it away.
Thanks to all, Hank
Hi Hank,
On https://www.youtube.com/watch?v=Y8oF0MaoUlQ I saw that you can use an new clean USB disk. When the usb disk is FAT formated, the probe will use that new usb stick.
Kind regards,
Michiel Piscaer
On 07-03-16 14:09, Hank Nussbacher wrote:
Hi,
What does that mean? I can try reseating the USB again, but if that doesn't work, it could be the USB is fried? Try the USB stick in a "normal" PC and see whether it can be formatted
On Mon, Mar 07, 2016 at 10:39:47AM +0200, Hank Nussbacher wrote: there. I recently had one of mine completely break - the stick could be seen, but it was empty and all write access failed. I pulled the USB stick and tried formatting it. Even though it says 4GB Sandisk, I could only get it to 1GB. So I opened a new probe, extracted its USB stick and stuck it into the
On 07/03/2016 10:49, Gert Doering wrote: probe as well (unformatted). Still off-line.
I went to our "lights out" facility 3x today - a 15 minute brisk walk across campus and don't have time to go there again.
At home it is far easier to play with these things then it is when the probe is installed as close to your network core as possible (which is usually at a LO facility). I know exactly how you feel!
-Hank
I'm not sure what the Atlas v3 does with its USB stick, but this is the number one problem issue... maybe a new firmware version could be designed that has more advanced flash handling (like, ubifs instead of "normal" filesystems) and falls back to "not use flash if the flash is broken".
What I see with my probes is that the aim of the flash buffer ("we can store measurement results if we can't upload them to the control server due to network outages etc." -> less probability of result loss) is actually backfiring into "extended downtimes of probes due to USB breakage of probes in locations where you can't just-so swap the USB flash"... (two of my 3 v3 probes have had virtually no network outages since they are operating, and the central servers also had few outages - but both have been down for weeks because I just had no time to go out, buy a new flash drive, and *drive over* to replace it - once again)
Gert Doering -- NetMaster
In fact looking back at the SOS logs it even managed to detect it: USB-READONLY On 9 March 2016 at 13:31, Marty Strong <marty@martystrong.co.uk> wrote:
I've had 2 probes that died recently, around the same time, USB seems to be dead. I saw a thread a while back about these SanDisk drives being known faulty and going into read-only mode. Replacing the USB seems to have sorted them anyway.
On 9 March 2016 at 08:46, Hank Nussbacher <hank@efes.iucc.ac.il> wrote:
On 07/03/2016 15:24, M. Piscaer wrote:
Finally got it up. USB was fired. Threw it away.
Thanks to all, Hank
Hi Hank,
On https://www.youtube.com/watch?v=Y8oF0MaoUlQ I saw that you can use an new clean USB disk. When the usb disk is FAT formated, the probe will use that new usb stick.
Kind regards,
Michiel Piscaer
Hi,
What does that mean? I can try reseating the USB again, but if that doesn't work, it could be the USB is fried? Try the USB stick in a "normal" PC and see whether it can be formatted
On Mon, Mar 07, 2016 at 10:39:47AM +0200, Hank Nussbacher wrote: there. I recently had one of mine completely break - the stick could be seen, but it was empty and all write access failed. I pulled the USB stick and tried formatting it. Even though it says 4GB Sandisk, I could only get it to 1GB. So I opened a new probe, extracted its USB stick and stuck it into the
On 07/03/2016 10:49, Gert Doering wrote: probe as well (unformatted). Still off-line.
I went to our "lights out" facility 3x today - a 15 minute brisk walk across campus and don't have time to go there again.
At home it is far easier to play with these things then it is when the probe is installed as close to your network core as possible (which is usually at a LO facility). I know exactly how you feel!
-Hank
I'm not sure what the Atlas v3 does with its USB stick, but this is
number one problem issue... maybe a new firmware version could be designed that has more advanced flash handling (like, ubifs instead of "normal" filesystems) and falls back to "not use flash if the flash is broken".
What I see with my probes is that the aim of the flash buffer ("we can store measurement results if we can't upload them to the control server due to network outages etc." -> less probability of result loss) is actually backfiring into "extended downtimes of probes due to USB breakage of probes in locations where you can't just-so swap the USB flash"... (two of my 3 v3 probes have had virtually no network outages since
On 07-03-16 14:09, Hank Nussbacher wrote: the they
are operating, and the central servers also had few outages - but both have been down for weeks because I just had no time to go out, buy a new flash drive, and *drive over* to replace it - once again)
Gert Doering -- NetMaster
Hi, I've never encountered the USB being fried but the USB flash drive failures are quite often nowadays. Try to replace it with a new one with capacity >= 4Gb. Just plug it in and your probe will reinitialize it. Do not expect your probe online immediately after it. Please give it some time because it requires a full reinitializing of the probe firmware. /vty On 3/7/16 9:39 AM, Hank Nussbacher wrote:
On 07/03/2016 09:45, Alistair Mackenzie wrote: Resolver Time (UTC) Query Type Power-up Time Info 2001:bf8:900:5:20c:29ff:fe79:3b51 2016-03-07 08:37:54 A 1h 50m NO-USB 128.139.227.250 2016-03-07 08:37:54 AAAA 1h 50m NO-USB
What does that mean? I can try reseating the USB again, but if that doesn't work, it could be the USB is fried?
-Hank
Can you send the SOS DNS packets?
On 7 Mar 2016 07:37, "Hank Nussbacher" <hank@efes.iucc.ac.il <mailto:hank@efes.iucc.ac.il>> wrote:
I too have a probe that won't come online after being online for months: https://atlas.ripe.net/probes/17879/#!tab-general <https://atlas.ripe.net/probes/17879/#%21tab-general>
I did the reset trick: I've stopped the probe, removed the USB drive, started the probe, waited 5 minutes and inserted the USB stick again. The probe comes up but via the WebGUI it shows offline. The IP is pingable so I am at a loss of what I should now do to get it back into the on-line mode.
Any help appreciated.
Thanks, Hank
participants (9)
-
Alistair Mackenzie -
Gert Doering -
Hank Nussbacher -
Jasper den Hertog -
M. Piscaer -
Marty Strong -
Robert Kisteleki -
Sebastian Castro -
Viktor Naumov