Go to file
Simone Basso 6351d898d6
refactor: miniooni should be outside of the engine (#206)
* refactor: miniooni should be outside of the engine

This is part of https://github.com/ooni/probe/issues/1335. We also need
to think whether we wanna keep libminiooni and miniooni separated.

The previous use case for having a top-level libminiooni was that of
enabling others to integrate miniooni into other binaries.

This was usegul when studying internet censorship in Spain in May 2020.

I am wondering whether we should be keeping this complexity. I am not
sure about this and probably we should be killing it.

(In any case, reducing complexity is not the objective of this diff,
since I would like instead to move things around with minimal changes
and make sure we have a ~good repository organization here.)

* fix: import in libminiooni
2021-02-03 11:21:10 +01:00
.github/workflows refactor: start building an Android package (#205) 2021-02-03 10:51:14 +01:00
CLI refactor: build miniooni from toplevel (#203) 2021-02-02 15:34:03 +01:00
cmd/ooniprobe chore: merge probe-engine into probe-cli (#201) 2021-02-02 12:05:47 +01:00
data feat: use ooni/probe-engine@286613b74e and cleanup (#177) 2020-11-26 18:48:20 +01:00
debian debian: run as a daemon, ask informed consent (#162) 2020-12-15 13:05:13 +01:00
docs Address feedback from @bassosimone 2019-12-04 13:13:13 +02:00
internal refactor: miniooni should be outside of the engine (#206) 2021-02-03 11:21:10 +01:00
MOBILE refactor: start building an Android package (#205) 2021-02-03 10:51:14 +01:00
pkg/oonimkall refactor: start building an Android package (#205) 2021-02-03 10:51:14 +01:00
.gitignore refactor: miniooni should be outside of the engine (#206) 2021-02-03 11:21:10 +01:00
build-android.bash refactor: start building an Android package (#205) 2021-02-03 10:51:14 +01:00
build-miniooni.sh refactor: miniooni should be outside of the engine (#206) 2021-02-03 11:21:10 +01:00
build.sh fix(build.sh): clarify for what Linux archs we build (#198) 2021-01-25 17:45:26 +01:00
CODE_OF_CONDUCT.md doc: add code of conduct (#157) 2020-11-03 21:16:04 +01:00
go.mod chore: merge probe-engine into probe-cli (#201) 2021-02-02 12:05:47 +01:00
go.sum chore: merge probe-engine into probe-cli (#201) 2021-02-02 12:05:47 +01:00
LICENSE.md Add LICENSE.md 2018-07-11 18:06:27 +02:00
publish-android.bash refactor: start building an Android package (#205) 2021-02-03 10:51:14 +01:00
Readme.md Update Readme.md 2020-12-09 12:52:57 +01:00
smoketest.sh fix: import path should be github.com/ooni/probe-cli/v3 (#200) 2021-02-02 10:32:46 +01:00
updatebindata.sh fix: import path should be github.com/ooni/probe-cli/v3 (#200) 2021-02-02 10:32:46 +01:00

OONI Probe CLI

linux-debian-packages GitHub issues by-label

The next generation OONI Probe Command Line Interface.

User setup

  1. Go into the releases and download the release for your architecture and platform

  2. Extract the tarball with tar xvzf ooniprobe_*.tar.gz

  3. Copy the ooniprobe binary into a location in your $PATH, for example /usr/local/bin/ooniprobe

  4. Run ooniprobe run to perform all the tests

Optional:

Add a crontab entry (on linux) to run ooniprobe daily at a random time:

(crontab -l 2>/dev/null; echo "$(( ( RANDOM % 60 )  + 1 )) $(( ( RANDOM % 24 )  + 1 )) * * * ooniprobe run") | crontab -

On macOS you can configure OONI Probe to run automatically using launchd.

Below is a sample launchd script, that should be placed inside of ~/Library/LaunchAgents/org.ooni.probe.cli.plist.

Be sure to replace /PATH/TO/BINARY/ooniprobe with the actual install location of the ooniprobe binary.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>org.ooni.probe.daily-run</string>

  <key>KeepAlive</key>
  <false/>
  <key>RunAtLoad</key>
  <true/>

  <key>ProgramArguments</key>
  <array>
      <string>/PATH/TO/BINARY/ooniprobe</string>
      <string>--log-handler=syslog</string>
      <string>run</string>
      <string>unattended</string>
  </array>

  <key>StartInterval</key>
  <integer>86400</integer>

</dict>
</plist>

Once you have written the file, you can enable ooniprobe to run automatically by doing: launchctl load org.ooni.probe.cli.plist.

Reporting issues

Please, report issues with this codebase at https://github.com/ooni/probe. Please, make sure you tag such issues using the ooni/probe-cli label.

Development setup

Be sure you have golang >= 1.14 and a C compiler (when developing for Windows, you need Mingw-w64 installed). The most basic build command is:

go build -v ./cmd/ooniprobe

To compile a release used the build.sh script. For more information

./build.sh help

The output generated by this command should provide you with updated information regarding the pre-requisites for building (and cross-building) ooniprobe as well as useful information regarding cross compiling.

To update bundled binary data use:

./updatebindata.sh

Updating dependencies

go get -u -v ./... && go mod tidy

Releasing

  1. update binary data as described above;

  2. update internal/version/version.go;

  3. make sure you have updated dependencies;

  4. run ./build.sh release and follow instructions.