Try setting the DUMP/RESTORE variables before executing ./configure
Jean-Louis
Chris Hoogendyk wrote:
ok. just tried this. I have /usr/local/etc/amanda/tools/ with symlinks
for gtar and ufsdump in that directory. Before doing the ./configure,
I added that directory to the beginning of PATH and exported it. If I
say `which ufsdump`, it tells me /usr/local/etc/amanda/tools/ufsdump.
However, if I do the configure, it finds, instead, /usr/sbin/ufsdump.
-- oh, I downloaded amanda-2.5.1p3.tar.gz, figuring if I had to
rebuild, I should get the latest bug fixes, so this was a fresh
configure.
I got gtar to work using the --with-gnutar= option on ./configure.
However, ./configure -h doesn't show any corresponding option for dump
or for ufsdump. But, in looking through configure (about line 10500
and something), it looks like it is saying that the user can provide
an alternative. I can't read the configure well enough to tell how to
do that, and it appears to be undocumented. Any ideas?
./config.log:configure:10502: checking for ufsdump
./config.log:configure:10520: found /usr/sbin/ufsdump
./config.log:configure:10532: result: /usr/sbin/ufsdump
If I can't get this to go, then I'll go to the sloppy route of finding
all instances of /usr/sbin/ufsdump in the Makefiles, etc. and hand
editing them. Yuck.
TIA
---------------
Chris Hoogendyk
-
O__ ---- Systems Administrator
c/ /'_ --- Biology & Geology Departments
(*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst
<[EMAIL PROTECTED]>
---------------
Erdös 4
Anthony Worrall wrote:
Hi
What I did was create a directory which had links to all the tools
that amanda needs such as ufsdump, gtar etc. I then compiled amanda
so it found the tools in this directory rather than the system
directories.
I can then replace the links with wrapper scripts as needed.
I hope this helps
Anthony Worrall
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Chris Hoogendyk
Sent: 06 February 2007 20:17
To: [email protected]
Subject: Re: wrapper for ufsdump with snapshots
Well, those are both interesting, but don't get me anywhere right now.
I know it can be done, I just don't know what it takes to do it.
Here's just enough information to tantalize:
http://forums.zmanda.com/showthread.php?t=75
I'd even be willing to tangle a little with source code, as long as it
didn't get too messy and someone could point me to it with enough
detail. Or, I wonder if it could be as simple as going into Makefile
and
changing "DUMP=/usr/sbin/ufsdump" to something else? "Simple" being
defined as excluding the process of writing and debugging the script --
but I've done that for my own backup scripts before adopting amanda.
A quick look through indicates that there are about 10 different src or
Makefiles that have "DUMP=/usr/sbin/ufsdump" after having run the
configure.
---------------
Chris Hoogendyk
-
O__ ---- Systems Administrator
c/ /'_ --- Biology & Geology Departments
(*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst
<[EMAIL PROTECTED]>
---------------
Erdös 4
Paddy Sreenivasan wrote:
Please take a look at Application API documentation in
http://wiki.zmanda.com/index.php/Application_API
Jean-Louis has started working on it.
Paddy
On 2/6/07, Patrick M. Hausen <[EMAIL PROTECTED]> wrote:
Hi, all!
On Tue, Feb 06, 2007 at 01:33:01PM -0500, Chris Hoogendyk wrote:
The examples of using wrappers assume you are backing up with tar
and
involve recompiling amanda using "--with-gnutar=..."
I see no comparable option "--with-dump=...", nor any examples with
dump. In particular, I want to run ufsdump on Solaris 9 systems from
a
snapshot created with fssnap.
...
I read your entire post and second your suggestions for the
future development of Amanda. It would be great if one could
specify the backup utilities used and their parameters via
configuration instead of via recompiling.
Short answer to your current problem: the FreeBSD port has got
an option to enable snapshots. If you choose to use them, it
patches the Amanda source.
Since the FreeBSD port maintainers in general seek to be as
non-intrusive as possible to 3rd party software, my educated
guess is that this is the only way to achieve the desired effect.
HTH,
Patrick M. Hausen
Leiter Netzwerke und Sicherheit
--
punkt.de GmbH * Vorholzstr. 25 * 76137 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
[EMAIL PROTECTED] http://www.punkt.de
Gf: Jürgen Egeling AG Mannheim 108285
