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.