[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

[Alexander Golovko]

On Wed, 18 Jul 2012 22:44:57 +0200, Luca Capello wrote:
> Hi there!
>
> Alexander, thank you for the detailed explanation, which means that 
> this
> bug should stay open (and retitled, in case).
>
> On Wed, 18 Jul 2012 19:55:29 +0200, Alexander Golovko wrote:
>> On Wed, 18 Jul 2012 18:35:07 +0200, AZ Imballaggi S.r.l. - Enrico
>> Ghera wrote:
>>> Il 18/07/2012 18:03, Luca Capello ha scritto:
>>>> Hi there!
>>>>
>>>> On Wed, 18 Jul 2012 03:18:44 +0200, Alexander Golovko wrote:
>>>>> So, this is not a bug in package, but dbconfig-common habits.
>>>>> Ofcourse, we should describe database upgrade habits in
>>>>> README.Debian
>>>>> UPGRADE section.
>>>> If you want to do that, then please go ahead, but strictly 
>>>> speaking
>>>> this
>>>> is not something that belongs to Debian, but in upstream manual.
>>>> Debian
>>>> provides a way to manage local and remote database, via
>>>> dbconfig-common.
>>>> If the admin changes that, than she/he should *know* that 
>>>> automatic
>>>> upgrades could fail (Debian can not assure all possible
>>>> configurations).
>>
>> We should describe differences from upstream - dbconfig-common usage
>> and common troubles.
>
> I slightly disagree, simply because dbconfig-common is the Debian way 
> of
> doing such things.  If we go on the path of documenting differences 
> WRT
> upstream, than each package using dbconfig-common should do the same,
> which is IMHO plainly wrong.

You are right, will be better to make package more standard and 
similarly other packages with dbconfig-common.


>
>> It is something difficult for me, because english is not native for
>> me, but i will try later.
>
> Do not worry for the language, having a not-completely-English
> documentation is better than no documentation at all.
>
>>>> Enrico, I am sorry for the bug, but I bet that having configured 
>>>> the
>>>> remote database via dbconfig-common (thus via `dpkg-reconfigure
>>>> bacula-director-mysql`) would have resulted in a correct upgrade.
>>
>> No, we should not use dpkg-reconfigure for change database 
>> parameters
>> without database reinstallation.
>> If we run dpkg-reconfigure, dbconfig ask to reinstall database and
>> rewrite config file
>> In choice of "don't reinstall database", dbconfig rewrite config 
>> file
>> and add to it 'dbc_install=false', so this will stop future database
>> upgrades.
>
> IMHO this is a bug in dbconfig-common or in the way we use it, given
> that we should be able to use it *without* database reinstallation.

Argh, this is a my fail!
dpkg-reconfigure correctly work if choose do not reinstall database.
It was because i try on not very clean system.

But this is don't solve this problem, because it can change database 
parameters only with database reinstallation.
Yes, we can say reinstall to already existed database and then ignore 
error about already existed tables, but, IMHO, it is better to change 
config by hands and then run dpkg-reconfigure without database 
reinstallation.



>
>>> just to understand better (and avoid other useless bug reports):
>>> everytime I modify my database settings I should run
>>> dpkg-reconfigure?
>>> doing the work twice? (one for actual conf and one for dbconfig)
>>> or I should run dpkg-reconfigure and it updates my conf as well?
>>> or my brain is dead and I have not understood anything?
>>
>> If you change only database connect parameters (host, dbname, user,
>> password, etc), than you should not run dpkg-reconfigure, but should
>> make changes in two places:
>> 1. in bacula config
>> 2. in dbconfig files
>> (/etc/dbconfig-common/bacula-director-(mysql|pgsql|sqlite3).conf
>
> IMHO this is prone to errors, which is why I blindly thought that
> dpkg-reconfigure would have done the trick.

dbconfig-common can't rename database (#439080).
But changing /etc/dbconfig-common/*.conf files is not anything 
incorrect.

As i understand, it is normal for dbconfig-common to make changes in 
/etc/dbconfig-common/package.conf and then run dpkg-reconfigure package 
without database reinstallation.
It is a ususal for all debian packages, that use dbconfig-common. Am i 
right?

So, there best solution will be make bacula-dir.conf consistent on 
dpkg-reconfigure.
We can do this by two methods:
1. dbconfig-common will generate additional file from template with 
database parameters (dbc_generate_*) and include it from bacula-dir.conf
2. substitute variables itself. This is will be very simple, when we 
migrate config files under ucf control.



>
> Enrico, in the end you were right, which also means that you 
> discovered
> a bug in the Bacula packaging (or in dbconfig-common, I would say).
>
> Thx, bye,
> Gismo / Luca

-- 
with best regards,
Alexander Golovko
email: alexandro at ankalagon.ru
xmpp: alexandro at ankalagon.ru