>... But one thing that has been a tad
>frustrating is the lack of standards, or more specifically the 'partial
>adherance' to standards as seen so far in my miniscule introduction to the
>*nix world. ...
For the OS portion of an installation, every vendor has their own
theories. It's actually much better than it used to be.
For add on packages such as Amanda, many of them use the GNU autoconf and
automake tools. Those define pretty clearly where things go and you can
read about that in their documentation. Amanda, for instance, does not
do anything special to control the installation locations of anything.
It leaves all that up to autoconf/automake.
>... Are you saying they just copy that
>/usr/local branch off to other machines? Is there nothing then that was put
>in /sbin or /bin etc? wow. That could be cool.
I don't know exactly how others do it. In my own setup, I install each
additional package in its own area in /opt (e.g. /opt/amanda-2.4.2)
and that's then trivial to rdist (copy) around.
I also install another "package general" symlink in /opt (e.g. /opt/amanda
-> amanda-2.4.2) that points to the current version I want to use.
That makes it easy to have multiple versions, and it also means all
references just have to be set up once (e.g. /opt/amanda/libexec/amandad)
and never changed again.
If the package is "public" (like gcc, for instance) that all users should
have access to, I fill /usr/local/bin with symlinks to the package bin
area in /opt (e.g. /usr/local/bin/gcc -> /opt/gcc/bin/gcc). Then a
user only has to have /usr/local/bin in their PATH to use the tools.
The symlinks only need maintenance when a new package is added or updated
(and I have Perl scripts to do most of the work).
This also lets a user get access to a new version easily by placing the
/opt entry (e.g. /opt/gcc-X.Y.Z/bin) before /usr/local/bin in the PATH.
If you install directly into /usr/local and didn't mind those being
identical between machines, you could rdist (duplicate) them. Better
would be to set up a Distfile (rdist control file) just for Amanda to
only ship it around.
Or the other way around would be to have a template machine that you could
rdist to other places and use the rdist option that inhibits removing
files on the target that don't exist on the source. So everything on
the template machine would get to the clients, but if the clients had
other stuff it would be left alone.
There are still things that have to be altered in /etc for Amanda, such
as inetd.conf, but those are once only changes when first bringing a
new client on line and (should) never need updating after that.
>Randy
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
