Error upgrading mysql database 2.10.5-1.bionic -> 2.11.0

mzac commented 5 years ago

Describe the bug

Did an upgrade from 2.10.5-1.bionic -> 2.11.0 and I got an error that it could not upgrade the 'icinga2' database, however my database is called 'icinga'. Why was it trying to find 'icinga2' ?

Setting up icinga2-ido-mysql (2.11.0-1.bionic) ...
Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
dbconfig-common: writing config to /etc/dbconfig-common/icinga2-ido-mysql.conf
creating database backup in /var/cache/dbconfig-common/backups/icinga2-ido-mysql_2.10.5-1.bionic.2019-09-19-20.33.23.
database does not exist.
applying upgrade sql for 2.10.5-1.bionic -> 2.11.0.
error encountered processing /usr/share/dbconfig-common/data/icinga2-ido-mysql/upgrade/mysql/2.11.0:
mysql said: ERROR 1049 (42000): Unknown database 'icinga2'
dbconfig-common: icinga2-ido-mysql configure: ignoring errors from here forwards
dbconfig-common: flushing administrative password

Start-Date: 2019-09-19  20:32:39
Commandline: apt upgrade
Install: libboost-thread1.67.0-icinga:amd64 (1.67.0-13.1.bionic, automatic), libboost-coroutine1.67.0-icinga:amd64 (1.67.0-13.1.bionic, automatic), libboost-context1.67.0-icinga:amd64 (1.67.0-13.1.bionic, automatic), libboost-filesystem1.67.0-icinga:amd64 (1.67.0-13.1.bionic, automatic), libboost-system1.67.0-icinga:amd64 (1.67.0-13.1.bionic, automatic), libboost-regex1.67.0-icinga:amd64 (1.67.0-13.1.bionic, automatic), libboost-program-options1.67.0-icinga:amd64 (1.67.0-13.1.bionic, automatic)
Upgrade: icinga2-bin:amd64 (2.10.5-1.bionic, 2.11.0-1.bionic), icinga2-doc:amd64 (2.10.5-1.bionic, 2.11.0-1.bionic), icinga2-ido-mysql:amd64 (2.10.5-1.bionic, 2.11.0-1.bionic), icinga2-common:amd64 (2.10.5-1.bionic, 2.11.0-1.bionic), icinga2:amd64 (2.10.5-1.bionic, 2.11.0-1.bionic)
End-Date: 2019-09-19  20:34:12

To Reproduce

Provide a link to a live example, or an unambiguous set of steps to reproduce this bug. Include configuration, logs, etc. to reproduce, if relevant.

Upgrade from 2.10.5-1.bionic -> 2.11.0

Expected behavior

It should determine the correct database stored in /etc/icinga2/features-enabled/ido-mysql.conf

library "db_ido_mysql"

object IdoMysqlConnection "ido-mysql" {
  user = "icinga",
  password = "<removed for github>",
  host = "localhost",
  database = "icinga"
}

Your Environment

Include as many relevant details about the environment you experienced the problem in

Version used (icinga2 --version): 2.10.5-1.bionic -> 2.11.0
Operating System and version: Ubuntu
Enabled features (icinga2 feature list): Ubuntu 18.04.3 LTS
Icinga Web 2 version and modules (System - About): 2.7.1
Config validation (icinga2 daemon -C): No errors

Additional context

I had a similar issue back on the 2.11 beta Icinga/icinga2#7393 could this be related?

Note that this upgrade I just did was not on the same system that I referenced in Icinga/icinga2#7393.

I was able to upgrade the database manually with the commands in the docs.

https://icinga.com/docs/icinga2/latest/doc/16-upgrading-icinga-2/#upgrading-mysql-db

mysql -u root -p icinga < /usr/share/icinga2-ido-mysql/schema/upgrade/2.11.0.sql

slalomsk8er commented 5 years ago

I had a similar problem on Debian 9. Since the installation I changed form a local database to a clustered one. I changed /etc/dbconfig-common/icinga2-ido-mysql.conf to the new values via dpkg-reconfigure but dbc_dbadmin= is useless without matching password for the remote dbc_dbserver.

In the end I skipped the schema upgrade in dpkg-reconfigure and did it by hand.

Possible points to improve the package:

check if /etc/dbconfig-common/icinga2-ido-mysql.conf and /etc/icinga2/features-enabled/ido-mysql.conf are out of sync
ask user for remote DB admin password to do the update even if remote?

dnsmichi commented 5 years ago

Given all the problems we had in the past years with dbconfig-common, I'd opt for retiring this for future database integrations and letting admins handle the database stuff on their own. It already is very well documented everywhere.

dnsmichi commented 5 years ago

For the IDO packages, we'll have to stick with dbconfig-common. Future iterations with IcingaDB will use a different method to do updates, or even move this into the admin's responsibility again.

Icinga / icinga-packaging