.. _deploy:
Deploying Simple Bandwidth Scanner
=====================================
To run sbws is needed:
- A machine to run the :term:`scanner`.
- One or more :term:`destination` (s) that serve a large file.
Both the ``scanner`` and your the ``destination`` (s) should be on fast,
well connected machines.
.. _destinations_requirements:
Destination requirements
------------------------
- TLS support to avoid HTTP content caches at the various exit nodes.
- Certificates can be self-signed.
- A fixed IP address or a domain name.
- Bandwidth: at least 12.5MB/s (100 Mbit/s).
- Network traffic: around 12-15GB/day.
- An HTTP Web server, see next subsection.
HTTP server requirements
~~~~~~~~~~~~~~~~~~~~~~~~
- If the consensus parameter ``bwscanner_cc`` is not set or has a value lower
than 2:
A Web server installed and running that supports HTTP GET, HEAD and
Range (:rfc:`7233`) requests.
``Apache`` HTTP Server and ``Nginx`` support them.
It also needs to allow ```keep-alive``, in order to reuse connections between
the sbws HEAD request and the several GET ones.
.. Note:: if the server is configured with ``keep-alive`` timeout, it'd need
to be at least the same timeout as in the sbws HTTP requests, which is 10
seconds by default (``http_timeout`` variable in the configuration file,
see more about in the next section).
It also needs a large file; at the time of writing, at least 1 GiB in size
It can be created running::
head -c $((1024*1024*1024)) /dev/urandom > 1GiB
- If the consensus parameter ``bwscanner_cc`` has value 2:
A Web server installed and running that supports HTTP POST either:
- via ``Content-Type multipart/form-data`` (:rfc:`2388`) as a file upload.
- via ``Content-Type multipart/form-data`` RFC 2388 as a raw (text) field
upload.
If your Web server supports HTTP MQTT binary but not the 2 previous methods,
open an issue so that we implement the MQTT client part in the scanner.
Example configurations:
- Apache supporting HTTP GET and the three POST methods::
AllowOverride None
Order Deny,Allow
Deny from All
Allow from All
Allow from All
And in the directory of static files served::
head -c $((1024*1024*1024)) /dev/urandom > 1G
echo OK > postpath
- nginx supporting the three POST methods::
location /postpath {
root /same/path/to/normal/directory;
client_max_body_size 1G;
# should not be necessary, but just in case nginx tries to litter:
client_body_in_file_only clean;
# this is a really horrible hack:
error_page 405 =200 $uri;
}
And in the directory of static files served::
echo OK > postpath
You can test your configuration running:
- HEAD request::
curl https://bwauth.httpd.ip/1G -i -H "Range: bytes=0-1023"
It should reply::
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Length: 1024
Content-Range: bytes 0-1023/1073741824
- GET request::
curl -v https://bwauth.httpd.ip/1G
It should reply::
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Content-Length: 1073741824
- POST request::
dd if=/dev/zero of=post-20MB.zero bs=1k count=20480
curl -F "sbwstest=@post-20MB.zero" https://bwauth.httpd.ip/postpath -O
curl -F "sbwstest=`_ (in the local directory or Tor
Project Gitlab) or ``_ (local build or Read the Docs).
To run the ``scanner`` it is mandatory to create a configuration file with at
least one ``destination``.
It is recommended to set several ``destinations`` so that the ``scanner`` can
continue if one fails.
If ``sbws`` is installed from the Debian package, then create the configuration
file in ``/etc/sbws/sbws.ini``.
You can see an example with all the possible options here, note that you don't
need to include all of that and that everything that starts with ``#`` and
``;`` is a comment:
.. literalinclude:: /examples/sbws.example.ini
:caption: Example sbws.example.ini
If ``sbws`` is installed from the sources as a non-root user then create the
configuration file in ``~/.sbws.ini``.
More details about the configuration file can be found in
``./docs/source/man_sbws.ini.rst`` (in the local directory or Tor Project
Gitlab) or ``_ (local build or Read the Docs) or
``man sbws.ini`` (system package).
generator setup
---------------
The Debian package from version 1.6.0 replaces cron jobs by `systemd.timer`_
to run the ``generator`` and the ``cleanup`` command to clean the old data.
After the package is installed, it's needed to enable and start the timers
(Debian policy is not to start/enable services by default)::
systemctl enable --now sbws_cleanup.timer
systemctl enable --now sbws_generate.timer
To ensure they are enabled run::
systemctl list-timers
It should show the next time the ``generator`` or cleanup timer is going to
run::
Wed 2023-10-18 08:35:00 GMT 19min left Wed 2023-10-18 07:35:02 GMT 40min ago sbws_generate.timer sbws_generate.service
You can check that the timer service is working by invoking it directly::
systemctl start sbws_generate.service
If sbws is installed in some other way, you would need to create the timers or
cron jobs. Example cron jobs::
35 * * * * sbws /usr/local/bin/sbws -c /etc/sbws/sbws.ini generate
05 0 * * * sbws /usr/local/bin/sbws -c /etc/sbws/sbws.ini cleanup
You can modify the timers or cron jobs to get emails on failures.
For the cron jobs, use ``MAILTO``, for the timers, use ``OnFailure`` to call an
email service.
If the cron job is configured to send Email alerts on errors, it's probably
better to configure the log level to ``ERROR`` instead of ``WARNING``.
At level ``WARNING``, the first days, the ``generator`` will log every hour
that it hasn't reached enough percentage of relays to report.
After some days, if the scanner is located near fasts exits, it would also log
every hour that it is reporting more than the 50% of the consensus bandwidth.
The log level can be changed in the configuration file, for example::
to_stdout_level = error
This setup will affect both to the ``generator`` and the ``scanner``, so for
Email alerts, it's probably more convenient to configure it from the command
line, for example::
/usr/local/bin/sbws --log-level error generate
See also ``./docs/source/man_sbws.rst`` (in the local directory or Tor Project
Gitlab) or ``_ (local build or Read the Docs) or ``man sbws``
(system package).
.. _Content delivery network: https://en.wikipedia.org/wiki/Content_delivery_network
.. _systemd.timer: https://www.freedesktop.org/software/systemd/man/systemd.timer.html
Reading BandwidthFiles from the directory authority
---------------------------------------------------
The directory authority tor's configuration (torrc) must include
``V3BandwidthsFile`` option with the whole path to the ``latest.v3bw`` files
that the ``scanner`` generates.
.. note:: the user running the directory authority tor's daemon must have
permissions to read this path. If the daemon is launched by a ``systemd``
service, you would need to add a ``ReadOnlyDirectories`` entry with the
directory where the ``latest.v3bw`` is generated.
.. note:: During the ~5 first days the ``scanner`` has been running, the
``generator`` will mark all the ``RelayLines`` with ``vote=0``
until the scanner has measured more than the ~60% of the network.
The directory authority tor's daemon `ignore these lines`_ and warn about
`Empty bandwidth file`_
.. _ignore these lines: https://gitlab.torproject.org/tpo/core/tor/-/blob/cc31724f409ee5cff10d82ca05d43e04a85a44e1/src/feature/dirauth/bwauth.c#L413
.. _Empty bandwidth file: https://gitlab.torproject.org/tpo/core/tor/-/blob/cc31724f409ee5cff10d82ca05d43e04a85a44e1/src/feature/dirauth/bwauth.c#L258
Troubleshooting
---------------
See ``./docs/source/troubleshooting.rst`` (in the local directory or Tor Project
Gitlab) or ``_ (local build or Read the Docs)