Configuring local Nano Client

The local.yml configuration is the base of a running Nano which handles the Nano instance, dependencies and localhost security.

For security reasons, Nano can not update this configuration file. To ensure that this rule won’t be circumvented it is recommended to set this file to read-only.

Updating this file requires the Nano to be restarted in order to see the changes.

log_config

Nano uses the builtin Python logging module for it’s internal logging tasks. For configuring the logging module, please refer to the official Python docs .

remote_admin_policy

default: "restrict"

This option sets the way Nano handles the remote configuration commands issued by the Nano owner.

Three settings are accepted here:
  • allow accepts all admin commands

  • restrict will prompt the owner to input a passcode of 5 digits along with each command

  • deny rejects all admin commands

The remote configuration commands update the settings found in the remote.yml configuration file.

Enabling this security policy may greatly limit the damage an adversary could do by gaining access to the account of the owner. The downside however is that even the owner will be unable to change configurations remotely, which could be highly inconvenient depending on the location of the hardware which runs the Nano client.

localhost_network_security

default: "ec"

This configuration determines how the different processes in a nano instance authenticate and communicate with each other. By default Nano ensures authentication and confidentiality during process communication. This can be changed to only require basic authentication which consumes less system resources.

Two settings are accepted here:
  • ec authenticates processes and encrypts communication with dynamically generated x5519 curves

  • basic authenticates processes with dynamically generated plain passwords


Danger

The configurations below handle software dependency - incorrect setup will stop Nano from booting up

config_dir

default: ""

An absolute path pointing to a writable directory where necessary configurations will be stored, such as drive, authentication etc.

data_dir

default: ""

An absolute path pointing to a writable directory where necessary data will be stored like sessions, state, etc.

pid_dir

default: "pid"

An absolute or relative path pointing to a writable directory where subprocess tracking information will be stored. This directory must be on a local filesystem.

Note

If the pid_dir is relative, it will be appended to data_dir

solr_dir

default: ""

An absolute or relative path pointing to a writable directory where Apache Solr stores index data and configurations. These paths can be overridden by more specific configurations (see below).

The directory should be on the local filesystem. (NFS is theoretically possible, but not supported well)

This location should be secured as properly as the data itself from local access (other users).

solr_data_dir

default: "data"

An absolute or relative path pointing to a writable directory where Apache Solr data files will be stored.

Note

If the solr_data_dir is relative, it will be appended to solr_dir

solr_logs_dir

default: "data"

An absolute or relative path pointing to a writable directory where Apache Solr log files will be stored.

Note

If the solr_logs_dir is relative, it will be appended to solr_dir

tika_dir

default: ""

An absolute or relative path pointing to a writable directory where Apache Tika stores log files and configurations. This path can be overridden by more specific configurations (see below).

The directory should be on the local filesystem. (NFS is theoretically possible, but not supported well)

This location should be secured as properly as the data itself from local access (other users).

tika_logs_dir

default: "logs"

An absolute or relative path pointing to a writable directory where Apache Tika log files will be stored.

Note

If the tika_logs_dir is relative, it will be appended to tika_dir

java_dir

default: ""

An absolute path pointing to a directory where JRE is located.

Some dependency software which Nano uses are Java based and require a JVM to run.

If left empty, Nano will try to lookup the JRE from default locations:
  • Use JRE that’s bundled with the client

  • Use JRE indicated by JAVA_HOME environment variable

  • Use JRE found in PATH (java executable)

solr_bundle_dir

default: “”

An absolute path pointing to a directory where Apache Solr is located.

If left empty, Nano will try to use the client’s bundled software.

tika_bundle_dir

default: “”

An absolute path pointing to a directory where Apache Tika is located.

If left empty, Nano will try to use the client’s bundled software.