Bug#848137: problem with the upgrade of tango-db

[Paul Gevers]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20170104/049f7078/attachment-0001.sig>