Re: Conventions for NFS sharing of binaries
From: Juhan Leemet (juhan_at_logicognosis.com)
Date: 07/27/04
- Next message: Juhan Leemet: "Re: odd characters in SQL queries doing odd things to putty"
- Previous message: Juhan Leemet: "Re: Open Source Leaving Microsoft Sitting on the Fence?"
- In reply to: Rick Denoire: "Re: Conventions for NFS sharing of binaries"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 27 Jul 2004 07:13:24 -0200
On Mon, 26 Jul 2004 22:36:07 +0200, Rick Denoire wrote:
> nobody@tek.com (Kevin) wrote:
>>> But I am not sure that I won't get a problem later. Do all packages
>>> which install from source put their files beneath the /usr/local tree?
>>
>>Many can.
>
> What I meant was whether they put all files beneath one directory
> without spreading to other places outside this tree.
Depends on the software. Some are pretty small and just put some binaries
in /usr/local/bin and a few libraries in /usr/local/lib, and maybe
(hopefully?) some man pages in /usr/local/man. Others create a directory
of their own in /usr/local/<pkgname> and create a bunch of directories and
files in there. The location for many software packages is often
determined by a symbol in a .spec file (or supplied by RPM) called prefix
(or _prefix). The distro uses prefix=/usr and you should use
prefix=/usr/local for your "local" stuff. If you have specified by prefix
that you're installing in /usr/local and the makefiles and/or installation
scripts put software anywhere else, it's likely a bug. Sometimes there are
good reasons: read README and/or INSTALL that comes with the software.
>>> What if they use some server-dependent configuration files? Would they
>>> be overwritten?
>>
>>Why would they be overwritten?
I'm inclined to agree? Do you have distro & local packages with same name?
> A couple of days ago, I installed a package in /usr/local which would
> put a package.PID in /usr/local/lib at start time (this file contains
> the process number). If I shared this software, well, every client host
> would overwrite this file. Shutting down the damon would fail, since the
> PID file would not contain the right process ID.
Bad place. Read FHS (Filesystem Hierarchy Standard) to explain what should
go where. There are variations, but they should be well considered.
.pid files should go into /var/run directory (or a subdirectory in there).
> Even worst, if a shared package puts a config file in a shared
> /usr/local/etc, and every server would use the package with a different
> configuration, that would result in chaos! (Usually, names of config
> files are hard wired).
You could consider that /usr/local/etc config file as a "template". It
would not get "magically" used anyway, unless you link to it, or specify
it (or if it is compiled into the code). Even if it is compiled in, you
should still be able to override it from the command line and/or startup
script(s). Your working configurations should be somewhere in /etc. You
can copy the "template" there, and season to taste.
> Did I mention the possibility of sharing /usr/local readonly? Would that
> work file for most tarballed software?
Probably good to share readonly, to avoid corruption by writing. You could
mount it r/w on your "master installation machine" (with RPM management).
Any working files should be somewhere in /var on executing machine.
>>> Well, other related questions would be: If I want to install a
>>> different version of a software from source which is already installed
>>> as an RPM package, what issues arise with the PATH variable? (Because
>>> depending on it, the RPM version or the /usr/local version will be
>>> used).
If you replace a package with a different one with the same name, hmm, you
could get snarled up. Say you want to use a "bleeding edge" package that
comes standard with your distro. RPM cannot (to my knowledge) maintain two
packages of the same name, but different version. It insists on doing an
"upgrade". However, if you have an "experimental" package you want to put
into /usr/local, and yet keep the "standard" package in /usr, you have a
problem. I think Mandrake people rename the package to "hack<package>" or
something like that. Then as far as RPM knows, they are totally
independent (even if they have identically named executables and files).
>>Wouldn't /usr/local be ahead of other stuff in PATH?
>
> Who said that users prefer the "extra" stuff instead of the system owned
> one?
You could leave it up to each user to include /usr/local into their own
PATH if they want it, or leave it out if they don't. I usually put
/usr/local at the head of my PATH, unless I'm doing something special.
>>Package managers deal with the problems you're citing. Learn how to use
>>one. I'd recommend RPM as you mentioned that you're using Redhat.
Ah, yes, but if your shared software is mounted readonly from an NFS
machine, then the local RPM really would not know anything about those
packages, would it? I don't know if RPM knows how to manage separate
databases and "merge them together". I don't think so? Otherwise, you
could also share the /usr/local RPM database. That would be kinda nice!
Unfortunately, this is a problem for most package management tools.
> I was addressing managing of unpackaged software (the one that is
> delivered in source code as a tarball containing configure/make skripts
> etc.). In general, you cannot "deinstall" (=delete) any particular
> software because its files are mixed up with all others.
I would still use RPM, even if you have to add extra rules/notes about
checking RPM on the NFS server that shares /usr/local. RPM will be able to
keep track of files in each package, and "deinstall" them by package.
Personally, for "bleeding edge" stuff, I have been building the packages
as if they were a part of the distro, but I have a directory on an NFS
server that contains all of my working stuff. I can easily check: RPM
tells me the package was built on one of my machines, and I have the
.src.rpm and .rpm files on my special NFS directory. If one of those is a
disaster, I can back it out and reinstall a distro standard version. That
works for me. I have not needed to have both installed simultaneously. For
any A/B testing, I have done that on 2 machines, each with different pkg.
-- Juhan Leemet Logicognosis, Inc.
- Next message: Juhan Leemet: "Re: odd characters in SQL queries doing odd things to putty"
- Previous message: Juhan Leemet: "Re: Open Source Leaving Microsoft Sitting on the Fence?"
- In reply to: Rick Denoire: "Re: Conventions for NFS sharing of binaries"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
