topic Re: DECNET in Operating System - OpenVMS

DECNET

Tim Pride — Wed, 14 Mar 2007 04:49:56 GMT

How do I make unrestricted access between nodes,
eg. at the moment I can do the following :
DIR NODE"user pass"::DISK:[dir] but I need to be able to DIR NODE::DISK:[dir], when I try I get a message saying no priv. or object prot. violation.
I have read the manual I think I need to alter the defaults that were setup when I created the three node network, but which and how.
Thanks for any help.

Re: DECNET

Volker Halle — Wed, 14 Mar 2007 05:02:41 GMT

Tim,

you need to set up DECnet PROXIES to allow access to the other nodes without specifying username and password.

Assuming you are logged in on NODE1 as USER1 and want to access files on NODE2 with the same username (USER1). You need to create a proxy on NODE2:

UAF> ADD/PROXY NODE1::USER1 USER1/DEFAULT

Volker.

Re: DECNET

Karl Rohwedder — Wed, 14 Mar 2007 05:03:40 GMT

Tim,

if you just want to skip the user/pass string, you can setup proxies between the nodes for specific users (MCR AUTHORIZE ADD/PROX).

Or if you want to setup an all accessible directory you can configure decnet to use a default access (using NET$CONFIGURE). This is done via object FAL, which normally runs under an username of FAL$SERVER, so the user FAL$SERVER should have access to DISK:[DIR].

You can check for FAL with:
- DECNet IV: MC NCP SHO OBJ FAL
- DECnet V: MC NCL SHO SESS CON APPL FAL ALL ATTR

regards Kalle

Re: DECNET

Robert Gezelter — Wed, 14 Mar 2007 05:27:33 GMT

Tim,

When configuring this type of access, please consider with care the security implications. Enabling global access via DECnet to all users is, at least potentially, the same as removing all file protections throughout the system.

Proxies are a fine way to achieve the functionality within limits. You will find a full description of the security implications in the Guide to System Security (available in the online documentation set at http://www.hp.com/go/openvms ).

If the three nodes comprise an OpenVMS cluster, then mounting devices clusterwide is the better option.

I hope that the above is helpful.

- Bob Gezelter, http://www.rlgsc.com

Re: DECNET

Wim Van den Wyngaert — Wed, 14 Mar 2007 05:46:55 GMT

Or consider SSH which avoids security risks.

Wim

Re: DECNET

Tim Pride — Wed, 14 Mar 2007 05:51:29 GMT

Hi Guys,
thanks for quick response, I have tried the proxy approach first as it seemed the quicker method, so I have made proxies on all nodes, uaf no error, but it still doesn't work, except I can now dir node1:: while being on node1 which was not possible before. On my eldest node where decnet was already setup I found the FAl$server.exe but on the other nodes which I setup the command gave an error, I have an bad feeling I have not set up the decnet correctly, but I can set host and dir (user pass) works.

Re: DECNET

Volker Halle — Wed, 14 Mar 2007 05:55:20 GMT

Tim,

you need to provide more details about VMS and DECnet versions (Phase IV or Phase V), which command you tried and what the error message was...

Volker.

Re: DECNET

Tim Pride — Wed, 14 Mar 2007 07:04:06 GMT

There are three nodes an old one which I am phasing out. Old node vms7.2-2 decnet 7.2-1, show net gives full listing idents, status etc.. net type DNA V, the two newer nodes run VMS 7.3-2 and decnet 7.3-2 net type DNA V, but when I show net/full decnet I get header detail but only errors after that, such as CMLSENFAILED, ACCESSDENIED and EMAAPROB .... error returned from vms ema agent.
These nodes I set up decnet with net$configure and as local, its supposed to run over tcpip, its looking more and more that I have not configured correctly, I thought net$configure did it all?

Re: DECNET

Wim Van den Wyngaert — Wed, 14 Mar 2007 07:09:13 GMT

When I remove BYPASS from my privs and do show net/fu, I also get ACCESSDENIED and the other messages.

Wim

Re: DECNET

Wim Van den Wyngaert — Wed, 14 Mar 2007 07:12:50 GMT

But not when I'm logged in as SYSTEM without bypass. My previous test was done with [7,3] where maxsysgroup is 7.

Wim

Re: DECNET

Volker Halle — Wed, 14 Mar 2007 07:14:11 GMT

Tim,

you need privs or the following identifier:

NET$EXAMINE - Permits display of the attributes of an entity

Trying to set up proxies with DECnet-over-IP can get tricky, especially if the underlying DECnet configuration has not been properly verified to work.

Consider enabling security alarms on the destination nodes and interpret the alarms you'll get, if the remote access does not work.

Volker.

Re: DECNET

Wim Van den Wyngaert — Wed, 14 Mar 2007 07:19:15 GMT

You need identifier net$examine but because I use bypass, I don't need it. System had it.

Wim

Re: DECNET

Tim Pride — Wed, 14 Mar 2007 08:15:53 GMT

I assume I add the identifier net$examine to user decnet or to the user i am trying to work with? In fact the user decnet does not exist on one of my nodes, so is it created by the net$configure ?

Re: DECNET

Ian Miller. — Wed, 14 Mar 2007 08:50:15 GMT

add net$examine to the username you are using.

Re: DECNET

Tim Pride — Wed, 14 Mar 2007 09:07:56 GMT

Sorry, I have added the ident. but I do not see how this helps me, I have the same problems as before. I am getting desperate.

Re: DECNET

Tim Pride — Wed, 14 Mar 2007 09:44:58 GMT

I have tried to set logging, I get ncp-w-sysmgt - system specific management not supported, so how can I monitor the node.

Re: DECNET

Hoff — Wed, 14 Mar 2007 11:43:46 GMT

Using AUTHORIZE in your SYSUAF, establish the following DECnet proxies:

UAF> ADD/PROXY remnode::remuser localuser /DEFAULT

Assuming no cluster, you'll need this on each node that will receive an incoming connection, and the localuser is the username with sufficient access to allow access. You can wildcard the remuser, if you trust the remote node.

If you have a cluster, mount the disks and go direct.

The most common failure with the DECnet proxy processing involve omitting the /DEFAULT, or with a node that does not have the name of the incoming node configured in its local database.

In the case of the latter, you can see what nodename or node number is used by issuing a valid username and password string in an access such as the following:

DIRECTORY remnode"user pwd"::

And then looking in the NET*SERVER.LOG file that gets created on remnode::. If you see numbers or such, or a name that does not match what you expect, you can use the DECNET_REGISTER tool to register the node name on DECnet-Plus (Phase V, DECnet/OSI), and you can use the NCP commands SET and then DEFINE NODE x.y NAME nodnam. On each node.

Also make sure you're on the right end of the connection when you're configuring stuff, or looking for a log file. The DECnet proxies and log files are on the node that is receiving the connection, for instance. This can easily get confusing.

And whenever there's a cluster involved, also ensure that all members of the cluster have the same username and password for the incoming usernames in DECnet and the DECnet proxy database, and ensure that the SYSUAF, RIGHTSLIST, NETPROXY, NET$PROXY, and the other twenty files (see SYLOGICALS.TEMPLATE) are configured and correctly shared across all nodes. But again, if there's a cluster involved, just mount the disks and go directly.

To troubleshoot the privilege-related errors, ensure security auditing or security alarms are enabled, and look in the audit file with ANALYZE/AUDIT or use REPLY/ENABLE to look at the alarms. The audit or alarm will be on the node receiving the incoming connection, and will typically indicate details of failed and triggered the NOPRIV error, and usually why.

Stephen Hoffman
HoffmanLabs

Re: DECNET

Colin Butcher — Thu, 15 Mar 2007 02:27:46 GMT

As a quick hack only to prove that proxy processing is working you could set up proxies on each node as follows:

UAF> ADD/PROXY *::TIM TIM /DEFAULT

Because we're using wildcard here that gets past some of the Phase IV / Phase V differences in name lookups - it's ause ful test, but not a good solution because it's not very secure (much worse is *::SYSTEM SYSTEM/DEFAULT!).

If that works, then you can tighten them up to:

on Node1:

UAF> ADD/PROXY NODE2::TIM TIM /DEFAULT
UAF> ADD/PROXY NODE3::TIM TIM /DEFAULT

on Node2:

UAF> ADD/PROXY NODE1::TIM TIM /DEFAULT
UAF> ADD/PROXY NODE3::TIM TIM /DEFAULT

on Node3:

UAF> ADD/PROXY NODE1::TIM TIM /DEFAULT
UAF> ADD/PROXY NODE2::TIM TIM /DEFAULT

Assuming that it's Phase V (which it looks like), then to erase any naming wierdness it's worth flushing the naming caches on each node with NCL> FLUSH SESSION CONTROL NAMING CACHE ENTRY "*".

It's also worth checking that FAL (File Access Listener) has proxy access enabled (NCL> SHOW SESSION CONTROL APPLICATION FAL ALL, OR NCP SHOW OBJECT FAL, or something like that - I'm in a hotel and working from memory at the moment).

All of the above will apply whether it's a cluster or not, except that in a cluster you would usually have a single common UAF / RIGHTSLIST and so on.

If you're wrestling with Phase V and have time for some background reading then you might find this useful: http://h71000.www7.hp.com/openvms/journal/v5/decnet.pdf

Come to the "bootcamp" in May if you can: http://h71000.www7.hp.com/symposium/index.html?jumpid=symposium

Cheers, Colin (www.xdelta.co.uk).

Re: DECNET

Tim Pride — Thu, 15 Mar 2007 05:58:03 GMT

Thanks Guys, I am in a better position than when I opened this discussion thanks to you all. There are still a few problems but they are not holding me up, they are just tunning, I hope.
:-)