[Beowulf] /usr/local over NFS is okay, Joe

[Prentice Bisbal]

Joe Landman wrote:
> 
> 
> Prentice Bisbal wrote:
> 
>> Here's another reason to use tarballs: I have /usr/local shared to all
> 
> eeek!!  something named local is shared???

Nothing wrong with that. "local" doesn't necessarily mean local to the
physical machine. It can mean for the local site. I do everything
according to standards, and adhere to them strictly. Sharing /usr/local
is is actually codified in the FHS:

<quote>
4.8.2. /usr/local : Local hierarchy
4.8.2.1. Purpose
The /usr/local hierarchy is for use by the system administrator when
installing software locally. It needs to be safe from being overwritten
when the system software is updated. It may be used for programs and
data that are shareable amongst a group of hosts, but not found in /usr.

Locally installed software must be placed within /usr/local rather than
/usr unless it is being installed to replace or upgrade software in /usr.
</quote>

You can share out /opt, too, but I use /opt for system that's installed
locally on a machine and not exported to others. I find this is easier
than putting it in /usr/local, since most packaged 3rd party software
insist on going in /opt, anwyway.

> 
> FWIW: we do the same thing, but put everything into /apps, and all nodes
> have mounted /apps ...
> 
> requires a little ./configure -prefix=/apps/...

My configure kung-fu is very strong. I usually do this, so I can install
multiple versions of the same software:

./configure --prefix/usr/local/foo-xx.yy
--exec-prefix=/usr/local/foo-zxx.yy/x86

If compiling for x86_64, then --exec-prefix=/usr/local/foo-zxx.yy/x86_64.

I have dozens of applications compiled for 32-bit and 64-bit on the same
/usr/local. I just put 64-bit binaries (actually symlinks) in
/usr/local/bin64, and make sure that comes first in the path on 64-bit
systems (ditto for lib64, etc.)

I do lots of other hocus-pocus, but I'm digressing enough already.

> magic, but it works well.
> 
>> my systems with with NFS. If want to install the lastest version of
>> firefox, you can just do this:
>>
>> cd /usr/local
>>
>> tar zxvf firefox-x.xxx.tar.gz
>>
>> cd /usr/local/bin
>>
>> ln -s ../firefox-x.xxx/firefox .
>>
>> Now all users can use the latest version of firefox (/usr/local/bin is
>> in their path, and comes before /usr/bin, usr/X11R6/bin, etc.)
> 
> Oddly enough, I am not a huge fan of dumping lots of binaries into one
> path.  Part of the reason is the package management one ... all you need
> is one renegade package and a packager that things [s]he is smart, and ...

I don't dump the binaries into one path. I put symlinks into
/usr/local/bin{,64}. All the binaries go into /usr/local/foo-xx.yy and
stay there:

./configure --prefix=/usr/local/foo-xx.yy
make
make install
cd /usr/local
ln -s foo-xx.yy foo #this makes the non-versioned dir the default
                    # just follow me here, okay?
cd /usr/local/foo/bin
for file in *; do ln -s ../foo/bin/$file /usr/local/bin/$file; done
# do the same for lib, include, man,...
# If I want to have multiple versions of foo available:
cd /usr/local/foo-xx.yy
for file in *; do ln -s ../foo-xx.yy/bin/${file} \
/usr/local/bin/${file}-xx.yy; done

Users can call the latest or default version by calling 'foo'. If they
want an earlier version, they call foo-<version>.

If I want to delete foo-xx.yy, I just do rm /usr/local/foo-xx.yy, and
then delete the broken links in /usr/local{bin,lib,incude,man}. This can
easily be done before deleting the install dir with scripts. If the
links are left around, they take up little disk space, since they are
only inodes. If I keep an earlier version of foo around, I change
/usr/local/foo to point to it.