Skip to main content

Configuration

Enabling networks​

Networks are enabled per node by adding a networks: section to the node's configuration file. The node that has it keeps the networks and blueprints, shows the Networks section in its dashboard, and becomes the relay of every network it creates.

The node must also be part of a hub, either as the hub server or as a node connected to one. A network is made up of the nodes connected to that hub.

Example configuration for a hub server that also keeps networks:

config.yaml
node:
  name: server

http:
  address: 127.0.0.1:8769

hubServer:
  authenticationByRequest:
    timeout: 5m

networks:

Other nodes don't need a networks: section to take part in a network. They join automatically once they are connected to the hub.

On the cloud hub, no node keeps networks: the cloud hub keeps them for all its nodes. See Networks on the cloud hub.

Nodes must be allowed to create network interfaces

The built-in Client blueprint creates a TUN interface (tun0) on every node in the network, including the relay. Run NanoPing as root (sudo np up), or on Linux give np the capabilities to create network interfaces. np up refuses to start a node that has neither, and says which capabilities are missing.

Networks on the cloud hub​

The cloud hub keeps the networks and blueprints of every node in your organization, and the dashboard shows them in its Networks section. You don't need a networks: section on any node.

A node with networks: in its configuration doesn't start while it is on the cloud hub, or when it will join it. np up fails with an error that says so. To start it, either:

  • remove networks: from its configuration, so it joins the cloud hub like any other node, or
  • keep it off the cloud hub, and connect it to a hub of your own or run one. A node that has never been on the cloud hub stays off it with cloudHub.enabled: false. One that has been on it has to leave it first, which also keeps it off the cloud hub until it joins again.

Moving networks to the cloud hub​

The networks and blueprints a node kept stay in its database, but they aren't moved to the cloud hub. Create them again in the dashboard, as described in Creating a network and Creating a blueprint.

To look at the old networks while you do, keep the node off the cloud hub for a while:

  1. Take the node off the cloud hub. If it has been on it, remove networks: from its configuration, start it with np up and leave the cloud hub. If it never has, set cloudHub.enabled: false in its configuration instead.
  2. Put networks: back if you removed it, and restart the node. It keeps its networks again, and its dashboard shows them.
  3. Create each network and blueprint again from the dashboard of a node that is on the cloud hub.
  4. Remove networks:, and cloudHub.enabled: false if you set it, from the configuration, and restart the node. A node that left the cloud hub joins it again with Join Cloud Hub on the Hub Connection page of its Settings; the other joins it by itself. Either way it gets the networks kept there.

Default node carriers​

A node can list the carriers it should get whenever it joins a network, so you don't have to add them by hand in every network. This is configured in each joining node's own configuration file, at the top level.

  • defaultNetworkCarriers
    • carriers - array
      • optional address
        • ip - string
        • port - uint32
        • optional externalIp - string
      • optional interface - string
      • optional bandwidthPriority - uint32

Each carrier needs an address, an interface, or both. The relay needs a carrier with an address. See Carriers for what each field means.

Example:

config.yaml
defaultNetworkCarriers:
  carriers:
    - address:
        ip: "192.168.0.10"
        port: 3425
        externalIp: "203.0.113.7"
      interface: "eth0"
      bandwidthPriority: 100

Default carriers are only applied when a node joins a network. Changing them later doesn't change networks the node is already in. Edit those carriers in the network instead.

Default blueprints​

The default blueprints are used by every network that doesn't have its own blueprint assigned. On first start, NanoPing sets the built-in Relay, Relay Client and Client blueprints as the defaults.

The simplest way to change a default is from the dashboard, as described in Default blueprints. On the cloud hub, that is the only way, since no node keeps the networks. On a hub of your own, you can fix a default in the configuration file instead, under networks: on the node that keeps the networks:

  • networks
    • defaultBlueprints
      • optional relay - string
      • optional relayClient - string
      • optional client - string

Each value is a blueprint key: the last part of the blueprint's address in the dashboard, /blueprint/<key>.

Example:

config.yaml
networks:
  defaultBlueprints:
    client: "74c6491e-bcad-11f1-95d3-9c6b008999fe"
note

A default set in the configuration file takes precedence and can't be changed from the dashboard. Trying it shows An error occurred while updating default … blueprint. Defaults that aren't in the file can still be changed from the dashboard.