Genera 8.1, NFS & my confusion

[barmar@Think.COM (Barry Margolin)]

    Date: Thu, 17 Oct 1991 17:39 EDT
    From: Dan Razzell <razzell@cs.ubc.ca>

    > 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.

    I agree with your description.  I don't agree that it is a suitable way
    to do NFS, however, since it screws us badly, as it would any site that
    designed its file services around the idea that servers and clients have
    different and fundamentally private information about their role in the
    network.  The filesystems, services, and network connectivity available
    to one host is not transitively available to any host connected to it,
    and it would be naive to think otherwise, as the Lispm guarantees to do.

Yes, the Lispm naively assumes general network access, and can be
screwed by firewalls.

    In our lab, for example, most of the Symbolics distribution resides on
    a fileserver which also happens to be a gateway from our lab subnet as
    well as an NIS slave server.  If the Lispm were to broadcast a request
    for NIS services, as it should by virtue of the way NIS distributed
    service is designed to work, our server would respond and all would be
    well.  Instead, by just the process you describe, the Lispm goes onto the
    server and asks it what its server would be, namely, the NIS master server
    on the backbone.  

Why not have all the NIS servers bind to themselves?  That's what we do.
However, that's a separate issue from your point, since it only solves
the case where the NIS and NFS servers are the same host.  Your point is
valid in any case where the Lispm has access to the NFS server but not
to the NFS server's NIS server.

		      But of course that server is not designed to be visible
    to our subnet, so the Lispm hangs.  The point to take home is that NIS
    services are not transitive, and if the Lispm models them as if they were,
    it will lose in cases where other machines work fine.

Conversely, consider the case of me using NFS to access a file server in
another organization.  Assume I have an account there, but my userid
number is different.

Sun NFS will naively use my local userid when making NFS requests to the
remote server, and I won't be able to access my files properly.  Lispm
NFS asks that system for its NIS domain and server, and does the correct
translation.

We have run into similar problems here, although in our case it was with
the Symbolics NFS server.  We also have a firewall that makes a portion
of our network inaccessible to most of the net.  Someone on a Unix
machine on the restricted net once tried to access a directory on a
Lispm, and it timed out.  The problem was that the Symbolics NFS server
was trying to query the client for its NIS domain and server, so that it
could translate the owner properties to userid numbers, but the firewall
prevented this query from going through.

    > 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.

    Again, this transitivity cannot be depended on.  I'll describe our scenario
    in a moment.  First, I want to remark that it is kind of gross to watch
    while an object-oriented system digs around in a bunch of text files
    trying to extract information that is supposed to be private to another
    host.  Why don't hosts export their root filesystems, you ask?  Why on
    earth should they be expected to?

I *didn't* ask why hosts don't export their root filesystems; I simply
explained that this is the usual cause of trouble.  I went through this
process four years ago when we first started beta-testing what was then
called ILA-NFS.  I had to keep reminding the Unix administrators to
export / when they configured new servers.

    Here is our local situation.  If anyone has any ideas how to make the
    Lispm work here, I'd love to hear from you.  Our Unix home directories
    live on several filesystems residing on several servers.  Unix users
    don't need to know this, because each home directory is available on
    each client on the network as, say, /home/smith, which might be a link to
    /nfs/home1host/home1/smith.  A directory like /nfs/home1host/home1 is the
    obviously the mount point for home1host:/home1.  Host aliases such as
    home1host are used in preference to the official host name so that server
    hosts can be replaced without affecting the abstraction.  I should also
    mention that the fileservers typically do not allow user logins.

    The NIS passwd map gives smith's home directory as /home/smith.  We often
    move users around from one of these home filesystems to another in order
    to balance server loads or filespace usage.  The servers themselves are
    often changed, as mentioned above.  The hosts map, which maps hostnames and
    aliases to Internet addresses, is changed accordingly.  The passwd map is
    not changed except to add and remove users.

    The Lisp Machine can't handle this kind of home directory structure, though
    Unix hosts and NFS in general is quite happy with it.  I can painfully add
    user smith to the namespace to mimic what is already available in the
    passwd map, but when I come to specify the home host to the namespace,
    I see that any value I might supply would be meaningless.  Even if I am
    willing to replace my nice abstraction with something much more brittle,
    the Lispm still fails because it wants to do more than simply mount a
    home directory as an NFS client should.  And of course, the one that
    catches everyone is that I can't specify an arbitrary client as the home
    host, because even though it can use all these filesystems, it is not a
    server for any of them.  The filesystem I want may be several links through
    several remote filesystems away.

It sounds like the following property on some Unix server would work:

	NFS-AUTOMOUNT /nfs -net

This specifies that /nfs/hostname/ corresponds to hostname:/.  Then
specify this Unix server as the home host for your users.  The Lispm
will see /home/smith in the passwd map, then mount /home on the server
and see that /home/smith is a link to /nfs/home1host/home1/smith.  The
above property tells it that /nfs/home1host is a mount point, so it
looks "home1host" up in the hosts NIS map and then mounts
home1host:/home1.

    If I could mount these filesystems on the Symbolics, and create appropriate
    directory links locally, and give something meaningful to the namespace,
    and use the NIS maps more comprehensively, and have the Symbolics play fair
    as an NIS and NFS client, then I think I could actually put users on the
    machine.  Am I missing something obvious?

Where would you put all the "directory links locally"?  In the FEP
filesystem?  That's the only local file system that most Lispms have.
You wouldn't want to put them in your LMFS server, because then you run
into the same transitivity problems that you're complaining about with
Unix servers.

What it sounds like you need is some kind of "virtual" NFS filesystem,
in which you'd make all the mounts.  Indeed, I've often wished I could
just say "NFS:pathname" and have the Lispm do the right thing.

But how would the above solution work in the case of links on NFS
servers that point back to client-dependent ?  Consider the following
filesystem layout:

HOST1 and HOST2 each have a /local filesystem.  They also mount
HOST3:/remote on /remote.  HOST3 has a symbolic link /remote/myname
which points to /local/myname; HOST1:/local/myname contains "host1", and
HOST2:/local/myname contains "host2".

OK, what should a Lispm user get when he tries to read
HOST1:/remote/myname and HOST2:/remote/myname?  The goal of the current
implementation is that the first should contain "host1" and the second
should contain "host2", just as they appear to users on those hosts.
That's what has always happened using the user-mode file protocols such
as QFILE, TFTP, and TCP-FTP, so it's what Lispm users expect.

By the way, the above is where the NFS bug, which is fixed in the ECO,
comes in.  Without the patch, accessing HOST1:/remote/myname would
result in trying to access HOST3:/local/myname.  When the Lispm is
following symlinks, it wasn't interpreting the targets in the context of
the original host.  This caused us problems because we have many such
links where the analogue of HOST3:/local doesn't exist.

You might say, "who cares what that case does -- all we care about is
providing a simple view of the globally-accessible part of the file
system."  That's a valid viewpoint, and we here could also make use of
that simplified view.  But it's not consistent with the Lispm file
system philosophy, which predates NFS by quite a bit.

                                                barmar