PDA

View Full Version : Specifying where to find GNUTAR on client?



Andrew Rakowski
February 6th, 2007, 09:38 PM
Okay, I'm probably missing the obvious here, but HOW can I specify to the client Amanda software where to find the GNUTAR program that I want it to use? In particular, this is on a system running Redhat Linux v9 to remain compatible with some finicky instrumentation that it's controlling. I'm using the stock Linux Amanda-2.5.1p2-1.rhel3.i386 client rpm packages from the Zmanda.com download site.

I have installed a modern version of tar (v1.16) in /opt/local/bin/tar, but the system default tar in /bin/tar is v1.13.25 . In looking at the /tmp/amanda/client/amandad/amandad.* debug file, I see that the amandad daemon was configure'd with "--with-gnutar=/bin/tar" and amandad itself is showing GNUTAR="/bin/tar" is being used.

So, how to I override that use of /bin/tar and make it /opt/local/bin/tar without having to change the /bin/tar file (which I don't want to change in case it breaks some vendor-specific software already running on this box)? I would think there might be an argument to the amandad daemon (similar to "-auth=bsdtcp") but didn't see anything for setting the GNUTAR value in the clientconf.c (or other) source files.

What am I overlooking here? I know I can select that I want to use GNUTAR vs DUMP in the "dumptype" settings, but it looks like a symbolic choice only, not a place to put an actual path.

Sorry for the raft of newbie and otherwise obscure questions...

-Andrew

shailen
February 7th, 2007, 01:04 PM
Andrew,

the best way to work around this would be to create a symbolic link in /bin pointing to /opt/local/bin/tar

that would be the easiest way to work around this issue.

you can rename the original tar in /bin to tar.orig. and then create the symbolic link and everything should work fine.

Thanks!
-Shailen :)

Andrew Rakowski
February 7th, 2007, 04:37 PM
Andrew,

the best way to work around this would be to create a symbolic link in /bin pointing to /opt/local/bin/tar

that would be the easiest way to work around this issue.


Hi Shailen, I agree that might be the easiest work-around, but that's not always something that can be done. With change management systems in place, packages can be verified, and "damaged" binaries (like a changed /bin/tar) can be automatically replaced. Also, in this case, the system is an instrument controller (think turn-key expensive scientific device run via a Linux controller). The idea is to change the configuration of one of these systems as little as possible.

I was thinking more along the lines of being able to change the default path for the amandabackup user so that /opt/local/bin might be first in the path, so that user's reference to "tar" would be found in the "right" place. However, I'm suspecting that the full path to the tar binary is stuffed into the Amanda client code at build time, with no way to override that value.

This seems like something that should fundamentally be configurable (I want to insure that even if RedHat or some other Linux vendor changes the tar package, my backups continue using what is needed to match the Amanda server and backup contents.) If it really can't be changed, then I'd like to suggest it as a future enhancement. Otherwise, simple system updates can break future backups without anyone knowing (so, another vote for automated restore testing as well! :) )

Cheers,

-Andrew