newbie nfs question
I want to try to run scribus and inkscape by not installing them on our clients and exporting via nfs. The binaries are in /usr/bin on our server. What do I export from the server to the clients (who already have a /usr/bin) and where do I mount it on the clients so it's in their path? Or maybe I'm asking for too much. Lan with all on 9.2. cheers, Steve.
steve wrote:
I want to try to run scribus and inkscape by not installing them on our clients and exporting via nfs. The binaries are in /usr/bin on our server. What do I export from the server to the clients (who already have a /usr/bin) and where do I mount it on the clients so it's in their path? Or maybe I'm asking for too much. Lan with all on 9.2.
Just an idea, but how about /usr/local/bin -- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Registered Linux user 231871
What do I export from the server to the clients (who already have a /usr/bin) and where do I mount it on the clients so it's in their path? Or maybe I'm asking for too much. Lan with all on 9.2.
Just an idea, but how about /usr/local/bin
That's a good idea and it works but it deletes stuff that was installed in /usr/local/bin beforehand. Also, by exporting /usr/bin I'm exporting over 400 files when I really only want two.
steve wrote:
What do I export from the server to the clients (who already have a /usr/bin) and where do I mount it on the clients so it's in their path? Or maybe I'm asking for too much. Lan with all on 9.2.
Just an idea, but how about /usr/local/bin
That's a good idea and it works but it deletes stuff that was installed in /usr/local/bin beforehand.
I didn't know. I have nothing there.
Also, by exporting /usr/bin I'm exporting over 400 files when I really only want two.
In that case, would it work to export it to anywhere, like /media/nfs, or /data, or whatever and then symlink just the two files to /usr/local/bin, or symlink the 2 files on the server in a different directory, and export only that directory like I mentioned above. I am not running nfs so I admit pure ignorance, no experience, and only ideas. HTH ;-) -- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Registered Linux user 231871
Op maandag 6 december 2004 21:15, schreef Joe Morris (NTM):
steve wrote:
What do I export from the server to the clients (who already have a /usr/bin) and where do I mount it on the clients so it's in their path? Or maybe I'm asking for too much. Lan with all on 9.2.
Just an idea, but how about /usr/local/bin
That's a good idea and it works but it deletes stuff that was installed in /usr/local/bin beforehand.
I didn't know. I have nothing there.
Also, by exporting /usr/bin I'm exporting over 400 files when I really only want two.
In that case, would it work to export it to anywhere, like /media/nfs, or /data, or whatever and then symlink just the two files to /usr/local/bin, or symlink the 2 files on the server in a different directory, and export only that directory like I mentioned above. I am not running nfs so I admit pure ignorance, no experience, and only ideas. HTH ;-)
-- Joe Morris
I would go for /opt/bin (underneath code is from suse-9.0:/etc/profile) or as alternative /opt/cross/bin: for dir in /var/lib/dosemu \ /usr/games \ /opt/bin \ /opt/gnome/bin \ /opt/kde3/bin \ /opt/kde2/bin \ /opt/kde/bin \ /usr/openwin/bin \ /opt/cross/bin do test -d $dir && PATH=$PATH:$dir done -- Richard Bos Without a home the journey is endless
I would go for /opt/bin (underneath code is from suse-9.0:/etc/profile) or as alternative /opt/cross/bin:
for dir in /var/lib/dosemu \ /usr/games \ /opt/bin \ /opt/gnome/bin \ /opt/kde3/bin \ /opt/kde2/bin \ /opt/kde/bin \ /usr/openwin/bin \ /opt/cross/bin do test -d $dir && PATH=$PATH:$dir done
Hi. That's in my 9.2 /etc/profile too. As far as I can see, I create /opt/bin on each client, export to it and it's in their path. Is that what it does? If so what would I have to do to export 2 files from /usr/bin on the server so that they appeared in /opt/bin on the clients? I see that I can only export directories. Cheers, Steve.
The Monday 2004-12-06 at 19:50 +0100, steve wrote:
That's a good idea and it works but it deletes stuff that was installed in /usr/local/bin beforehand. Also, by exporting /usr/bin I'm exporting over 400 files when I really only want two.
Export everything to an arbitrary directory, then symlink those two files locally. -- Cheers, Carlos Robinson
steve <mail@steve-ss.com> writes:
I want to try to run scribus and inkscape by not installing them on our clients and exporting via nfs. The binaries are in /usr/bin on our server.
IMHO, there is no simple solution in this case. We export /export/lw on our NFS server, the mount points is /lw. We either install programs into /lw directly (Matlab, Mathematica, ...) or compile them with --prefix=/lw (GCC, ...). Perhaps the --relocate option of rpm can be used to install some SUSE RPM packages there but I haven't tried it. -- A.M.
On Monday 27 December 2004 14:02, Alexandr Malusek wrote:
steve <mail@steve-ss.com> writes:
I want to try to run scribus and inkscape by not installing them on our clients and exporting via nfs. The binaries are in /usr/bin on our server.
IMHO, there is no simple solution in this case.
I agree. By the time you have messed around with it and found that you also need /usr/share and probably /opt too and your server can't cope anyway, you may as well have installed the stuff on the clients. I really thought that on a system designed for multi users it would be easier than this :-( Steve.
On Mon, 2004-12-27 at 08:23, steve wrote:
On Monday 27 December 2004 14:02, Alexandr Malusek wrote:
steve <mail@steve-ss.com> writes:
I want to try to run scribus and inkscape by not installing them on our clients and exporting via nfs. The binaries are in /usr/bin on our server.
IMHO, there is no simple solution in this case.
I agree. By the time you have messed around with it and found that you also need /usr/share and probably /opt too and your server can't cope anyway, you may as well have installed the stuff on the clients. I really thought that on a system designed for multi users it would be easier than this :-( Steve.
The /usr directory can be mounted read only from the server. This would run scribus and many other apps from the server. This is what the /usr directory is for. Clients should mount a /usr/local partition for any "non standard" local apps. If you do not want to export /usr, you could export a lib directory as well as a bin directory from the server. Update the clients once to include the shares in the path and /etc/ld.so.conf. Now copy the binaries in the shared bin directory and use ldd to determine which libs to copy to the lib share. That would give you "network" apps without sharing the entire /usr directory. Louis Richards
On Mon, 2004-12-27 at 19:09, Louis Richards wrote:
The /usr directory can be mounted read only from the server. This would run scribus and many other apps from the server. This is what the /usr directory is for. Clients should mount a /usr/local partition for any "non standard" local apps.
If you do not want to export /usr, you could export a lib directory as well as a bin directory from the server. Update the clients once to include the shares in the path and /etc/ld.so.conf. Now copy the binaries in the shared bin directory and use ldd to determine which libs to copy to the lib share.
That would give you "network" apps without sharing the entire /usr directory.
Louis Richards
Whithout the crappy HTML .... sorry Louis Richards
Louis Richards <louis@ldrinteractive.com> writes:
... If you do not want to export /usr, you could export a lib directory as well as a bin directory from the server. Update the clients once to include the shares in the path and /etc/ld.so.conf. Now copy the binaries in the shared bin directory and use ldd to determine which libs to copy to the lib share. ...
It may be done but there is no doubt that it is far from the desired solution when an organization uses a global file system where packages can be easily installed and updated. Administration costs must be kept as low as possible. -- A.M.
On Tue, 2004-12-28 at 13:07, Alexandr Malusek wrote:
Louis Richards <louis@ldrinteractive.com> writes:
... If you do not want to export /usr, you could export a lib directory as well as a bin directory from the server. Update the clients once to include the shares in the path and /etc/ld.so.conf. Now copy the binaries in the shared bin directory and use ldd to determine which libs to copy to the lib share. ...
It may be done but there is no doubt that it is far from the desired solution when an organization uses a global file system where packages can be easily installed and updated. Administration costs must be kept as low as possible.
-- A.M.
Mounting the entire /usr directory from the server will provide the desired results. Applications updated on the server are then available imediately to all clients. Of course, this is just one solution. Shortcuts could be provided for the users to run the programs through ssh (ssh -X server scribus). These shortcuts would continue to work after an upgrade on the server. The users could also run the programs through NX or some other remote client/server solution. This method works nicely if you still have Windows clients mixed in as they can run the apps as well. Or you could realy cut down on admin costs and move to terminals using NX or LTSP. Either of these can also run Windows apps by providing access to a terminal server. On the downside, mounting the whole /usr directory does seem to be more than you want/need. It limits your choice of which applications are networked. The ssh solution would require passwordless logons to be setup for ease of use on the client end. NX server costs money and requires client software. Terminals would most likely require some major changes to your current network setup for both the server and the clients. Uhhmm ... OK ... you were right all along. :-) Louis Richards
Louis Richards <louis@ldrinteractive.com> writes:
Mounting the entire /usr directory from the server will provide the desired results. Applications updated on the server are then available imediately to all clients. Of course, this is just one solution.
I know it's possible but have you tried this configuration in a classroom with many obsolete computers where students are supposed to start the same program at the same time? X, OpenOffice.org and other large programs will be loaded over the network and benefits of local disks will be lost. Also, updates of packages on clients are not quite straightforward unless you install only those packages which do not place files into /usr.
Shortcuts could be provided for the users to run the programs through ssh (ssh -X server scribus). These shortcuts would continue to work after an upgrade on the server.
Again, the application server has to be powerful enough to handle many users. It's usually no problem in a company where users don't execute the same commands at the same time but it may be a problem in a classroom. We use both application servers and diskless clusters here but they are dimensioned to a typical workload. It's not that easy to take an ordinary and obsolete PC and turn it into a server for many users. -- A.M.
Mounting the entire /usr directory from the server will provide the desired results.
In theory yes. But we forget what I originally wanted to do. Run scribus and inkscape from the server. Just try it with an amd server with 1024 and you'll soon see that my idea of using it on a 20 node school lan is simply out of the question. Maybe I should start another thread: What sort of spec server do I need to do this.
On Sunday 05 Dec 2004 19:25 pm, steve wrote:
I want to try to run scribus and inkscape by not installing them on our clients and exporting via nfs. The binaries are in /usr/bin on our server. What do I export from the server to the clients (who already have a /usr/bin) and where do I mount it on the clients so it's in their path? Or maybe I'm asking for too much. Lan with all on 9.2.
Are you installing from rpm or compiling from source? If it's from source then stow (http://www.gnu.org/software/stow/stow.html) might be useful - it puts all the files for an app in one directory and makes links from the 'expected' locations to the real files. For example, you could have the apps in /usr/local/stow/scribus and /usr/local/stow/inkscape with links from /usr/bin etc. Then export /usr/local/stow and create the necessary links on the clients. You might be able to do something similar with an rpm if it's relocatable - see the -prefix and relocate options in man rpm. Dylan
cheers, Steve.
-- "I see your Schwartz is as big as mine" -Dark Helmet
participants (7)
-
Alexandr Malusek
-
Carlos E. R.
-
Dylan
-
Joe Morris (NTM)
-
Louis Richards
-
Richard Bos
-
steve