Serviceguard Manager Version A.05.00 Release Notes, October 2005

Serviceguard Manager Version A.05.00 Release Notes
Patches and Fixes in this Version
Chapter 1 47
2. Type in something in the textfield to force trap setting.
The status should now be Trap Set.
The back-end logic is:
— Step 1: Use the community name supplied to set trap (Success or
Failure)
— Step 2: Query the status of the trap destination. Since the trap
destination is already set in the backend, Step 1 will not unset
the trap, even if the community name is not correct. Step 2 will
then display the updated status.
Note: If the status is already Trap Set, unsetting the trap destination
in the backend will not be visible in the front-end GUI. In this case,
please disconnect and then reconnect.
Serviceguard Manager uses both snmp event notification and polling
to ensure the most up-to-date data is available for the user. Even if a
snmp agent dies on the backend, the polling should be able to refresh
the data with a slight delay, depending on the polling interval setting
which can be customized by the user.
JAGaf45963 Cannot cmapplyconf from root from node in cluster
• What is the problem? For redundancy, Serviceguard commands use
all networks available on a system to communicate with
Serviceguard daemons. This includes configured interfaces not listed
in the cluster ASCII file. To authorize these communications,
Serviceguard must be able to resolve the source IP address to a valid
hostname. Valid hostnames include every node in the cluster and
any node outside the cluster that needs to communicate with nodes
within a cluster, which would include a Session Server COM node in
Serviceguard Manager.
A permission problem will result when Serviceguard cannot verify
that the source address of a message is authorized and cannot
resolve the source IP address to a valid hostname. The actual
symptoms of a permission problem will vary depending on what
operation is being performed. The following is an example of a
message which could be seen in syslog.log: