Bug#681790: [pkg-bacula-devel] Bug#681790: Bug#681790: /usr/sbin/bacula-dir: fails to upgrade database when database is on a remote machine
Il 18/07/2012 22:44, Luca Capello ha scritto: 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. 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. I agree on this. 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. also in my opinion doubling the places where to configure is too prone to errors. there should be a different way to make things, without doubling. maybe each package that requires dbconfig shoud be able to read the package's conf files and generate automatically the dbconfig's conf. it's a lot of effort but is transparent to users. this is how I think it should work: a) first installation: * run dbconfig asking wether to install on local machine or on remote one (also for new databases). * dbconfig shoud generate it's own conf files and place one example conf in the package's conf dir. * install package b) updates/upgrades: * first of all dbconfig shoud read the package's conf, and generate a new one for itself. * update/upgrade package this way if the sysadmin changes something in the package's conf on each subsequent upgrade/update dbconfig will find the right database. anyhow the syntax of configuration files is quite stable... this should be a one time work. 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). Wooo hooo! my first bug in Debian! Thx, bye, Gismo / Luca thank you all. Enrico -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681790: [pkg-bacula-devel] Bug#681790: Bug#681790: /usr/sbin/bacula-dir: fails to upgrade database when database is on a remote machine
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. 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. 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. 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 pgp8JdbOmEUTG.pgp Description: PGP signature
Bug#681790: [pkg-bacula-devel] Bug#681790: Bug#681790: /usr/sbin/bacula-dir: fails to upgrade database when database is on a remote machine
tags 681790 - moreinfo notfound 681790 5.2.6+dfsg-1~bpo60+1 thanks Enrico, thank you for dbconfig-common config file and apt log. package definetelly was installed with dbconfig-common, but then database was dropped or cleaned. debconf bacula-director-mysql/dbconfig-install and dbc_install was set to false when package upgrade fail and dbconfig ask you to reinstall database. So, this is not a bug in package, but dbconfig-common habits. Ofcourse, we should describe database upgrade habits in README.Debian UPGRADE section. Whith current /etc/dbconfig-common/bacula-director-mysql.conf dbconfig will not ask you about database upgrades. If you want automatic upgrades, please change 'dbc_install=true' and set correct values for dbc_dbuser, dbc_dbpass, dbc_dbserver, dbc_dbport, dbc_dbname, dbc_dbadmin. On Wed, 18 Jul 2012 01:11:28 +0200, Enrico Ghera - AZ Imballaggi S.r.l. wrote: On Tue, 17 Jul 2012 20:53:52 +0100, Bart Swedrowski b...@timedout.org wrote: Package: bacula-director-mysql Version: 5.2.6+dfsg-1~bpo60+1 Severity: important File: /usr/sbin/bacula-dir On 16 July 2012 16:45, Enrico Ghera enr...@azimballaggi.com wrote: * bacula-director-mysql/dbconfig-install: false This indicates that something went wrong with dbconfig; did you use dbconfig originally to set up the remote database or did you install it locally initially and perhaps *then* moved it to remote host? as far as I can remember I installed locally and then configured by hand the remote mysql host. my memories are misty... it was more than an year ago. Also, could you post contents of files /etc/dbconfig-common/bacula-* (grepping out sensitive information, naturally) # automatically generated by the maintainer scripts of bacula-director-mysql # any changes you make will be preserved, though your comments # will be lost! to change your settings you should edit this # file and then run dpkg-reconfigure bacula-director-mysql # dbc_install: configure database with dbconfig-common? # set to anything but true to opt out of assistance dbc_install='false' # dbc_upgrade: upgrade database with dbconfig-common? # set to anything but true to opt out of assistance dbc_upgrade='true' # dbc_remove: deconfigure database with dbconfig-common? # set to anything but true to opt out of assistance dbc_remove='' # dbc_dbtype: type of underlying database to use # this exists primarily to let dbconfig-common know what database # type to use when a package supports multiple database types. # don't change this value unless you know for certain that this # package supports multiple database types dbc_dbtype='mysql' # dbc_dbuser: database user # the name of the user who we will use to connect to the database. dbc_dbuser='bacula' # dbc_dbpass: database user password # the password to use with the above username when connecting # to a database, if one is required dbc_dbpass='#' # dbc_dbserver: database host. # leave unset to use localhost (or a more efficient local method # if it exists). dbc_dbserver='' # dbc_dbport: remote database port # leave unset to use the default. only applicable if you are # using a remote database. dbc_dbport='' # dbc_dbname: name of database # this is the name of your application's database. dbc_dbname='bacula' # dbc_dbadmin: name of the administrative user # this is the administrative user that is used to create all of the above dbc_dbadmin='root' # dbc_basepath: base directory to hold database files # leave unset to use the default. only applicable if you are # using a local (filesystem based) database. dbc_basepath='' ## ## postgresql specific settings. if you don't use postgresql, ## you can safely ignore all of these ## # dbc_ssl: should we require ssl? # set to true to require that connections use ssl dbc_ssl='' # dbc_authmethod_admin: authentication method for admin # dbc_authmethod_user: authentication method for dbuser # see the section titled AUTHENTICATION METHODS in # /usr/share/doc/dbconfig-common/README.pgsql for more info dbc_authmethod_admin='' dbc_authmethod_user='' ## ## end postgresql specific settings ## there I can see the password is not the one actually in use, and the host is not specified, assuming local. I don't remember being asked about databases during the first installation. maybe it's my fault. should I correct the content of /etc/dbconfig-common/bacula-director-mysql.conf to reflect the actual configuration? Regards, Bart ___ pkg-bacula-devel mailing list pkg-bacula-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-bacula-devel -- with best regards, Alexander Golovko email: alexan...@ankalagon.ru xmpp: alexan...@ankalagon.ru -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a
