Giters

m-lab / murakami

Run automated internet measurement tests in a Docker container.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

consider ooni probe-cli to support test runners for ooni suite of tests

critzo opened this issue · comments

commented

The test-ooni-probe-engine branch contains a Dockerfile and Dockerfile.template that builds the probe-cli binary. Test runners and integration into the Murakami system is still to-do.

commented

Below are some notes from recent conversations:

We've discussed using the option ooniprobe run unattended as being the default behavior within Murakami. This way it would function as an automated probe for most situations, but also could also be overridden to enable individual users to choose which tests of the suite to enable using options in a .ooniprobe config file.

So Murakami would have one environment variable for OONI:
MURAKAMI_TESTS_OONI_ENABLED=1

and all other options would be controlled by a .ooniprobe config file that ships with the Murakami release. This fits the model we're already using for multiple ndt7 tests in the internet-resilience branch.

ooniprobe run unattended produces four test results: websites, middlebox, im, & circumvention

We could install sqlite3 and then the exporters could read ~/.ooniprobe/db/main.sqlite3 for an index of existing tests, and then use ooniprobe show [1234], to output the JSON for each test to a result file. Then the exporter would run ooniprobe reset --force to reset the database, and finally copy an included config file to reset the options: cp /murakami/configs/ooniprobe-config.json ~/.ooniprobe/config.json

And if users don't want the default behavior, they could set options in ooniprobe-config.json and include it in their Murakami build.

commented

Thanks for adding these notes @critzo .

So, a general idea of how this integration could look like:

  1. The ooniprobe CLI tool is installed as part of the Dockerfile via the official APT repositories, provided by OONI. No additional first-time setup needed (more on the "onboarding" step below)
  2. A new Murakami runner is created, joining the existing ones as part of Murakami's normal test scheduling (configurable via TOML and/or env variables)
  3. The runner makes sure on each run that:
    a. the database is empty (ooniprobe reset --force)
    b. the onboarding is skipped (ooniprobe onboard --yes)
  4. The runner runs ooniprobe run unattended, waits for it to finish -- this creates 4 entries in ooniprobe's sqlite database
  5. The runner lists all the existing tests and their IDs with ooniprobe list --batch and extracts the IDs
  6. For each ID, it runs ooniprobe show <ID> --batch to get a minified JSON with the test results
  7. The runner wraps this JSON into another JSON containing Murakami metadata on the top level (connection type, location, etc)

Once this is done, the 4 JSON objects are passed to all the exporters the user has enabled, and processing happens as usual. There are no configuration options, as far as I can tell, other than the one to enable/disable this runner (MURAKAMI_TESTS_OONI_ENABLED=1)

Since the database cleanup happens at the beginning, the sqlite database will stay on disk (under ~/.ooniprobe/) but will only contain the results of the latest ooniprobe run at any given time.

I'm going to create specific issues for the steps above, please let me know if there is something incorrect.

commented

Completed in #103