[pkg-bacula-devel] Bug#825064: Bacula director does not start silently due to database mismatch

[Paul Gevers]

Hi

tl;dr: In the (long) past, the question during migration was different
and extremely confusing with respect to the underlaying logic. Klaus
probably got the old question, opted out of assistance and now had
problems during the upgrade. With respect to the current situation in
all involved packages, there is only a possible improvement in
dbconfig-common with respect to dpkg-reconfigure behavior.

I propose to reassign this bug to dbconfig-common to implement
dpkg-reconfigure options to opt-in for dbconfig-common support while not
reinstalling the database.

I'd like to note that while I was investigating what to write below, I
discovered three unrelated issues in two packages in how they react with
dpkg-reconfigure (in dbconfig-common and cacti), so whatever the outcome
of this bug is, it is going to improve the world. I will file those bugs
shortly.

On 24-05-16 22:40, Klaus Ethgen wrote:
> Am Di den 24. Mai 2016 um 18:02 schrieb Paul Gevers:
>> dbconfig-common will not reinstall the database on updates. If it ever
>> does that it is a grave bug. Klaus is right however that the database
>> can be reinstalled with dpkg-reconfigure, so you can loose the old
>> database that way, but that is intended behavior. The text he quotes is
>> however not the question that gets asked during upgrades. The text
>> during upgrades is given below and says nothing about reinstallation of
>> the database.
> 
> I didn't get the option at all to upgrade the database. I only always
> got the quoted question ever.

I am not sure if you are now talking about the current upgrade. If you
are than that is correct, you didn't get the question because you had
dbc_install=false. If you are talking about "ever" than something
clearly failed during the migration. Note however, this the question
that got asked (not the underlaying logic) has changed since
dbconfig-common 1.8.45 (released on 23 Feb 2010). As bacula migrated to
dbconfig-common support for their MySQL and PostgreSQL databases way
before that time (in 2006), I suspect you got the old (install) question
and this would explain why you haven't seen the question in mentioned in
my previous e-mail.

>> The reason why dbc_install=false drops the full support of
>> dbconfig-common is because that is the variable that is set during the
>> initial installation (and the only one if one opts-out of support). So
>> we need to check this before anything else. If you didn't want install
>> support, it doesn't make sense to ask if you want upgrade support.
> 
> And that might be the problem.

Why?

> At the initial installation that was
> handled via dbconfig, I already had a populated database that I couldn't
> risk to lose. For that reason I answered the already quoted question
> with "no" in the first place.

As mentioned, if bacula switched before 2010, than the bug that you got
the wrong question has long been fixed. A package that switches to
dbconfig-common MUST tell dbconfig-common the version in which the
switch took place. If you are upgrading from a version before the
switch, dbconfig-common will not install (I haven't checked yet, but I
believe not even before the question changed), but merely upgrades your
database.

> There was never a question about update.

As explained, with dbc_install=false that is to be expected.

> I never edited that file before. I always used dpkg-reconfigure (or the
> debconf question at the begin). And that was when the database already
> existed.

Interestingly, (and we could consider this a bug in dbconfig-common) you
can't get the dbc-install variable set to "true" via dpkg-reconfigure if
you are answering "no, I don't want you to reinstall the database". So
the only way to get dbconfig-common support after the first time is
answered with "no" is to edit the file. But, as it stands, you told the
package to NOT use dbconfig-common, and now you are expecting from the
package that even without dbconfig-common help it should do the right
thing? I think that is unreasonable to expect (although I grant you that
you may expect an option with dpkg-reconfigure to actually opt-in
again). Just so you know why I think the current behavior (again, minus
the reconfigure option) is correct, I am pointing you to the policy on
asking questions, paragraph 3.9.1¹ which says: "should ensure that the
user will only ever be asked each question once". Therefore, if you say
no, that is what we will honor.

> However, I don't think that the name should be changed but it should do
> what it is named for.

You just confessed that you never changed the file manually, so the name
of the variable doesn't matter. The question it stands for is, "do you
want dbconfig-common to manage the database on behalf of ${pkg}". And as
already noted, the question that is actually asked has been changed more
than 6 years ago.

> If install is false and upgrade is true, that is
> exactly what I have here and it should upgrade the database independent
> of the install setting.

Again, I can improve the documentation, but I am NOT going to change the
logic. dbc_install means: do you want dbconfig-common help at all.
dbc_upgrade only has meaning when you do.

> However, beside that problem of the upgrade itself, I also complained
> about that bacula-dir died silently and the only way to find out why is
> using the debug switch. More over, the init script told a successful
> restart.

Here I defer to the bacula-dir team. But pretty please (with a cherry on
top), never mix different issues in one bug report. Either file new
bugs, or (ask to) clone the existing one if that contains all the data
and follow up there.

Paul

¹
https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintscriptprompt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-bacula-devel/attachments/20160527/caffe3ca/attachment.sig>