The ENA Configuration Management module adds configuration management and monitor functions to ENA. Configuration Management allows you to configure devices and ports on your network by running scripts on those target devices, if the appropriate CLI credential sets have been established. Configuration Management requires a valid license and is activated through configure.
It uses a combination of the ENA information database, an Expect API and Groovy scripts to enable you to specify configuration tasks.
Configuration management functionality:
Configuration Management allows you to:
- retrieve and archive device configuration files.
- alert to changes in device configuration files.
- alert to changes to firmware versions and the automatic retrieval of device configuration.
- warn of unsaved changes in device configuration files.
- enable detailed comparison of device configuration files.
- identify trivial changes in device configuration files to be excluded when identifying differences between files.
- check device configuration files for best practice.
- access devices using Telnet and SSH.
- transport device configurations using FTP, TFTP, SCP and RCP protocols.
- integrate with ENA's permissions system.
- track configuration performance through the ENA UI.
- integrate with ENA reports.
- view archived configuration files.
- manage device configuration from the command line and through the ENA RESTful API.
- To use Configuration Management, you must either be an Administrator or have the Configuration Management Administration tool permission.
- Configuration Management access can set up configuration management tasks and steps.
- Configuration Monitor access can view and set all parameters, including:
- list of devices to monitor.
- frequency of monitoring.
- number of files to archive.
- matching patterns and policy patterns.
- Retrieved configuration details are associated with their device, so access permissions are granted based on that View membership.
- Current and archived files are saved to the Entuity server. Access to folders outside of ENA are controlled by the operating system permissions.
Remote and transport protocols:
ENA can use Telnet and Secure Shell (SSHv1 and SSHv2) to access devices for monitoring their configuration. All required executables are included in the package and preinstalled in the appropriate location. No additional installation steps are required to use either Telnet or SSH.
ENA can use FTP, TFTP, SCP and RCP servers for the retrieval of configuration files. For configuration retireval to work, the specified transfer server type must be running on the Entuity server.
Device configuration retrieval:
Configuration Management can attempt to retrieve device configuration for a device:
- managed by ENA, regardless of its management level (e.g. Full, Ping Only, Basic etc.).
- that has a retrieval script file associated with either its device sysOid or vendor sysOid. Full configuration management functionality is only available if there are also mapped exclusion and policy files.
Command line and RESTful API automated configuration retrieval:
You can use the ENA UI or RESTful API to apply configuration management settings to one or more specified devices. You can also use RESTful API to automate the management of device configuration retrieval.
Configuration administration and configuration tasks:
Configuration administration is managed through the Configuration Management page. This is accessible by clicking Main Menu > Administration > Configuration Management.
ENA uses a combination of the ENA information database, an Expect API and Groovy scripts to allow you to specify configuration tasks. A configuration task contains all the instructions required to complete ht e designated configuration management or monitor task. Tasks can be initiated from a context menu or through the scheduler. A task usually has a specific objective, which is often the configuration of a device or port. It involves a number of steps, e.g.:
- log in to a device.
- perform an action.
- log out of a device.
The login and logout steps are generic and could be reused by many tasks.
When you run a task, it becomes a job. If this job is running against a number of objects (devices or ports), then each object has its own sub-job. Therefore, the success or failure of a subjob on one object does not impact the processing of another subjob.
The configuration management task process is as follows:
- Task is run.
- The Entuity server identifies and validates the target objects. Where the target objects are managed by remote Entuity servers, this involves checking with those servers and potentially amending the list of targets against which the job runs. The validation tests that are applied before dispatching the job are as follows:
- check the task is still available.
- check the current version of the task is the same as that associated with the job, e.g. one user may call a task while another is updating it. This check is only applicable to tasks called from context menus.
- validate the Groovy script.
- check the user permissions of job owner are sufficient to run the job.
- apply the filter to derive the target objects.
- The Entuity server creates a dispatch job to send to the Script Engine of the Entuity server that is managing the target objects. The dispatch job contains 1 subjob for each target. When these targets are managed by different servers, Entuity creates a dispatch job for each server. Note, because jobs may be defined on a central server but run on a remote server, it is important that central and remote servers are running the same version of ENA.
- The Script Engine runs the subjobs, performing the specified task on the target device or port. Through the Job History page, you can view the progress of a job, and you can drill down to a subjob to view its progress. When tasks are configured for events, then ENA can raise events and incidents that report the success or failure of the job.