cc/td/doc/product/rtrmgmt/ip_mgr
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Advanced Usage

Advanced Usage

Overview of Component Servers

The Cisco IP Manager software consists of several executable server files that can be run concurrently or individually, depending on what features you need. These servers can be installed on multiple hosts in any combination, or all on one host. The Cisco IP Manager software is not dependent on any one server being located on a particular host. However, Oracle Net8 8.0.5.0.0 must be installed whenever any server is installed on a host that does not contain the Oracle database.

While it is possible to start the servers from the command line, it is strongly recommended that you always use the ipmgr.putit and ipmgr.launch scripts described in the chapter "Installation and Configuration." These scripts source the files allcommon.env, allserver.env, gui.env, and orbix.env, all found in the envs directory under your CIPM installation directory, to set up certain environment variables that the servers need, and they define a common set of server launch flag settings. You can change these flags by editing the environment files.

To use these scripts, you must also run the utility ipmgr.configure, as described in the "Installation and Configuration" chapter.

The startup scripts allow you to launch all of the servers at once (if they are all installed on a single host), or individual servers one at a time.

If you start the servers individually, NS and ES must be launched first, then LOGServer, then the others in any order.


Note 
If ES (the Event Server) stops for any reason, you must shut down, unregister, and restart all of the servers that you use. The ipmgr.rmit utility unregisters the servers from the Orbix implementation repository.

Though it is not recommended that you do so for normal use, it is possible to start most of the servers from the command line. If you launch a server without any arguments, even if the server is already running, a usage-text message defines the various launch flags for that server (except ES and NS, which fail and write core files if the Orbix daemon is not running).

If you launch a server (except NS and ES) with the -V flag, the version number of that server is output to stdout.

Server Locations

When you install any of the server packages as described in the chapter "Installation and Configuration," server executables are installed in the following subdirectory structure beneath the installation directory:
Table A-1: Server Locations
Server Location
ADMServer
install_dir/adm/bin/adm_server
CTMServer
install_dir/ctm/bin/ctm_server
ES
install_dir/OrbixES/1.1/bin/es
gui
install_dir/envs/gui.env
LOGServer
install_dir/log/bin/log_server
NEMServer
install_dir/nem/bin/nem_server
NS
install_dir/OrbixName/1.1/bin/ns
SGServer
install_dir/sgs/bin/sg_server
TGServer
install_dir/tgs/bin/tg_server
VCMServer
install_dir/vcm/bin/vcm_server

The OrbixMT subdirectory contains the Orbix (CORBA) operating files.

The java subdirectory contains the operating files needed to create the user interface.

The Orbix files are included in both GUI and server installations to accommodate installation of remote GUI workstations, independent of server installations. However, if GUI and server packages are installed on the same machine and you are not using the Cisco-provided launch scripts, only one set of Orbix files is needed. You can delete the other set.

However, if you do so, be aware of the following:

Orbix

The Orbix daemon must be launched before you can register any of the Cisco IP Manager servers.

If you use any of the launch scripts described in the chapter "Installation and Configuration," the Orbix daemon is started for you. If you do not use these scripts, you must start the daemon yourself, as follows:

orbixd -c $IPMGR_ORBIX_HOME/orbixd.log &
 

The -c parameter creates an Orbix checkpoint file named orbixd.log in the directory named by the IPMGR_ORBIX_HOME environment variable, which was set when you sourced ipmgr.csh. This checkpoint file allows a new daemon to recover data about the Cisco IP Manager servers in the event of an unexpected termination of the Orbix daemon.

The Orbix daemon is located in the OrbixMT/2.3c03-01/bin subdirectory.

Remote Login

To run the GUI remotely (using the rlogin command), you must first invoke the UNIX command xhost + remote_machine on the machine where you are working, and once you have logged in to the remote machine, the environment variable DISPLAY must be set to your local machine's host name, as shown in the following:

xhost +remote_machine
rlogin remote_machine
setenv DISPLAY your_machine_name:0
 

However, the machine on which the process is actually run must have sufficient resources to handle all of the concurrent sessions without terminating and writing a core file.

Server Launch Options

Servers can be launched in a variety of configurations, by setting their launch flags as described in the following sections. (If you launch a server executable (other than ES and NS) with the -V flag---whether the server is running or not---a message is sent to stdout identifying the version of that server. If you specify the -V flag when the server is not already running, the message is generated, but the server is not launched.)

ADMServer

The ADMServer (Administration Server) provides authorization services (by managing Cisco IP Manager permissions groups) and authentication services (by verifying users' permissions when operations are attempted); controls access to the system and its data for the other servers; manages domains; and manages user information. Every Cisco IP Manager operation can be validated against the permission that defines what a user can do on a particular resource. The server handles creation, deletion, and modification of permissions and user groups; addition and deletion of user group membership; and validation of domain and system-based resources.

Permissions are checked for those operations requiring user permission by CTMServer, LOGServer, and NEMServer only if those servers are launched with the -A flag (the default condition in the ipmgr.launch script).

ADMServer Syntax

adm_server flags 
flag options and defaults

-u database _user_name

-p database_password

[-n database _name]

Defaults to empty.

[-s database _server_name]

Defaults to empty. With an Oracle database, both -n and -s flags are equivalent to $ORACLE_SID.

[-L log_output]

One of server, stdout, console, filename; if server, then output is sent to the LOGServer for storage in the database. Default is none.

[-q thread_pool_size]

Defaults to 20.

[-i database_minimum_connections]

Defaults to 1.

[-x database_maximum_connections]

Defaults to 5. 

[-A]

Enable access control. Defaults to no.

[-V]

Display server version number.

CTMServer

The Configuration Template Manager (CTMServer) manages templates and template data.

CTMServer Syntax

ctm_server flags 
flag options and defaults

-u database _user_name

-p database_password

[-n database _name]

Defaults to empty.

[-s database _server_name]

Defaults to empty. With an Oracle database, both -n and -s flags are set to $ORACLE_SID.

[-L log_output]

One of server, stdout, console, filename; if server, then output is sent to the LOGServer for storage in the database. Default is none.

[-i database_minimum_connections]

Defaults to 1.

[-x database_maximum_connections]

Defaults to 5. 

[-q thread_pool_size]

Defaults to 20.

[-A]

Enable access control. Defaults to no.

[-V]

Display server version number.

ES (Event Service)

The Event Service (ES) provides an abstraction layer that gives the application the capability of pushing creation, deletion, and modification events. When launching this server from the command line, you must specify event channels.

This server is launched by the ipmgr.launch utility with the following command:

es Domain_Creation Domain_Modification Domain_Deletion Permission_Creation Permission_Modification Permission_Deletion User_Creation User_Modification User_Deletion Usergroup_Creation Usergroup_Modification Usergroup_Deletion Device_Creation Device_Modification_Comm Device_Modification_Config Device_Modification_Admin Device_Deletion Template_Creation Template_Modification Template_Deletion Templatedata_Creation Templatedata_Modification Templatedata_Deletion Configuration_Modification Label_Creation Label_Modification Label_Deletion ArchiveFile_Creation ArchiveFile_Deletion Administration_ServerStateChanged -nonames

GUI

The GUI provides a user interface for working with the Cisco IP Manager servers.

GUI Syntax

ipmgr.gui

LOGServer (Log and Audit Server)

The Log and Audit server (LOGServer) manages the logging of messages from the component servers. These messages contain date and time of the operation (GMT), the name of the server that generated the message, location in the program, a message category identifier, a message description, and a user name. Output can be captured into the database or a user-specified file, or redirected to the console or terminal. LOGServer is itself capable of generating messages that can be captured in the database.

LOGServer Syntax

log_server flags 
flag options and defaults

-u database _user_name

-p database_password

[-n database _name]

Defaults to empty.

[-s database _server_name]

Defaults to empty. With an Oracle database, both -n and -s flags are set to $ORACLE_SID.

[-L log_output]

One of server, stdout, console, filename; if server, then output is sent to the LOGServer for storage in the database. Default is none.

[-q thread_pool_size]

Defaults to 20.

[-A]

Enable access control. Defaults to no.

[-V]

Display server version number.

NS

The Naming Server (NS) helps applications find initial CORBA server object references using server names. NS has no user command-line access.

NEMServer

The Network Element Manager (NEMServer) is responsible for managing network elements and for communications between elements and servers. NEMServer maintains communication status, supports network element operations, and monitors element status. NEMServer supports downloading and uploading configuration files.

For each operation, NEMServer returns an operation error code that is written to a system log file, with detailed information identifying the operation and its result, the network element, and the time.

TFTP

NEMServer was designed to exchange data with network elements using a TFTP server, which you do by selecting a domain and bring up the Domain Properties window. Then bring up the Telnet Gateway Properties dialog and specify a particular TFTP Server address in the TFTP Server field.

If you do not do this, data is downloaded to devices line by line using the Cisco IOS configure terminal command and is uploaded from devices by capturing the output following a show command. (However, this results in a slow data exchange rate.)

It is recommended that each machine on which you install NEMServer be configured to act as its own TFTP server. To do this, you must specify either its host name or IP addressing in the Telnet Gateway Properties dialog. (If you use host names, every device that communicates through the TFTP server must be able to resolve names.)

NEMServer Syntax

ctm_server flags 
flag options and defaults

-u database _user_name

-p database_password

[-t Telnet_gateway_hostname host1+host2+host3]

[-n database _name]

Defaults to empty.

[-s database _server_name]

Defaults to empty. With an Oracle database, both -n and -s flags are set to $ORACLE_SID.

-d Orbix_diagnostic_level

Set Orbix diagnostic level as specified, in the range 0-2.

-D debug_level

Set debug level as specified, in the range 0-5.

[-O ldebug_output]

One of stdout, console, filename. Default is none.

[-L log_output]

One of server, stdout, console, filename; if server, then output is sent to the LOGServer for storage in the database. Default is none.

[-i database_minimum_connections]

Defaults to 1.

[-x database_maximum_connections]

Defaults to 5. 

[-q thread_pool_size]

Defaults to 20.

[-A]

Enable access control. Defaults to no.

[-V]

Display server version number.

SGServer

The SGServer monitors router configuration changes by listening for SNMP traps that you can specify. The SGServer listens for SNMP traps on the standard SNMP trap port 162. To listen for SNMP traps, the SGServer needs to be run as root and listens on UDP port 162. Therefore, no other process on the same machine can listen on that port.

Cisco IOS Commands

The following Cisco IOS SNMP commands should be configured before using the Cisco IP Manager upload and download operations via SNMP. These commands configure the router's read and write community strings.

SGServer Syntax

sg_server flags 
flag options and defaults

[-V]

Display server version number.

[-h]

Print help message.

TGServer

The Telnet Gateway Server (TGServer) allows NEMServer to perform low-level network element operations.

The TGServer is transparent to users. A flat file stores telnet attributes such as the TFTP server IP address, timeout value, and so on, in such as way that TGServer can be relaunched without losing its attribute data.

Debugging TGServer Configuration Errors

You can monitor your TGServer communications by using any of several trace options, which are turned on and off in the IOS.common.debug.exp file located in the Cisco IP Manager subdirectory $EXPECT_SCRIPT_ROOT/scripts. To turn a trace feature on, set its value to 1; to turn a feature off, reset its value to 0.

Trace options are:

The setTelnetTraceOn and setTelnetTraceOff utilities located in the $IPMGR_SRVRS_HOME/utility subdirectory can be used to set the log_user option.

Detecting Banner Text Errors

If banner text contains the characters # and > (used by Cisco IOS as part of a prompt), download operations can fail when the console connect method is used (see "Element Properties" in the chapter "Managing Network Elements").

The test that detects illegal banners imposes an additional delay on each operation equal in length to the prompt timeout. Accessing a device using console mode actually connects to the terminal server first and then to the device. This causes a delay twice as long as the prompt timeout.

You can use the setCheckPromptOn and setCheckPromptOff scripts described in the "Other Utilities" section of the "Installation and Configuration" chapter to turn the check on or off, but you cannot reset the length of the delay with these utilities.

Cisco IOS Commands

The following Cisco IOS commands are those that TGServer uses while communicating with individual devices. The CIPM administrator should verify that each device on the network has been configured to enable users to send each of the listed Cisco IOS commands.

command can be startup, running, version, etc.
command can be startup, running, version, etc.
Upload: source_filename could be startup, running configuration, or the file located on a flash device; dest_filename is the destination file name on the TFTP server.
Download: dest_filename is the destination file name, which could be startup, running configuration, or the file located on a flash device.

TGServer Syntax

tg_server flags 
flag options and defaults

[-V]

Display server version number.

-S server_name

Defaults to TGServer.

-d Orbix_diagnostic_level

Set Orbix diagnostic level as specified, in the range 0-2.

-D debug_level

Set debug level as specified, in the range 0-5.

[-O ldebug_output]

One of stdout, console, filename. Default is none.

[-L log_output]

One of server, stdout, console, filename; if server, then output is sent to the LOGServer for storage in the database. Default is none.

[-q thread_pool_size]

Defaults to 20.

VCMServer

The Version Control Manager (VCM; also known as Archive Manager) archives the configuration file on each network element (NE) and template. It also maintains a history of configuration file changes on each network element.

VCMServer Syntax

vcm_server flags 
flag options and defaults

-u database _user_name

-p database_password

[-n database _name]

Defaults to empty.

[-s database _server_name]

Defaults to empty. With an Oracle database, both -n and -s flags are set to $ORACLE_SID.

[-L log_output]

One of server, stdout, console, filename; if server, then output is sent to the LOGServer for storage in the database. Default is none.

[-g] number

Stores full text only every number of iterations.

[-A]

Enable access control. Defaults to no.

[-q thread_pool_size]

Defaults to 20.

[-V]

Display server version number.

Server Launch Default Values

The default values for various server flags are the values that are in effect if you do not specify that flag when the server is started.

These values should not be confused with the default values assigned when ipmgr.launch is run. When this script is used, it sets the server flags to values that are considered appropriate by Cisco as a starting point for your installation.

This is a default installation; it does not mean that the servers are started up with default (or unmodified) values.

Editing Server Flags

Launch flags for each of the servers are defined in the Cisco-provided environment files in the envs directory located below your installation directory. When you source the file ipmgr.csh, it reads the environment variables in these files to set the server command-line launch flags as shown in Table A-2. When you launch a server with one of the scripts in the scripts directory, the script first checks to see if the appropriate variables are set; if not, the script also reads the environment variables in these files.


Note Exercise extreme caution before changing any of the flag values in any of the environment files in the envs directory. Due to interactions that proliferate through Cisco IP Manager, the slightest mistake (which could include any small typographical error in any argument) could cause unanticipated errors in your system, errors that will be extremely difficult to track down.


Table A-2: Server Launch Script Defaults
Variable Flags
ADM_CL_ARGS
-u database_user_id_specified_in_ipmgr.configure
-p database_upassword_specified_in_ipmgr.configure
-L server
-D 5
-d 2
-s Oracle SID_specified_in_ipmgr.configure
-n Oracle SID_specified_in_ipmgr.configure
CTM_CL_ARGS
-u database_user_id_specified_in_ipmgr.configure
-p database_upassword_specified_in_ipmgr.configure
-A
-D 5
-d 2
-L server
-s Oracle SID_specified_in_ipmgr.configure
-n Oracle SID_specified_in_ipmgr.configure
ES_CL_ARGS
Administration_ServerStateChanged ArchiveFile_Creation ArchiveFile_Deletion Configuration_Modification Device_Creation Device_Deletion Device_Modification_Admin Device_Modification_Comm Device_Modification_Config Domain_Creation Domain_Deletion Domain_Modification Label_Creation Label_Deletion Label_Modification Permission_Creation Permission_Deletion Permission_Modification Template_Creation Template_Deletion Template_Modification Templatedata_Creation Templatedata_Deletion Templatedata_Modification User_Creation User_Deletion User_Modification Usergroup_Creation Usergroup_Deletion Usergroup_Modification
LOG_CL_ARGS
-u database_user_id_specified_in_ipmgr.configure
-p database_upassword_specified_in_ipmgr.configure
-A
-D 5
-d 2
-L server
-s Oracle SID_specified_in_ipmgr.configure
-n Oracle SID_specified_in_ipmgr.configure
NEM_CL_ARGS
-u database_user_id_specified_in_ipmgr.configure
-p database_upassword_specified_in_ipmgr.configure
-A
-D 5
-d 2
-L server
-s Oracle SID_specified_in_ipmgr.configure
-n Oracle SID_specified_in_ipmgr.configure
NS_CL_ARGS
" "  // NS is launched without command-line
     // arguments
SGS_CL_ARGS
" "  // SGS is launched without command-line
     // arguments
TGS_CL_ARGS
-D 5
-d 2
-L server
VCM_CL_ARGS
-u database_user_id_specified_in_ipmgr.configure
-p database_upassword_specified_in_ipmgr.configure
-D 5
-d 2
-L server
-s Oracle SID_specified_in_ipmgr.configure
-n Oracle SID_specified_in_ipmgr.configure

These environment variables are not retained in memory after the conclusion of the process in which ipmgr.launch is executed, so they cannot be reviewed by displaying your environment variables in stdout.

To change the value of the -u, -p, -s or -n flag for any of the servers, you should rerun ipmgr.configure and specify different values when asked for the Oracle Server ID (-s and -n flags), Oracle user ID (-u) and Oracle password (-p).


Note The -s and -n flags may be set to different values for compatibility with other databases, if the Cisco IP Manager software is enhanced in the future; for an Oracle database, they are both set to the same value---the ORACLE_SID value.

To change the values of the -f and -P flags for NEMServer, rerun ipmgr.configure and specify a different host name or IP address for the TFTP server (-f) and a directory name when asked for a TFTP directory (-P; must be relative to /tftpboot).

To launch all servers without ADM control, open the file install_dir/envs/allserver.env in a text editor and search for the following line:

setenv IPMGR_AAS_FLGS "-A"
 

Remove the -A flag, so that the line reads as follows:

setenv IPMGR_AAS_FLGS ""
 

Alternatively, you can search for the environment variable that sets each server and remove $IPMGR_AAS_FLGS from each.

To change the -L flag for all servers, search for the following line:

setenv IPMGR_LOG_FLGS "-L server"
 

Change server to cout, console, or a file name, or set the entire flag to "".

Alternatively, you can search for the environment variable that sets each server and remove $IPMGR_LOG_FLGS from each, or change it to "-L option" (include the quote marks) as desired for each server.


hometocprevnextglossaryfeedbacksearchhelp
Posted: Mon Feb 14 14:08:54 PST 2000
Copyright 1989 - 2000©Cisco Systems Inc.