cmclconfd - security token exchange?

[support_5]

Hi Guys,

I've noticed my cmviewcl, cmgetconf, cmquerycl commands are taking a while (1-2 minutes) to return. I've got a 7 node cluster with 36 packages. All nodes have dedicated heartbeat LANs.

As I'm adding a new package, I got the message below:

# cmapplyconf -v -P /etc/cmcluster/packages/stcards/stcards.conf

Checking existing configuration ... Done
Gathering configuration information ... Done
Parsing package file: /etc/cmcluster/packages/stcards/stcards.conf.
Attempting to add package stcards.
(this took a while to come back too)
Maximum configured packages parameter is 70.
Configuring 36 package(s).
34 package(s) can be added to this cluster.
198 access policies can be added to this cluster.

Modify the package configuration ([y]/n)? y
Adding the package configuration for package stcards.
Unable to perform the security token exchange with cmclconfd on node hods01
Unable to perform the security token exchange with cmclconfd on node drds04
Unable to perform the security token exchange with cmclconfd on node drds02
Unable to perform the security token exchange with cmclconfd on node hods04
Unable to perform the security token exchange with cmclconfd on node hods02
Unable to perform the security token exchange with cmclconfd on node drds06
Completed the cluster update.

I can startup the new package ok.

Questions:
1. What is that security token exchange thing?
2. Why is it taking longer for cmviewcl, cmgetconf, cmquerycl to return?

Any help would be greatly appreciated.


Many thanks.

Tung

[RAC_1]

The mesaages about access configuration makes me think that this is latest version of SG. (At least 11.16?)
What version SG?

Did you think about applying it with -k option? I think (not sure though) security token messages are on account of existing access policies.

[support_5]

Whoops, silly me. All nodes running HP-UX 11.23, SG 11.16.

Thanks for the suggestion, RAC, but no go, I tried cmquerycl with the -k option, it was a bit faster, but it took a while "Gathering configuration information...", but the warnings and errors below worries me.

Warning: Not probing node drds06 as it is currently unreachable.
This may cause network partitions to be reported.
Warning: Not probing node hods02 as it is currently unreachable.
This may cause network partitions to be reported.

Error: Cannot connect to configuration daemon (cmclconfd) on node drds06
Error: Cannot connect to configuration daemon (cmclconfd) on node hods02

cmclconfd is running on both drds06 and hods02, I can ping both servers from hods01. It was not always like this, the latest change was adding drds06 into the cluster.

More question:
3. Why is it complaining it cannot connect to configuration daemon cmclconfd?

Hmmm...


Many thanks.

Tung

[RAC_1]

From those two hosts, Can you do cmviewcl on any of the packages running on another hosts?

Are you up to date on patches?

[support_5]

Yup, I was able to run cmviewcl -p PACKAGE_NAME successfully from the two hosts, still slower to return, though. As for patches, a set of ServiceGuard 11.16 patches were applied from Sep 2005.

We also moved our DNS and Sendmail server, but not sure if that could have affected it?

[John Bigg]

These messages could imply that there is a problem talking to identd. What messages are logged into syslog at the time the messages are reported by cmapplyconf? Can you verify that identd is setup and working correctly?

If identd appears to be working correctly and syslog gives no further clues then it would probably be necessary to turn on logging to determine what is causing this.

[Stephen Doud]

If your servers rely on identd for Serviceguard, insure:
1) identd (sendmail) is at version 8.9.3.1 and patched

2) /etc/nsswitch.conf =
hosts: files dns

3) /etc/hosts contains a list of every IP-bearing NIC on each cluster node

4) nslookup and "who -Rm" shows the correct hostname

5) Port 113 is not denied in /var/adm/inetd.sec

6) Internode HB connection is not done by a router, and if done by switch, no filtering of hacl ports or identd port numbers

[support_5]

Sorry for the late reply, guys. identd is not used, commented out in /etc/inetd.conf.

Anyway, the problem went away after a restart of inetd daemon. It seems to have played up after our redundant core switch died? We restarted inetd because our Control-M agents were playing up too, complaining about inetd. cmviewcl and cmgetconf runs great now.

Is this normal behaviour? Strange that it should complain about some security token exchange?

Thanks again for your help, guys.