Tip

This is the documentation for the 25.06 version. Looking for the documentation of the latest version? Have a look here.

Configuration Database

TNSR maintains three separate configuration databases: startup, candidate, and running. These files are stored as XML in plain text files.

startup:

The configuration loaded when the host boots up.

Note

A restart of TNSR services is not the same as a reboot. If, for example, the clixon services are restarted, TNSR will still be using the running database.

candidate:

An in-process potential configuration that exists while the TNSR configuration is being actively edited. When committed, this configuration will be accepted as the running configuration by TNSR if it is free of errors.

running:

The active running configuration, which reflects the current state of TNSR.

Note

These databases are located in /var/tnsr/ on the host, but these files are not intended to be accessed outside of TNSR.

The configuration database is managed using the db command.

Tip

The db command is available in config mode and basic mode. The older configuration command form is only available within config mode, and still works there as an alias to the db command.

See also

Saving the Configuration

For changes to persist between reboots of the TNSR host, the running configuration must be copied to the startup configuration as shown in this example:

tnsr# db copy running startup

There is a shortcut command for this specific operation as well, which may be familiar for certain users:

tnsr# write-running-config

Tip

The write-running-config can be abbreviated as write or even wr.

Viewing the Configuration

To view the configuration databases, use the show db command followed by the database name, for example:

tnsr# show db running

or:

tnsr# show db run

The output format can be given after the database name using one of the following names:

xml [(explicit|report-all)]:

XML format. The default output format, and the native format of the configuration databases.

The optional parameters control which information is returned by the command:

explicit:

Only reports configuration items which have explicitly been configured by the user. This is the default behavior.

report-all:

Report not only explicitly configured configuration values, but default values assumed by TNSR.

json [(explicit|report-all)]:

JSON format, similar to the data format used by RESTCONF. The optional parameters work the same as they do for XML format noted previously.

cli [<section>]:

Outputs a set of CLI commands which can be pasted back into a terminal to re-create the current configuration.

Tip

The cli format is useful for replicating parts of a configuration on another TNSR instance without restoring a full configuration database.

When using the cli format, an optional configuration area name can limit the output to a certain portion of the database. For example, to show only the DHCP server configuration:

tnsr# show db running cli kea
dhcp4 enable
dhcp4 server
    option domain-name
        data example.com
    exit
    description LAN DHCP Server
    lease persist true
    lease lfc-interval 0
    interface listen LAN
    interface socket raw
    subnet 10.2.0.0/24
        id 1
        interface LAN
        option domain-name-servers
            data 10.2.0.1
        exit
        option routers
            data 10.2.0.1
        exit
        pool 10.2.0.129-10.2.0.191
        exit
    exit
exit

There is a shortcut command to view the CLI format output, which may be familiar for certain users:

tnsr# show running-configuration

This command can be abbreviated to sh run. Like its fully typed out counterpart, the output can be limited by adding a section name to the end of the command.

Reverting to the Startup Configuration

TNSR can also revert to the previously saved startup configuration to remove undesirable changes to the running configuration, should a regression in behavior occur.

For example:

tnsr# db copy startup candidate
tnsr# db candidate commit
tnsr# exit

Warning

It is not possible to copy the startup configuration directly to the running configuration as that will not result in the settings being active. The configuration must be committed after copying to the candidate.

Configuration Database Commands

These brief examples show other available configuration database management commands.

Delete the candidate database entirely, which if committed will leave TNSR with an empty configuration:

tnsr# db candidate clear

Commit changes made to the candidate database, which if successful will become the running database:

tnsr# db candidate commit

Note

Nearly all changes made in the TNSR CLI will be committed automatically as commands are entered by the user. There is rarely a need to perform this step manually.

Discard the current candidate database to remove a change that has failed to validate, returning to the running configuration without the attempted changes:

tnsr# db candidate discard

Attempt to validate the current candidate configuration to locate errors:

tnsr# db candidate validate

Load a file from the host into the candidate database. The contents of the file can replace the candidate entirely, or merge a new section into an existing configuration. After loading, the candidate must be committed manually.

tnsr# db candidate load <filename> [(replace|merge)]

Copy the candidate configuration to the startup configuration:

tnsr# db copy candidate startup

Copy the running configuration to either the candidate or startup configuration:

tnsr# db copy running (candidate|startup)

Copy the startup configuration to the candidate configuration:

tnsr# db copy startup candidate

Save either the candidate or running configuration to a file on the host.

tnsr# db save (candidate|running) <filename>

While not a configuration database command directly, the TNSR CLI automatically discards the candidate database if it fails to validate. This behavior can be changed using the following command:

tnsr# no cli option auto-discard