brunelli@csd4.csd.uwm.edu (Perry Brunelli) (12/15/89)
We are considering PC-NFS as opposed to Novell in a network lab environment. Question: is it possible to install network version software on a PC-NFS server? The thinking is that network software would handle situations such as writes to temporary files, etc. that would otherwise cause problems when more than a single user loads a software package. Please respond to: brunelli@csd4.csd.uwm.edu
geoff@hinode.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top) (12/15/89)
Quoth brunelli@csd4.csd.uwm.edu (Perry Brunelli) (in <1511@uwm.edu>):
#We are considering PC-NFS as opposed to Novell in a network lab
#environment. Question: is it possible to install network version
#software on a PC-NFS server? The thinking is that network software
#would handle situations such as writes to temporary files, etc. that
#would otherwise cause problems when more than a single user loads a
#software package.
This sounds like overkill. If you have an application which
expects to read/write data files in the same directory where its binaries,
etc. are stored, you can avoid multiple user clashes using
links (hard or symbolic) on the server. The following (long)
posting describes an example.
Suppose you had several users who wanted to use "procomm". (I'm
assuming that you have registered multiple copies: I'm not condoning
piracy here.) Obviously each user wants a private copy of the
configuration file so that they can customize it for their own
purposes. Here's how to do it.
(1) Create a base directory on the NFS server. This is what users will
mount with "net use". In the following example I used "/usr2/public/demo".
(2) Create a directory for the application files and one per user.
%cd /usr2/public/demo
%mkdir apps user1 user2
%ls -l
total 3
drwxrwxrwx 3 geoff 512 Dec 15 08:27 apps
drwxrwxrwx 2 geoff 512 Dec 15 08:32 user1
drwxrwxrwx 2 geoff 512 Dec 15 08:34 user2
(3) Install the application in the "apps" directory.
%ls -l apps
total 209
drwxrwxrwx 2 geoff 512 Dec 15 08:27 dnload
-rw-rw-rw- 1 geoff 2010 Dec 15 08:26 procomm.dir
-rw-rw-rw- 1 geoff 165296 Dec 15 08:26 procomm.exe
-rw-rw-rw- 1 geoff 1366 Dec 15 08:26 procomm.hlp
-rw-rw-rw- 1 geoff 21978 Dec 15 08:26 procomm.hst
-rw-rw-rw- 1 geoff 2025 Dec 15 08:26 procomm.img
-rw-rw-rw- 1 geoff 500 Dec 15 08:26 procomm.key
-rw-rw-rw- 1 geoff 2 Dec 15 08:26 procomm.log
-rw-rw-rw- 1 geoff 631 Dec 15 08:26 procomm.prm
-rw-rw-rw- 1 geoff 256 Dec 15 08:26 procomm.xlt
-rw-r--r-- 1 geoff 0 Dec 15 08:26 qmodem.doc
-rw-r--r-- 1 geoff 0 Dec 15 08:26 qmodem.hlp
(4) Populate each user directory with symbolic links to the
application files. The easiest way to do this is:
%cd user1
%foreach i(../apps)
? ln -s $i `basename $i`
? end
(Yes, I know that the `basename $i` is redundant, but it makes things
clearer.)
(5) Delete the link to the parameter file, "procomm.prm". This
will force "procomm" to recreate it. (Alternatively you could
delete the link and copy the actual file.) Also delete "procomm.log"
if present. This leaves "user1/" looking like this:
%ls -l user1
total 10
lrwxrwxrwx 1 geoff 14 Dec 15 08:28 dnload -> ../apps/dnload
lrwxrwxrwx 1 geoff 19 Dec 15 08:28 procomm.dir -> ../apps/procomm.dir
lrwxrwxrwx 1 geoff 19 Dec 15 08:28 procomm.exe -> ../apps/procomm.exe
lrwxrwxrwx 1 geoff 19 Dec 15 08:28 procomm.hlp -> ../apps/procomm.hlp
lrwxrwxrwx 1 geoff 19 Dec 15 08:28 procomm.hst -> ../apps/procomm.hst
lrwxrwxrwx 1 geoff 19 Dec 15 08:28 procomm.img -> ../apps/procomm.img
lrwxrwxrwx 1 geoff 19 Dec 15 08:28 procomm.key -> ../apps/procomm.key
lrwxrwxrwx 1 geoff 19 Dec 15 08:28 procomm.xlt -> ../apps/procomm.xlt
lrwxrwxrwx 1 geoff 18 Dec 15 08:28 qmodem.doc -> ../apps/qmodem.doc
lrwxrwxrwx 1 geoff 18 Dec 15 08:28 qmodem.hlp -> ../apps/qmodem.hlp
(6) Each user can now run "procomm" in their own private directory with their
own private configuration. If, for example, they start a log of their
session the default log file ("procomm.log") will be created in
their own directory. However all application files (binaries, help text,
etc.) are shared.
Those with sharp eyes will notice that each user directory contains a
link to the "apps/dnload" directory. This shows how you can share
either files or directories using this technique.
Note that each user must NFS mount the base directory (here
"/usr2/public/demo") rather than their own directory. If a user did
inadvertantly mount "/usr2/public/demo/user1" on (say) drive "H:",
PC-NFS would be unable to resolve the symbolic links beginning
"../apps/", since you can't go ".." from the root.... (Remember that
the symbolic link is interpreted on the PC, not on the server.)
Hope this is useful.
Geoff
Geoff Arnold, PCDS Group, | Quote of the week: Too long to include
Sun Microsystems Inc. | here - read "Being an American" by
Internet: geoff@East.Sun.COM | Theodore A.Kaldis, <kaldis@topaz.rutgers.edu>
Disclaimer: Obviously.... | in talk.politics.misc. Quite amazing stuff!