Scenario: 1) create virtual server "dev.newsite.com" with MySQL dbase "newSite" and "newUser" admin. 2) go to WebMin add database permission for dbase "newSite" for user "oldUser" (MySQL now shows access to the data base for two users)
3) finish development and port content to "oldSite" in /home. 4) go virtualMin, dev.newsite.com --> edit databases -->disassociated dbase "newSite" from this virtual server. 5) delete virtualServer "dev.newsite.com" 6) go to WebMin --> MySQL Server --> Database Permissions. 7) both users previously assigned to this, now disassociated dbase, are gone. 8) it should only delete the permissions for dbase "newSite" / user "newUser" and leave the permissions for dbase "newSite" user "oldUser" intact, since this latter is in now way connected to the virtual server being deleted and because the database has been disassociated.
Comments
Submitted by JamieCameron on Tue, 01/25/2011 - 15:07 Comment #1
From looking at the code, I can't see how this could happen ...
Did the old and new users perhaps both have logins that started with the same 16 characters?
Submitted by katir on Tue, 01/25/2011 - 15:30 Pro Licensee Comment #2
Nope
New user for devsite was "devtoday"
and the old user was "htoday"
so, close, but not same 16 chars.
but possibly if your algorithm matched them because of the last 5 chars being the same?
Submitted by JamieCameron on Tue, 01/25/2011 - 15:38 Comment #3
No, having the last 5 chars the same wouldn't trigger this..
So which domain was the "oldUser" created under? The one being deleted, or the other domain?
Submitted by katir on Tue, 01/25/2011 - 15:57 Pro Licensee Comment #4
1) create new domain: dev.hinduismtoday.com 2) admin user: devtoday; content: /home/devtoday; dbase devtoday 3) WebMin --> Database permissions -- Add database permissions --> choose dbase "devtoday" add user "htoday" with all permission "all" 4) disassociate dbase devtoday 5) delete virtual server "dev.hinduismtoday.com" 6) database permissions for both users devtoday and htoday) for devtoday disappeared.
Well at this point I can't really spend time trying to replicated this, but will watch for it in the future, if you code seems solid and this should not happen, then I have no response to that, other than I can say for sure I did do the above.
We can leave this as a gremlin for now... or if you can test it yourself and see that other users' permissions for a disassociated database are not removed on removal of the domain under which it was originally created, then it falls under the "works for me, cannot replicate" bug category... i.e not a bug, but a gremlin (my term for issues for which there are no explanations and the time and mental re-estate required to pursue them are counter-productive)
Submitted by JamieCameron on Tue, 01/25/2011 - 16:09 Comment #5
Where was the user
htodaycreated in Virtualmin though? If it was created in the domaindev.hinduismtoday.com, then it being deleted is actually expected ..Also, are you sure the user wasn't removed from "Database permissions" at step 4, when the dis-association happened?
Submitted by katir on Tue, 01/25/2011 - 16:37 Pro Licensee Comment #6
user htoday has been in place for "years" i.e. no, it was not created in the domain dev.hinduismtoday.com, but was a pre-existing domain user (/home/htoday + it's own dbase) I manually added this user in the permissions for the new database "devtoday."
"Also, are you sure the user wasn't removed from "Database permissions" at step 4, when the dis-association happened?"
You got me there. I would not know as I did not check the status of user permissions for the dbase "devtoday" after disassociating it. I naively assumed the user "htoday" would persist for that database and straight away ent and deleted the dev.hinduismtoday.com server.
Much to my stomach churning, heart-pounding dismay when I went to "www.hinduismtoday.com" XOOPS told me that it could not access the database and I had one "hellavuh" scary moment, thinking the dbase "devtoday" had been deleted (even after disassociation) But relieved to find I only had to re-add the htoday user in the database permission for devtoday and it started working again.
Submitted by JamieCameron on Tue, 01/25/2011 - 17:11 Comment #7
Ok, I see the real cause now .. it is the dis-association that incorrectly causes the user to be deleted. I will fix this in Virtualmin 3.84.
Submitted by katir on Tue, 01/25/2011 - 19:19 Pro Licensee Comment #8
Great, glad you found it... and I'm glad to know I'm not daft. (smile)
cheers from Beautiful Kauai
Submitted by Issues on Tue, 02/08/2011 - 19:19 Comment #9
Automatically closed -- issue fixed for 2 weeks with no activity.