Discussion:
Bug#848137: problem with the upgrade of tango-db
Add Reply
PICCA Frederic-Emmanuel
2017-01-03 15:00:07 UTC
Reply
Permalink
Raw Message
Hello, I would like to discuss about this bug [1]

I tryed to reproduce the scenary of piuparts in a virtual machine (gnome-box)

installed in 3 steps:
jessie base system
mysql-server (I need a working database)
tango-db (daemon)


It works ok, I have a running tango-db daemon (ps aux | grep tango)

then

replace jessie by stretch in the sources.list

apt-get update
apt-get install mysql-server (5.5 -> 5.6)

the tango-db is still working.


Now I installed the new default-mysql-server


apt-get install default-mysql-server (5.6 -> mariadb 10.1)

the tango-db daemon is still working.

Now I upgrade tango-db

apt-get install tango-db (tango8 -> tango9)

and during this upgrade I have a problem of right that you can see in the bug report.

I would like to know how to debug this problem, I tryed to export dbc_debug=1, But I got no real information about the failing mysqldump.

I would say that I know almost nothing about sql, but I can learn.

What is strange from mmy point of view, is that I created the table and populate it only with dbconfig-common.
So I find strange that the dump can not work.

Maybe this is a problem of compatibility between mysql/mariadb, because the dabatase was first created with mysql 5.5 and the upgrade is done via mariadb.

Are you aware of problem of right due to mariadb ?


thanks for your help


Fred

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848137


please CC me I am not on the mailing list
PICCA Frederic-Emmanuel
2017-01-03 20:30:01 UTC
Reply
Permalink
Raw Message
I am not sure that I follow what you are doing, but if you need the code
/usr/share/dbconfig-common/data/PACKAGE/upgrade-dbadmin/DBTYPE/VERSION
/usr/share/dbconfig-common/data/PACKAGE/upgrade/DBTYPE/VERSION
Hello Paul

I just try to use dbconfig-common like I did before,
(create the tango database, populate it with a few values and create some procedures.)

What is strange to me is that with dbconfig-common (jessie version), I end up with procedure owned by
root @ localhost

but when I use the dbconfig-common of stretch, the procedure are owned by tango @ localhost 5which is right)

I always used the non dbadmin script in order to configure my database.
This is why I do not understand why the mysqldump does not work anymore.
Does the dump changed between the jessie and strecth dbconfig-common ?

By change I mean.

In jessie it is run as root, but on stretch it is run as tango ?

Cheers

Fred
Paul Gevers
2017-01-03 21:40:01 UTC
Reply
Permalink
Raw Message
Hmmm,
Post by PICCA Frederic-Emmanuel
I just try to use dbconfig-common like I did before,
(create the tango database, populate it with a few values and create some procedures.)
What is strange to me is that with dbconfig-common (jessie version), I end up with procedure owned by
I always used the non dbadmin script in order to configure my database.
This is why I do not understand why the mysqldump does not work anymore.
Does the dump changed between the jessie and strecth dbconfig-common ?
By change I mean.
In jessie it is run as root, but on stretch it is run as tango ?
Let me check the (huge) delta between jessie and stretch (hopefully
tomorrow). I made major improvements in the code, but I don't
specifically remember anything related to this issue. Furthermore, I
don't rule out that this is indeed MySQL/MariaDB related. We/you could
also ask the maintainers list of those packages if the current behavior
rings a bell. Additionally, trying to do the tests as you did so far but
sticking to MySQL instead of moving over to MariaDB would be an
interesting and insightful exercise.
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).

Out of time now.

Paul
PICCA Frederic-Emmanuel
2017-01-04 18:10:01 UTC
Reply
Permalink
Raw Message
Hello,
Post by Paul Gevers
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.

I agreed also that I must fix the wrongly created procedure/tables due to the previous dbconfig-common behaviour.

Can you help me in this proces in order to produce the right snopset to put in my package (preinst ?) script.

I need to change the owner of the procedure from

root @ localhost -> tango @ locahost

Which kind of script should I add in my debian scripts ?

thansk for your help


Frederic
PICCA Frederic-Emmanuel
2017-01-05 17:30:01 UTC
Reply
Permalink
Raw Message
Hello,

I discuss with the tango-db upstream and he found that

this one line fixed the problem, befrore doing the tango-db upgrade

UPDATE mysql.proc SET Definer='***@localhost' where Db='tango';

Ideally it should be something like

UPDATE mysql.proc SET Definer='xxx' where Db='yyy';

where xxx is the dbuser and yyy the database name.à
It is true that for now my package works only if the database name is tango.


this is a limitation but I do not want to mix this into this bug report.

so can you help me write the right snipser at the right place in the debian scripts.

Or maybe I should just put the upgrade script og tango-db 9.2.5 intot eh dbadmin part with this fix at the end in order to have something consistant forthe next upgrade (tango 10)


Thanks for your help

Cheers

Frederic

Loading...