On Fri, Dec 16, 2011 at 07:46:36 -0500, Jean-Louis Martineau wrote:
> Nathan,
>
> Thanks for reporting the bug, it is already fixed in trunk but we
> forget to backported it to 3.3.
> I'm attaching the patch, it also apply to 2.6.1p2
Jean-Louis: yes, thanks, that's exactly the bug I was planning to report....
For those following this thread on the list: the issue here is that
while amgtar (all versions up through 3.3, it seems) does parse its
command line options and notice the --gnutar-listdir option there, it
then proceeds to retrieve the "gnutar-list-dir" setting from the
configuration file -- and in the process over-writes the value it found
on the command line. So the net effect is that the application-tool
GNUTAR-LISTDIR property setting ends up being ignored.
(Jean-Louis's patch moves the retrieval of the config-file value so that
it happens first, and thus the command-line option setting can override
the config-file setting.)
As far as my original problem goes, looking at the patch made me realize
that the specific configuration file involved in this case is actually
the "amanda-client.conf" file, and thus that for Amanda versions which
support that file, it's actually possible to use settings there to
control where the GNU tar snapshot files are stored. It's not as clean
a solution as using the amgtar application property, since the
configuration has to be done on each client machine rather than once on
the server side, but in my tests it does seem to successfully allow me
to separate the snapshot files (and "amdatates" file as well) for
different Amanda configurations (without having to rebuild Amanda using
Jean-Louis's patch).
Specifically, on each client machine I created a file
/etc/amanda/<config>/amanda-client.conf containing the following lines:
gnutar_list_dir "/var/lib/amanda/gnutar-lists/<config>"
amandates "/var/lib/amanda/amandates_<config>"
, and then I created the /var/lib/amanda/gnutar-lists/<config> directory
with the same ownership and permissions as the gnutar-lists directory
itself.
(At the same time, I went ahead and commented out the application-tool
"property GNUTAR-LISTDIR" line in the amanda.conf on the server, just so
it was clear that it wasn't being used.)
[In my case -- Ubuntu/Debian machines -- Amanda is built with CONFIG_DIR
is set to "/etc/amanda", listed_incr_dir set to
"/var/lib/amanda/gnutar-lists", and build.default_amandates_file to
"/var/lib/amanda/amandates".]
After that, the tar-related from the various dumps using different Amanda
configurations were all kept separate, and I was able to add disklist
items to each configuration without worrying about making sure the names
were all unique.
(I assume that these two amanda-client.conf settings would be used by
the standard GNUTAR program just as they are with the amgtar
application, though I haven't tried that out myself.)
For the servers running the old (pre-application-tool and
pre-amanda-client.conf) version of Amanda, I went ahead and used the
"diskname" field in the disklist file to put a configuration-specific
prefix for each DLE, thus ensuring that the client-side files all have
unique names. (So, for example, in the DailySet1 configuration, I
changed
<host> / <dumptype>
to
<host> ds1-/ / <dumptype>
), thus ensuring that DailySet1's dump of "/" uses different file names
than DailySet2's, etc.
It's not very pretty, but the combination of these two workarounds seems
to be allowing successful backups of the same directories from multiple
different configurations....
Nathan
----------------------------------------------------------------------------
Nathan Stratton Treadway - [email protected] - Mid-Atlantic region
Ray Ontko & Co. - Software consulting services - http://www.ontko.com/
GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239
Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
