ripe-ncc / ripe-atlas-tools Goto Github PK
View Code? Open in Web Editor NEWOfficial command-line client for RIPE Atlas
License: GNU General Public License v3.0
Official command-line client for RIPE Atlas
License: GNU General Public License v3.0
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' ).
Something like this:
$ ripe-atlas create-key <permission-name>
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
Try to keep output within 80 columns width. For example the output of measurements is just a few characters more.
At the moment there's an amount of extra text besides the output. This should only appear if the user actually asks for it
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
Extend the measure
command to support NTP.
% 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'
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.
We don't currently have a desired format for this, so that should be worked out before we even start here.
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.
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.
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.
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 need a way to make reports a little more customised. like --use-hostname or --use-asn
I get this error when trying this tools
`ripe-atlas report --help
No such command.`
Am I doing something wrong ?
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.
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)
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.
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]"
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.
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
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
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.
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.
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.
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.
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.
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
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/
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
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).
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?
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
We want a way to allow someone to invoke ripe-atlas with --config /path/to/config
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.
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.
$ 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 ;)
I've tested the following DNSMON msm types (for both address families):
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
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)
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
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.
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.
$ 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.
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.
"ripe-atlas measure --help" should be a bit more helpful
Extend the measure
command to support HTTP.
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.