Setting Up the Development Environment

In order to make nodewatcher development as simple as possible, a Docker development environment can be built from the provided Dockerfile. To help with preparing the environment and running common tasks, Docker Compose configuration is also provided. This section describes how to use both to work on nodewatcher. It is assumed that Docker and Docker Compose are already installed, so in order to install them, please follow the guides on their respective pages.

Running the Development Instance

In order to ensure that you have the latest versions of all dependent Docker images, you have to first run the following command in the top-level nodewatcher directory:

$ docker-compose pull

Then, to build the development instance, run:

$ docker-compose build

You should re-run these two commands when performing git pull if you think that the build dependencies or development environment configuration might have changed to ensure that your Docker images are synced. Finally, to run the development server simply execute the following command:

$ docker-compose up


Default container configuration stores the database under /tmp/nodewatcher-db, so it will be removed on host machine restarts. You may change this location by editing docker-compose.yml.

The following containers will be created and started when you run the above commands:

  • db contains the PostgreSQL 9.5 database server with installed extension PostGIS 2.1.
  • influxdb contains the InfluxDB time-series database server.
  • redis contains the Redis server.
  • builder* contain firmware builders that you can use for development (see Running a Firmware Builder).
  • generator contains the Celery workers for the firmware image generator. These workers connect to the builder via SSH in order to build firmware images.
  • monitorq contains the Celery workers for handling monitoring push requests.
  • web contains the nodewatcher frontend (Django development server), running on port 8000 by default.

Initializing the Database


This and all further sections assume that the development environment has been started via docker-compose up and is running (in the background or in another terminal). If the environment is not running, some of the following commands will fail.

In order to prepare the database, after running the development server execute:

$ docker-compose run web scripts/docker-init-database

This will recreate the nodewatcher database and thus erase ALL data from the database. If you wish to reinitialize the database at any later time, simply re-running the above command should work. Then, to populate the database with nodewatcher schema call migrate:

$ docker-compose run web python migrate

This will initialize the database schema.


When running any Django management command, do not forget to run it via the container as otherwise the settings will be wrong. You can do it by prefixing commands with docker-compose run web like this:

$ docker-compose run web python <command...>

Compiling Stylesheets

For default nodewatcher stylesheets we are using Compass, which means that SCSS files have to be compiled into CSS files before CSS files can be served to users. Compass is built on top of Sass, which is an an extension of CSS3 and adds nested rules, variables, mixins, selector inheritance, and more. Sass generates well formatted CSS and makes our stylesheets easier to organize and maintain. It also makes stylesheets easier to extend and reuse so it is easier to build on default nodewatcher stylesheets and add small changes you might want to add for your installation.

To compile SCSS files into CSS files run:

$ docker-compose run web python collectstatic -l

Initial Setup

From Scratch

If you are installing the nodewatcher from scratch, you should probably now create a Django admin account. You can do this by opening nodewatcher initial setup page at http://localhost:8000/setup/, and follow instructions there.

Afterwards, you can login with this account into the nodewatcher at http://localhost:8000/account/login/ or into the nodewatcher’s admin interface at http://localhost:8000/admin/.


Depending on your Docker installation the web interface might not be available at localhost but at some other address.

From nodewatcher v2 Dump

If you have a JSON data export from nodewatcher version 2 available and would like to migrate to version 3, the procedure is as follows (after you have already performed the database initialization above). Let us assume that the dump is stored in a file called dump.json (note that the dump file must be located inside the top-level directory as commands are executed inside the container which only sees what is under the toplevel nodewatcher directory). The dump can be imported by running:

$ docker-compose run web python import_nw2 dump.json

Now the database is ready for use with nodewatcher 3.

Running a Firmware Builder

In order to develop firmware generator related functions, a firmware builder is provided with the development installation. In order to use it, you have to configure it via the nodewatcher admin interface. First, you have to create a default build channel and add a builder (or multiple builders if you want support for multiple architectures).

The following information should be used when adding a builder:

  • Host:
    • builderar71xx
    • builderlantiq
  • Private key:

    -----END RSA PRIVATE KEY-----


    This public/private key pair should only be used for development. For production deployments you should generate new key pairs and configure them appropriately (the public key can be configured by setting the BUILDER_PUBLIC_KEY environmental variable on the builder Docker container).

    In order to generate a new RSA key pair, you may use:

    $ ssh-keygen -f builder.key -C "builder@host"

    This will generate a builder.key (private key) and (public key).

Running the Monitoring System

In order to enable data collection from nodes, the monitoring system needs to be running. It is important that the nodewatcher instance is able to connect to the nodes directly by their IP addresses. This can usually be achieved by establishing a VPN tunnel to some server that is connected to the mesh network.

Then, there are two configuration options that need to be set in

  • OLSRD_MONITOR_HOST should point to an IP address where an olsrd instance is responding to HTTP requests about the routing state using the txtinfo plugin. In the default configuration, this will be used by the modules.routing.olsr module to enumerate visible nodes and obtain topology information.
  • MEASUREMENT_SOURCE_NODE should be set to an UUID of a node that is performing the RTT measurements (this means that such a node must first be created using nodewatcher). This option is planned to be removed from and moved into the administration interface.

After the above settings are configured, one may run the monitoring system by issuing:

$ docker-compose run web python monitord

There are some additional options which might be useful during development:

  • --run=<run> will only execute one run instead of all runs configured using MONITOR_RUNS setting.
  • --cycles=<cycles> will only perform a fixed amount of cycles before terminating. By default, the monitor process will run indefinitely.
  • --process-only-node=<node-uuid> may be used to only perform monitoring processing on a single node, identified by its UUID.


The monitoring system may use a lot of CPU and memory resources when there are a lot of nodes to process.