cmviewcl error: "Error: Permission denied to 127.0.0.1"

[Matt Hearn]

Hi all! I have a serviceguard cluster that I'm preparing to move into production, and I'm getting the following error when I run "cmviewcl:"

Error: Permission denied to 127.0.0.1
cmviewcl : Cannot view the cluster configuration. Either this node is not configured in a cluster, or else there is some obstacle to viewing the configuration. Check the syslog file for more information. For a list of possible causes, see the ServiceGuard manual for cmviewcl.

I've never gotten this before. Most of the forum stuff seems to indicate DNS issues, but both boxes can resolve themselves, each other, the loopback addresses, everything they should need.

The only thing that's changed since the last time I ran a cmviewcl was that they have given us two IP addresses in the same subnet with DNS names mapping to them, but I haven't even added them to the package control files yet! I logged in to test adding multiple IPs to a failover package, ran cmviewcl, and boom. Error. Any ideas?

[Kofi ARTHIABAH · Accepted solution]

Hmm... very curious! Have you tried adding 127.0.0.1 root to the /etc/cmcluster/cmclnodelist for testing purposes?
echo "127.0.0.1 root " >> /etc/cmcluster/cmclnodelist

then try again... you should not normally have to include this. You might want to check your /etc/hosts file ; your /etc/nsswitch.conf

Good luck

[Matt Hearn]

Hm. I didn't actually HAVE a cmclnodelist file. I created one with the command you recommended, but it didn't make a difference.

Earlier (after I came across the cmviewcl problem), I had noticed that in /etc/hosts on both boxes, 127.0.0.1 was doubly defined, first as the boxes' DNS hostnames, and then as loopback localhost, like this:

127.0.0.1 newbox1a
[some other entries]
127.0.0.1 localhost loopback

So I removed the newbox1a line. Didn't seeem to make a difference.

My /etc/nsswitch.conf file is super-simple, and seems to work fine. Just one line:
hosts: files [NOTFOUND=continue UNAVAIL=continue] dns [NOTFOUND=return UNAVAIL=continue TRYAGAIN=return]

Would it help trying to stop the package? I didn't actually get to the thing I wanted to test (involving taking the package down) because cmviewcl didn't work.

Also, I've run "inetd -c" a couple times on both boxes, as well as "inetd -k; inetd" once.

[Steven E. Protter]

1) Back the change out and see if that really was the cause of the problem. It might have been the network configuration.

2) I had something similar happen. I had a perfectly happy cluster running in the US, sitting at my office which doubled as an ISP. All was well and DNS was working. Shut down the D boxes took them to Israel fired them up and nada, nothing. Turned DNS off on, no difference. As it turned out serviceguard refused to work at all until I opened up the offending node to remsh traffic with inetd.conf changes. It made no sense at all, but shows you how sensitive SG is to a change in network environment.

SEP

[Matt Hearn]

A new tidbit of information:

newbox2a:/etc/cmcluster
(root)#: cmcheckconf -k -v -C /etc/cmcluster/cmclconfig.ascii

Checking cluster file: /etc/cmcluster/cmclconfig.ascii
Checking nodes ... Done
Checking existing configuration ... Done
Warning: Can not find configuration for cluster DMPLUS
Error: Unable to establish communication to node newbox1a: 19
cmcheckconf : Failed to gather configuration information

[Matt Hearn]

Unfortunately, Stephen, I can't do the IP and DNS changes myself, and the folks that can are gone for the day. I'm hoping to find a solution to this tonight, but if I don't I'll have them take care of it tomorrow.

[Matt Hearn]

BAM. Found it!

I had never put a cmclnodelist on either box. I put one on that contained the the loopback addresses plus the IPs of both servers, and it works like a champ. Not sure what I must have done to anger it, but it never needed the cmclnodelist before.

Thanks everybody!

[Stephen Doud]

All currently supported versions of Serviceguard require either cmclnodelist or .rhosts on each intended cluster server.

Previous clusters may already have had .rhosts built, but increasing concern for system security these days is striking out the use of rlogin from /etc/inetd.conf - negating the function of .rhosts, and forcing cmclnodelist to be used, at least for the initial cluster creation where A.11.16 of Serviceguard is involved. Thereafter, this version of SG uses 'identd' (see inetd.conf) to validate SG command authenticity.

Also, a fairly exhaustive review of your error message is discussed in this Online document:
UMCSGKBRC00008185
TITLE: Cluster Configuration Commands Fail with "permission denied"