Genera 8.1, NFS & my confusion

[razzell%cs.ubc.ca@Warbucks.AI.SRI.COM (Dan Razzell)]

> I was bothered by this at first, but eventually realized that it's
> probably the right thing.
> ...
> [followed by some insightful comments on why things are as they are]

I can go along with the philosophy of maintaining a consistent model
of file access in a given environment.  The thing that stops us again
and again is that the particular model that the Lispm uses does not jive
with the way the rest of the hosts work together on our network.  So,
as a result, I have some problem understanding how our lab benefits from
having an elegant implementation of something that nobody can effectively
use, because it's cut off from our NFS filesystems.  Your comments are no
less valid on that account, but let me take them as a framework for
describing the problems that arise here because of the way Symbolics NFS
has been implemented.

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

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

As a side comment on the operation of NIS, note that even if the network
were configured so that a backbone NIS server could respond to a request,
that server may be too busy to respond.  It is for precisely that reason
that an NIS client is supposed to broadcast its requests, so that whatever
server is available will respond.  So even when the Lispm does manage to
connect transitively, it does so by subverting a mechanism that is intended
to balance server loads.

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

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.

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?