Joomla 3.1.5 install script does not use the database-specifc password to insatall (database creation works)

Submitted by beat on Thu, 09/05/2013 - 04:57

Hi, Title says it all.

On a long-existing customer account, the customer changed his username (through WHMCS, which changed virtualmin's user password via API).

As configured, database password didn't change, which is good otherwise installed scripts would have stopped working.

The customer can create databases, and when he installs a script, the database is created fine. However, the script fails installing:

Found http://joomlacode.org:80/gf/download/frsrelease/18622/83486/Joomla_3.1.5-Stable-Full_Package.tar.gz in cache ..

Configuring webserver PHP settings ..
.. already done.

Applying web server configuration ..
.. done

Now installing Joomla version 3.1.5 ..

    Database connection failed : DBI connect failed : Access denied for user 'xxxxxxx'@'localhost' (using password: YES) 1376.

.. failed! See the error message above for the reason why.

Applying web server configuration ..
.. done
Status: 
Active

Comments

Submitted by andreychek on Thu, 09/05/2013 - 08:23

Jamie may need to comment on why that's occurring and what may have caused it -- but I'm curious if you're able to correct it by logging into Virtualmin, going into Edit Virtual Server -> Configurable Options, and resetting the Administrative Password.

It may be that somehow, what Virtualmin thinks is the password may have gotten out of sync with reality, and resetting that may resolve the issue you're seeing.

Submitted by JamieCameron on Thu, 09/05/2013 - 12:24

Is the problem here that Virtualmin is using the wrong username to connect to MySQL (xxxxxx in the error above), or the wrong password?

Submitted by beat on Thu, 09/05/2013 - 12:53

Username is correct. I removed the username as it was too unique (and replaced by xxxx's as usual).

I had also tried to-re-set the password from whithin Virtualmin's edit server screen, no changes.

Creating databases works, even from within the joomla install script. Created database is left over after install, and can be deleted by the customer, so it's really probably populating the database from the joomla script that doesn't use the right password imho.

Submitted by JamieCameron on Thu, 09/05/2013 - 23:57

If you click on Edit Databases on the left menu and then on the Passwords tab and change the password, does that fix the problem? It sounds like the actual MySQL password is out of sync with what Virtualmin expects.

Submitted by beat on Thu, 09/26/2013 - 11:09

Actually, even not changing the password (checked that it was the right one with "Show password" link near that field), simply clicking the save button below the password fixed the issue.

The bug seems thus to be:

When updating a Virtualmin account password using the API, then the Virtualmin password for database gets changed (by error too). But not the corresponding database password (which is correct, otherwise all installed scripts would stop working instantly).

The workaround is:

In menu databases, tab password, just re-save the password with the **** without changing it. Then you can install scripts again.

The fix would be:

Do not change the Virtualmin's duplicate-copy of the user's database password when an update through the virtualmin API of the password (e.g. from WHMCS) is required.

Submitted by JamieCameron on Thu, 09/26/2013 - 16:09

So the problem was triggered by a WHMCS API call? I wonder exactly what API function and parameters they are calling?

You should be able to see this by looking at the log of calls at Webmin -> Webmin Actions Log.

Submitted by beat on Fri, 09/27/2013 - 18:15

This is the log description:

Called remote API modify-domain.pl --pass xxxxxx --domain example.net

(changed by xxx's and example.net the sensitive information). We have written our own Virtualmin driver for WHMCS way before WHMCS wrote their encryted own, so we fortunately have the sources of the driver (did I say that I don't like non-open-source nature of proprietary software ?).

I have the entry in a browser window and can email it to you if you want to see the details (ofc with hidden passwords).

Submitted by beat on Sun, 09/29/2013 - 04:24

Hi Jamie,

Email sent with full log entry,

Thanks a lot for your stellar support and bugfixing.

Submitted by JamieCameron on Sun, 09/29/2013 - 12:24

Thanks for the log output! It looks like the actual MySQL password was indeed not changed, as expected.

Can you check for me if the domain's file /etc/webmin/virtual-server/domains/135586506711994 contains a mysql_pass line? That will indicate if it has a MySQL password separate from the admin password.

Submitted by beat on Sun, 09/29/2013 - 16:22

Yes, that file contains a mysql_pass line, which contains the (correct) previous password.

(And yes, the virtualmin settings were long ago set to not change database password when the virtualmin user password was changed, to avoid breaking all already installed scripts at user password change. Additionally, it's a slight improvement in security to have different passwords.)

Submitted by JamieCameron on Sun, 09/29/2013 - 17:55

I am mystified that as to why the wrong password would be used for MySQL.

Unless perhaps the user was installing Joomla into a sub-server ?

Submitted by beat on Sun, 09/29/2013 - 18:58

Yes, indeed, it was into a subserver (but which is sharing same database user and same mysql password as I'm understanding, Virtualmin doesn't automatically create separate database users for sub-servers), as that plan allows for up to 5 servers+subservers per user account, and he doesn't use the main server which was created automatically when he registered that main server with that main domain that he only used statically.

Submitted by JamieCameron on Mon, 09/30/2013 - 00:31

A sub-server will share the same MySQL login, but has its own separate databases. However, I'm still mystified as to why the wrong password would be used in this case.

If you check the files under /etc/webmin/virtual-server/domains for the top-level and sub-servers, do they have different pass= or mysql_pass= lines ?