This is the documentation for the v21.03 version. Looking for the documentation of the latest version? Have a look here.
TNSR maintains three separate configuration databases: startup, candidate, and running. These files are stored as XML in plain text files.
The configuration loaded when the host boots up.
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.
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.
The active running configuration, which reflects the current state of TNSR.
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
configuration command from
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# configure tnsr(config)# configuration copy running startup
Viewing the Configuration¶
To view the configuration databases, use the
show configuration command
followed by the database name, for example:
tnsr# show configuration running
tnsr# show conf run
The output format can be given after the database name using one of the following names:
XML format. The default output format, and the native format of the configuration databases.
JSON format, similar to the data format used by RESTCONF
- cli [<section>]
Outputs a set of CLI commands which can be pasted back into a terminal to re-create the current configuration.
cliformat is useful for replicating parts of a configuration on another TNSR instance without restoring a full configuration database.
When using the
cliformat, 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 configuration 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 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
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.
tnsr# configure tnsr(config)# configuration copy startup candidate tnsr(config)# configuration candidate commit tnsr(config)# exit
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(config)# configuration candidate clear
Commit changes made to the candidate database, which if successful will become the running database:
tnsr(config)# configuration candidate commit
Discard the current candidate database to remove a change that has failed to validate, returning to the running configuration without the attempted changes:
tnsr(config)# configuration candidate discard
Attempt to validate the current candidate configuration to locate errors:
tnsr(config)# configuration 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(config)# configuration candidate load <filename> [(replace|merge)]
Copy the candidate configuration to the startup configuration:
tnsr(config)# configuration copy candidate startup
Copy the running configuration to either the candidate or startup configuration:
tnsr(config)# configuration copy running (candidate|startup)
Copy the startup configuration to the candidate configuration:
tnsr(config)# configuration copy startup candidate
Save either the candidate or running configuration to a file on the host.
tnsr(config)# configuration 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(config)# no cli option auto-discard