Perhaps it is my database setup, but this should be changed either way. During database provisioning the database host name isn't specified for the user permission grant function, even though it is available. The function _provision_mysql_grant() uses a default value of "%". This causes the following error message during the site install task:

The command could not be executed succesfully (returned: Unable to connect to database server @import "/misc/maintenance.css"; @import "/modules/system/defaults.css"; @import "/modules/system/system.css"; Unable to connect to database server If you still have to install Drupal, proceed to the installation page. If you have already finished installing Drupal, this either means that the username and password information in your settings.php file is incorrect or that we can't connect to the MySQL database server. This could mean your hosting provider's database server is down. The MySQL error was: Access denied for user 'site_487'@'localhost' (using password: YES). Currently, the username is site_487 and the database server is localhost.

    * Are you sure you have the correct username and password?
    * Are you sure that you have typed the correct hostname?
    * Are you sure that the database server is running?

For more help, see the Installation and upgrading handbook. If you are unsure what these terms mean you should probably contact your hosting provider. , code: 0)

The attached patch fixes the problem, and sites install correctly.

CommentFileSizeAuthor
add_dbhost.patch550 bytes13rac1

Comments

13rac1’s picture

13rac1 commented
Component: Documentation » Code

Changed to correct component.

I was just reviewing this. Should I have my MySQL database setup differently? I have a default Ubuntu MySQL install. Maybe this patch isn't the correct way to fix the problem. Should I delete the default MySQL anonymous user? Will the patch conflict with the experimental multiple database servers support?

I imagine that someone else will run into this issue.

mrthumpz’s picture

mrthumpz commented
Component: Code » Documentation

I believe this is more of a documentation issue. In order for me to get provision to work, I had to pull my hair out and then figure out that I needed to remove the Anonymous/localhost user.

Some explanation of why is found here:

http://dev.mysql.com/doc/refman/5.1/en/adding-users.html

One account ('monty'@'localhost') can be used only when connecting from the local host. The other ('monty'@'%') can be used to connect from any other host. Note that it is necessary to have both accounts for monty to be able to connect from anywhere as monty. Without the localhost account, the anonymous-user account for localhost that is created by mysql_install_db would take precedence when monty connects from the local host. As a result, monty would be treated as an anonymous user. The reason for this is that the anonymous-user account has a more specific Host column value than the 'monty'@'%' account and thus comes earlier in the user table sort order

It should be documented that this is required.

13rac1’s picture

13rac1 commented

Yep, thats the MySQL documentation that I was reviewing when I added my second comment. Whenever I create users on my servers, I always specify "localhost", so I have never had a problem with the default MySQL installation. It really seems to me that the code should be able to handle this issue, or there needs to be a better notification during the site creation about what has caused the error.

If it is a local server then create the user as localhost. If remote server create the user as any. That would seem to agree with the SQL documentation. Although, the simplest option is to create all users with both permissions.

I believe it is better to add a little code, than be forced to create a "important notice" for installation requirements.

adrian’s picture

adrian commented

This is directly related to http://drupal.org/node/336431

We were initially creating 2 accounts, but we found that the @localhost variant was unnecessary. All the installs we checked allowed the @% variant to work from localhost. Apparently we were mistaken

The issue is that you don't need to create an entry for each db server, but for each web server that can access the database server, and presently we don't support multiple web servers. This also has issues when taking into account having multiple web front ends. So at present, the most flexible method is to allow all access.

anarcat’s picture

anarcat commented
Title: Use of "%" instead of db hostname, causes database access failure during site install. » Document properly the '%' user in the release notes and install docs
Category: bug » task
Priority: Normal » Critical
Status: Needs work » Active

So I agree this is an issue, but it's a site-specific problem. For example, I do not have this problem on Debian. It is essential that the created user be '%' so that other (web) servers can connect to the database server properly, but this needs to be documented. So I'm turning this into a documentation issue.

"We need to say somewhere in the docs that we create a % host wildcard, which is a security issue... In the relnotes?"

We also need to mention that the anonymous user will cause problems and should be removed.

anarcat’s picture

anarcat commented

Oh and keep in mind this is a documentation issue because we do not have the proper controls to allow admins to control which host will be configured, which is feature #337485: allow configuration of the 'host' part of the created mysql users.

adrian’s picture

adrian commented
Title: Document properly the '%' user in the release notes and install docs » Create @localhost and @% entries for the database user.
Status: Active » Fixed

I have confirmed that several distributions package mysql with the ''@localhost default entry, which acts as a 'deny all' to logins.

For security and simplicity of configuration purposes, I have re-introduced the configuration of the localhost and % user accounts.

Some additional configuration will need to be made for external database servers, but that is an experimental feature that can be documented as such.

13rac1’s picture

13rac1 commented

Good to hear. Thanks!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

anarcat’s picture

anarcat commented
Issue tags: +multiserver

tagging this old issue