Node Configuration Schema

Per-node configuration schema in nodewatcher is built from various Django models and mixins, using light extensions provided by the Registry ORM Extensions. This documentation specifies, for each registry item identifier (see Registry Items) the models that provide parts of the final schema.

Each node is defined as an instance of nodewatcher.core.models.Node and represents a network-connected device that may be managed by nodewatcher. The model instance itself only provides a universally unique identifier (UUID) and has no other attributes. All configuration attributes are added by various models through the use of the registry.


The general schema contains a basic node name configuration.

In case firmware generation support is enabled (by loading the nodewatcher.core.generator.cgm module), an extended set of options becomes available. These options configure the specific target device and firmware version that should be generated when requested.


The nodewatcher.modules.administration.types module provides a schema extension that enables types for each node to be configured. Currently, the following node types are registered by default:

  • server,
  • wireless,
  • test,
  • mobile,
  • dead,
  • unknown.

Additional types may be registered by other modules.


The nodewatcher.modules.administration.projects module provides a schema extension that enables projects for each node to be configured. Projects provide logical or geographical structuring of node deployments.

Each project may have multiple SSID configurations attached.

For each node a project may then be configured.


The nodewatcher.modules.administration.description module provides a schema extension that enables unstructured notes and an URL to be added to any node.


The nodewatcher.modules.administration.location module provides a schema extension that provides geographical positioning of a node.


To identify nodes within the routing protocols a configuration schema is provided to configure the router identifier of a node. Each node may have multiple router identifiers. The following router identifier families are registered by default:

  • ipv4,
  • ipv6.

Additional families may be registered by other modules (for example MAC addresses for L2 routing protocols).

For IP based router identifiers, there exist two specializations. The first enables static IP based router ID configuration.

The second enables allocation of router identifiers from IP pools.


There are multiple options provided for configuring user authentication on the nodes. By default, the nodewatcher.core.generator.cgm module provides a base class for all authentication mechanisms.

A password configuration option is also provided by default.

Public key authentication is provided by nodewatcher.modules.authentication.public_key module. It extends the schema with the public key authentication method. Multiple authentication methods may be configured for each node.

Public keys should be provided in a SSH-compatible encoding format, for example:

ssh-rsa AAAAB3NzaC1yc2EAAAADA...Oipsw25uxIvkDKjAxzQ== user@host


The module nodewatcher.modules.administration.roles adds support for specifying roles that a node may have. Several default roles are provided.

The following roles are provided by default:

  • system (the node has an important system function, required for network operation),
  • border-router (the node is a border router, enabling access to external networks),
  • vpn-server (the node provides a VPN server for other nodes),
  • redundancy-required (the node requires multiple redundant links).


When a device supports switch configurations, the switch may be configured using this registry item. A concrete implementation is provided with the core module.

All switches must define a default preset under the identifier default in their device descriptor.


Each switch can contain multiple VLAN configurations, which define how individual switch ports are grouped into VLANs.


In order to configure network interfaces, several interface types are implemented. All interface configurations extend a base class.

An abstract mixin is provided for configuring interfaces which may be used for routing purposes by the registered routing protocols. In case an interface should support routing, it should include the mixin among its bases.

The following interface types are currently implemented by nodewatcher.core.generator.cgm:

  • ethernet,
  • wifi radio,
  • wifi virtual interface,
  • mobile,
  • vpn,
  • bridge.

Wireless interfaces are split into two configuration classes. The first class instances represent physical wireless radios.

Then, for each wireless radio, multiple wireless virtual interfaces may be configured. Each virtual interface will cause a new wireless network to be created. By default, the following wireless modes are registered:

  • mesh,
  • ap,
  • sta.

Additional modes may be registered by other modules.

Modules may provide support for VPN tunnel interfaces. The nodewatcher.modules.vpn.tunneldigger module provides support for configuring Tunneldigger-based tunnels.

Configuration classes for mobile interfaces, like 3G, are also provided.

Bridges consisting of multiple other devices may also be configured.

For each of the above physical interfaces, various network configurations may be set. Note that not all network configurations may be used on all types of interfaces. A base class is provided for all network configurations.

An abstract mixin is provided for configuring networks which may be announce via a dynamic routing protocol. In case a network should support such announcement, it should include the mixin among its bases.

Another abstract mixin is provided for configuring networks which may be leased to clients via DHCP or other protocols. In case a network should support leases, it should include the mixin among its bases.

The simplest is a static IP network configuration.

Resources may also be configured from various pools (for available fields, see Resources).

Interfaces may also be configured to obtain addresses via DHCP.

Ethernet interfaces may also be configured via PPPoE.

For bridge slaves, network configuration specifies the master bridge interface.


Various limits (like QoS) may also be configured for each interface.

Currently, a throughput limit may be configured.


Multiple DNS servers may also be configured.