Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!pilchuck!ssc!rolls!attdso!tim
From: tim@attdso.ATT.COM (Tim J Ihde)
Newsgroups: comp.unix.wizards
Subject: Re: RFS Questions
Summary: Don't do it!
Message-ID: <577@attdso.ATT.COM>
Date: 6 Sep 88 15:23:31 GMT
Article-I.D.: attdso.577
References: <793@mccc.UUCP>
Reply-To: tim@attdso.UUCP (Tim J Ihde)
Distribution: na
Organization: AT&T Data Systems Organization HQ
Lines: 49

In article <793@mccc.UUCP> pjh@mccc.UUCP (Peter J. Holsberg) writes:
>
>I'm running RFS over a STARLan network between two 3b2/400s, and I would
>like to make the bin directories of the host machine available to the
>users on the other.  I'm thinking that I should mount /bin on one point,
>/usr/bin on a second, and /usr/local/bin on a third, and then add
>/pt1/bin, /pt2/usr/bin, and /pt3/usr/local/bin to everyone's PATH.  Will
>this work?

Mounting /bin through the network would be a BIG MISTAKE!!

Consider: about the last thing your machine will do on boot-up will be to
start up RFS.  Before this occurs lots of useful programs will be run in
your /etc directory (and elsewhere) - a good portion of which are shell
scripts.  Uh oh, we can't run any shell scripts because /bin/sh isn't there
because RFS isn't up yet.

I've seen this type of problem a couple of times when people decide
something like "wow, this ksh is really great so I'll make
/usr/local/bin/ksh the default shell for root."  Also a problem when
/usr/local isn't mounted yet.

Remote mounting /usr/local is not a bad idea, since there shouldn't be anything
there necessary to run the system.  There isn't supposed to be anything
necessary in /usr/bin either, but I'd leave that if I were you.  If you
ever need to fix something you might want some of those programs (like vi).

> Will the C compiler on the host find the include files on
>the host and #include them with C source on the client?  The libraries, too?

Not unless you tell the compiler where these file are.  By default, my cpp
will look in /usr/include for #included files unless told otherwise via
the -Y or -I options (System V C Compilation System, Issue 4.2 4/29/87; your
mileage may vary).  Alternatively, you could just wipe out the contents
of your local /usr/include directory and mount the remote /usr/include under
that name.  Then no compiler options would be necessary since everything is
where it is expected to be.  I've done this with some extra troff libraries
and it works fine - in fact our /usr/spool/news is mounted this way by
several other machines.

Similar for /lib.

>Pete Holsberg                   UUCP: {...!rutgers!}princeton!mccc!pjh

	tim
-- 
Tim J Ihde					att!attdso!tim
(201) 898-6687					tim@attdso.att.com
This disclaimer intentionally left blank.  	attmail!tihde