Bug#971256: dbconfig-common: autopkgtests fail on unexpected strings from MariaDB 10.5
> > I did not find any code that would change the username and for recent > > years the setting has said "user = root", and before that it was > > "user = debian-sys-maint" > > This is (or used to be) the MySQL default. Is MySQL now also using the > socket authentication and root? Yes, also MySQL in Debian/Ubuntu has also moved to passwordless root and no new install needs the debian.cnf file anymore. > > One option could potentially be that if dbconfig-common does not find > > the username, it could default to just "root". > > I guess that could work, if it works for MySQL as well. Or does MySQL > still always create the filled /etc/mysql/debian.cnf file? Yes, it will work for MySQL as well. However, I am now about to merge on master the following change: https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/a6583c15226ad9a0ca37861e1bd01057bcff32a5 This would partially revert the debian.cnf change on new installs so that dbconfig-common can again find the username entry, while at the same time documenting that in the long run this file should be obsoleted.
Bug#971256: dbconfig-common: autopkgtests fail on unexpected strings from MariaDB 10.5
Hi Otto, On 02-10-2020 15:44, Otto Kekäläinen wrote: > The /etc/mysql/debian.cnf file is only root-readable, and intended for > root users to be able to access the database console e.g. when the > maintainer scripts run and start/stop the server. That's exactly why dbconfig-common reads it. > The new way of using > socket authentication is a superior way from both security and > management point of view. The file has been obsolete for a couple of > years and now I emptied the contents of it. Ack, but you share this file with MySQL. > According to codesearch.debian.net there are quite a few places that > run `mysql --defaults-file=/etc/mysql/debian.cnf` and they will fail > if the file is missing, so it is now there, but empty. In the current implementation, dbconfig-common will fail both ways, empty or absent. > I did not find any code that would change the username and for recent > years the setting has said "user = root", and before that it was > "user = debian-sys-maint" This is (or used to be) the MySQL default. Is MySQL now also using the socket authentication and root? > One option could potentially be that if dbconfig-common does not find > the username, it could default to just "root". I guess that could work, if it works for MySQL as well. Or does MySQL still always create the filled /etc/mysql/debian.cnf file? > I will wait for a couple of days to see if anybody else sends feedback > about /etc/mysql/debian.cnf and then decide what to do. Same for me. Paul signature.asc Description: OpenPGP digital signature
Bug#971256: dbconfig-common: autopkgtests fail on unexpected strings from MariaDB 10.5
Thanks for researching this! The /etc/mysql/debian.cnf file is only root-readable, and intended for root users to be able to access the database console e.g. when the maintainer scripts run and start/stop the server. The new way of using socket authentication is a superior way from both security and management point of view. The file has been obsolete for a couple of years and now I emptied the contents of it. According to codesearch.debian.net there are quite a few places that run `mysql --defaults-file=/etc/mysql/debian.cnf` and they will fail if the file is missing, so it is now there, but empty. I did not find any code that would change the username and for recent years the setting has said "user = root", and before that it was "user = debian-sys-maint" One option could potentially be that if dbconfig-common does not find the username, it could default to just "root". I will wait for a couple of days to see if anybody else sends feedback about /etc/mysql/debian.cnf and then decide what to do.
Bug#971256: dbconfig-common: autopkgtests fail on unexpected strings from MariaDB 10.5
Hi Otto, From IRC (#debian-mysql) on 28 September: [21:42:11] ottok: dbconfig-common parses /etc/mysql/debian.cnf [21:42:22] did the content of that file change? [21:42:36] I'm now only seeing this in my unstable lxc [21:42:46] # Automatically generated for Debian scripts. DO NOT TOUCH! [21:43:04] shouldn't there be some root set (with password)? [21:44:28] at least it seems to me that the test fails due to this empty config file [21:44:44] -*- elbrus is generating a testing lxc to check [22:12:17] I think both mysql and mariadb have moved away from root password as default, and instead use unix socket authentication [22:12:54] So system root can log in without a password [22:20:49] # cat /etc/mysql/debian.cnf [22:20:49] # Automatically generated for Debian scripts. DO NOT TOUCH! [22:20:49] [client] [22:20:49] host = localhost [22:20:49] user = root [22:20:49] password = [22:20:49] socket = /var/run/mysqld/mysqld.sock [22:20:49] [mysql_upgrade] [22:20:49] host = localhost [22:20:49] user = root [22:20:49] password = [22:20:49] socket = /var/run/mysqld/mysqld.sock [22:21:28] but in the current implementation dbconfig-common still processes the file (at least in the test) [22:21:48] I'll check tomorrow if the production code does so too [22:27:10] well, at least https://salsa.debian.org/debian/dbconfig-common/-/commit/252b921f6a6a50e6d98d1c11bb71f2810d7f2278 is still in place [22:27:14] so that needs updating [22:27:55] which means that MariaDB in unstable broke packages that need dbconfig-common to install [22:28:19] not saying MariaDB needs to fix it, but it shouldn't migrate to testing as-is So, the summary is that dbconfig-common as it currently is relies on /etc/mysql/debian.cnf to contain at least the username for connecting (and the password for systems that don't do socket authentication): # Now we are pretty sure we can use the password # Command taken from mysql-server-5.5.postinst script dbc_dbadmpass="$(sed -n 's/^[ ]*password *= *// p' /etc/mysql/debian.cnf | head -n 1)" # We also want to obtain the dbc_dbadmin from this file as MySQL has # debian-sys-maint, but MariaDB may have root. dbc_dbadmin="$(sed -n 's/^[ ]*user *= *// p' /etc/mysql/debian.cnf | head -n 1)" I implemented this after a discussion I had with you at FOSDEM some years ago. What's the proposal I do now? Paul signature.asc Description: OpenPGP digital signature
Bug#971256: dbconfig-common: autopkgtests fail on unexpected strings from MariaDB 10.5
Hi Otto, Thanks for contacting me. On 28-09-2020 10:22, Otto Kekäläinen wrote: > The command3 seems to be failing on unexpected output from MariaDB (if > I read the output correctly). Yes. > -creating database testdbname: success. > -verifying database testdbname exists: success. > +sanity check failed for dbc_dbadmin. > > -dropping database testdbname: success. > -verifying database testdbname was dropped: success. > +sanity check failed for dbc_dbadmin. > > -checking privileges on database testdbname for testdbuser@localhost: > user creation needed. > -granting access to database testdbname for testdbuser@localhost: success. > -verifying access for testdbuser@localhost: success. > +sanity check failed for dbc_dbadmin. > > -checking privileges on database testdbname for testdbuser@localhost: ok. > +sanity check failed for dbc_dbadmin. > > -revoking access to database testdbname from testdbuser@localhost: success. > +sanity check failed for dbc_dbadmin. > > > Maybe the test should be updated to expect new strings..? What, ignore a "sanity check"? That must be there on purpose. Let me check what's going on. Paul signature.asc Description: OpenPGP digital signature
Bug#971256: dbconfig-common: autopkgtests fail on unexpected strings from MariaDB 10.5
Package: dbconfig-common Noticed that autopkgtests started failing with the upload of MariaDB 10.5 to unstable. The command3 seems to be failing on unexpected output from MariaDB (if I read the output correctly). >From >https://ci.debian.net/data/autopkgtest/testing/amd64/d/dbconfig-common/7197597/log.gz -creating database testdbname: success. -verifying database testdbname exists: success. +sanity check failed for dbc_dbadmin. -dropping database testdbname: success. -verifying database testdbname was dropped: success. +sanity check failed for dbc_dbadmin. -checking privileges on database testdbname for testdbuser@localhost: user creation needed. -granting access to database testdbname for testdbuser@localhost: success. -verifying access for testdbuser@localhost: success. +sanity check failed for dbc_dbadmin. -checking privileges on database testdbname for testdbuser@localhost: ok. +sanity check failed for dbc_dbadmin. -revoking access to database testdbname from testdbuser@localhost: success. +sanity check failed for dbc_dbadmin. Maybe the test should be updated to expect new strings..?
