5.20.2 Configuration Server Startup Parameters

When the Web NMS is started, the startup parameters specified in the NmsProcessesBE.conf present in <Web NMS Home>/conf directory is read and the processes are started. Each of the process consists of two parts,

• PROCESS - the fully qualified class name of the process.

• ARGS - the arguments needed for starting the process.

This document concentrates on explaining the purpose of the various processes defined in the conf file along with the description of the command line arguments supplied for starting the process.

Process

• BE Startup Options
  com.adventnet.nms.config.NmsConfigurationServer

• FE Startup Options
  com.adventnet.nms.fe.config.ConfigFE

BE Startup Options

PROCESS: com.adventnet.nms.config.NmsConfigurationServer

ARGS:

[CONFIG_SERVER_PORT num]

[CONFIG_UPDATER_MODEL updaterModelClassName]

[CONFIG_AUDIT_MODE RDBMS/Serialize]

[CONFIG_XML_DIR XML_DIR]

[USER_REQUEST_HANDLER className]

[CONFIG_AUTH_MODEL authModelClassname]

[TASK_MANIPULATION_INTERFACE taskManipulationModelName]

[INVENTORY_HANDLER inventoryHandler]

[BIND_IN_REG true/false]

[RMI_REG_PORT num]

[AUDIT_LEVEL number]

[DEBUG true/false]

[DEBUG_LEVEL number]

[AUTHORIZATION_INTERFACE authorizationClassName]

[CLEAN_AUDIT_INTERVAL num_days]

[CONFIG_PERSISTENCE_MODE RDBMS/Serialize]

[CREATE_DEFAULT_TASK true/false]

This process is used to start the Configuration Management service. This service enables you to configure the devices in the network; thus enabling the improvement of performance of the network.

Arguments and Description

Arguments	Description
CONFIG_SERVER_PORT	This parameter is used to specify the port number in which the ConfigServer has to be started. If the port number is not specified, then the ConfigServer will be started in any of the free ports available. The port at which the ConfigServer gets started is logged into the file CSPORT.html present in <Web NMS Home>/html directory.
CONFIG_UPDATER_MODEL	This parameter is used to specify the implementation class that needs to be executed, whenever a device gets configured. When you have a MO inventory containing the details about the devices, and when you want to synchronize this inventory based on the newly configured values, then an implementation class can be written by implementing ConfigUpdater interface and the fully qualified class name can be specified as the value for this parameter. Default implementation has been provided, that will synchronize the topology database with the latest configuration details.   Default Value: com.adventnet.nms.config.MOConfigUpdater
CONFIG_AUDIT_MODE	This parameter is used to specify the mode of storage of the audit information.  This parameter can take values namely "RDBMS" or "Serialize".  When "RDBMS" is specified, the audit data are stored in the database.  If "Serialize" is specified, the audit data are stored in files, that are specified in the log4j.xml file present in <Web NMS Home>/conf directory.    Default Value:  RDBMS
CONFIG_XML_DIR	This parameter is used to specify the directory (with respect to CONFIG_ROOT_DIR), in which any device or task specific information can be stored, apart from storing it in the database. The application specific details can be stored in this directory by using the method saveConfigurationProfiles() present in ConfigClientAPI.    Default Value: "configxml" directory.
USER_REQUEST_HANDLER	The implementor class which is used to define and handle the user defined request across the client and the server is specified as the value for this parameter.
CONFIG_AUTH_MODEL	If you want to authenticate the users configuring the system, then a class can be written with authentication logic, that implements AuthenticationModel interface which can be supplied as the value for this parameter.
TASK_MANIPULATION_INTERFACE	Before the task is submitted for configuration, you are given the facility of manipulating and changing the attributes of the task, before it gets applied to the devices. A class can be written by implementing the TaskManipulation interface, and the same can be given as an input to this parameter.  By doing so, this class gets executed each time, the task is submitted for execution.
INVENTORY_HANDLER	This parameter is used to specify the ConfigServer, as from where the inventory input has to be got, when the configured task is of template type. A class can be written implementing InventoryHandler interface, in which you can specify the nature of inventory inputs to the configuration templates.   Default Value: com.adventnet.nms.config.NmsInventoryHandler
BIND_IN_REG	This parameter takes either "true" or "false" as its input.  Based on this value, the ConfigurationAPI will be bound with the registry.   Default Value:  "true"
RMI_REG_PORT	This parameter takes the port number where the RMI registry is running.   Default Value: "1099"
AUDIT_LEVEL	This parameter is used to specify the levels of audit that has to be logged.  This can take values from 0 to 2.  When "1" is specified, the Task and Device level audit information will be logged. When a value "2" is given, then Task, Attribute and Device level auditing will be done.  If "0" is given, auditing will be suppressed.  Please note that the client relies on this parameter to show the audit details in the client. When auditing is suppressed, then the client will not be able to show the audit information.   Default Value:  "2"
DEBUG	This takes either "true" or "false" as its input.  This parameter is used to switch ON or OFF, the debugging mode.     Default Value:  "false"
DEBUG_LEVEL	This value specifies the debugging level needed, which will be helpful while developing an application.  If the value "1" is given, only the ConfigServer related debug will be switched ON.  If the value "2" is given, both ConfigServer and Management Server related debugging are switched ON.  This parameter is not used by default, since the DEBUG is set as "false".
AUTHORIZATION_INTERFACE	An implementation for verifying the user, configuring the system can be written and the class can be given as input to this parameter.  Based on the implementation given, the authorization check for the user configuring the system is made.   Default Value: com.adventnet.management.config.AuthorizationInterfaceImpl`
CLEAN_AUDIT_INTERVAL	This takes an integer value which represents the number of days up to which the auditing information has to be stored. The audit details whose age is more than the specified number of days will be deleted from the database.  If a value that is less than or equal to "zero" is given, then the audit cleaning will not be done.     Default Value:  "1", which means that the audit information more than one day will get deleted.
CONFIG_PERSISTENCE_MODE	This specifies the mode in which the ConfigTasks, device lists and data source are stored. It can take two values namely "RDBMS" and "Serialize". If "RDBMS" is given, the configuration task is stored in the database and if "Serialize" is given, the task is stored in files.   Default Value:  "RDBMS"
CREATE_DEFAULT_TASK	Determines whether the default HelloWorld task should be created for the newly added users. If false is specified, Web NMS will not create the HelloWorld task for each newly added user. Note that this argument holds good from Web NMS 4.7 SP1 onwards only and will not be present in NmsProcessesBE.conf, by default.   Default Value: true meaning the default task will be created for each new user

Dependencies

This process depends on the Topology module. 

• The parameter RMI_REG_PORT should be used along with the BIND_IN_REG parameter.

• The parameter DEBUG_LEVEL should be used along with the DEBUG parameter.  

FE Startup Options

PROCESS: com.adventnet.nms.fe.config.ConfigFE

ARGS: NONE

Functionality

This process is used to bind the RMI proxy APIs to overcome the security restrictions and scalability, so that the client can make use of it for task creation and execution. It handles the audit related tasks done by the client, like handling the custom views. This process neither has arguments with nor has dependency on other processes. Please note that if this process doesn't get started along with other FE processes, the clients would not be in a position to connect the FE.

Dependencies

None

Mandatory Process Dependencies for Configuration Module

The mandatory processes dependent on the Configuration module is given in the Module Services section.  These services have to be enabled, for the Configuration process to start.