NCS man-pages, Volume 1

ConfFile is the path to a ncs.conf file. If the -c File argument is not given to ncs, first $PWD is searched for a file called ncs.conf, if not found $NCS_DIR/etc/ncs/ncs.conf is chosen.

Change working directory

Add Dir to the set of directories NCS uses to load fxs, clispec, NCS packages and SNMP bin files.

Do not log initial startup messages to syslog.

Number of threads to run for Symmetric Multiprocessing (SMP). The default is to enable SMP support, with as many threads as the system has logical processors, if more than one logical processor is detected. Giving a value of 1 will disable SMP support, while a value bigger than 1 will enable SMP support, where NCS will at any given time use at most as many logical processors as the number of threads.

Do not start as a daemon. Can be used to start NCS from a process manager. In combination with -v or --verbose, all log messages are printed to stdout. Useful during development. In combination with --stop-on-eof, NCS will stop if it receives EOF (ctrl-d) on standard input. Note that to stop NCS when run in foreground, send EOF (if --stop-on-eof was used) or use ncs --stop. Do not terminate with ctrl-c, since NCS in that case won't have the chance to close the database files.

When NCS starts, if the private package directory tree already exists, NCS will load the packages from this directory tree and not search the load-path for packages. If the --with-package-reload option is given when starting NCS, the load-path will be searched and the packages found there copied to the private package directory tree, replacing the previous contents, before loading. This should always be used when upgrading to a new version of NCS in an existing directory structure, to make sure that new packages are loaded together with the other parts of the new system.

When NCS is started from the /etc/init.d scripts, that get generated by the --system-install option to the NCS installer, the environment variable NCS_RELOAD_PACKAGES can be set to 'true' to attempt a package reload.

When reloading packages NCS will give a warning when the upgrade looks "suspicious", i.e. may break some functionality. This is not a strict upgrade validation, but only intended as a hint to NSO administrator early in the upgrade process that something might be wrong. Please refer to Loading Packages section in NSO Administration Guide for more information.

If all changes indicated by the warnings are intended, this option allows to override warnings and proceed with the upgrade. This option is equivalent to setting NCS_RELOAD_PACKAGES environment variable to 'force'.

When CDB starts on an empty database, or when upgrading, it starts a transaction to load the initial configuration or perform the upgrade. This option makes NCS skip any validation callpoints when committing these initial transaction. (The preferred alternative is to use start-phases and register the validation callpoints in phase 0, see the user guide).

Perform a full validation of the entire database if the data models have been upgraded. This is useful in order to trigger external validation to run even if the database content has not been modified.

Do not compact CDB files when starting the NCS daemon.

Start the daemon, but only start internal subsystems and CDB. Phase 0 is used when a controlled upgrade is done.

Determines whether NCS should use an enhanced poll() function (e.g. Linux epoll(7)). This can improve performance when NCS has a high number of connections, but there may be issues with the implementation in some OS/kernel versions. The default is true.

This call hangs until NCS has initialized start phase0. After this call has returned, it is safe to register validation callbacks, upgrade CDB etc. This function is useful when NCS has been started with --foreground and --start-phase0. It will keep trying the initial connection to NCS for at most TryTime seconds (default 5).

Do not start the subsystems that listen to the management IP address. Must be called after the daemon was started with --start-phase0.

Must be called after the management interface has been brought up, if --start-phase1 has been used. Starts the subsystems that listens to the management IP address.

This call hangs until NCS is completely started. This function is useful when NCS has been started with --foreground. It will keep trying the initial connection to NCS for at most TryTime seconds (default 5).

Reload the NCS daemon configuration. All log files are closed and reopened, which means that ncs --reload can be used from e.g. logrotate(8), but it is more efficient to use ncs_cmd -c reopen_logs for this purpose. Note: If we update a .fxs file it is not enough to do a reload; the "packages reload" action must be invoked, or the daemon must be restarted with the --with-package-reload option.

Asynchronously reload the NCS daemon configuration. This can be used in scripts executed by the NCS daemon.

Stop the NCS daemon.

Prints status information about the NCS daemon on stdout. Among the things listed are: loaded namespaces, current user sessions, callpoints (and whether they are registered or not), CDB status, and the current start-phase. Start phases are reported as "status:" and can be one of starting (which is pre-phase0), phase0, phase1, started (i.e. phase2), or stopping (which means that NCS is about to shutdown).

Dump debug information from an already running NCS daemon into a File. The file only makes sense to NCS developers. It is often a good idea to include a debug dump in NCS trouble reports.

Additional options are supported as following

Dump cli structure information from the NCS daemon into a file.

Walks through the entire data tree (config and stat), or only the Namespace or Path, and verifies that all read-callbacks are implemented for all elements, and verifies their return values.

Load configuration in curly bracket format from File.

Rollback configuration to saved configuration number Nr.

Load configuration in XML format from Files. The configuration is completely replaced by the contents in Files.

Load configuration in XML format from Files. The configuration is merged with the contents in Files. The XML may use the 'operation' attribute, in the same way as it is used in a NETCONF <edit-config> operation.

Specify the maximum time to wait for the NCS daemon to complete the command, in seconds. If this option is not given, no timeout is used..

Print debug information about the CDB files in Directory to stdout. This is a completely stand-alone feature and the only thing needed is the .cdb files (no running NCS daemon or .fxs files etc).

Additional options may be provided to alter the output format and content.

Specify subtrees to prevent printing the entire database.

The output may also be filtered by file type using the skip_conf, skip_oper and skip_snap options to filter out configuration, operational and snapshot databases respectively.

Compact CDB files in Directory. This is a completely stand-alone feature and the only thing needed is the .cdb files (no running NCS daemon or .fxs files etc).

Reports the ncs version without interacting with the daemon.

See above

Restore a previously created backup. For backups of "system installations", the Backup argument is either the name of a file in the RunDir/backups directory or the full path to a backup file. If the argument is omitted, unless the --non-interactive option is given, the command will offer selection from available backups.

For backups of "local installations", the Backup argument must be a path to a backup file. Also, "local installation" restoration must target an empty directory as --install-dir.

Specifies the directory for installation of NCS static files, like the --install-dir option to the installer. In the case of "system installations", if this option is omitted, /opt/ncs will be used for InstallDir.

In the case of "local installations", the --install-dir option should point to the directory containing an 'ncs.conf' file. If no 'ncs.conf' file is found, the default 'ncs.conf' of the NCS installation will be used.

If you are restoring a backup of a "local installation", --install-dir needs to point to an empty directory.

If this option is used, restore will proceed without asking for confirmation.

If this option is used, the backup will not be compressed (default is compressed). The restore will uncompress if the backup is compressed, regardless of this option.

command to start and control the NCS daemon

NCS daemon configuration file format

CLI specification file format

MIB annotations file format

Display help text.

Gives the name of the current host. The ncs_cli program will use the value of the system call gethostbyname() by default. The host name is used in the CLI prompt.

CLI address to connect to. The default is 127.0.0.1. This can be controlled by either this flag, or the UNIX environment variable NCS_IPC_ADDR. The -A flag takes precedence.

CLI port to connect to. The default is the NSO IPC port, which is 4569 This can be controlled by either this flag, or the UNIX environment variable NCS_IPC_PORT. The -P flag takes precedence.

Path of the UNIX domain socket to connect to, used in place of TCP (address and port). Controlled by either this flag, or the UNIX environment variable NCS_IPC_PATH. The -S flag takes precedence.

The current working directory for the user once in the CLI. All file references from the CLI will be relative to the cwd. By default the value will be the actual cwd where ncs_cli is invoked.

The protocol the user is using to connect. This value is used in the audit logs. Defaults to "ssh" if SSH_CONNECTION environment variable is set, "console" otherwise.

The IP (or IP address and port) which NSO reports that the user is connecting from. This value is used in the audit logs. Defaults to the information in the SSH_CONNECTION environment variable if set, 127.0.0.1 otherwise.

Produce additional output about the execution of the command, in particular during the initial handshake phase.

Force the CLI to echo prompts and commands. Useful when ncs_cli auto-detects it is not running in a terminal, e.g. when executing as a script, reading input from a file or through a pipe.

Force the CLI to only show the output of the commands executed. Do not output the prompt or echo the commands, much like a shell does for a shell script.

Force the CLI to terminate at the first error and use a non-zero exit code.

A special character that forcefully terminates the CLI when repeated three times in a row. Defaults to control underscore (Ctrl-_).

This flag sets the mode of the CLI. -J is Juniper style CLI, -C is Cisco XR style CLI.

The username of the connecting user. Used for access control and group assignment in NSO (if the group mapping is kept in NSO). The default is to use the login name of the user.

A comma-separated list of groups the connecting user is a member of. Used for access control by the AAA system in NSO to authorize data and command access. Defaults to the UNIX groups that the user belongs to, i.e. the same as the groups shell command returns.

The numeric user id the user shall have. Used for executing OS commands on behalf of the user, when checking file access permissions, and when creating files. Defaults to the effective user id (euid) in use for running the command. Note that NSO needs to run as root for this to work properly.

The numeric group id of the user shall have. Used for executing OS commands on behalf of the user, when checking file access permissions, and when creating files. Defaults to the effective group id (egid) in use for running the command. Note that NSO needs to run as root for this to work properly.

A comma-separated list of supplementary numeric group ids the user shall have. Used for executing OS commands on behalf of the user and when checking file access permissions. Defaults to the supplementary UNIX group ids in use for running the command. Note that NSO needs to run as root for this to work properly.

Completely disables all AAA checks for this CLI. This can be used as a disaster recovery mechanism if the AAA rules in NSO have somehow become corrupted.

Pass an opaque string to NSO. The string is not interpreted by NSO, only made available to application code. See "built-in variables" in clispec(5) and maapi_get_user_session_opaque() in confd_lib_maapi(3). The string can be given either via this flag, or via the UNIX environment variable NCS_CLI_OPAQUE. The -O flag takes precedence.

Which IP address to connect to.

Which TCP port to connect to.

Which UNIX domain socket to connect to, instead of TCP address and port.

Path to the file containing a secret if IPC access check is enabled.

Set by openssh and used by ncs_cli to determine client IP address etc.

Passed on to terminal aware programs invoked by NSO.

Normal exit

Failed to read user data for initial handshake.

Close timeout, client side closed, session inactive.

Idle timeout triggered.

Tcp level error detected on daemon side.

Internal error occurred in daemon.

User interrupted clistart using special escape char.

User interrupted clistart using special escape char.

Daemon abruptly closed socket.

Stopped on error.

Debug flag. Add more to increase debug level. All debug output will be to stderr.

Don't load the schemas at startup.

The address used to connect to the NSO daemon, overrides the compiled in default.

The port number to connect to the NSO daemon on, overrides the compiled in default.

Specifies the directory for installation of NCS static files, like the --install-dir option to the installer. If this option is omitted, /opt/ncs will be used for InstallDir.

This option is used to also include a full backup (as produced by ncs-backup(1)) of the system. This helps Cisco support to reproduce issues locally.

This option is useful when a resource leak (memory/file descriptors) is suspected. It instructs the ncs-collect-tech-report script to run the command ncs --debug-dump multiple times.

When the NCS installation script is invoked with this option, or is given only the LocalInstallDir argument, NCS will be installed in the LocalInstallDir directory only.

When the NCS installation script is invoked with this option, it will do a system installation that uses several different directories, in accordance with Unix/Linux application installation standards. The first time a system installation is done, the following actions are taken:

This is the directory where static files, primarily the code and libraries for the NCS daemon, are installed. The actual directory used for a given invocation of the installation script is InstallDir/ncs-VSN, allowing for coexistence of multiple installed versions. The currently active version is identified by a symbolic link InstallDir/current pointing to one of the ncs-VSN directories. If the --install-dir option is omitted, /opt/ncs will be used for InstallDir.

This directory is used for config files, e.g. ncs.conf. If the --config-dir option is omitted, /etc/ncs will be used for ConfigDir.

This directory is used for run-time state files, such as the CDB data base and currently used packages. If the --run-dir option is omitted, /var/opt/ncs will be used for RunDir.

This directory is used for the different log files written by NCS. If the --log-dir option is omitted, /var/log/ncs will be used for LogDir.

By default, the system installation will run NCS as the root user. If a different user is given via this option, NCS will instead be run as that user. The user will be created if it does not already exist. This mode is only supported on Linux systems that have the setcap command, since it is needed to give NCS components the required capabilities for some aspects of the NCS functionality.

When the option is used, the following executable files (assuming that the default /opt/ncs is used for --install-dir) will be installed with elevated privileges:

The ncs-setup command is not usable in a "system installation", and is therefore by default excluded from such an installation to avoid confusion. This option instructs the installation script to include ncs-setup in the installation despite this.

If this option is given, the installation script will proceed with potentially disruptive changes (e.g. modifying or removing existing files) without asking for confirmation.

If given this option, the installation script will not install systemd or SysV scripts. This can be useful when running in, for example, a containerized environment where init scripts are typically not used.

If given this option, the installation script will not install systemd scripts. The script installs SysV scripts instead.

Debug flag. Add more to increase debug level. All debug output will be to stderr.

Measure how long the requested command takes and print the result on stderr.

Selects the format of the configuration when loading and saving, can be one of following:

Hide all hidden nodes. By default, no nodes are hidden unless ncs_load has attached to an existing transaction, in which case the hidden nodes are the same as in that transaction's session.

Unhide all hidden nodes. By default, no nodes are hidden unless ncs_load has attached to an existing transaction, in which case the hidden nodes are the same as in that transaction's session.

Loading and saving the configuration is done in a user session, using these options it is possible to specify which user, groups (more than one -g can be used to add groups), and context that should be used when starting the user session. If only a user is supplied the user is assumed to belong to a single group with the same name as the user. This is significant in that AAA rules will be applied for the specified user / groups / context combination. The default is to use the system context, which implies that AAA rules will not be applied at all.

Instead of starting a new user session and transaction, ncs_load will try to attach to the init session. This is only valid when NSO is in start phase 0, and will fail otherwise. It can be used to load a “factory default”file during startup, or loading a file during upgrade.

Filename to save configuration to (option is deprecated, just give the filename on the command line).

Include leaves which are unset (set to their default value) in the output. By default these leaves are not included in the output.

Include the default value of a leaf as a comment (only works for CLI formats, not XML). (Corresponds to the MAAPI_CONFIG_SHOW_DEFAULTS flag).

Only include the configuration below keypath in the output.

Filter the configuration using the XPath expression. (Only works for the XML format.)

Include operational data in the output. (Corresponds to the MAAPI_CONFIG_WITH_OPER flag).

Include only operational data, and ancestors to operational data nodes, in the output. (Corresponds to the MAAPI_CONFIG_OPER_ONLY flag).

Include only data stored in CDB in the output. (Corresponds to the MAAPI_CONFIG_CDB_ONLY flag).

Include NCS service-meta-data attributes in the output. (Corresponds to the MAAPI_CONFIG_WITH_SERVICE_META flag).

The file to load (deprecated, just list the file after the options instead).

Merge in the contents of filename, the (somewhat unfortunate) default is to delete and replace.

Do not run FASTMAP, if FASTMAPPED service data is loaded, we sometimes do not want to run the mapper code. One example is a backup saved in XML format that contains both device data and also service data.

Only load data to CDB inside NCS, do not attempt to perform any update operations towards the managed devices. This corresponds to the 'no-networking' flag to the commit command in the NCS CLI.

Lax loading. Only applies to XML loading. Ignore unknown namespaces, attributes and elements.

Replace the part of the configuration that is present in filename, the default is to delete and replace. (Corresponds to the MAAPI_CONFIG_REPLACE flag).

When loading configuration in 'i' or 'c' format, do a commit operation after each line. Default and recommended is to only commit when all the configuration has been loaded. (Corresponds to the MAAPI_CONFIG_AUTOCOMMIT flag).

When loading configuration do not abort when encountering errors (corresponds to the MAAPI_CONFIG_CONTINUE_ON_ERROR flag).

Delete entire config before loading.

Delete everything below keypath before loading the file.

Accept but ignore contents in the file which is operational data (without this flag it will be an error).

Start a transaction to load only operational data, and ancestors to operational data nodes. Only supported for XML input.

The address used to connect to the NSO daemon, overrides the compiled in default.

The port number to connect to the NSO daemon on, overrides the compiled in default.

If set ncs_load will attach to an existing transaction in an existing user session instead of starting a new session.

These environment variables are set by the NSO CLI when it invokes external commands, which means you can run ncs_load directly from the CLI. For example, the following addition to the <operationalMode> in a clispec file (see clispec(5))

<cmd name="servers" mount="show">
  <info/>
  <help/>
  <callback>
    <exec>
      <osCommand>ncs_load</osCommand>
          <args>-F j -p /system/servers</args>
    </exec>
  </callback>
</cmd>

will add a show servers command which, when run will invoke ncs_load -F j -p /system/servers. This will output the configuration below /system/servers in curly braces format.

Note that when these environment variables are set, it means that the configuration will be loaded into the current CLI transaction (which must be in configure mode, and have AAA permissions to actually modify the config). To load (or save) a file in a separate transaction, unset these two environment variables before invoking the ncs_load command.

Read element value at Path and display result. Multiple values can be read by giving more than one Path as argument to get.

Set the value of Path to Value. Multiple values can be set by giving multiple Path Value pairs as arguments to set.

Display all instances found at path. Multiple Paths can be specified.

Exit with exit code 0 if Path exists (if multiple paths are given all must exist for the exit code to be 0).

Delete element found at Path.

Create the element Path.

Insert the element at Path. This is only possible if the elem has the 'indexed-view' attribute set.

Remove all changes in the transaction.

Send message to a user logged on to the system.

Send prio message to a user logged on to the system.

Send system message to a user logged on to the system.

Read and display CLI session parameter or attribute. Multiple params can be read by giving more than one Param as argument to cliget. Possible params are complete-on-space, idle-timeout, ignore-leading-space, paginate, "output file", "screen length", "screen width", terminal, history, autowizard, "show defaults", and if enabled, display-level. In addition to this the attributes called annotation, tags and inactive can be read.

Set CLI session parameter to Value. Multiple params can be set by giving more than one Param-Value pair as argument to cliset. Possible params are complete-on-space, idle-timeout, ignore-leading-space, paginate, "output file", "screen length", "screen width", terminal, history, autowizard, "show defaults", and if enabled, display-level.

Display the C- and I-style command for a given path. Optionally display the command to delete the path, and optionally emit the parents, ie the commands to reach the submode of the path.

Display the C- and I-style command for going from the running configuration to the current configuration.

Display the difference between the current state in the attached transaction and the running configuration. One line is emitted for each difference. Each such line begins with the type of the change, followed by a colon (':') character and lastly the keypath. The type of the change is one of the following: "created", "deleted", "modified", "value set", "moved after" and "attr set".

Attempts to derive an aaa-style namespace and path from a C-/I-style command path.

Execute cli command in ongoing session, optionally ignoring that a command is hidden, unhiding a specific hide group, or ignoring the fullpath check of the argument to the show command. Multiple hide groups may be unhidden using the --unhide parameter multiple times.

User session to use.

The transaction to use when performing the operations.

Maapi debug information will be printed if this variable is defined.

The address used to connect to the NSO daemon, overrides the compiled in default.

The port number to connect to the NSO daemon on, overrides the compiled in default.

Print a short help text and exit.

By default the generated package will be written to a directory in current directory with the same name as the provided package name. This optional flag writes the package to the --dest provided location.

Once the package is created, build it too.

Do not generate the test directory.

Create a NETCONF NED package, using the device YANG files in DIR.

Generate a skeleton package for a generic NED. This is a good starting point whenever we wish to develop a new generic NED.

Create a SNMP NED package, using the device MIB files in DIR.

Create a NETCONF NED package for LSA, when the device is another NCS (the lower ncs), using the device YANG files in DIR. The NED is compiled with the ned-id tailf-ncs-ned:lsa-netconf.

If the lower NCS is running a different version of NCS than the upper NCS or if the YANG files in DIR contains references to configuration data in the ncs namespace, use the option --lsa-lower-nso.

Generate a skeleton package for a simple RFS service, either implemented by Java code, Python code, based on a template, or a combination of them.

Generate a skeleton package for a simple data provider.

Generate a skeleton for an Erlang package.

By default ncs-make-package will create packages which will fail when encountering warnings in YANG or MIB files. This is desired and warnings should be corrected. This option is for legacy reasons, before the generated packages where not that strict.

Generate a nano skeleton package for a simple service with nano plan, either implemented by Java code with template or Python code with template, or on a template. The options java and java-and-template, python and python-and-template result in the same skeleton creation.

Augment the generated service model under PATH, e.g. /ncs:services.

Put the generated service model in a container named NAME.

NAME is the Java package name for the Java classes generated from all device YANG modules. These classes can be used by Java code implementing for example services.

Do not generate a netsim directory. This means the package cannot be used by ncs-netsim.

Do not generate any Java classes from the device YANG modules.

Do not generate any Python classes from the device YANG modules.

Do not generate any device templates from the device YANG modules.

The vendor element in the package file.

The package-version element in the package file.

Sanitize the device's YANG files. This will invoke pyang --sanitize on the device YANG files.

Control which datastore netsim should use when simulating the device. The candidate option here is default and it includes the setting writable-through-candidate

If the yang code in a package depends on the yang code in another NCS package we need to use this flag. An example would be if a device model augments YANG code which is contained in another NCS package. The arg, the package we depend on, shall be relative the src directory to where the package is built.

Specifies the package name for the lower NCS, the package is in $NCS_DIR/packages/lsa, or a path to the package directory containing the cisco-nso-nc package for the lower node.

The NED will be compiled with the ned-id of the package, cisco-nso-nc-X.Y:cisco-nso-nc-X.Y.

This optional parameter specifies the python-class-name of the generated package-meta-data.xml file. It must be in format module.Class. Default value is main.Main.

This optional parameter will produce an example of an Action.

This optional parameter will produce an example of a CDB subscriber.

Add a skeleton for an Erlang application. Invoke the script multiple times to add multiple applications.

Create a new NCS project.

Export an NCS project.

For each git package repository, execute an arbitrary git command.

Populate a new NCS project or update an existing project. NOTE: Was called 'setup' earlier.

Display the man-page for the specified NCS project command.

Print a short help text and exit.

Specify the project (directory) location. The directory will be created if not existing. If not specified, the project-name will be used.

Specify the exact URL pointing to an NCS install binary. Can be a http:// or file:/// URL.

Specify the exact path pointing to a bundled NCS Project. The bundle should have been created using the ncs-project export command.

Print a short help text and exit.

Print debugging information when creating the bundle.

Add a prefix to the bundle file name. Cannot be used together with the name option.

Use a specific prefix for the compressed packages used in the bundle instead of the default "ncs-$lt;vsn>" where the <vsn> is the NCS version that ncs-project is shipped with.

Skip any configured name and use name as the bundle file name.

When the packages have been retrieved from their different locations, this option will skip trying to build the packages. No (re-)build will occur of the packages. This can be used to export a bundle for a different NCS version.

This option will not try to use the package versions defined in the "bundle" part of the project-meta-data, but instead use whatever versions are installed in the "packages" directory. This can be used to export modified packages. Use with care.

Add a timestamp to the bundle file name.

Any git command, including options.

Print a short help text and exit.

Print information messages about what is being done.

Answer yes on every questions. Will cause overwriting to any earlier setup.mk files.

Update using the packages defined in the bundle section.

ncs-setup generates files and directories, all files are written into the --dest directory. The directory is created if non existent.

If you have an existing ncs-netsim simulation environment, that environment consists of a set of devices. These devices may be NETCONF, CLI or SNMP devices and the ncs-netsim tool can be used to create, control and manipulate that simulation network.

A common developer use case with ncs-setup is that we wish to use NCS to control a simulated network. The option --netsim-dir sets up NCS to manage all the devices in that simulated network. All hosts in the simulated network are assumed to run on the same host as ncs. ncs-setup will generate an XML initialization file for all devices in the simulated network.

Generic devices used in a simulated netsim network will normally be run as netconf devices. Use this option if the generic devices should be forced to be run as generic devices.

When you want to create an execution environment where NCS is used to control real, actual managed devices we can use the --package option. The option can be given more than once to add more packages at the same time.

The main purpose of this option is to creates symbolic links in ./packages to the NED (or other) package(s) indicated to the command. This makes sure that NCS finds the packages when it starts.

For all NED packages that ship together with NCS, i.e packages that are found under $NCS_DIR/packages/neds we can just provide the name of the NED. We can also give the path to a NED package.

To setup NCS to manage Juniper and Cisco routers we execute:

   $ ncs-setup --package juniper --package ios

If we have developed our own NED package to control our own ACME router, we can do:

   $ ncs-setup --package /path/to/acme-package

This option generates fresh ssh keys. By default the keys in ${NCS_DIR}/etc/ncs/ssh are used. This is useful so that the ssh keys don't change when a new NCS release is installed. Each NCS release comes with newly generated SSH keys.

By default, ncs-setup will create relative symbolic links in the ./packages directory. This option copies the packages instead.

By default, ncs-setup searches upward in the directory hierarchy for a netsim directory. The chosen netsim directory will be used to populate the initial CDB data for the managed devices. This option disables this behavior.

When developing the Java code for an NCS application, this command can be used to setup eclipse .project and .classpath appropriately. The .classpath will also contain that source path to all of the NCS Java libraries.

This option resets all data in NCS to "factory defaults" assuming that the layout of the NCS execution environment is created by ncs-setup. All CDB database files and all log files are removed. The daemon is also stopped

Removes the installation of static files for NCS version Version. I.e. the directory tree rooted at InstallDir/ncs-Version will be removed. The Version argument may also be given as the filename or pathname of the installation directory, or, unless --non-interactive is given, omitted completely in which case the command will offer selection from the installed versions.

Completely removes the NCS installation. I.e. the whole directory tree rooted at InstallDir, as well as the directories for config files (option --config-dir to the installer), run-time state files (option --run-dir to the installer), and log files (option --log-dir to the installer), and also the init script and user profile scripts.

Specifies the directory for installation of NCS static files, like the --install-dir option to the installer. If this option is omitted, /opt/ncs will be used for InstallDir.

If this option is used, removal will proceed without asking for confirmation.