[Rear-users] Hi to the ReaR community
lesmikesell at gmail.com
Wed Jan 25 14:50:28 CET 2012
On Wed, Jan 25, 2012 at 6:07 AM, Dag Wieers <dag at wieers.com> wrote:
>> What prevents you from plugging extra scripts into ReaR on individual
>> hosts? ReaR is meant to be open and modular, so why not make use of this?
> You can ask the same question regarding the pre and post backup scripts.
> Why not have the user add their own scripts and leave it out of Rear ?
> I am not convinced that it's a good practice to have individual
> customizations in /usr/share/rear, ever. A company can do this as part of
> their own custom package if this is required on all of their servers, but
> modifying individual servers (or even packaging individual packages for
> configuration) is not something I would advise.
In the Red Hat style of things, you'd probably let your RPM create a
ReaR directory in /etc/sysconfig and have either a file or directory
that could be created there for each event - or pre/post files where
you'd source the pre version to override variables to control the
stock code (and possibly execute something) and the post would execute
after the stock event. This would include steps in both the backup
runs and things that get copied/included in the restore environment.
An RPM could create the directory and possibly some template files but
would never modify the local changes in updates.
> Not only is it confusing to have individual files in a /usr directory, it
> makes it hard to troubleshoot different behaviour just because these files
> are under the normal radar. Same problem if you add them to per-host
> custom config package, it makes it harder to tell what's different.
Exactly. It is best to abstract local changes from any packaged
files. And even better if they are planned in a way where it would be
easy to wrap a web-form interface around edits that are likely to be
>>> My concern here is that if we introduce something now for the time being,
>>> we will have to maintain compatibility at a later stage, while if we think
>>> it through now, we may never need anything else, ever. (Wishful thinking
>>> on my part ;-))
>> I won't be afraid of imcompatible changes if they happen in a major
>> release, IMHO that is one reason to bump the major release number.
As long as developers keep making incompatible changes, users will
keep avoiding it. At least that's the way I think. It's one thing to
maintain a system for a client where they trust/pay you to fix the
incompatibilities that are introduced, and something else for users
that install the code on their own and have to hope it keeps working
>> I think that if somebody needs pre/post backup scripts let them submit the
>> patch for it and then we see again.
> I don't mind patches at all. But Jeroen already proposed patches that
> fixes this requirement (and any future similar requirement) and only a few
> paragraphs ago you asked me what's wrong with plugging extra scripts into
It would not make any more sense for me to submit a patch to invoke a
restore over ssh from my backuppc server than it would to expect
RedHat to patch my IP addresses into the distributions. Those are
changes that need to be part of the local config and never changed by
updates. And they might be simpler to add if they didn't have to
worry about affecting anything else except setting some documented
lesmikesell at gmail.com
More information about the rear-users