Genera 8.1, NFS & my confusion

[barmar@Think.COM (Barry Margolin)]

    Date: Wed, 16 Oct 1991 19:08 EDT
    From: razzell%cs.ubc.ca@Warbucks.AI.SRI.COM (Dan Razzell)

    What I can say is that Symbolics NFS has an unusual model of how to
    interact with other NFS hosts:

    1) It doesn't broadcast its requests for NIS (Yellow Pages) maps, so the
       ones it gets by copying from a neighboring host are often inappropriate.
       I have a crude workaround for this if you have NFS sources.

I was bothered by this at first, but eventually realized that it's
probably the right thing.  It makes the Lispm interact with NFS servers
outside the local site properly.  Recall that the goal of the Lispm
remote file access model is that when you specify "HOST:pathname", you
should get the file and its attributes as if a user on HOST were
specifying "pathname" locally.  Thus, the Lispm must emulate the HOST's
view of the file system.

Regarding NIS maps, the Lispm has to translate between Unix userid
numbers and user names, since Genera deals only with user names.  I
don't know what you mean by "copying from a neighboring host".
Symbolics NFS asks the NFS server itself what its NIS server and domain
are, and then queries that NIS server.  That way it's guaranteed to do
the translations in the same way as that host.

My only complaint about this mechanism is that it's not smart enough to
realize that all servers for the same domain are equivalent.  It
currently keeps caches of the NIS information, but maintains a separate
cache for each server.  Instead, it should keep a per-domain cache.  The
only problem this could cause is if two sites happen to choose the same
NIS domain name, and a Lispm user accesses servers in both domains; this
seems unlikely, since sites on the Internet are likely to use their DNS
domain name as their NIS domain name (many system administrators don't
even realize that these are completely unrelated uses of the word
"domain", and assume that the NIS domain must be the same as the DNS
domain -- the NIS domain is actually much more like the Genera namespace
notion of "site").

    2) It will try to mount a filesystem through another host instead of
       making the mount request to the server of that filesystem.  This is
       the problem you describe.  It sounds like the 8.1 ECO #1 NFS patches
       are supposed to address this.

This is not the problem that the ECO fixes.  If you get the "Too many
levels of remote in path" error, it indicates a configuration error.

Symbolics NFS tries to figure out where a filesystem actually resides
and mount it from the correct server.  Its usual mechanism is to read
the /etc/mtab (or /etc/fstab on Ultrix) file on the host you specify, to
learn where that host mounts the filesystem.  The most common cause of
the above error is that the root filesystem isn't exported, so the Lispm
can't read /etc/mtab; if /etc isn't accessible to the Lispm, you can put
NFS-REMOTE-FILESYSTEM properties in its namespace entry to provide this
information.  You can also specify NIS maps in NFS-AUTOMOUNT properties
(the Unix host doesn't even have to be running the automounter -- this
property just tells the Lispm how to emulate the automounter if it were
running).

I'm not sure how they could have done this any other way, and still fit
into the Genera remote file system model of HOST:pathname.  It could
have been much worse: they could have required users to specify the
actual physical host name in all NFS pathnames, and not automatically
followed remote NFS mounts.  But in order to emulate the remote host's
mounts, Genera has to be able to find out what its filesystem layout is.
In my experience, it does a damn fine job.

    3) Compounding this is the matter of the Symbolics namespace having to be
       maintained separately from the NIS maps and being unable to defer to
       them.  That is not a problem with the NFS implementation per se, just an
       unpleasant fact of life.

In fact, NFS often *does* defer to NIS maps.  When interpreting host
names in /etc/mtab and automount maps it will query the NIS hosts map in
order to interpret it as the server would.

As for the rest of Genera, yes, it's sometimes a pain that we must
maintain a parallel database of hosts, users, and printers.
Unfortunately, NIS doesn't provide all the information that Genera
needs.  For instance, there's no OS and service information in the NIS
hosts map, which are necessary for Genera's feature of automatically
choosing the most appropriate protocol for a service (I've got an
enhancement to this feature that allows me to specify global and per-OS
default service entries, so that I don't have to repeat information in
every namespace entry, but this makes the OS information even more
important).  Or do you prefer Unix's method of requiring the *user* to
choose between telnet, rlogin, supdup, etc.?

                                                barmar