Navigation in Config CLI

Starting a Session in Config CLI

Start the config shell by typing config at a bash prompt. The bash prompt is presented to root and admin users when they log in via SSH or on the management or local console.

Exiting a Config CLI Session

You can exit the Interactive CLI by in any of the following ways:

Type exit to end the session.
Send an EOF (Control+D).
Send an INT (Control+C).

Note:The session is prevented from exiting if there are un-committed changes, this condition is indicated by a message. However, you can force an exit by immediately executing an exit command again, any un-committed changes will be discarded.

Navigating the Config CLI

The Config CLI operates using a hierarchy . Due to the variety of endpoints, there are several ways to get to a place where you may want to make changes.

Starting at the root, enter endpoint names to descend down to lower endpoints.
Similarly, type 'up' to ascend towards the root or type 'top' to reset to the root context.

Note:Every endpoint name is an operation that descends into that endpoint.

When using the config CLI, it is possible to navigate ‘downwards’ through multiple contexts with a single command line.

Hierarchical Identifiers

This section outlines the identifiers needed to navigate the CLI.

Identifier	Description
Singleton endpoints	These require only the endpoint name to be uniquely identified.
List/item endpoints	The first level is the endpoint name, the second level is the item identifier (the identifier is the same identifier used by ogcli).
Multiple identifiers	A single endpoint (ssh/authorized_keys) requires an extra identifier. In this case, the hierarchy is: ssh/authorized_keys > userid > [key_id]
Nested fields	The interactive CLI treats nested fields as additional hierarchy levels. This applies both to arrays and maps. For arrays of complex values, each value shall also be a hierarchy level.

Understanding Fields, Entities and Contexts

The Config CLI allows you to configure the device settings through a number of required fields, which provide the settings for the device.

These fields are grouped in entities that describe a small set of functionality, for example, there is a ‘user’ entity which is used to access user settings. Entities can contain sub-entities as well as simple fields.

How Context Operates in the Config CLI

Description

The context is the current entity that is the focus of the config shell. When the shell is first started, the context is a special parent context from which sub-entities can be seen. Within the config shell, a number of commands are available, depending on the current context.

When config shell is started the context is at the “top context” which lists all the entities when the show command is used. If the name of an entity is typed, then the context moves 'down' into that entity. When simple commands such as show, help or apply are used, they will act on the current context. The context can be moved down further by typing the name of an item.

Entities can contain sub-entities as well as simple fields. For example, there is a ‘user’ entity which is used to access user settings. Fields are grouped within entities that describe a small set of functionality.

Navigating Using Context

You select a context by typing the name of the target entity and pressing Enter/Return; the new context is shown in the prompt between brackets. In the following example, the ‘user’ context is accessed and then the ‘john’ sub-entity is accessed causing the context to become ‘user john’.

The ‘show’ command is used to list the entities and fields that descend from the current context.

config: user
config(user): show
Item names for entity user
  john matt myuser netgrp root
config(user): john
config(user john):
Entity user item john
  description
  enabled         true
  no_password                 false
  password
  ssh_password_enabled true
  groups (array)
config(user john):

The following example will navigate the context to the root user object without first having to navigate to the user context:

config: user root

config(user root):

Sub-objects are supported. In the following example, power_supply_voltage_alert and syslog are nested sub-objects of the onitoring/alerts/power entity:

config: monitoring/alerts/power power_supply_voltage_alert syslog
config(monitoring/alerts/power power_supply_voltage_alert syslog):