Guest

Cisco Element Manager System

Frequently Asked Questions About CEMF Miscellaneous Topics

Document ID: 24966



Questions


Q. Why can't I login to a CEMF session after installing CEMF 3.0.4 Patch 2? (Products affected : CEMF 3.0.4 Patch 2 onwards )
A. Patch 2 introduces password encryption. Passwords for existing users (created before the patch was installed) are stored in plain-text format and are incompatible with the new encryption functionality.

You can employ either one of the following two methods to resolve this problem:

  • The first is a manual process that requires the use of the Access Manager Application. The advantage of this method is that it preserves all existing user-created partitioning objects (Users, User Groups, and Access Specifications). This method is suitable for installations that have a small number of CEMF users (in addition to the Admin user).

  • The second requires less manual work but deletes all user-created partitioning objects (Users, User Groups, and Access Specifications).

You must perform Step 1 for both methods. Where an installation has no users other than the default Admin user this is the only step that you must perform.

Note: All steps should be run by the UNIX root user in a CEMF shell environment.

  1. Reset Admin user password to default (Admin). This resets the password using an encrypted version. The Admin user can then login to a CEMF Session (using default password). To do so run command:
    <CEMFROOT>/bin/partitioningTool -r

  2. Perform one of the following:

    • Method A: This step involves manually resetting the passwords for all users. All existing partitioning objects will be preserved.

      1. Start a CEMF Session, logging in as the Admin user.

      2. Launch the Access Manager Application.

      3. With Users displayed in the main Access Manager screen, select the first user.

      4. Select the Edit->Change Password menu option.

      5. In the resulting Change User Password dialog enter a new password for the user (required to enter password twice for confirmation).

      6. Click the Ok to close the dialog and commit the password change.

        Repeat steps 3 to 6 for each user.

    • Method B

      WARNING: This method deletes all user-created partitioning objects (Users, User Groups, and Access Specifications). Only the Admin user and system-supplied Access Specifications remain.

      The administrator performing this operation must be aware of the location of the CEMF databases and whether they are located in a RawFS partition.

      1. Stop CEMF.

      2. Remove CEMF partitioning database using the following command (non-RawFS):
        rm -f <CEMFROOT>/db/partitioning.db

        For databases stored in a RawFS partition use the command:

        <OS_ROOTDIR>/bin/osrm <RawFS_Database_Path>/partitioning.db

        where <RawFS_Database_Path> is the path of the RawFS directory where the database files are stored.

      3. Start CEMF.
      4. Recreate default partitioning objects (including Admin user) by running command:
        <CEMFROOT>/bin/partitioningTool -a
Q. On CEMF 2.1.4, what do I need to do to move databases from one computer to another? (Products affected : CEMF 2.1.4)
A. You cannot move a 2.1.4 system between machines with the Event Manager installed if you want all information retained. The Event Manager has an IP addresses stored within the alarm databases that cannot be configured. If the alarm databases are removed, you can perform the steps below.

Note: This has not been verified at Cisco and should not be tried at a deployed site.

  1. On the original system, change the ipaddress of the management node in mgmtContainment to the ipaddress of the target machine. This can be done using ObjectConfig.
  2. Perform a cemf stop in the original system.
  3. Perform a backup of the full system.
  4. Remove these files:
    • alarm.db
    • alarmGroup.db
    • alarmReceiver.db
  5. On target system, ensure that same versions of CEMF, Event Manager, and EMs are installed.
  6. On target system, CEMF should not be running. Copy the dbs from the original system into the db directory of target system.
  7. Start the target system.
  8. Rebuild status propagation by performing a kill -SIGUSR1 on mapdaemon process.
  9. Verify that EM functions, like action launching, are functioning correctly.


Related Information



Updated: Jan 31, 2006 Document ID: 24966