| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 147.1 | Try using node names, not alias | RICKS::OPP | | Wed Feb 05 1997 22:14 | 7 |
| As I recall from struggling with UAF proxies a couple years
back, some applications present themselves as ALIAS::USERNAME but
most present as NODE::USERNAME. Things may have changed since then,
but I'd start by avoiding the cluster alias.
Greg
|
| 147.2 | | AUSS::GARSON | DECcharity Program Office | Wed Feb 05 1997 22:29 | 19 |
| re .0
Whether the initiating node presents the cluster alias is a function of
the outbound object's definition.
$ NCP SHOW OBJ FAL CHAR
Number = 17
File id = FAL.EXE
User id = DIFFERENTLY_ABLED
Proxy access = incoming and outgoing
Alias outgoing = Enabled
should mean that a remote file access request originating on this node
will send this node's cluster alias and this needs to be taken into
account on the remote node if the remote node is going to define a proxy.
Needless to say that proxies themselves need to be enabled (which can
be set on the EXECutor and on the object and I believe the object
overrides the executor).
|
| 147.3 | Is this V6.1 by any chance? | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Thu Feb 06 1997 03:25 | 7 |
| What OpenVMS version is this? Since you mention Cluster Aliases, I
presume there must be more than one node involved at aeach end of the
copy. Are all the nodes in each cluster VAXs or all Alphas? In OpenVMS
V6.1, there was a small problem that only the VAX version knew about
the new proxy file NET$PROXY.DAT, so if you added a proxy from one of
the Alpha nodes, it would only be updtaed in the old file,
NETPROXY.DAT, and so the VAX wouldn't be able to see it.
|
| 147.4 | Questions, No Answers... | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Thu Feb 06 1997 09:29 | 35 |
| : All inputs would be greatly appreciated.
o Please post the OpenVMS versions, if this is DECnet Phase IV
or DECnet-Plus, or a mix, and if this VMScluster has one or
(unsupported) more SYSUAF files around.
o Please post the full error message(s).
o Enable and use security auditing (alarms) for the login and
login failures, and for protection problems. Alarms are an
invaluable tool for detecting various security-relevent
problems.
o Always check for a NETSERVER.LOG file -- without knowing
the full error message(s) reported, it's certainly possible
the process *has* logged in, and there's something else
that's causing the "%COPY-E-OPENOUT" error... And that
`something else' often shows up in NETSERVER.LOG.
o Always check for break-in evasion -- intrusion records can
(correctly) prevent an otherwise valid login from being
accepted.
o Please confirm that the DECnet node(s) involved all have
the node names present in the database -- proxies will
fail to match existing proxy records when the text name
is listed in the proxy, and the numeric address is used
on the login. (This is usually a result of the failure
to define/register/etc the alias name and/or the node
name in the DECnet database...)
o Check the UAF record for access settings that may prevent
the login. (network prohibitions, bad device or directory
settings, etc.)
|
| 147.5 | need ECO kits? | COMEUP::SIMMONDS | lock (M); while (not *SOMETHING) { Wait(C,M); } unlock(M) | Thu Feb 06 1997 19:29 | 4 |
| You probably need to install the ALPLOAD02 ECO kit on the Alpha node(s)
and VAXLOAD02 ECO kit on the VAX node(s)
John.
|
| 147.6 | Feed back for notes .2 .4 .5 | YIELD::DELAHUNTY | | Fri Feb 07 1997 21:10 | 118 |
| Been trying some of the suggestion (thanks!)
====================================================
TRIED inputs from note input 147.2
====================================================
AXP side
---------------
NCP>show obj fal char
Object Volatile Characteristics as of 7-FEB-1997 20:01:10
Object = FAL
Number = 17
File id = FAL.EXE
User id = FAL$SERVER
*Proxy access = incoming and outgoing
*Alias outgoing = Enabled
* = added/mod to current state
Still no luck :-(
====================================================
Inputs for note input 147.4
====================================================
> o Please post the OpenVMS versions, if this is DECnet Phase IV
> or DECnet-Plus, or a mix, and if this VMScluster has one or
> (unsupported) more SYSUAF files around.
AXP side
------------------------------
OpenVMS V6.2-1H2
(ALPHA cluster only not mixed)
*** EXECUTOR CHARACTERISTICS ***
Identification = DECnet for OpenVMS AXP V6.2
Management version = V4.0.0
Incoming timer = 45
Outgoing timer = 60
Incoming Proxy = Enabled
Outgoing Proxy = Enabled
NSP version = V4.1.0
Type = nonrouting IV
Nonprivileged user id = DECNET_DEFAULT
Nonprivileged password = INVALID
Default access = incoming and outgoing
Alias incoming = Disabled
VAX side
---------------------------------
OpenVMS V6.2
(VAX cluster only not mixed)
*** EXECUTOR CHARACTERISTICS ***
Identification = DECnet for OpenVMS VAX V6.1
Management version = V4.0.0
Incoming timer = 120
Outgoing timer = 120
Incoming Proxy = Enabled
Outgoing Proxy = Enabled
NSP version = V4.1.0
Type = routing IV
Nonprivileged user id = DECNET_DEFAULT
Nonprivileged password = INVALID
Default access = incoming and outgoing
Alias incoming = Enabled
> o Please post the full error message(s).
$ copy TEST.TXT;1 yield::[yes]
%COPY-E-OPENOUT, error opening YIELD::[YES]TEST.TXT;1 as output
-RMS-E-DNF, directory not found
-SYSTEM-W-NOSUCHFILE, no such file
%COPY-W-NOTCOPIED, USER1$:[HP_TEST_SYS]TEST.TXT;1 not copied
> o Always check for a NETSERVER.LOG file -- without knowing
> the full error message(s) reported, it's certainly possible
> the process *has* logged in, and there's something else
> that's causing the "%COPY-E-OPENOUT" error... And that
> `something else' often shows up in NETSERVER.LOG.
--------------------------------------------------------
Connect request received at 7-FEB-1997 19:59:16.33
from remote process ACAR::"0=HP_TEST_SYS"
for object "RAMDISK1:[SYSEXE]FAL.EXE"
--------------------------------------------------------
--------------------------------------------------------
Connect request received at 7-FEB-1997 20:02:05.58
from remote process ACAR::"0=HP_TEST_SYS"
for object "RAMDISK1:[SYSEXE]FAL.EXE"
--------------------------------------------------------
FAL$SERVER job terminated at 7-FEB-1997 20:07:05.86
Accounting information:
Buffered I/O count: 196 Peak working set size: 3964
Direct I/O count: 89 Peak page file size: 10902
Page faults: 7769 Mounted volumes: 0
Charged CPU time: 0 00:00:01.57 Elapsed time: 0 00:07:52.57
> o Always check for break-in evasion -- intrusion records can
> (correctly) prevent an otherwise valid login from being accepted.
%SHOW-F-NOINTRUDERS, no intrusion records match specification
> o Please confirm that the DECnet node(s) involved all have
> the node names present in the database -- proxies will
> fail to match existing proxy records when the text name
> is listed in the proxy, and the numeric address is used
> on the login.
All node involved are define....
> o Check the UAF record for access settings that may prevent
> the login. (network prohibitions, bad device or directory
> settings, etc.)
Account on recieving side (VAX) access settings are fine. There
are "no access restrictions" with the account.
====================================================
Will investagate input for 147.5
====================================================
I will also find out if the ALPLOAD02 ECO kit was installed...
|
| 147.7 | | AUSS::GARSON | DECcharity Program Office | Sun Feb 09 1997 18:34 | 32 |
| re .6
> AXP side
> *** EXECUTOR CHARACTERISTICS ***
I would expect to see "Alias node" in there and also I found that I
needed to have "Type = Routing IV" in order to get an Alpha to have a
cluster alias. That in turn (I think) requires a different DECnet licence.
It looks as if the proxy is not working. To be sure you should disable
the default access to FAL on the VAX (incoming side). It's a security
risk anyway. Having done this, you should find that the COPY fails with
"invalid login info..." and you can then use security audit/alarm or
accounting to track this further.
> AXP side
> ---------------
> NCP>show obj fal char
Wouldn't mind seeing this for the receiving side...
Do we get to see the proxies defined on the VAX? All of them would be
better but if there are many unrelated ones then just the ones you
think are relevant.
> $ copy TEST.TXT;1 yield::[yes]
This command is unusual in that it doesn't specify a disk. It would
seem that if the proxy worked, you are assuming that there is a
directory [YES] that happens to be on the same disk as the home
directory of the VAX account to which the Alpha account has a proxy.
However since the proxy doesn't seem to be working this is academic.
|
| 147.8 | Proxy Environment Questions... | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Mon Feb 10 1997 09:18 | 16 |
|
Please confirm you are running OpenVMS VAX V6.1 and OpenVMS Alpha V6.2,
and please confirm that you do not have any prior OpenVMS versions on
either platform in use in the VMScluster.
Please post the output of:
$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> SET ENVIRONMENT/CLUSTER
SYSMAN> DO SHOW LOGICAL NET*PROXY/FULL
SYSMAN> DO DIRECTORY NETPROXY/FILE
SYSMAN> DO DIRECTORY NET$PROXY/FILE
and please provide us the specific component filename of the system
startup procedure where the NET*PROXY logical names have been defined.
|
| 147.9 | just to confuse the Russians? | AUSS::GARSON | DECcharity Program Office | Mon Feb 10 1997 19:25 | 4 |
| re .6,.8
Note that DECnet under VAX VMS V6.2 appears to misidentify itself as
V6.1.
|
| 147.10 | DECnet Version Does Not Track OpenVMS Version | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Tue Feb 11 1997 16:06 | 7 |
| : re .6,.8
:
: Note that DECnet under VAX VMS V6.2 appears to misidentify itself as
: V6.1.
And OpenVMS Alpha V7.0 and V7.1 identify as V6.2.
This is why I asked for the confirmation. :-)
|