HP Instant Capacity release notes for Version 10.x (March 2011)

• When a standby manager is added (icapmanage -a -S) certificates are exchanged
between the active group manager and the standby manager, and between the standby
manager and every host of every member of every managed group.
• When a standby manager takes over a group (icapmanage -Q) certificates are exchanged
between the new active manager and any member hosts which have not already exchanged
certificates with this manager.
Whenever the GiCAP software needs to exchange SSL certificates between hosts it will prompt for
the root password so that it can exchange the certificates. If the GiCAP software needs to exchange
SSL certificates it will remove any existing certificates with the same “Issuer” and “Subject” attributes
as the certificates the GiCAP software wishes to install. WBEM does not allow the installation of
certificates with the same Issuer and Subject as previously installed certificates. The GiCAP software
uses private certificates with an Issuer and Subject that should not conflict with other certificates.
Note that the addition of the -n option to the icapmanage -Q command means certificates will
not be exchanged and no password prompting will occur. This option is provided for situations
where certificates have already been exchanged and the icapmanage command must be
embedded in a control script.
Use the cimtrust -l command to list all WBEM certificates on a host system.
Status Considerations
You can use the icapmanage -s -v command on a group manager system to evaluate if the
SSL certificates have been properly exchanged for the group. The -v (verbose) option checks each
member host to make sure that two-way communication has been established between the manager
and the host. If there is a problem, a note at the end of the display will indicate which hosts might
have a problem with group communication. It is recommended that you do this check periodically
on both the active manager and on any standby manager that you have defined, particularly if
you want to be prepared for any failover from the active group manager to any standby manager.
Only the icapmanage -s command with the -v option does this complete communication check
though all icapmanage -s operations report on communication problems uncovered as
icapmanage -s fetches the information it needs from the various group members.
The icapstatus command on a member host does not check that two-way communication has
been established but it will report on problems trying to contact the active group manager. (It does
not try to contact a standby manager if one is defined.)
Lost Certificates
SSL certificates allow the secure exchange of information between two hosts without the use of
passwords. Each host maintains the SSL key information necessary to connect to the other host. If
you inadvertently remove these SSL keys (for example by reigniting a member system or by
accidentally deleting certificate files) you have broken the ability to communicate with the other
host. Fixing this problem may involve multiple steps.
Consider the case where someone accidently deletes the certificate files in the /etc/opt/iCAP
directory on a GiCAP member (GiCAPcert.pem and GiCAPpkey.pem). An icapstatus on
such a system will show errors similar to the following:
Member xyz in GiCAP group One
-------------------------------------------------
Active Group Manager: gm1.oa.hp.com
Standby Group Manager: gm2.ba.hp.com
ERROR: Unexpected error
PGS00415: SSL EXCEPTION: PGS09207: CANNOT GET SERVER CERTIFICATE.
While /etc/opt/iCAP/GiCAP_keygen will create new copies of these files (as will a
re-installation of iCAP), this is insufficient to restore communication between the member host and
its GiCAP group manager. Instead of the message above, icapstatus will report something similar
to:
32 Major Changes, New Features, and Requirements of Instant Capacity Version 10.x