tim@attdso.ATT.COM (Tim J Ihde) (09/06/88)
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
pjh@mccc.UUCP (Pete Holsberg) (09/08/88)
In article <577@attdso.ATT.COM> tim@attdso.UUCP (Tim J Ihde) writes: ...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 think we have a miscommunication. I didn;t intend to mount /bin of the server on /bin of the client. ...> 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. I made a script with cc and a bunch of -Y options, but if mounting server's /usr/include on client's /usr/include and mounting server's /lib on client's /lib will do the trick, I will go that route as it seems a cleaner approach. You're saying that all header files and all libraries will be accessible by cc that way? Many thanks. Pete
tim@attdso.ATT.COM (Tim J Ihde) (09/12/88)
In article <809@mccc.UUCP> pjh@mccc.UUCP (Pete Holsberg) writes: >I made a script with cc and a bunch of -Y options, but if mounting >server's /usr/include on client's /usr/include and mounting server's >/lib on client's /lib will do the trick, I will go that route as it >seems a cleaner approach. You're saying that all header files and all >libraries will be accessible by cc that way? Yes - just be careful when installing new packages that put stuff in /lib or /usr/lib (such as informix). Make sure you know where they are going (esp. if you mount the rfs'ed filesystem read only). As long as you can look at /lib or /usr/include, and see the files there that are supposed to be there, then the compiler will find them too. The fact that they are RFS'ed should be invisible. >Many thanks. You're welcome. tim -- Tim J Ihde att!attdso!tim (201) 898-6687 tim@attdso.att.com This disclaimer intentionally left blank. attmail!tihde