On Thursday 11 September 2014 09:27:31 Brian Cuttler did opine
And Gene did reply:
> The more you customize the greater the chance you will have a
> problem unraveling come update time.
>
> I'd suppose you, if you want an unsupported solution, that you
> could replace the original path's binary with a # ln file.
>
> On Wed, Sep 10, 2014 at 11:29:27AM -0500, Jason L Tibbitts III wrote:
> > >>>>> "JM" == Jean-Louis Martineau <[email protected]> writes:
> > JM> It's not possible to set the path at runtime. It can only be set
> > at JM> compilation time
> >
> > OK, I guess Red Hat gets a bug report on that. I went ahead built a
> > fresh package that has dump in the build environment and all is well.
> >
> > - J<
>
> ---
> Brian R Cuttler [email protected]
> Computer Systems Support (v) 518 486-1697
> Wadsworth Center (f) 518 473-6384
> NYS Department of Health Help Desk 518 473-0773
I am not a fan of having red hat or any other proponent of a "package
manager" which is not capable of dealing with the amanda security
framework, something I consider to be a couple of levels above anything
any of the package managers I have dealt with, involved in the amanda
install process. To that end on my amanda server, this machine, no rpm or
deb has ever been installed after my first experience turned out badly and
the distro's list offered no help.
So, I use a script and build from the tarballs, and I get exactly what
amanda wants. A consistent build every time that has no variations because
I can't remember what options I used the last time.
==cut here=>
#!/bin/sh
# since I'm always forgetting to su amanda...
if [ `whoami` != 'amanda' ]; then
echo
echo "!!!!!!!!!!!!!!!!!! Warning !!!!!!!!!!!!!!!!!!!"
echo "Amanda needs to be configured and built by the"
echo "user amanda, but must be installed by user root."
echo
exit 1
fi
make clean
rm -f config.status config.cache
./configure --with-user=amanda \
--with-group=disk \
--with-owner=amanda \
--with-gnu-ld \
--prefix=/usr/local/ \
--with-debugging=/tmp/amanda-dbg/ \
--with-tape-server=coyote \
--with-bsdtcp-security --with-amandahosts \
--with-configdir=/usr/local/etc/amanda \
--with-gnutar=/usr/bin/tar
echo "sleeping for reading configures warnings"
echo "a make as amanda will continue after 15 seconds..."
sleep 15
make
<======EOF, cut at arrow
After amanda has been built, then a "sudo make install" is done, followed
by an 'su amanda -c "amcheck Daily"' just to make sure there aren't any
upgrade surprises. I have had to change 2 lines above in something over a
decade, the location of tar because my distro's tar was broken in terms of
obeying amanda, (so my tar is also locally built) and the bsd security
line was changed to bsdtcp.
If the group "disk" does not exist on your system, then check and see if
"backup" is usable.
Equally obvious is that the user amanda has a /home/amanda directory that
is used only to build amanda in. Totally insulated, the user amanda
doesn't even have a login password here.
Other than that, it Just works(TM), and the other two machines I also
backup, have much older versions of the client software that is installed
from a .deb, all 100% compatible with 3.3.6 that I am currently running
here on this server, and has worked with probably 40 different versions of
the 4.0.0-alpha builds this machine has run over the last 5 years.
IMO, the server side of amanda is terminally broken, particularly by
attempts to make it fit in the rpm way of doing installs. IMO, rpm itself
is broken regardless of its version, and will remain so until such time as
it can install something suid.
My $0.02.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
