Re: [BackupPC-users] debian patch for localconfig.pl

[G.W. H. <ba...@ju...>]

Hi there,

On Sat, 15 Nov 2025,  Paul Fox via backuppc-users wrote:

> jbk wrote:
> 
> > Unless I'm misunderstanding this, is the localconfig.pl to 
> > define a backup schedule for the server?
>
> No, not specifically.  It holds any configuration you might otherwise
> put in config.pl, which is read prior to localconfig.pl.  All it
> really does is let you segregate local changes from distributed
> changes, if that's useful to the administrator.
>
> Honestly, now that we're talking about it, I can't see why this shouldn't
> just be added to backuppc as a permanent feature.  It's pretty lightweight,
> and useful.  So I guess I'm championing it after all.

Hmmmm...

You can get the entire patchset from (for example)

https://udd.debian.org/patches.cgi?src=backuppc&version=4.4.0-11

and easily apply the localconfig part.  It's a one-line change in
.../lib/BackupPC/Storage/Text.pm.  Although I've gone through all the
patches, checked whether or not they should be aplide here at the top
of the stream and applied those that I think shoudld, I haven't spent
a lot of time on this one and I haven't applied it.  At this stage I
don't propose to.  There's a good chance I've missed something but as
it stands I'm not sure that I understand what the patch is for.  I'm
also not sure that it will do what everyone here seems to think that
it will do.  So I have reservations.  Below is how I read it.  I'd be
very pleased if others will chime in with their own take on it.

The BackupPC configuration routines read the configuration files into
a big hash.  With the Debian patch, when localconfig.pl is present it
will be read *before* BackupPC's main config.pl, and anything in your
localconfig.pl which *also* exists in config.pl will be overridden by
the values in config.pl, so if you wanted the values in localconfig.pl
to be used in preference to those in config.pl, you'd have to comment
them out or whatever in config.pl.  So far so not especially useful.

But if you use the Web interface to edit the configuration, things go
rapidly downhill.  When the Web interface saves the configuration, it
all gets saved to config.pl.  The localconfig.pl isn't touched at all.
So now you have a localconfig.pl which is quite possibly obsolete and
misleading.  For some poor sysadmin newly arrived on the first day in
a new job and who is going to be hard pressed for a few weeks, this I
think will violate the Principle of Least Surprise.  When she finds
out what happened, I wouldn't want to defend against her imprecations.

For the record I'm not very keen on the way that the configuration in
config.pl is saved by the editor in the Web UI.  You might start with
a nicely formatted document which happens to be valid Perl, but after
EditConfig.pl has done with it you can have something which is rather
untidy, even if it is still valid Perl.  A great deal of value text is
wantonly changed (e.g. things like different quoting) without actually
changing the values.  It makes using 'diff' a nightmare.  If I were to
dig into that, I'd want to do something to make sure that the original
comments and formatting were left as far as possible intact.  I think
that might be a tall order.  And more and more we have to think about
UTF-8 encoding in the text.

There is already a mechanism for configurations for individual hosts,
in files under .../pc/.  Something more like that would, I think, be
more useful than this patch but it would be a bit more work.  I'm far
too busy with things that are broken to look at this myself, but I'd
welcome more discussion here on the list and hopefully at the end of
it a well thought out PR.

Finally a word on security.  In addition to my being a little unhappy
with what the current EditConfig.pl does with the main configuration
file, I'm also a little nervous about editing configuration files in
BackupPC by the combination of a Web server and a browser.  If I were
running the show in a large organization I'd probably lock that down,
because one of the biggest risks in any organization which uses a lot
of computers with browsers on them is that one of the browsers will be
compromised by something malicious.  Conceivably, then, a hacker might
be in a position to prevent backups from from happening [1] or even to
delete them all.  Just to be on the safe(r) side I tend to chown/chmod
my configs root/640.  OTOH there *is* something to be said for making
it easy(/easier) for a relatively unskilled user to change some of the
configuration.  I feel that the aggregate damage from large numbers of
inexperienced people being let loose with an unfamiliar text editor on
BackupPC's configuration files might significantly exceed that caused
by the occasional workstation compromise.  So I think we should all be
thinking very carefully about how we approach this for the future.

-- 

73,
Ged.

[1] Something not unlike this happened in an incident discussed here
on the list last week, although it turned out that it was by accident
and not by design.