<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Why would cmviewcl command timeout? in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/why-would-cmviewcl-command-timeout/m-p/3958427#M695293</link>
    <description>One thing to point out is that A.11.15 of Sg is no longer supported, you may want to consider at least ensuring the latest patch is on it, or uopgrade to a later supported revision (A.11.16 in this case)&lt;BR /&gt;&lt;BR /&gt;Also there are specific ports that SG needs available, see:&lt;BR /&gt;&lt;A href="http://docs.hp.com/en/5874/securingserviceguard_nov2005.pdf" target="_blank"&gt;http://docs.hp.com/en/5874/securingserviceguard_nov2005.pdf&lt;/A&gt;</description>
    <pubDate>Thu, 08 Mar 2007 17:10:45 GMT</pubDate>
    <dc:creator>melvyn burnard</dc:creator>
    <dc:date>2007-03-08T17:10:45Z</dc:date>
    <item>
      <title>Why would cmviewcl command timeout?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/why-would-cmviewcl-command-timeout/m-p/3958425#M695291</link>
      <description>I have a working cluster, running HPUX 11.11, ServiceGuard B.11.15, PARISC on 2 rp7410 servers.&lt;BR /&gt;&lt;BR /&gt;/etc/cmcluster/cmclconf.ascii shows:&lt;BR /&gt;&lt;BR /&gt;NODE_NAME               nodeA&lt;BR /&gt;  NETWORK_INTERFACE     lan0&lt;BR /&gt;    STATIONARY_IP       71.1.239.200&lt;BR /&gt;  NETWORK_INTERFACE     lan4&lt;BR /&gt;  NETWORK_INTERFACE     lan2&lt;BR /&gt;    HEARTBEAT_IP        192.168.5.1&lt;BR /&gt;  NETWORK_INTERFACE     lan6&lt;BR /&gt;    HEARTBEAT_IP        192.168.6.1&lt;BR /&gt;  FIRST_CLUSTER_LOCK_PV /dev/dsk/c4t0d0&lt;BR /&gt;NODE_NAME               nodeB&lt;BR /&gt;  NETWORK_INTERFACE     lan0&lt;BR /&gt;    STATIONARY_IP       71.1.239.201&lt;BR /&gt;  NETWORK_INTERFACE     lan4&lt;BR /&gt;  NETWORK_INTERFACE     lan2&lt;BR /&gt;    HEARTBEAT_IP        192.168.5.2&lt;BR /&gt;  NETWORK_INTERFACE     lan6&lt;BR /&gt;    HEARTBEAT_IP        192.168.6.2&lt;BR /&gt;  FIRST_CLUSTER_LOCK_PV /dev/dsk/c4t0d0&lt;BR /&gt;&lt;BR /&gt;lan0 is the primary for each node; lan4 is the standby. Heartbeat lans are lan2 and lan6, with a lock disk.&lt;BR /&gt;&lt;BR /&gt;All of this works together to provide an HA solution. The server sits in a special subnet of my company. The idea is that since this server is used for critical tasks, we want to be able to isolate it from the rest of the network, in case of network attack, virus attack, etc. So, our telecom people devised what we are calling a "drawbridge" on their routers. All services that are needed (such as DNS) are inside the special subnet. When an attack is declared, the telecom people pull up the drawbridge, which severs the connection between the special subnet and the rest of the company. All servers inside the special subnet should be able to survive without the link to the main company network.&lt;BR /&gt;&lt;BR /&gt;A few months ago, we tested this to see if it work work as advertised. And, for the most part it did. An odd thing happened to the cluster mentioned above. While the drawbridge was up, cmviewcl, and most other cluster commands would fail:&lt;BR /&gt;&lt;BR /&gt;cmviewcl  : Cannot view the cluster configuration. Either this node is not confi&lt;BR /&gt;gured in a cluster, or else there is some obstacle to viewing the configuration.&lt;BR /&gt; Check the syslog file for more information.  For a list of possible causes, see&lt;BR /&gt; the ServiceGuard manual for cmviewcl.&lt;BR /&gt;&lt;BR /&gt;Occasionally (1 out of 10 tries), it would complete successfully.&lt;BR /&gt;&lt;BR /&gt;If you put the drawbridge back down (ie, connected the special subnet back to the main company network), then cmviewcl would operate correctly.&lt;BR /&gt;&lt;BR /&gt;No packages failed. The cluster was alive. It was strange that the cmviewcl command would fail as see above.&lt;BR /&gt;&lt;BR /&gt;It caused problems with the applications because most of them use cmviewcl to determine on which node they are running and then act accordingly.&lt;BR /&gt;&lt;BR /&gt;I've exhausted my list of things to look for. The DNS servers are correct. I even hardcoded things in the /etc/hosts file, thinking it may be the issue. The /etc/cmcluster/cmclnodelist has all the nodes, IP addresses, etc., in it that I thought it should need. Obviously, there is something that the cluster is trying to access that must exist outside its subnet, but I don't know what. Anyone have any ideas on where I can look next? Anyone have some quickstart guides to using nettl for looking at serviceguard traffic?&lt;BR /&gt;&lt;BR /&gt;Thanks,&lt;BR /&gt;Doug</description>
      <pubDate>Thu, 08 Mar 2007 15:48:35 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/why-would-cmviewcl-command-timeout/m-p/3958425#M695291</guid>
      <dc:creator>Douglas D. Denney</dc:creator>
      <dc:date>2007-03-08T15:48:35Z</dc:date>
    </item>
    <item>
      <title>Re: Why would cmviewcl command timeout?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/why-would-cmviewcl-command-timeout/m-p/3958426#M695292</link>
      <description>Doug,&lt;BR /&gt;&lt;BR /&gt;   I do vaguely recollect seeing a problem similar to this. &lt;BR /&gt;&lt;BR /&gt;   I can tell  you why it works after 10 tries. This is most probably because of the hung cmclconfd daemon.&lt;BR /&gt;&lt;BR /&gt;   Whenever cmviewcl is issued, cmclconfd is forked that gathers configuration information and status from other nodes in the cluster.&lt;BR /&gt;&lt;BR /&gt;   If for somereason cmclconfd could not finish or hung, cmviewcl will fail, but cmclconfd takes minutes to timeout and end.During this period, all cm* commands will fail, since it will use the exisiting cmclconfd daemon.&lt;BR /&gt;&lt;BR /&gt;   Next time this happens, the quickest way to recover is to kill cmclconfd (the one with -p) and then issue cmviewcl.&lt;BR /&gt;&lt;BR /&gt;Sundar.&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Thu, 08 Mar 2007 16:08:34 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/why-would-cmviewcl-command-timeout/m-p/3958426#M695292</guid>
      <dc:creator>Sundar_7</dc:creator>
      <dc:date>2007-03-08T16:08:34Z</dc:date>
    </item>
    <item>
      <title>Re: Why would cmviewcl command timeout?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/why-would-cmviewcl-command-timeout/m-p/3958427#M695293</link>
      <description>One thing to point out is that A.11.15 of Sg is no longer supported, you may want to consider at least ensuring the latest patch is on it, or uopgrade to a later supported revision (A.11.16 in this case)&lt;BR /&gt;&lt;BR /&gt;Also there are specific ports that SG needs available, see:&lt;BR /&gt;&lt;A href="http://docs.hp.com/en/5874/securingserviceguard_nov2005.pdf" target="_blank"&gt;http://docs.hp.com/en/5874/securingserviceguard_nov2005.pdf&lt;/A&gt;</description>
      <pubDate>Thu, 08 Mar 2007 17:10:45 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/why-would-cmviewcl-command-timeout/m-p/3958427#M695293</guid>
      <dc:creator>melvyn burnard</dc:creator>
      <dc:date>2007-03-08T17:10:45Z</dc:date>
    </item>
    <item>
      <title>Re: Why would cmviewcl command timeout?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/why-would-cmviewcl-command-timeout/m-p/3958428#M695294</link>
      <description>Sounds like your servers are configured to rely on DNS - which is not recommended for Serviceguard.&lt;BR /&gt;&lt;BR /&gt;in /etc/nsswitch.conf, set &lt;BR /&gt;hosts:  files dns&lt;BR /&gt;&lt;BR /&gt;In /etc/hosts, list every fixed IP assigned to each NIC on each node in the cluster&lt;BR /&gt;&lt;BR /&gt;Finally on each line, add the simple hostname of the server at the end of each line if it's not already listed on the line.&lt;BR /&gt;</description>
      <pubDate>Fri, 09 Mar 2007 09:37:01 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/why-would-cmviewcl-command-timeout/m-p/3958428#M695294</guid>
      <dc:creator>Stephen Doud</dc:creator>
      <dc:date>2007-03-09T09:37:01Z</dc:date>
    </item>
  </channel>
</rss>

