To edit a node configuration in the CLI, the CLI context must be changed to be that of the target node by using the cc command. For example, to change the CLI context to be the node called my-node1, the following command would be entered:

admin@InCenter:/> cc StandaloneNode my-node1 
admin@InCenter:/my-node1>

The CLI prompt changes to indicate the context has become my-node1 and a valid InCenter command can now be entered to change the configuration of my-node1.

Assume that a new IPv4 address book object called my-address1 is to be added to the node's configuration. The following InCenter CLI command would be used to do this:

admin@InCenter:/my-node1> add IPAddress
			Name=my-address1
			Address=192.0.2.1
Added IPAddress my-address1
admin@InCenter:/my-node1>

New and Old Values Are Visible Before Activating

When using the show command, the old and new values for most objects will be displayed before the changes are activated. For example, suppose that the IP address of the object my-address1 is changed with the following command:

admin@InCenter:/my-node1> set IPAddress my-address1
			Address=203.0.113.3

A show command before activating the change will now display the old and new values:

admin@InCenter:/my-node1> show IPAddress my-address1
Property                     Value           Original
---------------------------  --------------  -----------
                      Name:  my-address1
             ActiveAddress:  0.0.0.0
                   Address:  192.0.2.1       203.0.113.3
      NoDefinedCredentials:  No
            UserAuthGroups:  <empty>
                  Comments:  <empty>

Once this change is activated, the original value is lost and only the Value column would be displayed.

Configuration Changes are Stored Temporarily Until Activated

After making changes, there is a choice as to when an activate with its associated commit command is issued. Further changes on other nodes can be performed before deployment. All undeployed changes will be kept in non-volatile memory and will be retained across any type of system restart. Only the reject command will delete all pending changes.

If an activate/commit command sequence is entered at the top level CLI context, all undeployed changes for all nodes will be saved in the InCenter database and deployed. However, selective activation is also possible. If the active command sequence is entered in the CLI context for a particular node then only the changes pending for that node will be deployed. This is explained further in Section 4.5, Selective Activate.

If the activate and commit operations are performed in the current node context, the command sequence would look like the following:

admin@InCenter:/my-node1> activate
Activate successful
admin@InCenter:/my-node1> commit
Committed

The address object my-address1 has now been added to both the firewall configuration of node my-node1 as well as the copy of that configuration held by the InCenter database.

Returning to the Default CLI Context

To return to the original, default CLI context, the command is cc on its own.

admin@InCenter:/my-node1> cc 
admin@InCenter:/>

Knowing What Has Been Modified and Discarding Changes with Reject

The following command will show a summary of undeployed configuration changes:

admin@InCenter:/> show -changes

To discard all undeployed changes, use the following command in the default CLI context:

admin@InCenter:/> reject

When the reject command is used in the CLI context for a StandaloneNode, HAPair or HAMemberNode, all pending changes for that context are discarded. For example, to reject all pending changes for the StandaloneNode called my-node1 the command would be the following:

admin@InCenter:/> cc StandaloneNode my-node1 
admin@InCenter:/my-node1> reject

When performing a reject operation on an HAPair, the changes are rejected for both the contained HAMemberNode objects.

Note that if the CLI context is an HAMember then the reject command will discard any changes made to its parent HAPair object as well as the other HAMember object in the pair.

Using Reject Command Options

As stated above, the reject command on its own will reject all pending changes for the context in which it is used. However, it is possible to use the -all option to reject all pending changes for the entire system, regardless of the CLI context in which the command is used:

admin@InCenter:/> cc StandaloneNode my-node1 
admin@InCenter:/my-node1> reject -all

The reject operation can also be applied to a specific configuration object. For example, if all the changes made to the IPAddress object called my-ip1 on node my-node1 are to be rejected then the command would be the following:

admin@InCenter:/> cc StandaloneNode my-node1 
admin@InCenter:/my-node1> reject IPAddress my-ip1

If the reject operation is applied to an object with child objects, by default, the child objects will be unaffected. To change this default behavior so that changes to all child objects (and any children below them) are rejected, the -recursive option must be used.

Note that the reject command cannot have the object types StandaloneNode or HAPair or NodeGroup as an argument.

A Summary of CLI Configuration Editing

The following is a summary of points that should be noted when editing configurations through the CLI:

To edit the configuration of a node, the node must be first selected in the main WebUI node list and the Configure button pressed.

Depending on the type of node, the way the configuration is edited is different:

Adding a Configuration Object

As an example of configuration editing, the following steps will add a new IP address to a node configuration: