Hi,
Davide Brini wrote on 2009-09-05 14:32:48 +0100 [Re: [BackupPC-users] Merge
config in per-host config?]:
> On Saturday 05 September 2009, Craig Barratt wrote:
> > Davide,
> >
> > The basic problem with putting perl expressions in the config file
> > (to make settings cumulative) is that it isn't compatible with the
> > CGI config editor.
that is true, but that's how it is anyway. If you put Perl expressions in the
config file (which you can already do), then you're incompatible with the CGI
editor. That is really an independant issue.
The suggestion here is merely to *enhance* the possibilities of using Perl
expressions in the config file by providing the value of %Conf from config.pl
(which is available to the calling code anyway, so it's not really a bother,
just a courtesy, to make it visible inside host.pl).
I would like to stress again, that the code does not seem to change anything
else (as suggested by Carl). Settings from config.pl remain overridden by
host.pl, just that host.pl can now use the value from config.pl in generating
the new value (which could just as well be
$Conf {XferMethod} = $Conf {XferMethod} eq 'smb' ? 'rsync' : 'tar';
$Conf {ClientTimeout} += 3600;
- which doesn't make much sense, other than demonstrating that it's not
limited to a 'push'). As far as the patch is concerned, I'd even suggest
diff -uNr BackupPC-3.0.0/lib/BackupPC/Lib.pm
BackupPC-3.0.0-patched/lib/BackupPC/Lib.pm
--- BackupPC-3.0.0/lib/BackupPC/Lib.pm 2007-01-29 06:02:48.000000000 +0000
+++ BackupPC-3.0.0-patched/lib/BackupPC/Lib.pm 2009-09-03 20:13:26.000000000
+0100
@@ -328,7 +328,7 @@
# Read host config file
#
if ( $host ne "" ) {
- ($mesg, $config) = $bpc->{storage}->ConfigDataRead($host);
+ ($mesg, $config) = $bpc->{storage}->ConfigDataRead($host, $bpc->{Conf});
return $mesg if ( defined($mesg) );
- $bpc->{Conf} = { %{$bpc->{Conf}}, %$config };
+ $bpc->{Conf} = $config;
}
[sorry, that patch is hand-edited ;-] ... as merging the configurations is now
obsolete. For whatever it's worth, that would also allow host.pl to delete
config variables set in config.pl (I can't think of any reason to want that -
setting a variable to undef already overrides a config.pl setting to much the
same effect).
> Yeah I understand that. It's not a big problem for me because I don't use the
> web interface to edit the configuration anyway. Of course, I'm not saying
> that this is true for every user, so your objection makes perfect sense.
Except that providing the values does not hurt *any* user. It just might
encourage more users to actually use the Perl configuration files to the
extent of flexibility they were originally, I believe, meant to provide.
> > The config editor will get the intended computed
> > values, but when it re-writes the config file it will just write the
> > values, not the original expression.
>
> Yes, the way the web interface works currently makes it quite difficult to
> incorporate my change there.
I don't believe that is necessarily true. I fully understand the difficulty in
*parsing* a Perl expression to correctly extract and substitute the RHS of the
assignment. If that were implemented, some kind of convention could be
established for including code instead of a literal value - maybe the same
convention as cmdSystemOrEval uses, except that I'd add the '&' for display
and remove it before writing to the config file (meaning an assignment
$Conf{foo} = bar;
could be displayed as a value '&bar' in the text field on the web page;
conversely, a value input as '&expression' would be stripped of the '&' and
put in the host.pl file unquoted). This should be simple for scalars, but it
doesn't extend well to arrays or hashes, which are probably the more useful
usage cases. Hmm. And using the *same* convention as with cmdSystemOrEval
would actually interfere with the usage of the convention for values to be
used with cmdSystemOrEval (my favorite: $Conf{PingCmd} = '&{sub {0}}';).
Well, choose a different character, that no config variable value will ever
start with (and forbid SMB passwords starting with that character ;-).
Limited to the usage suggested in this thread, it would even be rather easy.
There could be a checkbox 'Make setting relative to setting from global config
file' which would make the config editor replace the settings from the global
config by a reference to %Conf in the value written to the host.pl file, e.g.
config.pl:
$Conf {BackupFilesExclude} = {
'/' => [ '/sys', '/proc' ],
'/home' => [ '/*/tmp' ],
}
config from editor:
$Conf {BackupFilesExclude} = {
'/' => [ '/sys', '/proc', '/var/spool' ],
'/home' => [ '/*/tmp' ],
'/data' => [ '/BackupPC' ],
}
generated config put in host.pl:
$Conf {BackupFilesExclude} = {
'/' => [ @{$Conf{BackupFilesExclude}{'/'}}, '/var/spool' ],
'/home' => @{$Conf{BackupFilesExclude}{'/home'}},
'/data' => [ '/BackupPC' ],
}
or possibly:
$Conf {BackupFilesExclude} = {
%{$Conf {BackupFilesExclude}},
'/' => [ @{$Conf{BackupFilesExclude}{'/'}}, '/var/spool' ],
'/data' => [ '/BackupPC' ],
}
or even:
push @{$Conf{BackupFilesExclude}{'/'}}, '/var/spool';
push @{$Conf{BackupFilesExclude}{'/data'}}, '/BackupPC';
The last example could even delete values from the global one (e.g. if the
'/proc' exclude were removed for this host, for the sake of an example).
Maybe not simple to code, but simple to visualize in a web page.
> However, I still think that having the ability to do per-host additions to the
> default config without having to copy over the whole thing would be useful in
> a number of circumstances, and probably something some user might expect
> given that the config file is normal Perl code (and evaluated with "do").
You are not the first person that was surprised it didn't work as you had
expected.
A different (but related) issue, directly resulting from ...
> > The basic problem with putting perl expressions in the config file
> > (to make settings cumulative) is that it isn't compatible with the
> > CGI config editor.
... is that it might be desirable to protect host.pl files from CGI
modifications. That could be as simple as adding
$ConfigEditorDontOverwriteMe = 1;
(or $Conf{...} if that's easier) in the file and respecting that variable in
the config editor. Whether one person is using both the CGI config editor and
editing the host.pl files, or several people are cooperating on one BackupPC
server, it's rather easy to inadvertantly overwrite some code, because, as you
point out, it's not *visible* in the CGI editor that it was code that
generated some literal values.
Regards,
Holger
------------------------------------------------------------------------------
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/
|
