Conference noted::dnu_osi

2184.0. "World network access to /usr/tmp..." by FORTY2::CLARKE () Wed May 28 1997 12:22

    
    I am seeing the following in relation to a test suite setup,
    and would greatly appreciate any ideas. 
    
    On VMS node A, our test suite does the following when trying
    to access /usr/tmp (which I'll call Unix node B) via DECNET,
    
    $ dir ONEUP2::"/usr/tmp/nclr_1696.out"
    %DIRECT-E-OPENIN, error opening ONEUP2::"/usr/tmp/nclr_1696.out" as
    input ... -RMS-E-FND, ACP file or directory lookup failed
    -SYSTEM-F-INVLOGIN, login information invalid at remote node
    
    However access is available to Unix node C from the same VMS node A.
    Likewise, there seems to be a pattern when /usr/tmp on Unix node
    B is off-limits to remote decnet nodes, whereas /usr/tmp on Unix 
    node C is generally available.
    
    I've checked directory protection of /usr/tmp (which is a link
    to /var/tmp), which is...
    
    lrwxrwxrwx   1 root     system         8 May 28 15:34 tmp -> /var/tmp
    drwxrwxrwx   2 root     system       512 May 28 14:01 tmp
    
    The file protection is the same on both Unix systems. I've also checked 
    for session level proxies using NCL, none exist on either node. There is 
    nothing in hosts.equiv, which I don't think is relevant to Unix anyway.
    
    So, what could be set on Unix node C that is enabling access, which
    isn't set on node B?. The only other thought I had was that maybe
    Inspect is running on node B only?, but if so I wouldn't know 
    specifically what to look for.
    
    Or, is there a way to enable full access to certain trusted systems 
    via DECnet to Unix node B?.
    
    Thanks,
    
    Paul.

    Without specifying a username or password you are using the default
    account for fal.  What does "ncl sho ses con appl fal all" say it
    is?  Does that account exist?  If you are running enhanced security
    you have to enable the account as well.  dnascd can also be somewhat
    verbose about what it's doing, so you might find something helpful
    in the daemon.log file.  --  Vince
    

    
    Vince,
    
    Many thanks - fal was trying to use a non-existant "guest" account. 
    I've remedied this and things are starting to work.
    
    Paul.