4.4. Activating Changes

Home Prev	InCenter 2.2.5 On-Premises Administration Guide	Next

Changes made through the CLI are stored in the InCenter database but not deployed to nodes until an activate command is issued. This must then be followed by a commit command to make these changes permanent:

admin@InCenter:/> activate
Operation in progress... / 
Activate successful
Nodes activated: my-node1
Run the "commit" command to keep the new configuration
admin@InCenter:/> commit
Committed
admin@InCenter:/>

This command sequence is exactly the same as the sequence used when changing a node configuration directly. It makes sure that the change will not break communication with the server by requiring that a second command is entered within a certain period of time to commit the changes. The period of time is known as the RevertTimeout and is set by default to 30 seconds. The following is an example of changing this timeout to a value of 60 seconds:

admin@InCenter:/> cc Settings 
admin@InCenter:/Settings> set Activation RevertTimeout=60

User Database Changes are an Exception

It should be noted that changes made to the InCenter user database are an exception. Such changes are applied directly and do not require an activation sequence to be entered. This also means that such changes are not part of the InCenter configuration history and cannot be undone using the history.

Commenting a Change

When changes are deployed, it can be useful to add a brief comment which is saved in the history and is available for display later. This is done by using the -comment option to the commit command. The comment itself need to be surrounded by single or double quotes if it contains spaces. For example:

admin@InCenter:/> commit -comment="This is my comment"

Activated Changes are All-or-Nothing By Default

One or many changes might be pending before the activate command is entered to deploy them. By default, InCenter will try to activate all changes to all nodes in a single operation. The activations are done on an all-or-nothing basis. If any single activation fails for any reason on any node, the entire deployment is aborted.

With this default behavior, the commit command can be entered to make the changes permanent only after activation has been successful on all nodes.

However, the option also exists to perform a selective activate when pending changes are to be deployed only to certain nodes. This is discussed in Section 4.5, Selective Activate.

The Changes Activated Depend on the CLI Context

When the CLI context is the top level default context, an activate operation will apply all pending changes. However, if the CLI context is changed to be a particular standalone node will be applied when an activate command is entered. The same applies if the CLI context is an HA pair.

Ignoring Unreachable Nodes

The default all-or-nothing behavior described above, ensures that the configuration copy kept by InCenter is always synchronized with the copy on the node itself. However, it is possible to change this deployment behavior when there are unreachable nodes by setting the global activation option AcceptUnreachable to a value of Yes:

admin@InCenter:/> set Activation AcceptUnreachable=Yes

When this is done, unreachable nodes will not cause activation to be aborted for all nodes, only a validation failure will do this.

When allowing activation with unreachable nodes, it should be noted that InCenter will automatically push its current configuration copy onto the node when it becomes reachable again.

Configuration Changes Cannot Be Made Between activate and commit

After entering the activate command, InCenter will not allow a configuration change for any node until either of the following occurs:

A commit command is entered.
Or the commit command is not entered in time and a bi-directional time-out condition occurs. In this case, all the affected configurations reverted to their original state before the activate command was issued.

In addition, none of the pending changes are lost. The sequence of the activate command followed by the commit command could therefore be entered again to try and deploy the same changes.

Deployment Errors/Warnings and the cfglog Command

As stated above, changes are all or nothing during deployment. Any errors or warnings will usually occur following the activate command and such messages will be displayed in the CLI console.

To investigate the cause of a deployment error further, configuration log messages can be examined using the cfglog command. The following is an example of cfglog output after trying to commit an erroneous change:

admin@InCenter:/> cfglog
Last Activation Output:
Session validation failed
Errors:
  my-node1:
    - IPAddress my_addr_obj1.Address: Value is not a valid reference
  my-node2:
    - IPAddress my_addr_obj2.Address: Value is not a valid reference

The output of the above command will provide only the first few errors/warnings. The complete list can be seen by adding the -verbose option.

The above output can be restricted to a single node after the cfglog command or changing the CLI context to be the node and using the cfglog command with no options. The following is an example of the first method:

admin@InCenter:/> cfglog my-node1
Last Activation Output:
Session validation failed
Errors:
  my-node1:
    - IPAddress my_addr_obj1.Address: Value is not a valid reference

When troubleshooting, it is also possible to drill down further by looking at the configuration messages generated by a particular node itself. This is done by using the -fromNode option with the cfglog command. In the following example, the activation log messages taken directly from the node named my-node1 are listed:

admin@InCenter:/> cfglog my-node1 -fromNode
Configuration log for my-node1:
Notices:
  Config notice  vsinit:3155  2018-11-24 15:46:51
  - Beginning system reconfigure. Activating new configuration.
  Config notice  vsinit:3663  2018-11-24 15:46:51
  - Reconfigure completed successfully.
  Config notice  vsinit:1337  2018-11-24 15:46:52
  - Configuration changes committed.

Fixing Configuration Mismatches with the export Option

If the configuration on a node becomes out of synchronization with InCenter's copy , it is possible to manually force the node by using the export option of the node command. For example:

admin@InCenter:/> node my-node1 export

This option does not require an activate and commit sequence to complete.

Note that an export operation can fail for one of the following reasons:

If the software version on the firewall is not supported by InCenter. The solution is to upgrade the firewall software version to one that is supported.
The firewall has a higher software version than the configuration copy in InCenter. The solution for this is to make a small change in the firewall's configuration and then deploy that change. This will cause the version of the firewall's software in the InCenter database to be updated to the correct version.
The firewall has a lower software version than the configuration copy in firewall version was downgraded. The solution for this is to upgrade the firewall version so it matches the version in InCenter.

The relationship between the version of InCenter and the version of software running on a managed node is explained further in Chapter 11, Version Management.

A way of just pushing the current InCenter copy of the configuration to the firewall is to make configuration changes in InCenter and to then activate the changes. As long the new configuration is valid then it will overwrite the configuration on the node. However, this will not ensure that both sides have the same software version.

To determine if there is a configuration mismatch, the status option of the node command can be used. For example:

admin@InCenter:/> node my-node1 status

Switching Off Deployment for a Node

It is possible to switch off the deployment of configuration changes for a particular node using the IncludeInDeploy property. This means that even though changes are activated, only the InCenter copy of the configuration is updated. This is explained further in Section 10.4, Node/Firewall Synchronization.

	Note: Activating Changes for Large Node Numbers
	Caution is recommended when activating changes for large numbers of nodes at the same time. If the number of nodes with pending changes exceeds 2,0000, activation should only be performed with remote node validation enabled. This feature is explained next.

Node Validation

By default, when configuration changes are activated, the validation processing required is performed locally by InCenter before the configuration is sent to nodes. However, deployment times when activating changes on large numbers of nodes can be improved by having configuration validation performed remotely on the node itself. This feature can be enabled globally for all deployments with the following command:

admin@InCenter:/> set Activation Validation=Node

To turn off all node validation and return to the original default, the command would be the following:

admin@InCenter:/> set Activation Validation=Local

As described earlier in this section, it is possible to change the default all-or-nothing activation behavior so that unreachable nodes are ignored. Both global behavior options can be combined:

admin@InCenter:/> set Activation Validation=Node
			AcceptUnreachable=Yes