[pkg-bacula-devel] Bug#681790: Bug#681790: Bug#681790: Bug#681790: /usr/sbin/bacula-dir: fails to upgrade database when database is on a remote machine

[Bart Swedrowski]

On 19 July 2012 09:01, AZ Imballaggi S.r.l. - Enrico Ghera
<enrico at azimballaggi.com> wrote:
> b) updates/upgrades:
>     * first of all dbconfig shoud read the package's conf, and generate a
> new one for itself.
>     * update/upgrade package

I'm of an opinion db-config behaviour was as expected and correct to its design.

While it's an awesome tool which greatly helps with upgrades, I
actually would be tempted to say its fully automatic behaviour should
be limited (and this limitation clearly communicated) to local
database installations only.  While it'd be great to have all the
possible configurations supported, the list of things that can
possibly go wrong with remote database is quite long and anyway, if
users moves database to remote host you can't really treat this setup
as "basic" anymore; user moves the database conciously and is supposed
to update dbconfig configuration as a part of this move.

My knowledge about dbconfig is not great, however reading packages
configs doesn't sound like dbconfig's job to me. If we wanted to do
this, again the list of things that can potentially go wrong is quite
long, eg. what if I split  bacula config into multiple files and
include one from within another one?  Should dbconfig read all of
them?  Some of them?  If so, which ones?

I think the correct tool for the job here would be Puppet, which could
manage Bacula as well as dbconfig flat configuration file and change
database location accordingly.