Error while running cmview cl -v

BOUZALMAD Youssef — Thu, 23 Dec 2004 08:53:23 GMT

When running cmviewcl -v on both nodes of a MC Service Guard cluster, we got the following error message :

First Node :
root:/# cmviewcl -v >/dev/null
Error: Permission denied to 10.168.92.34

Second Node :
root:/# cmviewcl -v >/dev/null
Error: Permission denied to 10.168.92.33

Each time this is the public IP of the other node.

What is the mistake in our configuration ?

Re: Error while running cmview cl -v

bhavin asokan — Thu, 23 Dec 2004 09:12:07 GMT

hi,

which version of MCSG you are using.
if it is 11.14 or less do you have entries of both servers in the /etc/cmcluster/cmclnodelist

or in the .rhosts file .

regds,

Re: Error while running cmview cl -v

BOUZALMAD Youssef — Thu, 23 Dec 2004 09:41:15 GMT

Below the output of swlist :

PHSS_30370 1.0 MC/ServiceGuard A.11.15.00

The file /etc/cmcluster/cmclnodelist appears to be correct.

The both servers are in the /etc/hosts file :

10.168.92.33 dfhh1e01
10.168.92.34 dfhh1e02

Re: Error while running cmview cl -v

Sanjay_6 — Thu, 23 Dec 2004 10:11:39 GMT

Hi,

Take a look at this thread from hp docs site,

http://docs.hp.com/en/B3936-90079/ch05s01.html

Looks for the section "Access in Serviceguard versions A.11.15 and earlier".

Hope this helps.

Regds

Re: Error while running cmview cl -v

BOUZALMAD Youssef — Thu, 23 Dec 2004 10:55:42 GMT

I've checked all my configuration files.

/etc/cmcluster/cmclnodelist and .rhosts are exactly the some on both nodes.

Other commands :

root:/# cmquerycl -v

Begin checking the nodes...
Looking for ServiceGuard nodes ... Done

Cluster Name Node Name Version Status
clust_pec
dfhh1e01 up to date
dfhh1e02 up to date

root:/# cmgetconf > /dev/null
Error: Permission denied to 10.168.92.34

Re: Error while running cmview cl -v

Robert-Jan Goossens — Thu, 23 Dec 2004 11:18:45 GMT

could you post the output of.

ll /.rhosts

from both hosts.

regards,
Robert-Jan

Re: Error while running cmview cl -v

Stephen Doud — Thu, 23 Dec 2004 17:17:34 GMT

There are several possible causes for this problem. Serviceguard uses tcp/udp network communication to perform the cluster configuration commands on both the
local as well as the remote servers.

This means that ~/.rhosts must exist on every server in the cluster, and must contain all server names in the new cluster. Do NOT list any from other cluster
s. If /etc/cmcluster/cmclnodelist exists on all nodes, it will be accessed instead of .rhosts.

Some known causes and solutions of the problem:
--------------------------------------------------------------------------------
CAUSE 1: An existing cluster binary file (/etc/cmcluster/cmclconfig) with an old hostname/IP combination is confusing cmquerycl.

SOLUTION: Copy the /etc/cmcluster/cmclconfig file and then do a 'cmdeleteconf -f' (may require execution on each node).

--------------------------------------------------------------------------------
CAUSE 2: ~/.rhosts file missing on the local host
SOLUTION: Add the local server name to ALL .rhosts files on servers.

Example .rhosts:
eon root
ion root

--------------------------------------------------------------------------------
CAUSE 3: Missing .rhosts file on one of the cluster nodes.
SOLUTION: Create one, or if more desirable, create a file called /etc/cmcluster/cmclnodelist on all nodes using the same syntax - to provide more system secu
rity. (NOTE: cmscancl requires .rhosts in order to complete).

--------------------------------------------------------------------------------
CAUSE 4: .rhosts file not in root's home directory
SOLUTION: As root, type "cd" to get to root's home directory. Create a .rhosts file there.

--------------------------------------------------------------------------------
CAUSE 5.1: The content of /etc/cmcluster/cmclnodelist is inaccurate on one or more of the servers in the cluster. cmclnodelist is formatted just like .rhosts
and MUST give root permission to EVERY node in the cluster (including the local hostname).

If this file is not in use, Serviceguard will look at ~/.rhosts.

If the one of the cluster nodenames is not in the cmclnodelist file, this results:
cmrunnode : Unable to determine the nodes on the current cluster
cmrunnode : Either no cluster configuration file exists, or the file is corrupted, or cmclconfd is unable to run and this is in syslog.log:
inetd[4095]: hacl-cfg/udp: Connection from unknown (127.0.0.1)

SOLUTION: Recreate either file in this format on each server:

hostA root
hostB root
hostC root

NOTE: non-root users may encounter this message message when attempting to use cmviewcl. Use /etc/cmcluster/cmclnodelist to authorize non-root users to oper
ate cmviewcl command.

CAUSE 5.2: Non-cluster hostnames in cmclnodelist has produced the
message: error: permission denied to 127.0.0.1

SOLUTION: See Solution for 5.1

CAUSE 5.3: An invalid (old) /etc/cmcluster/cmclconfig file was restored from ignite, producing this error when cmquerycl was executed: error: permission deni
ed to 127.0.0.1

SOLUTION: If there is no cluster built, remove cmclconfig on all nodes in the intended cluster.
--------------------------------------------------------------------------------
CAUSE 6: /etc/hosts file contains hostname aliases to the left (instead of to the right) of the actual hostname

SOLUTION: Reverse the order of the hostname. It should be to the left of the alias

--------------------------------------------------------------------------------
CAUSE 7: Hostname resolution services (whether local /etc/hosts or DNS) may be supplying a mix of fully qualified domain names (FQDN) with simple hostnames.

SOLUTION: Use 'netstat -i' on each node to see whether simple or FQDN hostnames are used. ALL cluster-related files must reference the hostname the way that
the name service supplies it. Update either the name service provider or the cluster-related file so that the same type of reference is used. Simple hostna
mes are preferred.

--------------------------------------------------------------------------------
CAUSE 8: If the simple hostname is not the first name after the IP listed in the /etc/hosts file, this error will occur.

Example:

Wrong: 15.44.49.75 eon.atl.hp.com eon
Right: 15.44.49.75 eon eon.atl.hp.com

--------------------------------------------------------------------------------
CAUSE 9: Hostname resolution services accounts or other server communication problems.

For instance, a missing /etc/resolv.conf file, or a mismatch between the use of a simple hostname and a fully qualified domain name in name resolution source
files and the .rhosts can cause the following sort of messages:

Error: Unable to determine an IP address for ion: 1.
Error: Unable to communicate with node ion
Error: Unable to determine an IP address for ion: 1.
Error: Unable to determine device configuration: failed to send device query to node ion
Error: Unable to determine an IP address for ion: 1.
Error: Unable to determine lvm configuration: failed to send lvm query to node ion
Failed to gather configuration information.

In the above case, the /etc/hosts file lists the fully qualified server name instead of the simple hostname.

Use this troubleshooting method:
On both nodes, temporarily edit /etc/nsswitch.conf to configure "hosts" to resolve to /etc/hosts before DNS. Then update /etc/hosts to list all cluster nodes
, with simple hostnames to the left of fully qualified names.

NSSWITCH.CONF
hosts: files [NOTFOUND=return] dns
^^^^^ ^^^
refers to /etc/hosts

/etc/hosts
127.0.0.1 localhost loopback
16.113.9.255 ion ion.alf.mycorp.net # Serviceguard node
16.113.9.254 eon eon.alf.mycorp.net # Serviceguard node

The above approach has solved 'rlogin' or 'remsh' failures with the "permission denied" error too.

--------------------------------------------------------------------------------
CAUSE 10: Originating host not what was expected

From each node in the cluster, remsh to another node in the cluster.
Next, perform a "who -Rm". Example:

eon # remsh ion
<--- snip login messages --->
ion # who -Rm
root pts/1 Jul 20 09:54 (eon)

On the right side of the output is the originating identity. Insure it is the HOSTNAME of the originating server and not the alias of another NIC, or an IP a
ddress which was not resolved by hostname resolution services.

NOTE: .rhosts must be configured to permit remote host access to complete
this test.

Re: Error while running cmview cl -v

Nguyen Anh Tien — Fri, 24 Dec 2004 01:09:13 GMT

1, as stephen saying. You should try to fix cause 1.
I do not recommend you fix other cause becasue after correcting .rhosts and cmnodelist file you can use cmquerycl command.
2, You should check all relative patches for MC-SG 11.15 version by "show_patches" command. and install unavailable required patches.
Regard
tienna

topic Re: Error while running cmview cl -v in Operating System - HP-UX

Error while running cmview cl -v

Re: Error while running cmview cl -v

Re: Error while running cmview cl -v

Re: Error while running cmview cl -v

Re: Error while running cmview cl -v

Re: Error while running cmview cl -v

Re: Error while running cmview cl -v

Re: Error while running cmview cl -v