NFS client (TCPIP MOUNT) requires fully qualified host name?

[sms]

Code: Select all

   While trying to use the NFS client on this:

ITS $ tcpip show version

  HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.7 - ECO 5
  on an HP rx2600  (1.50GHz/6.0MB) running OpenVMS V8.4-2L3

I ran into an unexpected problem, where TCPIP MOUNT seems to require a
fully qualified host name to work properly.

ITS $ type mount_nfs_nfq.com   ! The non-fully-qualified script.
$ tcpip mount DNFS11:[its] -
   /host = myclex4101 -
   /path = "/nfs/its" -
   /automount -
   /structure = 5
ITS $ 

ITS $ tcpip dismount /all
ITS $ 

ITS $ @ mount_nfs_nfq.com   ! The non-fully-qualified attempt.
%TCPIP$DNFSMOUNT-S-MOUNTED, /nfs/its mounted on _DNFS11:[ITS]

   Looks good to me, but:

ITS $ dire DNFS11:[ITS]
%DIRECT-E-OPENIN, error opening DNFS11:[ITS]*.*;* as input
-RMS-E-DNF, directory not found
-SYSTEM-F-NOSUCHNODE, remote node is unknown

ITS $ tcpip dismount /all
%TCPIP$DNFSDISMOUNT-S-DISMOUNTED, _DNFS11:[ITS] dismounted
ITS $ 

ITS $ gdiff mount_nfs_nfq.com mount_nfs_fq.com
2c2
<    /host = myclex4101 -
---
>    /host = myclex4101.antinode.info -

ITS $ @ mount_nfs_fq.com   ! The fully-qualified attempt.
%TCPIP$DNFSMOUNT-S-MOUNTED, /nfs/its mounted on _DNFS11:[ITS]

   Looks the same to me, but:

ITS $ dire DNFS11:[ITS]
%DIRECT-W-NOFILES, no files found

   The directory is empty, so that's the expected result.

ITS $ show symbol nslookup
  NSL*OOKUP == "$ SYS$SYSTEM:TCPIP$NSLOOKUP.EXE"

ITS $ nslookup myclex4101
Server:  its.antinode.info
Address:  10.0.0.140

Name:    myclex4101.ANTINODE.INFO
Address:  10.0.0.163

ITS $ nslookup myclex4101.antinode.info
Server:  its.antinode.info
Address:  10.0.0.140

Name:    myclex4101.antinode.info
Address:  10.0.0.163

   A different service doesn't care:

ITS $ telnet myclex4101
%TELNET-I-TRYING, Trying ... 10.0.0.163
%TELNET-E-CONNFAIL, Failed to connect to remote host
-SYSTEM-F-REJECT, connect to network object rejected

ITS $ telnet myclex4101.antinode.info
%TELNET-I-TRYING, Trying ... 10.0.0.163
%TELNET-E-CONNFAIL, Failed to connect to remote host
-SYSTEM-F-REJECT, connect to network object rejected


   It's not obvious to me that the fully qualified name should be
required.  Many of the TCPIP HELP MOUNT Examples examples show
non-fully-qualified names.

   The results are similar here:

V87 $ tcpip show version

  VSI TCP/IP Services for OpenVMS x86_64 Version X6.0
  on a VMware, Inc. running OpenVMS E9.2    

(If I set the date back to accommodate the expired PAKs.)

   The NFS server is a Western Digital My Cloud EX4100.  I haven't yet
tried any others.

[volkerhalle]

Steven,

similar behaviour here:

VSIAXP $ tcpip sho vers

HP TCP/IP Services for OpenVMS Alpha Version V5.7 - ECO 5
on an AlphaServer DS20E 67/667 running OpenVMS V8.4-2L2

VSIAXP $ ucx sho host axpvms

BIND database

Server: 10.20.30.10

Host address Host name

10.20.30.203 AXPVMS.invenate.local

VSIAXP $ tcpip mount dnfs:/host=axpvms/path="/vms_nfs/nfs"
%TCPIP$DNFSMOUNT-E-MOUNTFAIL, error mounting _DNFS11:[000000]
-SYSTEM-F-NOSUCHNODE, remote node is unknown
VSIAXP $ tcpip mount dnfs:/host=axpvms.invenate.local/path="/vms_nfs/nfs"
%TCPIP$DNFSMOUNT-E-MOUNTFAIL, error mounting _DNFS12:[000000]
-SYSTEM-F-NOPRIV, insufficient privilege or object protection violation

VSIAXP $ ucx set host "axpvms"/addr=10.20.30.203
VSIAXP $ tcpip mount dnfs:/host=axpvms/path="/vms_nfs/nfs"
%TCPIP$DNFSMOUNT-E-MOUNTFAIL, error mounting _DNFS13:[000000]
-SYSTEM-F-NOPRIV, insufficient privilege or object protection violation

Something to do with case sensitivity ?

Volker.

[debbee.west]

This behavior has been with us for awhile. If you are using the simple name, TCPIP mount only looks in the localhost table. If you use the FQDN, then the BIND server will be called. Engineering is aware of this and will review this behavior.

Thank you for reporting this issue.

Debbee West

[sms]

Code: Select all

> This behavior has been with us for awhile. [...]

   Thanks for the explanation.  Clearly, unless someone has a good
reason for the difference, it would make more sense to me if the NFS
stuff used the same name-resolution scheme as every(?) other service.

Added in 4 hours 21 minutes 33 seconds:

Code: Select all

   From the success of the TCPIP MOUNT command, and the failure of the
actual file access, I'd infer that TCPIP MOUNT just records the useful
data without checking them, and some other software (FCP?) does the
actual action which fails.  The results are the same
(%TCPIP$DNFSMOUNT-S-MOUNTED for the MOUNT, and -SYSTEM-F-NOSUCHNODE for
the file access) for a nonexistent host as for a valid non-FQDN.

   It might be helpful if TCPIP MOUNT did a basic check on the stuff
before declaring success.  Perhaps emit a warning if the host lookup
fails?  Presumably the host-lookup situation could improve between TCPIP
MOUNT and some actual attempt at file access, so a worse-than-W status
might be inappropriate, but even an informational would be more helpful
than quiet success.

   Of course, I haven't seen the code, so I don't know how hard this
would be to arrange.

[sms]

Code: Select all

> [...]  If you are using the simple name, TCPIP mount only looks in the
> localhost table. [...]

   Does this apply to NFS proxies, too?  (Until someone fixes it, that
is?)

   That possibility dawned on me when I was having unexpected
ownership/permission problems.  I was about to run the experiment, but
when I tried to REMOVE+ADD the proxy-of-interest(there being no
MOFDIFY?), I got some unexpected complaints:

ITS $ tcpip
TCPIP> show proxy BACKUP
 
VMS User_name     Type      User_ID    Group_ID   Host_name
                                                   
BACKUP            OD           1000        1000   MYCLEX4101

TCPIP> remove proxy backup /nfs = O   ! (That's a letter "O".)
%TCPIP-E-PROXYERROR, error processing proxy request
-TCPIP-E-INVQUAL, invalid qualifier value for /NFS Incoming or Outgoing

   "/nfs = O" had worked as I'd expected for ADD.

TCPIP> remove proxy backup /nfs = Outgoing
%TCPIP-E-PROXYERROR, error processing proxy request
-TCPIP-E-INVQUAL, invalid qualifier value for /NFS Incoming or Outgoing

   At least one of us is confused.

TCPIP> remove proxy backup /nfs           
 
VMS User_name     Type      User_ID    Group_ID   Host_name
                                                   
BACKUP            OD           1000        1000   MYCLEX4101
Remove? [N]:y
%TCPIP-E-PROXYERROR, error processing proxy request
-TCPIP-E-INVQUAL, invalid qualifier value for /NFS or COMMUNICATION
-TCPIP-I-PROXYINFO, User: BACKUP, UID:       1000, HOST: MYCLEX4101

   That complaint seems a bit late (as well as confusing) to me.

TCPIP> remove proxy backup   ! Not everything fails...
 
VMS User_name     Type      User_ID    Group_ID   Host_name
                                                   
BACKUP            OD           1000        1000   MYCLEX4101
Remove? [N]:y
TCPIP> 

   Note that ADD PROXY seems to be more easily satisfied:

TCPIP> add proxy backup /nfs = O /uid = 1000 /gid = 1000  -
 /host = "myclex4101.antinode.info"

TCPIP> show proxy BACKUP
 
VMS User_name     Type      User_ID    Group_ID   Host_name
                                                   [<-- Note useless spaces.]
BACKUP            OD           1000        1000   myclex4101.antinode.info

Added in 5 hours 52 minutes 29 seconds:

Code: Select all

   Also, as I stumble around trying to guess just which credentials
(UID, GID) are being sent from the client to the server in different
scenarios, I wonder if are there any diagnostics available in TCPIP
which would be more convenient to use than, say, Wireshark, in such a
situation.

[debbee.west]

I guess I am a little confused. We were talking about NFS client. Proxies will use either the local host table or the BIND/DNS server. Local host table has priority.

If you want to see what UID/GID your client is sending over, well, honestly, i have never had any reason to not trust the proxies. But, you would want to run a TCPdump/TCPTRACE.

If you are running NFS server, you can turn on opcom, have the client make the connection. You will see that how the host comes over - IP address, simple name or FQDN. You will also see the UID/GID being passed. This would help you determine how to configure your proxy(s).