Hi Frederic-Emmanuel, Andreas, @Andreas, am I correct in the assumption that jessie to stretch with tango-db was fine until MariaDB became the default? Or was this migration with tango-db just never tested before? Have you seen other dbconfig-common dependent packages fail since MariaDB became default (or maybe since dbconfig-common 2.0.5 (26-08-2016)?
In the former case, I believe that the issue at hand is that MariaDB is stricter in permissions that MySQL and either MariaDB needs to mimic MySQL more in this respect or dbconfig-common needs to cope with that (not nice because dbc will need to get admin privileges just to dump the database, even when it otherwise wouldn't need it. I propose we start asking the MariaDB maintainers what they know/think. On 04-01-17 19:00, PICCA Frederic-Emmanuel wrote: >> I am suspecting that this commit may be related to the current behavior: >> https://anonscm.debian.org/cgit/collab-maint/dbconfig-common.git/commit/?id=acdb99d61abfff54630c4cfba6e4452357a83fb9 > >> I believe I implemented there that the drop of the database is performed >> with the user privileges instead of the dbadmin privileges because I >> believed one should always have the rights to drop the db. Apparently I >> was wrong. We may need to clone or reassign this bug to dbconfig, but >> I'm not sure yet if there aren't more things, or if tango-db should work >> around the issue (which may be created by buggy dbconfig-common behavior >> of the past). > > I can not give an educated guess if the current logic of dbconfig-common is > good or not. > I do not have enough knowledge of SQL/MySQL/Postsgresq etc... > > This problem could affect other package using dbconfig-common. Agree. Although I still don't understand why in jessie it was root that owned the procedure. What I suspect is that the procedures are owned by root because the database was created by root. Since the commit referenced above, the database for MySQL is created with user credentials, so maybe in new databases, procedures are owned by the user. Once I have enough time, I'll try to figure out. > I agreed also that I must fix the wrongly created procedure/tables > due to the previous dbconfig-common behaviour. Hmm, not so quick ;). I believe dbconfig-common should be robust against the issue at hand. But indeed, once the dumping goes well, I expect the upgrade to fail slightly later because I *expect* the tango user doesn't have the privileges to delete the procedures owned by root (this is the next step in the upgrade code of tango-db).. *If* this is a MariaDB specific issue and the MariaDB maintainers are willing to mimic MySQL behavior (assuming this is the issue) than both tango-db and dbconfig-common don't need to do anything. However, if they don't want this behavior (which I expect), or if it isn't MariaDB specific, then depending on the real root cause of why root owns the procedures, both dbconfig-common and tango-db need to fix something. dbconfig-common needs to be robust against root owned procedures (and maybe other things) in the dumping code, and tango-db needs to fix the ownership of the procedures. For the latter, I can only advice once we have established what determines who owns the procedures. > Can you help me in this proces in order to produce the right snopset > to put in my package (preinst ?) script. I'll try to help, once we know the root of the ownership. > I need to change the owner of the procedure from > > root @ localhost -> tango @ locahost Not sure. > Which kind of script should I add in my debian scripts ? Not sure yet. It depends on the answer to all my questions. Paul Side note: tango-db is buggy, in the sense that the MySQL code to create the procedures and tables is assuming the database name is tango. However, the system administrator has the freedom (with dbconfig-common) to choose a different database name (and database user) if (s)he wishes.
signature.asc
Description: OpenPGP digital signature
