Q. Should databases remain in the system when they
are not part of the system being restored? (Products affected : CEMF 3.x)
A. Yes, this is the expected behaviour. Doing a restore doesn't
automatically remove old databases and configurations before performing the
An Element Manager (EM) stores data in several databases. Therefore, when
you restore a backup created before an EM was installed, you overwrite the
databases with databases that have no knowledge of that EM. Any databases
that were associated directly with the EM, but were not included within
the backup that you have restored, remains in the system (they are not removed).
To avoid problems when restoring an earlier backup (if you have installed
an EM since the backup was made), the following steps describe the correct
way to proceed:
Install a new EM
Use the new EM
Restore backups taken at step 1 (that is, with no knowledge of the
Q. How do I update the IP address of an existing CEMF
server installation? (Products affected : CEMF 3.x)
A. The IP address of an existing server installation may be updated via the
/cemf updateIP -m xxx.xxx.xxx.xxx (where xxx.xxx.xxx.xxx
is the desired IP address)
Note: This facility is available in the base CEMF 3.1 package, but
CEMF 3.0.4 - Patch 05 is required for it to work on CEMF 3.0.4.
Q. How do I install a CEMF server on a machine with
multiple IP addresses when I don't want to use the default IP
address? (Products affected : CEMF 3.x)
A. On a CEMF 3.1 installation, use the updateIP function
to change the server to the desired IP address, and following this change,
clients can connect to the server on the new address.
Because the updateIP function isn't present in the base CEMF 3.0.4
system, the initial (unpatched) server installation must specify the first
(default) IP address. Following this, apply the patch containing the updateIP
function and then the existing server IP address is updated to the desired
value denoted in the updateIP command. The CEMF 3.0.4 installation
is then available for new client connections on this address.
Q. How do I connect my client to a CEMF installation
that is not using its default IP address? (Products affected : CEMF
A. When installing the client, specify the IP address being used
by the server together with the PROPER host name (it is important that the proper host name is used).
Q. How can I change the host name and/or IP Address
that my CEMF installation uses? (Products affected: CEMF 3.x)
A. Cisco EMF provides the user with the updateName and updateIP
functions for this purpose.
Refer to the Cisco Element Management Framework - Installation and Administration
Guide, section "Administering Cisco EMF WorkStations", subsections "Updating
Hostname" and "Updating IP address" for details of how to carry out these
Q. What are jumbo, mini, and mini-jumbo patches and
how does their numbering convention work? (Products affected : CEMF 3.x)
A. Jumbo patches (or jumbos) are patches applied to CEMF, that roll-up
all updates from previous patches.
Mini patches contain selective software updates, and are applied to specific
jumbos. Mini patches can be applied in any order, so they should not contain
duplicate files. If they contain duplicate patches, regression may occur.
Mini-jumbo patches are mini-patches that contain software updates that
exist in other mini patches. Any installed mini patches that are obsoleted
by a mini-jumbo, are automatically deinstalled when that mini-jumbo is applied.
In turn, any subsequent attempt to install the obsoleted mini patch fails
as long as the mini-jumbo is present. Like mini patches, mini-jumbos can
be applied in any order. The following rules apply:
A mini or mini-jumbo patch can only be installed on the jumbo patch
it is patching.
It is not possible to install a mini or mini-jumbo patch if a later
jumbo is already installed.
Installing a jumbo patch automatically de-installs all previous patches.
Installing a mini-jumbo patch automatically de-installs all previous
mini and mini-jumbo patches made to that jumbo patch.
A jumbo patch can only be installed on top of the version of the package
it is patching (for example, applying a CEMF 3.1 based patch to a CEMF
3.0.4 system is not permitted).
It is not possible to install a mini or mini-jumbo patch if its fixes
are already incorporated into a later mini-jumbo that is already installed.
The identification format is slightly different between jumbo and mini/mini-jumbo
patches. This is explained below.
The CEMF jumbo-patch ids use the following format:
Digits 1 and 2 are used to indicate that the patch is a jumbo patch
pertaining to CEMF, and is set to a value of 17.
Digits 3 and 4 indicate whether the jumbo patch pertains to the server
or client - 00 or 01, respectively.
Digits 5 and 6 represent the jumbo-patch level, which is sequential.
Digit 7 is a hyphen, used solely as a divider.
Digits 8 and 9 indicate the build number of the patch, which is sequential.
For example, 170003-12 represents build 12 of CEMF-server patch level 3, while
170105-02 indicates build 2 of CEMF-client patch level 5.
The CEMF mini and mini-jumbo patches use the following format:
Digits 1 and 2 indicate a mini or mini-jumbo patch pertaining to the
server or client, where 19 indicates a server patch and 20 a client.
Digits 3 and 4 indicate the level of the parent jumbo patch.
Digits 5 and 6 represent a unique identification number for the mini
or mini-jumbo patch.
Digit 7 is a hyphen, used solely as a divider.
Digits 8 and 9 indicate the build number of the patch, which is sequential.
For example, 191101-03 indicates build 3 of a CEMF-server mini or mini-jumbo
patch, with an id number of 01, pertaining to a level 11 jumbo patch. While,
201104-05, indicates build 5 of a CEMF-client mini or mini-jumbo patch, with
an id number of 04, which pertains to a level 11 jumbo.
The following example illustrates how the patching mechanism should be
used. Ignore the patch build numbers since these vary depending on which
version/build of CEMF is being patched.
For this example, a server based jumbo patch 170021-05 requires a series
of mini and mini-jumbo patches over a period of time.
Assume that you have installed jumbo patch 170021-05 onto a system it
already has patches applied, an action that results in the automatic removal
of any previously applied patches:
[CEMF + various patches] --> [CEMF + 170021-05]
Next you apply mini patches 192101-03, 192102-03 and 192103-01, which coexist
with the installed jumbo.
Any attempt to reinstall 192102-03 results in failure as long as 192104-02
Q. My CEMF Management machine is behind a firewall.
What ports should I open on the firewall to allow me to use auto discovery
to deploy and manage 6400 devices? (Products affected : CEMF 3.x)
A. You must enable the following ports on the firewall so that auto
discovery can work normally through the firewall:
Type of Traffic
161 and 162
TCP and UDP
Q. How do I update the CEMF Server that my CEMF Client
is using? (Products affected : CEMF 3.x)
A. Follow these steps:
Ensure that CEMF is not running on the client.
Open all files in this directory: <CEMFROOT>/config/env/
Replace all occurrences of the old CEMF Server hostname with the new
CEMF Server hostname in each file.
If this following file is present, /var/adm/Atlantech/system/info
replace all occurrences of the old CEMF Servers' hostname and IP address
with the new CEMF Server hostname and IP address.
Restart your client installation and the new session points to the new
Q. Why does my installation abort when I try to install
my Element Manager on top of CEMF? (Products affected : CEMF 3.x)
A. This is a known problem with certain versions of the tar
utility, and is related to the version of Solaris that you are using.
The problem appears during the Element Manager (EM) installation process,
but it is not a CEMF problem since CEMF does not use the tar utility. The
source files for the installation of the EM were corrupted when they were
untarred. The following text is a response to a support call to Sun MicroSystems
to inquire about this tar/Solaris problem:
"There are incompatibility issues between tar for Solaris 2.5.1 (or
older versions of 2.6)
and 2.6. These only manifest themselves on
file names that are *exactly* 100 characters long. If a tar is
created on 2.6 and then
extracted on 2.5.1 (or old 2.6) file names 100 chars long will
This has been confirmed by the Sun Support team who refer to the following
Sun bug references: 4230018, 1159730, 4159825, 105792-03. The problem has
been reproduced within Suns' support labs (although the engineer said he
had never seen it before). Sun recommends that you upgrade to 2.6 and get
the latest patches to work around the problem.
Q. Why do I get the message "/usr/bin/showrev:
get_env_var(remove.list, SUNW_PATCHID)" when I install a CEMF patch?
And why can't I use the <CEMFROOT>/cemfinstall -r command to uninstall
the patch package? (Products affected : CEMF 3.x)
A. Cisco EMF installation scripts use the unix /usr/bin/showrev
command, which in turn reads the contents of /var/sadm/pkg. This directory
is intended to hold only package information and if it contains anything other
than that, the showrev command fails.
In this case a file called remove.list has been (wrongly) added
to directory /var/sadm/pkgs. If this file is deleted then the showrev
command works the way Cisco EMF expects, and the patch installation completes
Q. How do I delete a DSLAM that I mistakenly deployed
directly under the Physical view, so that I can deploy it under a Site object
I created under the Physical view? (Products affected : CEMF 3.x)
A. To prevent duplicate IP addresses within the system, Cisco EMF
uses the Network view to check for attempts to deploy objects with an IP address
the same as existing objects. In order to resolve the problem above you must
delete the relevant network from the Network view, and then the unwanted DSLAM
from the Physical view. The DSLAM should now deploy successfully under the
Q. How can I make sure my installed CEMF functions
after I change my machine hostname? (Products affected : CEMF 2.1.x)
A. Assuming the IP address of the host remains the same, follow
Before starting the system, rename the configuration environment (config/env)
files to the new host name. These files are used to locate the ports to
talk to/bind to for this host.
Change the hostname in the licence file to the new hostname. This file
is used to determine which host we should talk to for licence requests.
However, the licence file uses the hostID, so as long as this has not changed,
a new licence key is NOT needed.
Ensure that ObjectStore is stopped. Rename the server configuration file
in <os_rootdir>/etc from:
On start-up, the ObjectStore startup script looks for a server file
with its host name to see if it should start a server or not.
This is only used to keep the information entered by a user during
installation. Any re-installation uses these values as the defaults
in prompts, so you should ensure that these are the correct values.
Q. What hardware specification do you recommend for
deployments? (Products affected : CEMF 3.x)
Sun Ultra 60 configured as follows:
2 x 9Gb internal disks
1 x 9Gb 10,000rpm external disk
512 Mb memory. (This may need to increase to 1Gb depending on performance benchmarking)
2 x 360 MHz processors
Sun Enterprise 450 configured as follows:
6 x 9Gb 10,000 rpm disks on 3Ultra SCSI controllers
1 Gbyte memory
4 x 250 Mhz processors
As above, with
Q. What Solaris 2.6 patches should I install for running
CEMF? (Products affected : CEMF 3.x)
A. CEMF requires only a standard Solaris installation, with the
default patches. Running showrev -p on one of our workstations shows
that the following patches are installed. This is the specification we would
The files in these directories define types/groups/objects that are essential
to the system operation. They are only parsed on an initial CEMF startup or
after a reset; after that the information is databased. After/during parsing
of these files the system creates objects internally to hold this information.
When multiple EMs are installed on a CEMF platform, it is possible that
the system tries to create too many objects at once. You can control this
by changing the following line in the CEMFROOT/config/init/objectSpecificationFileParser.ini
Change the line:
MaxPerContext = 1000
MaxPerContext = 100
If any of the files in these directories is incorrect, in that it doesn't
specify types/groups/objects, or if any of these files are duplicates and
specify the same types/groups/objects twice, the system will likely fail
Check these directories for core files, editor backup files, user copies
of files etc. Any of these should be removed.
For either solution you must stop, reset, and start CEMF.
Q. Why do Mapviewer and Auto Discovery fail to launch
from the launch pad unless I invoke a session as root? (Products affected
: CEMF 3.x)
A. When your system reports the following error, "The X server
has refused connection for this session," this is actually an incorrect
and misleading message for the problem described above. The problem is that
OPENWINHOME is not set. Ensure this is set and the value is correct for the
installation path for openwin (normally /usr/openwin). Set it
to this value if it is not.
Q. Why won't CEMF applications run when the OPENWINHOME
environment variable is not set? (Products affected : CEMF 3.x)
A. The following error, "The X server has refused connection
for this session" appears when the OPENWINHOME environment variable is
not set. This error relates to xhost settings. It occurs when you attempt
to run a CEMF session by remotely logging on to a client or manager installation
and using the X DISPLAY variable to display back to your local machine.
This is not a supported CEMF configuration and is not recommended. However,
in a development environment it is often useful to allow xhost access
in both directions between the the remote machine and your local machine.
This can be achieved by running the following commands:
run: xhost +<REMOTECEMFHOSTNAME> on your local machine and then
run: xhost +<LOCALHOSTNAME> on the CEMF client or manager.
Note: If you experience problems when trying to run xhost on
the remote machine, ensure that DISPLAY is set to the remote machine and that
the X server is currently running. If you are still experiencing problems,
consult the xhost documentation.
Q. Why does the CEMF session splash screen hang after
I enter my user name and password? (Products affected : CEMF 3.x)
A. If the Solaris hostname of the client is wrongly configured,
this can cause the CEMF session to hang (the splash screen and login open
but hang after the username and password are entered). This is caused by the
clients machine name being mismatched with its name in DNS. The following
scenario highlights this problem:
On the client machine, hostname returns nameA.
On the Manager, doing an nslookup for nameA fails.
In DNS, the client machine is called nameB.
The workaround is to change the hostname in the following files to use
Q. Why does CEMF fail to start up and displayed the
error message, 'Failed to load process files?' (Products affected : CEMF
A. This can be caused by the machine's hostname not being in /etc/hosts.
The problem has been seen on machines not using NIS or DNS, only files. The
solution is to ensure the hosts file is updated to include the machine's hostname.
Q. How do I control which CEMF processes are running?
(Products affected : CEMF 3.0.x)
CEMF 3.x uses the concept of the run level. This is an integer in the
range 1..2^31-1 that is assigned to a process. It controls the order of
startup on an ascending run level basis, and shutdown on a descending run
Querying processes on a run level basis
A binary exists called sysmgrClient that allows interogation
of all the processes currently being handled by the sysmgr on a per
run level basis. It must be run within a CEMF shell.
Querying multiple run levels
In the CEMFROOT/bin directory, issuing the following command
gives a list (to stdout) of all processes under sysmgr control
between run levels 1 and 14. This includes information such as the
state of the process, the run level for the process and its tag
(that is, the name identifier for process):
./sysmgrClient -s 1 -e 14
If the specified end level is higher than specified start level,
start and end levels are swapped and the information displayed.
If only one of -s or -e is specified, a default value
of 1 is used for the start level and 2^31-1 for the end level. Therefore,
entering the following command lists all processes under sysmgr
control between run level 1 and 2^31-1:
./sysmgrClient -s 1
Querying a single run level
It is also possible to display information for a single run level.
To displays information for any processes at run level 5, enter
the following command:
./sysmgrClient -i 5
Retrieving the current run level of the sysmgr
Entering the following command retrieves the current run level
of the sysmgr and logs to the sysmgrClient log file (and stdout)
the current run level of the sysmgr:
Changing the current run level of the sysmgr
To change the current run level of the sysmgr to 10, enter:
./sysmgrClient -r 10
Setting the run level of the sysmgr has one of three effects:
Specifying a run level higher than the current run level causes
the sysmgr to start any processes present within the sysmgr that
are present between the old and new run levels.
Specifying a run level lower than the current run level causes
the sysmgr to stop any processes present within the sysmgr that
are present between the old and new run levels.
Specifying a run level equal to the current run level results
in no change of state within the sysmgr.
Loading/Unloading of processes
The sysmgrClient binary may also be used to load and
unload a set of processes (under sysmgr control) specified in a processes
To load a set of processes from a process file, the sysmgrClient
binary can be used as follows:
./sysmgrClient -l <processes-file-or-directory>
Specifying a directory of process files to be loaded into the sysmgr
results in these processes being first added to the sysmgr and then
started. Specifiying a single file loads that file only. Multiple
files or directories are not currently supported.
Processes are only added if they are not already present within
the sysmgr (a comparison is performed on the process tag). Processes
are only started if the current run level of the sysmgr is less
than or equal to the run level of the process.
To unload a set of processes from a process file, the sysmgrClient
binary can be used as follows:
./sysmgrClient -u <processes-file-or-directory>
Specifying a directory of process files to be unloaded from the sysmgr
results in these processes being stopped and then removed from the
sysmgr. Specifiying a single file loads that file only. Multiple files
or directories are not currently supported.
Processes are only stopped or removed if they are present within
Note: If a run level is specified while trying to load
or unload a set of processes, the run level is set before the loading
or unloading operations are performed.
Stopping/Starting processes by name
Note: The name used by sysmgrClient is not the
name of the process binary. sysmgrClient uses the name
tag of the process that is specified within the appropriate process
file in the <CEMFROOT>/config/processes directory (that is,
The sysmgrClient binary can be used to start and stop
processes (under sysmgr control) simply by specifying the process name.
For example, if you interrogate the sysmgr using the sysmgrClient
by entering the following command:
Again, note the change in state of the Coordinator.
Note: Process starting/stopping by name has no effect on
the run level of the sysmgr. Also, process starting/stopping by
name operations are incompatible with all other operations that
can be performed using the sysmgrClient. For example:
./sysmgrClient -x Coordinator -r 10
Would be an invalid set of operations to perform, and the sysmgrClient
would exit with the error message:
Process kill operation incompatible with other operations,
Usage options for sysmgrClient
By typing the following command:
A usage help screen is displayed as follows:
[-c] check files only
[-l <process-file-or-directory>] start and load processes specified in files
[-u <process-file-or-directory>] stop and unload processes specified in files
[-r <int-level>] set the run level
[-g] get the current run level (output to logger)
[-s <int>] start level to display processes under sysmgr control
[-e <int>] end level to display processes under sysmgr control
[-q] shutdown sysmgr
[-k <process-name>] kill specified process.
[-x <process-name>] execute specified process.