I migrated a web site from a dedicated server with multiple sites on the same box to three different Linode Cloud instances. For one of these sites I migrated the database separately and changed it's name. On the old box, the database was "xoop_108" on the new cloud instance it is "hinduism_today" and this is the only database on this cloud instance. I also installed the non-pro free version of VirtualMin, since I do not require multiple server management...
During migration I also pulled over the VM "stuff" and in the install scripts I see an old PHPMyAdmin script which points to the old directory.. and it indicates "directory manually deleted." So I deleted that script, which was still pointing to the now, no-existent "xoop_108" database.
After that, I got clean new, shortlist of scripts I could install (much shorter than the pro-version)... OK so far so good.
I clicked on the phpMyAdmin script installer and try to install: it offers the option to use the existing setting or from "selected databases"
But in the selected databases field there is the old name:
xoops_108 (mySql)
ergo: Bug: the installer is not scanning for existing databases... but is picking up something deep inside your virtualMin/webMin configuration that came over with the migration.
So: blocker: there is no way for me to set the phpMyAdmin installer script to the new "hinduism_today" database.
Of course I could install PhpMyAdmin on my own, and make it all work, but I prefer doing it via VirtualMin to maintain the "integrity" of the web management framework. If that makes sense....plus I thought you might like to know about this bug... hence this report.
Comments
Submitted by JamieCameron on Mon, 07/06/2015 - 01:29 Comment #1
It sounds like the list of databases Virtualmin thinks are associated with the domain is out of date. Check that on the Edit Databases page that the databases listed are the ones you expect to be associated with the domain - otherwise you may have to use the import feature on that page.
Submitted by katir on Mon, 07/06/2015 - 18:04 Pro Licensee Comment #2
Good call: I did have to import the database that was needed. BUT whatever VirtualMin did in the set up of PhpMyAdmin when I ran the install script has prevented the administrative user of this web site to log into the mySQL Server... I can only get in thru the PHPMyAdmin log in screen as root.
I can't really can't allow that log in to be given out those on the team that need to use PHPMyAdmin.
In previous scenarios where I installed PHPMyadmin myself it was as simple matter of downloading source to public_html, unzip, change the directory name for obscurity, run the setup... then go into WebMin, set the user and database permissions. Go to a browser and log in, phpMyAdmin with one of those users, who would then only see any database that user has access to.
In this scenario, there is one user (the virtual server owner aka "admin") and one database. But admin cannot login even though the MySQL permissions are all set correctly.
does VirtualMin do any write to any phpMyAdmin files after the scripts are unzipped? I did change the directory name after the install and now the install script says
Version to install 4.4.10 (Latest) Installation status Directory has been manually deleted
But does not give me any option to manually change the directory. Now that PHPMyAdmin is in fact, associated with the database, I cannot delete the script as suggest by VM
I'm thinking now I really should have done this manually as VM is just getting in the way of something that should be really simple...
Submitted by JamieCameron on Tue, 07/07/2015 - 01:48 Comment #3
It looks like Virtualmin is confused by the manual directory change, which isn't a good idea as it prevents upgrades.
However, you can fix this manually by editing the file under /etc/webmin/virtual-server/scriptlog/XXX (where XXX is the domain's unique ID) and changing the directory in the file.
Submitted by katir on Tue, 07/07/2015 - 13:01 Pro Licensee Comment #4
Thanks Jamie: I did that ... edited 1436217335305411.script and restarted webmin
but the log in to phpMyAdmin still fails using the web site owner/password invoked via the new path which is
www.hinduismtoday.com/theNewDirectoryName
Log in screen is invoked OK.. So PHPMyAdmin is installed and functional, and I can log in as root (which is bad... I can't, obviously give that out) and see and operate on the dBase....i.e.
still does not work for the website owner "hindutoday" edit the script file to match... but I wonder... does the install script settings even impact the PhpMyAdmin log in at all? i.e. PhpMyAdmin is not reading this file to function correctly. Is It? I think I have some other issue with the PHPMyAdmin not recognizing the MySql User/Database permissions settings...
opts_path=/theNewDirectoryName opts_auto=0 desc=Under public_html/theNewDirectoryName opts_all_langs=0 id=1436217335305411 partial= user=hindutoday opts_phpver=5 opts_db= url=http://hinduismtoday.com/theNewDirectoryName/ name=phpmyadmin opts_dir=/home/htoday/public_html/theNewDirectoryName pass=AngelsDontWorryAboutVolcanoes version=4.4.10
Submitted by andreychek on Tue, 07/07/2015 - 13:14 Comment #5
phpMyAdmin uses the database user's credentials to log in. That can be the same as the Virtual Server owner, but it doesn't have to be.
So if your database uses a different username or password, that could occur.
For example, when using hashed passwords, the MySQL user would have a different password.
What if you set a different password in Edit Databases, does that help?
Submitted by JamieCameron on Tue, 07/07/2015 - 18:37 Comment #6
Also, be aware that Virtualmin doesn't configure a login in phpMyAdmin at all - instead it just uses whatever username and password the user enters when accessing phpMyAdmin.
Submitted by katir on Wed, 07/08/2015 - 20:40 Pro Licensee Comment #7
Solution: as it turns out the migration from the old server brought over a MySQL user that had the same name as the main admin user/owner for the site but not the correct password. I re-entered the password in the MySQL user (same user name as: ) password of the main site "Administration password" .... now it works.
Case closed