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

Fri May 27 12:34:36 UTC 2016

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,

Am Fr den 27. Mai 2016 um 13:08 schrieb Paul Gevers:
> 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.

Nice. :-)

> > 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.

True, with upgrade I did not get any question.

I got this (and only this) question when using dpkg-reconfigure.

> 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.

Well, I do not know how long, but I use bacula for really long time now.
I have file dates up to begin of 2009 but using bacula much longer.

As database, I always used sqlite. (And yes, I know that it might be
dangerous to use eatmydata as preload and that mysql or postgresql might
be a better solution. Without that preload, the backup postprocessing
(feeding data into the database) needs more than 1½ hours instead of
far under 1 minute now. And the danger to exactly break in that small
time is much lower than in 1½ hours.)

> >> 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?

Well, I want to use the upgrade but not the install of a new database.

> > 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.

Well, I used dpkg-reconfigure to get that question I pasted.

> > There was never a question about update.
> 
> As explained, with dbc_install=false that is to be expected.

I mean, there as never a question about that even when dbc gots
installed in the begin.

> > 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?

Well, from the user perspective, I just vote for not overwriting my
existing database. I did not get any question about migrating the
database. (That was working bevore bacula switched to dbc.)

> 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.

Thats fine. But as stated above, the quote came from a recent manual run
of dpkg-reconfigure.

> > 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.

True.

> 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.

Well, it asked to purge my existing database.

> > 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.

Well, that was the first reason I posted that bug. The dbc stuff is the
underlying problem cause.

Regards
   Klaus
- -- 
Klaus Ethgen                              http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16   Klaus Ethgen <Klaus at Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Charset: ISO-8859-1

iQGcBAEBCgAGBQJXSD7TAAoJEKZ8CrGAGfasBy0L/3Ow/SMcxWDy+sgtW8OqqgAp
rYGPRmr3MwJLz3ptOKQxFVXiXqtdXxz12RZ9/hx65CtrUyWT3Fv4qsU8iYFCuy5Z
1NMDIKkM75Bw8G8IVehHFzwFBi2T0jUwVWA6oTsR5IboOMiCwvpd3VkdObolEFmL
l+E8R65PmpNmHoedxh3rzmZpTPgwAFK7aCrC0WkYkrCWFhJSNzCRg4TFXnrFjMNv
IQ180V++toYCGxg8UHuYznWJYxH7QGd+u9/Z98MEXNTVuR/WMZmCusjkZwA+5oKF
1Pk1C4Pfu1lW4OzT8S6xiouz584Rp2S0xi/qDdZn4WrpDzQFkA9p3Dlit9ma0I5J
800oorz5Wt+In9LzYQ8euxG3XDbo8eru9s15zNjhMLMn+lUQv+rdMUH9D+lU6hIN
L4JZqiEBUI0o6Yh+WtTXLRyMyvOHeReFxRy+IC2Iclz+97usA8LdlryCgUiUbnn/
1oNJvZdaKFCy2KiN7fxNdEp4NzljfTh4PM0lQuVfhw==
=e27f
-----END PGP SIGNATURE-----