Decnet Proxy Question(s)

[Warren Landrum_1]

All,

We are having intermitent problems with proxies on our VMS 7.3-2 3-node cluster (that I inherited) and I'm wondering if you guys out there in Forum-land can help me. Here are the particulars.

1. Created a new acct and proxies for testing, creating new proxies as follows:

UAF> add/proxy node1::john john/def
add/proxy node2::john john/def
add/proxy node3::john john/def

I notice that when I made this change, for some reason, netproxy.dat got update, whereas I would have expected net4proxy.dat to get updated since we are running decnet phase V.

2. Symptoms:

If I'm logged into user john on 1 of the nodes, and do a $ MONI CLUST, which uses proxies, it returns me info for all 3 nodes as expected BUT if I'm on any of the 3 nodes and do a DIR using the nodename as follows (just to test proxy access):
$ dir node2::sys$manager:, it comes back and gives me a failure with the old "login information invalid atremote node" message.

3. I notice that even though I added the proxies as node::username, when I do a UAF> SHOW/PROXY on that user, it returns it as LOCAL:.node::username username (D)

Does anyone have any idea what may be happening here? Do I perhaps need to do a CONVERT/PROXY or anything like that? The fact that updates are happening against netproxy.dat makes me think maybe one wasn't done when this system was upgraded before I got here?

One of our application programmers says that this problem with proxies has been happening intermittently for around 4 years now since they (the late deceased systems manager) did something with proxies.

Help !

Warren

[Jim_McKinney]

On node2 and node3

$ SET SERVER/SECURITY RESTART

?

[Warren Landrum_1]

Jim,

Thanks for the response.

Obviously the command you suggested restarts the Security Server. What, if any, aderse effects would this have on the cluster or specifically on the other 2 nodes, at the time the command is issued? This is a production cluster.

Also, would you mind giving me a little background/detai on why you think I should do this. I always just like to know a little about WHY I'm doing something before I do it. Thx,

Warren

[Jim_McKinney]

ooops, the syntax that I gave you was incorrect. The command should read

$ set server/restart security

I suggest this since I suspect that these other nodes have prior proxy info cached in their security server processes (pure speculation here). Restarting the servers shouldn't be an issue as it's quick, though there may be a second or so where proxy access may fail.

[Jim_McKinney]

It's been a long time since I had to look at this stuff so I just did a google search to jog my memory. You might take a look at

http://groups.google.com/group/comp.os.vms/browse_frm/thread/1d8c77e07f2da923/ed9bcb6ed4e4f9d1

which seems to mirror your issues? (I would still try just restarting the servers before converting the proxy dbs.)

[Colin Butcher]

You're using LOCAL naming option in Phase V, hence the LOCAL:. prefix.

When you add a proxy the node name is converted to it's fullname before the proxy is added to the database.

So a node synonym of XD123 would get converted to it's fullname, typically LOCAL:.XD123 (assuming a flat namespace).

That's what gets added to the proxy database. That's why 'old' Phase IV proxies such as XD123::FRED FRED stop working - they need to become LOCAL:.XD123::FRED FRED instead. That's part of the proxy database conversion process, provided that you've populated your DECnet Phase V local namespace first and thus the names are available for synonym to fullname resolution.

I always use the infamous command MCR NCL FLUSH SESSION CONTROL NAMING CACHE ENTRY "*" after messing with DECNET_REGISTER before doing anything else. The naming cache (used for name to address resolution) is 'sticky' over reboots and doesn't get flushed except by timer or by explicitly flushing it.

Personally I like to re-create the DECnet node name to address resolution database and the proxy database from scratch by command file - it's a good way to clean things up and only have the stuff you need.

The same synonym to fullname resolution happens with IP style names if you're using DECnet over IP - which is a bit of a nusiance if the machine you're enabling proxies for is on a dynamic IP address...

TCP/IP proxies (for NFS access etc.) are managed through the TCPIP management interface and aren't stored in NETPROXY / NET$PROXY.

Have fun.
Cheers, Colin.

[Volker Halle]

Warren,

for troubleshooting, I would suggest that you enable network logfailure audit alarms and enable your terminal as an operator terminal:

$ set audit/alarm/ena=logfail=network
$ REPLY/ENABLE
$ DIR node1::

This will allow you to see the exact nodename and username causing the login failure. These test may get an additional level of complexity, if a DECnet cluster alias would be involved.

Volker.

[Warren Landrum_1]

Jim,

Tried set server/restart security and that didn't really do anything for me.

Colin and Volker,

Thanks for your suggestions. Will have a go at trying some of that stuff today. Much obliged !

Warren

[Warren Landrum_1]

Volker,

Looks like that additional level of complexity that you mentioned has come to pass. The login failure points to the Remote node fullname as being a Decnet Cluster alias - LOCAL:.TMPCLU.

I am attaching output I received after I enabled network logfail audit alarms.

Here are the particulars.

1. I'm using account LANDRW2 on node PHXAX7.
2. Did DIR of PHXAX6::sys$manager - PHXAX6 is in same cluster (homogenous)

3. TMPCLU is cluster alias that must have been defined before I got here

4. When I do a UAF> SHOW/PROXY/OLD, I see that some proxies still reference TMPCLU::username, although the ones for LANDRW2 show up as LOCAL:.PHXAX3::LANDRW2 and LOCAL:.PHXAX6::LANDRW2. PHXAX3 is the 3rd node in the cluster

5. When I go into NCL and do a SHOW ALIAS ALL, it returns:

Node 0 Alias
at 2006-04-06-09:30:28.030-07:00Iinf

with the creation time being last time this node (PHXAX7) was rebooted back on March 3rd 2006.

Hope I'm not bombarding you with too much info that may not be useful.

Thanks in advance for your help

[Volker Halle · Accepted solution]

Warren,

RMS DECnet remote access (like in the $ DIR node:: command) will use the FAL session control application. By default, this will use the local alias as the local nodename sent with the outgoing DECnet connect.

You could look at this with:

$ MC NCL SHOW SESS CONTROL APP FAL ALL
and change it with
$ MC NCL SET SESS CONT APP FAL OUTGOING ALIAS = FALSE

But it would be better, to add the alias as LOCAL:.TMPCLU::user user/DEF on the remote nodes, because DECnet proxy access would then work from all nodes in the TMPCLU cluster.

Volker.