"flush Privileges" Missing After "rename User" Command

[larsen]

Hi,

I just changed the host a user is allowed to connect from and then noticed that I had to manually execute “FLUSH PRIVILEGES” to make the changes work. Shouldn´t SQLyog automatically do this?

Using 8.8 beta 2

Lars

[peterlaursen]

HOW did you change it? Please elaborate step-by-step.

I think we use RENAME USER and then FLUSH should not be necessary (it only is when manipulating the mysql.user table directly with INSERT/UPDATE/DELETE statements). So it could also be a server bug. So what is the server version?

[larsen]

1. Click on the user manager icon

2. Select user

3. Change host

4. Click on “save changes”

Server version is 5.0.51a-24+lenny5-log

[peterlaursen]

OK .. I did this myself as see in HISTORY tab:

Code:

RENAME USER 'peter'@'localhost' TO 'peter'@'%';

In this case FLUSH PRIVILEGES is *not* required (only it we “UPDATE `mysql`.`user` SET … WHERE.. “as we did before the new User management GUI it is).

Looks like a bug with a server version (that is now also rather old) . But undoubtedly we have 5.0.45 or 5.0.51 in office (I don't here). I have already arranged with a developer that he will check tomorrow.

Also see this:

http://www.webyog.com/faq/content/1/178/en/sqlyog-is-a-client-for-the-mysql-server-_-but-what-server-versions-are-supported.html : “for 5.0 specifically we recommend 5.0.67 or higher.”

I know that some Linux users are reluctant to upgrade the MySQL version that shipped with the distro. But there really are reasons for this recommendation. Too many server bugs before 5.0.67.

[larsen]

'peterlaursen' wrote:

I know that some Linux users are reluctant to upgrade the MySQL version that shipped with the distro. But there really are reasons for this recommendation. Too many server bugs before 5.0.67.

Yes, so am I =)

The problem is that we have about 20 servers and you really don´t want to update all of them everytime a new release comes out – especially regarding that that might also add new problems. Updating to a tested version with “apt-get upgrade” is much easier and safer.

Though, Debian Squeeze is on it´s way bringing MySQL 5.1.49

Until then, I can surely live with that MySQL bug.

Thanks for your help =)

[peterlaursen]

Well .. maybe we can FLUSH in that case. It will do no harm. And 5.045 / 5.0.51 are still widely used really so if there is a simple workaround we could consider. It will then not be the only code-piece in SQLyog that works around server bugs.

But let us see this happening for ourselves first.

[vishal.pr]

Hi Larsen,

We tried to replicate the issue at our end with the exact server version, but we couldn't. Can you explain it step by step starting from create user to rename user.

Thank you.

Vishal P.R

[larsen]

Hmmm… I couldn´t reproduce it now either. The time it happened, a customer told me that the login wasn´t possible. It worked when I had flushed the privileges. Perhaps, there was some other reason at my customer´s side why it didn´t work in the first place.

Sorry, I should have tested this again by myself to see if I can reproduce the problem 🙁

[larsen]

I noticed this problem again (didn´t rename a user in a long time) after I changed the host a user is allowed to connect from. After a manual “flush privileges” it worked.

MySQL Version : 5.0.51a-24+lenny5-log

I know it is still the old version from Debian Lenny, but if an explicit flush would do no harm in other cases, I would appreciate it, if you simply issued it after renaming.

[peterlaursen]

To the question whether SQLyog should not automatically FLUSH PRIVILEGES the answer is that since we rewrote SQLyog User Management to use GRANT/REVOKE syntax in 8.6 this is not required anymore. FLUSH is required if you manipuate privilege tables with INSERT, UPDATE, DELETE statements directly. GRANT/REVOKE implicitily FLUSH'es – or rather it should.

But there are situations where FLUSH PRIVILEGES is required even though it should not be so. It is a bug with the MySQL server (some versions) reported and verified here: http://bugs.mysql.com/bug.php?id=61865. (there may be more reports of same).

[larsen]

Yes, I know that it is a bug in MySQL and the real problem is the old version, of course. Though, if it can be worked around by SQLyog and FLUSH PRIVILEGES after a RENAME (using SQLyogs user manager; this doesn´t use GRANT/REVOKE as far as I could see in the history tab!) and this doesn´t cause other problems, this would be nice.

[peterlaursen]

You are right that it does not seem that MySQL are in a hurry to fix this bug.  It would be harmless to FLUSH PRIVILEGES when the User Management dialog is closed.  We will do it in the next release (9.51) that will release this week (probably tomorrow or Wednesday)  

[larsen]

Cool, thanks!

To clarify: The flush will occur on closing the dialog and not after saving a user? I guess some people (including me) might have the dialog open, change and save something, not close the dialog, and test if the change worked (which it wouldn´t when the flush occurs later).

[peterlaursen]

We planned to excute FLUSH ..  when the dialog is closed only.

But do you suggest that we do it after every 'save changes'? As long as the UM dialog is modal I do not see much difference. If you have the dialog open you cannot use other areas of the program,

[larsen]

Yes, saving after every rename action would be better. For example: We have a user for a service (used by a customer) that is allowed to connect from one IP. When the IP changes, I would change it via the user manager too and without closing the dialog I would first check, if the service can connect again.

The problem I see is that the user normally assumes that pressing “save” is all he has to do. It´s common that after saving, everything works (well, most of the time ;-)).

[ashwin]

Hi Larsen,

Quote:

The problem I see is that the user normally assumes that pressing “save” is all he has to do.

We have released 9.51GA. In this build after you press 'Save Changes' in User manager 'FLUSH PRIVILEGES' will be executed. You can download it from [url=”http://http://webyog.com/en/downloads.php”%5Dhere%5B/url%5D

Regards,

Ashwin A

[larsen]

Cool, thx!

As always, it´s a pleasure reporting bugs/workarounds here 😉

[Author]

Posts