ripe-ncc / ripe-atlas-tools Goto Github PK

Strictly speaking, we're not doing SSL, but rather TLS. Regardless, internally we tend to refer to these sorts of measurements as sslcert.

The problem is when we're supporting TLS measurements, either by way of reporting, streaming, or creating, there's currently no consistency established. What's worse, the most common case is "sslcert" which is ugly and user unfriendly.

For example, to create a measurement, which is better?

$ ripe-atlas measure tls --target ripe.net
$ ripe-atlas measure ssl --target ripe.net
$ ripe-atlas measure sslcert --target ripe.net

Personally, I like tls, but I'm open to having my mind changed on this. Whatever we settle on though, needs to permeate the codebase, and currently there's no common ground there.

Perhaps a better method to determine SSL cert. consistency should be used, maybe the same used on the RIPE Atlas website GUI in order to have consistent results between this cmd line tool and the web GUI?

Hiya,

If I use the render mode against a standard JSON download blobs from the UI, I get the following error:

$ ripe-atlas render --from-file RIPE-Atlas-measurement-10301-probe-17011.json

Traceback (most recent call last):
  File "/Users/cpetrie/Library/PythonVEs/ripe-atlas-tools/bin/ripe-atlas", line 10, in <module>
    execfile(__file__)
  File "/Users/cpetrie/Library/PythonVEs/ripe-atlas-tools/src/ripe.atlas.tools/scripts/ripe-atlas", line 79, in <module>
    sys.exit(RipeAtlas().main())
  File "/Users/cpetrie/Library/PythonVEs/ripe-atlas-tools/src/ripe.atlas.tools/scripts/ripe-atlas", line 70, in main
    cmd.run()
  File "/Users/cpetrie/Library/PythonVEs/ripe-atlas-tools/src/ripe.atlas.tools/ripe/atlas/tools/commands/render.py", line 76, in run
    Rendering(renderer=self.arguments.renderer, payload=results).render()
  File "/Users/cpetrie/Library/PythonVEs/ripe-atlas-tools/src/ripe.atlas.tools/ripe/atlas/tools/helpers/rendering.py", line 81, in render
    self._smart_render(self.payload)
  File "/Users/cpetrie/Library/PythonVEs/ripe-atlas-tools/src/ripe.atlas.tools/ripe/atlas/tools/helpers/rendering.py", line 104, in _smart_render
    for line in self._get_rendered_results(data):
  File "/Users/cpetrie/Library/PythonVEs/ripe-atlas-tools/src/ripe.atlas.tools/ripe/atlas/tools/helpers/rendering.py", line 86, in _get_rendered_results
    for sagan in data:
  File "/Users/cpetrie/Library/PythonVEs/ripe-atlas-tools/src/ripe.atlas.tools/ripe/atlas/tools/helpers/rendering.py", line 38, in __iter__
    on_warning=Result.ACTION_IGNORE
  File "/Users/cpetrie/Library/PythonVEs/ripe-atlas-tools/src/ripe.atlas.sagan/ripe/atlas/sagan/base.py", line 210, in get
    kind = raw_data["type"].lower()
TypeError: list indices must be integers, not str

This doesn't happen with the 'fragmented JSON', just on a regular JSON download.

Cheers,
Colin

i can't remember all the measurement ids for measurements i've created, but i can remember them by short names. it would be great if the tools could help me find my measurement back by storing short names.

ie.
instead of
ripe-atlas report 123456789
i could say
ripe-atlas report my-cool-ipv6-measurement

and there would be a local cache of ->msm_id mappings

It would be useful if we could offer this to people. I think there are some python libs that could implement this easier for us.

$ ripe-atlas measure ping --target google.com

There was a problem found in the attempt to create your measurement.  Please send the command you tried to execute to [email protected] and we'll try to address it.

$

I have configured an API key, but it is very hard to debug with this error message.

Hiya,

If I want to do a v6 ping from many atlas probes, lets say I'm using the defaults of 50 from region WW,
My default expectation is that it should not select probes where v6 doesn't work.
Since the system has 'system-ipv6-works' tags assigned to probes, I'd like to be able to set tags in the measurement creation.

For extra bonus points, a v4 measurement should only select 'system-ipv4-works' and v6 measurements should only select 'system-ipv6-works' by default (or allow me to configure it in my defaults)

That'd be awesome and shiny :-)

Cheers,
Colin

ripe-atlas report 3606560 --renderer traceroute_aspath
Probe #12185: AS10026 AS1921, completed
Probe #22880: AS10026 AS1921, completed

This is not complete. The traceroute shows:
1 192.168.2.254
2 96.120.89.13
3 68.87.198.29
4 162.151.79.133
5 68.85.154.93
6 4.68.127.109
7 4.69.144.143
8 4.69.144.143
9 64.215.81.146
10 202.147.51.46
11 194.0.25.10

Those the AS path should be something like:
?, 7922, 3356, 3549, 10026, 1921

It would also be great if the renderer could write down the AS name (I know this is probably more difficult)

We don't currently have a desired format for this, so that should be worked out before we even start here.

Hi,

It would be great if the tool could accept optional times (or ranges of times) to fetch data from, as well as just the latest data from the API

Cheers
Colin

For practical reasons, it doesn't make sense for us to be promoting this project as anything other than RIPE Atlas Tools, but when we're talking about the code itself, statements like "just use the tool" or just "tools" doesn't really play well.

So, let's have a code name for this. If we're to conform to the other libraries and bits we have out there (Cousteau, Sagan), it should be an explorer. Post your preferences here and vote with a 👍 if you like. We'll pick one and I'll put something easter-egg like in there for you all to play with at some point.

We don't currently have a desired format for this, so that should be worked out before we even start here.

If libyaml devlopment files are not installed, it is apparently not done automatically by pip install:

Running setup.py install for pyyaml
checking if libyaml is compilable
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I/usr/include/python2.7 -c build/temp.linux-x86_64-2.7/check_libyaml.c -o build/temp.linux-x86_64-2.7/check_libyaml.o
build/temp.linux-x86_64-2.7/check_libyaml.c:2:18: fatal error: yaml.h: No such file or directory
compilation terminated.

libyaml is not found or a compiler error: forcing --without-libyaml
(if libyaml is installed correctly, you may need to
 specify the option --include-dirs or uncomment and
 modify the parameter include_dirs in setup.cfg)

% ripe-atlas measure ping --target www.afnic.fr
Traceback (most recent call last):
File "/home/stephane/.local/bin/ripe-atlas", line 77, in
sys.exit(RipeAtlas().main())
File "/home/stephane/.local/bin/ripe-atlas", line 67, in main
[self.command]
File "/home/stephane/.local/lib/python2.7/site-packages/ripe/atlas/tools/commands/measure.py", line 5, in
from ripe.atlas.cousteau import (
File "/home/stephane/.local/lib/python2.7/site-packages/ripe/atlas/cousteau/init.py", line 10, in
from .stream import AtlasStream
File "/home/stephane/.local/lib/python2.7/site-packages/ripe/atlas/cousteau/stream.py", line 1, in
from socketIO_client import SocketIO
File "/home/stephane/.local/lib/python2.7/site-packages/socketIO_client/init.py", line 12, in
from .transports import (
File "/home/stephane/.local/lib/python2.7/site-packages/socketIO_client/transports.py", line 1, in
import requests
File "/usr/local/lib/python2.7/dist-packages/requests-2.0.0-py2.7.egg/requests/init.py", line 53, in
from .packages.urllib3.contrib import pyopenssl
File "/usr/local/lib/python2.7/dist-packages/requests-2.0.0-py2.7.egg/requests/packages/urllib3/contrib/pyopenssl.py", line 42, in
ssl.PROTOCOL_SSLv3: OpenSSL.SSL.SSLv3_METHOD,
AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3'

During the measurement, or after with 'ripe-atlas report', I can get the details of the measurement for each probe but I do not see how I get a synthesis (such as, for ping measurements, the average RTT, the percentage of probes which failed to reach the target, etc).

We need a way to make reports a little more customised. like --use-hostname or --use-asn

It is not clear from the names of the "render" and "report" commands why they are different, and they do principally do the same thing. IMHO this is made a bit clearer with the extra help text, but there is still room for improvement.

One possible solution would be to merge the commands into one, by e.g. adding stdin reading and a --from-file option to "report" and deprecating "render". Another solution would be to rename one or both of them so that the distinction is clearer, although I think that in that case we should make one an explicit superset of the other because at the moment we have duplicate code.

I was trying to find my probe on the cli today and I immediately tried to filter out the noise with a --status connected and it barked at me that this wasn't supported. It'd be nice if we could filter the list a little better with some tags like these:

--id
--id-greater-than
--id-less-than
--address_v6
--is-anchor
--country
--region (this would be nice, but it's obviously problematic)
--is-public
--status
--in-prefix
--in-asn

Try to keep output within 80 columns width. For example the output of measurements is just a few characters more.

"ripe-atlas measure --help" should be a bit more helpful

If I try to get list of all probes filtered by country; not getting the full list.

ripe-atlas probes --country NZ

Showing 25 of 130 total probes

I get this error when trying this tools

`ripe-atlas report --help

No such command.`

Am I doing something wrong ?

I'm trying to display report for a measurement using stable RIPE Atlas tools installed inside virtualenv on a Gentoo box. When I ask for a report, the tool crashes:

$ ripe-atlas report 1695915

RIPE Atlas Report for Measurement #1695915
===================================================
Anchoring Measurement: Traceroute IPv6 for anchor cz-prg-as2852.anchors.atlas.ripe.net

Traceback (most recent call last):
  File "/home/oskar/Downloads/atlas/venv/bin/ripe-atlas", line 94, in <module>
    sys.exit(RipeAtlas().main())
  File "/home/oskar/Downloads/atlas/venv/bin/ripe-atlas", line 85, in main
    cmd.run()
  File "/home/oskar/Downloads/atlas/venv/lib/python3.4/site-packages/ripe/atlas/tools/commands/report.py", line 128, in run
    payload=results
  File "/home/oskar/Downloads/atlas/venv/lib/python3.4/site-packages/ripe/atlas/tools/helpers/rendering.py", line 80, in render
    self._smart_render(self.payload)
  File "/home/oskar/Downloads/atlas/venv/lib/python3.4/site-packages/ripe/atlas/tools/helpers/rendering.py", line 100, in _smart_render
    for line in self._get_rendered_results(data):
  File "/home/oskar/Downloads/atlas/venv/lib/python3.4/site-packages/ripe/atlas/tools/helpers/rendering.py", line 87, in _get_rendered_results
    for sagan in data:
  File "/home/oskar/Downloads/atlas/venv/lib/python3.4/site-packages/ripe/atlas/tools/helpers/rendering.py", line 42, in __iter__
    for sagan in self._attach_probes(sagans):
  File "/home/oskar/Downloads/atlas/venv/lib/python3.4/site-packages/ripe/atlas/tools/helpers/rendering.py", line 60, in _attach_probes
    [(p.id, p) for p in Probe.get_many(s.probe_id for s in sagans)]
  File "/home/oskar/Downloads/atlas/venv/lib/python3.4/site-packages/ripe/atlas/tools/probes/__init__.py", line 40, in get_many
    probe = cache.get("probe:{}".format(pk))
  File "/home/oskar/Downloads/atlas/venv/lib/python3.4/site-packages/ripe/atlas/tools/cache.py", line 46, in get
    expires, value = pickle.loads(self._db[key])
UnicodeDecodeError: 'ascii' codec can't decode byte 0xdf in position 1: ordinal not in range(128)

Different crash occurs for the live streaming:

$ ripe-atlas stream 1695915
Traceback (most recent call last):
  File "/home/oskar/Downloads/atlas/venv/bin/ripe-atlas", line 94, in <module>
    sys.exit(RipeAtlas().main())
  File "/home/oskar/Downloads/atlas/venv/bin/ripe-atlas", line 85, in main
    cmd.run()
  File "/home/oskar/Downloads/atlas/venv/lib/python3.4/site-packages/ripe/atlas/tools/commands/stream.py", line 49, in run
    self.arguments.measurement_id
  File "/home/oskar/Downloads/atlas/venv/lib/python3.4/site-packages/ripe/atlas/tools/streaming.py", line 44, in stream
    stream.timeout(self.timeout)
  File "/home/oskar/Downloads/atlas/venv/lib/python3.4/site-packages/ripe/atlas/cousteau/stream.py", line 62, in timeout
    self.socketIO.wait()
  File "/home/oskar/Downloads/atlas/venv/lib/python3.4/site-packages/socketIO_client/__init__.py", line 232, in wait
    self._process_packets()
  File "/home/oskar/Downloads/atlas/venv/lib/python3.4/site-packages/socketIO_client/__init__.py", line 256, in _process_packets
    self._process_packet(engineIO_packet)
  File "/home/oskar/Downloads/atlas/venv/lib/python3.4/site-packages/socketIO_client/__init__.py", line 461, in _process_packet
    delegate(socketIO_packet_data, namespace)
  File "/home/oskar/Downloads/atlas/venv/lib/python3.4/site-packages/socketIO_client/__init__.py", line 482, in _on_event
    namespace._find_packet_callback(event)(*args)
  File "/home/oskar/Downloads/atlas/venv/lib/python3.4/site-packages/ripe/atlas/tools/streaming.py", line 32, in on_result_response
    on_malformation=Result.ACTION_IGNORE
  File "/home/oskar/Downloads/atlas/venv/lib/python3.4/site-packages/ripe/atlas/tools/renderers/traceroute.py", line 24, in on_result
    "ms  ".join(["{0:8}".format(rtt) for rtt in rtts])
  File "/home/oskar/Downloads/atlas/venv/lib/python3.4/site-packages/ripe/atlas/tools/renderers/traceroute.py", line 24, in <listcomp>
    "ms  ".join(["{0:8}".format(rtt) for rtt in rtts])
TypeError: non-empty format string passed to object.__format__

Using virtualenv with Python 2.7.10 works without error.

Extend the measure command to support NTP.

Listening to the result stream should stop after I get all the results.

For bonus points: the user could specify "stop after getting X results" or "stop after getting X% of the results" as well as "time out after X seconds [after the last received result]"

$ ripe-atlas report 1
Traceback (most recent call last):
  File "/Users/codemonk/python/bin/ripe-atlas", line 77, in <module>
    sys.exit(RipeAtlas().main())
  File "/Users/codemonk/python/bin/ripe-atlas", line 68, in main
    ).Command(*self.args, **self.kwargs).run()
  File "/Users/codemonk/python/lib/python2.7/site-packages/ripe/atlas/tools/commands/report.py", line 56, in run
    formatter_instance = Report.get_formatter(detail["type"]["name"])()
TypeError: string indices must be integers
$

A useful error message would be much appreciated ;)

We already have --probes option to show results from these probes, we can extend it to show results from specific asns as well as per @emileaben suggestion.

Instead of ripe-atlas measure ping ..., ripe-atlas m p ... would be faster to use and unambiguous as well.

Here is a code snippet which adds that functionality to argparse: http://guido.vonrudorff.de/python-argparse-graceful-parameter-parsing/

My probe is in my home in London, in Zone 2, which is to say that by comparison to most people living in London, I live pretty close to the centre. However, the following command renders 0 results:

$ ripe-atlas probes --location "London"

If you widen the radius to 5 however you get some probes, but still not mine:

$ ripe-atlas probes --location "London" --radius 5

To get mine, you need to extend the radius to 7, but even then, you're only getting probes within a 7km radius from London's centre. Given that most people living in London live up to 25 or even 30km away from the centre, it would appear that the default radius is insufficient. Indeed, even setting --radius 1 returns 92 results, so something is fishy there.

Extend the measure command to support HTTP.

I just discovered stevedore, a simple way to build your app around a plugin architecture. It's already in use in a bunch of other toolkits and Fedora has a package for it already, so I thought it worth looking into.

Someone from hackathon suggested we have a programmatic way to fetch key from a config place.
Something like:

from ripe.atlas import key_mng
ckey = key_mng.get_create_key()
rkey = key_mng.get_results_key()

I am not sure if the place of implementation is here, cause I see people using cousteau can use that as well. So, maybe we should implemented in cousteau and then use it here??
We could use a similar path structure $HOME/.config/ripe-atlas

tools currently print headers, even if i want the 'raw' version:
atlas report 2048605 --renderer=raw | head

RIPE Atlas Report for Measurement #2048605
===================================================

900 pool.ntp.org ntp 4 -1

(then json starts, but also with leading spaces)

I think it would be best if 'report' and 'stream' do as little changing to the raw data as possible (no header, no leading spaces), so you can use the toolset output to pipe into other tools that understand the raw json ( like 'jq' ).

Users who have more than one Python instance on their machine will get annoying crashes when trying to run Magellan in one version and then again in another because of how the different versions store data. A simple work around for this would be to use different cache files based on the Python version.

I'd recommend using sys or six to determine the Python version, and then just set the local cache file name based on that. Something like: ${HOME}/.config/ripe-atlas-tools/cache-2.7.db.

See #105 for more info.

Currently there's zero sanitation on strings that Magellan prints to stdout. Typically this isn't a problem, but theoretically, someone with creative use of escape sequences could do some Interesting Things here. A probe result for example could contain colour changing escape sequences that would break the layout, and perhaps there's something more nefarious that could happen as well.

We need to find a way to sanitise anything that comes from the API whilst still retaining the ability to change colours on our end.

I'm open to suggestions on this one.

Implement a way to list/search probes & measurements.

$ ripe-atlas list-measurements

1234567  Description https://...
1234567  Description https://...
1234567  Description https://...

Additionally, a --ids-only flag should be available for use in pipelines.

Note that this needs API key support.

So at the moment, the tools don't have a sense of time, they always return the latest result.
If I want to see previous data, I've probably had to get it from the API or the download part of the UI, which means I have a blob of JSON (in my case a traceroute) in a file. In my case, it's a day's worth of data from a probe's built-in DNS and traceroute measurements.
What would be awesome is to be able to pipe that file into the appropriate renderer, to turn it into something that is easy to read :)

Using the tool as a parser for any Atlas JSON seems to me like a use case, so if you have already retrieved some JSON, the tool can be used to render it.

At the moment there's an amount of extra text besides the output. This should only appear if the user actually asks for it

Something like this:

$ ripe-atlas create-key <permission-name>

Currently, just installing ripe-atlas-tools with pip --user ripe.atlas.tools
will lead to a nonfunctional installation. Some commands will work, like
'measurements'. Others, like 'stream' or 'report' will fail with the extremely
irritating error-message No such command.. This is caused by the fact that
ripe-atlas-tools is incompatible with the current version 1.1 of
ripe-atlas-cousteau released on Feb 09.

Manually downgrading the version of ripe-atlas-cousteau to 1.0.7
(pip install --user ripe.atlas.cousteau==1.0.7) makes ripe-atlas-tools work
again.

I've tested the following DNSMON msm types (for both address families):

• hostname.bind
• UDP SOA
• TCP SOA
• Traceroute
• version.bind

hostname.bind queries explode [1]. Take msms 1423330 and 1423386 as examples.

(atlas-cli)iortiz@monet:~
$ python -V
Python 2.7.10
(atlas-cli)iortiz@monet:~
$ uname -a
Linux monet 4.0.0-2-amd64 #1 SMP Debian 4.0.8-1 (2015-07-11) x86_64 GNU/Linux

1iortiz@monet:~
$ ripe-atlas stream 1423386
Traceback (most recent call last):
File "/home/iortiz/.virtualenvs/atlas-cli/bin/ripe-atlas", line 77, in
sys.exit(RipeAtlas().main())
File "/home/iortiz/.virtualenvs/atlas-cli/bin/ripe-atlas", line 68, in main
).Command(_self.args, *_self.kwargs).run()
File "/home/iortiz/.virtualenvs/atlas-cli/local/lib/python2.7/site-packages/ripe/atlas/tools/commands/stream.py", line 41, in run
detail["type"]["name"], pk)
File "/home/iortiz/.virtualenvs/atlas-cli/local/lib/python2.7/site-packages/ripe/atlas/tools/streaming.py", line 37, in stream
stream.timeout()
File "/home/iortiz/.virtualenvs/atlas-cli/local/lib/python2.7/site-packages/ripe/atlas/cousteau/stream.py", line 53, in timeout
self.socketIO.wait()
File "/home/iortiz/.virtualenvs/atlas-cli/local/lib/python2.7/site-packages/socketIO_client/init.py", line 232, in wait
self._process_packets()
File "/home/iortiz/.virtualenvs/atlas-cli/local/lib/python2.7/site-packages/socketIO_client/init.py", line 256, in _process_packets
self._process_packet(engineIO_packet)
File "/home/iortiz/.virtualenvs/atlas-cli/local/lib/python2.7/site-packages/socketIO_client/init.py", line 461, in _process_packet
delegate(socketIO_packet_data, namespace)
File "/home/iortiz/.virtualenvs/atlas-cli/local/lib/python2.7/site-packages/socketIO_client/init.py", line 482, in _on_event
namespace.find_packet_callback(event)(*args)
File "/home/iortiz/.virtualenvs/atlas-cli/local/lib/python2.7/site-packages/ripe/atlas/tools/streaming.py", line 26, in on_result_response
sys.stdout.write(formatter.format(Result.get(result)))
File "/home/iortiz/.virtualenvs/atlas-cli/local/lib/python2.7/site-packages/ripe/atlas/tools/reports/dns.py", line 21, in format
r += cls.get_formatted_response(probe_id, created, response)
File "/home/iortiz/.virtualenvs/atlas-cli/local/lib/python2.7/site-packages/ripe/atlas/tools/reports/dns.py", line 65, in get_formatted_response
"answer", response.abuf.answers),
File "/home/iortiz/.virtualenvs/atlas-cli/local/lib/python2.7/site-packages/ripe/atlas/tools/reports/dns.py", line 85, in get_section
header.upper()) + "\n".join([" {}".format() for _ in data]) + "\n"
File "/home/iortiz/.virtualenvs/atlas-cli/local/lib/python2.7/site-packages/ripe/atlas/sagan/dns.py", line 325, in str
return "{} {} {} {} {}".format(Answer.str(self), self.data_string)
IndexError: tuple index out of range

Hiya,

Just updated to the latest git master of ripe-atlas-tools, ripe-atlas-cousteau and ripe.atlas.sagan.
When I run:

ripe-atlas report 1001 --renderer raw

It dumps out many rows but after about 3300 rows, it dies with a traceback:

Traceback (most recent call last):
  File "/Users/cpetrie/Library/PythonVEs/ripe-atlas-tools/bin/ripe-atlas", line 10, in <module>
    execfile(__file__)
  File "/Users/cpetrie/Library/PythonVEs/ripe-atlas-tools/src/ripe.atlas.tools/scripts/ripe-atlas", line 79, in <module>
    sys.exit(RipeAtlas().main())
  File "/Users/cpetrie/Library/PythonVEs/ripe-atlas-tools/src/ripe.atlas.tools/scripts/ripe-atlas", line 70, in main
    cmd.run()
  File "/Users/cpetrie/Library/PythonVEs/ripe-atlas-tools/src/ripe.atlas.tools/ripe/atlas/tools/commands/report.py", line 112, in run
    payload=results
  File "/Users/cpetrie/Library/PythonVEs/ripe-atlas-tools/src/ripe.atlas.tools/ripe/atlas/tools/helpers/rendering.py", line 81, in render
    self._smart_render(self.payload)
  File "/Users/cpetrie/Library/PythonVEs/ripe-atlas-tools/src/ripe.atlas.tools/ripe/atlas/tools/helpers/rendering.py", line 104, in _smart_render
    for line in self._get_rendered_results(data):
  File "/Users/cpetrie/Library/PythonVEs/ripe-atlas-tools/src/ripe.atlas.tools/ripe/atlas/tools/helpers/rendering.py", line 86, in _get_rendered_results
    for sagan in data:
  File "/Users/cpetrie/Library/PythonVEs/ripe-atlas-tools/src/ripe.atlas.tools/ripe/atlas/tools/helpers/rendering.py", line 43, in __iter__
    for sagan in self._attach_probes(sagans):
  File "/Users/cpetrie/Library/PythonVEs/ripe-atlas-tools/src/ripe.atlas.tools/ripe/atlas/tools/helpers/rendering.py", line 61, in _attach_probes
    [(p.id, p) for p in Probe.get_many(s.probe_id for s in sagans)]
  File "/Users/cpetrie/Library/PythonVEs/ripe-atlas-tools/src/ripe.atlas.tools/ripe/atlas/tools/probes/__init__.py", line 40, in get_many
    probe = cache.get("probe:{}".format(pk))
  File "/Users/cpetrie/Library/PythonVEs/ripe-atlas-tools/src/ripe.atlas.tools/ripe/atlas/tools/cache.py", line 42, in get
    expires, value = pickle.loads(self._db[key])
AttributeError: 'module' object has no attribute 'Status'

Thought I'd let you know :)

Cheers
Colin

If on_start() and on_finish() in the base renderer exposed measurement metadata directly, the reports could include relevant metadata about the results the report is displaying, making it all more useful.

Is this in the "roadmap"? If it is not, would anybody else like to see it in?

It'd be highly useful for the Atlas core team to know how much this tool is used Using the UA (tool, version) to let the service know would go a long way. This should apply to all interactions with the API (measurements, probes, streaming).

For bonus points: as a byproduct, package maintainers could have a simple way to set this for themselves.

The shorthand commands of aping, atraceroute, etc. should all work, but they're not documented yet. This should be added to the "Measurement Creation" section of the docs.

We want a way to allow someone to invoke ripe-atlas with --config /path/to/config

We've got a sexy command line client here. We should show it off in the README. I believe Vesna should have some of the screenshots I took a while back.

This issue was inspired by a recent Reddit post on the subject.

The UI does this, but the command line doesn't yet. We need something generates " measurement to " for measurements with a target, and "DNS measurement for <query_argument>" for the special case where DNS measurements don't require a target.

I've started two measurements, ping (2437452) and DNS (243745) and, 15 or 20 minutes later, the command still did not yield back to the shell.