BackupPC-users

Re: [BackupPC-users] Merge config in per-host config?

2009-09-03 16:33:37
Subject: Re: [BackupPC-users] Merge config in per-host config?
From: Davide Brini <dave_br AT gmx DOT com>
To: backuppc-users AT lists.sourceforge DOT net
Date: Thu, 3 Sep 2009 21:26:55 +0100
On Thursday 03 September 2009, Carl Wilhelm Soderstrom wrote:
> On 09/03 08:45 , Davide Brini wrote:
> > I agree that it should work like that. However, if I'm not mistaken, it
> > seems that what's written here still applies:
> >
> > http://osdir.com/ml/sysutils.backup.backuppc.general/2003-10/msg00010.htm
> >l
>
> I think the current behavior is the correct behavior -- where the per-host
> config file variable data completely replaces the defaults set in the
> config.pl.
>
> The reason is that there are some settings in config.pl where is it not
> sensible to add the value in config.pl to the value in the per-host file;
> such as the rsync command.

That's actually another issue we're having, which would be solved by my patch. 
We have a set of basic rsync options in config.pl (that is, $Conf{RsyncArgs} 
and $Conf{RsyncRestoreArgs}) which do not include --checksum-seed=32761, as 
some of the hosts we back up have a too old rsync version installed. But, for 
the hosts that DO support that, we want to use it. So my patch enables us to 
do something like

push @{$Conf{RsyncArgs}}, '--checksum-seed=32761';
push @{$Conf{RsyncRestoreArgs}}, '--checksum-seed=32761';

in the per-host config file only for the hosts that can support that. The 
alternative would be to include the full $Conf{RsyncArgs} with checksum 
caching appended at the end in each per-host config file. If some day we want 
to change an option in rsync's default options, we would have to change that 
in config.pl AND in all the per-host config files where we were forced to 
paste the same options only to add checksum caching, which would be 
inconvenient.

So far, we were able to kind of simulate the same behavior by doing, in each 
per-host config file,

do "/etc/backuppc/config.pl";
# host specific stuff here, including appending of values
...

but that looks like a hack to me.

> It would be bad from a discoverability standpoint to have some variables be
> additive, and others ablative. They should all behave the same way; and the
> only sensible way IMHO is current behavior.
>
> Please correct me if I misunderstand your statement and intent.

Well I see your point, but keep in mind that the two behaviors are not 
mutually incompatible; people who used to override values in the per-host 
config file can still do so (in fact without changing anything); on the other 
hand, my suggestion would allow you to get additive behavior *only if you 
want*, because to do that you have to explicitly craft Perl code like the 
above or similar, which should mean you know what you're doing.

-- 
D.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/