Two users created for sites when using external database

I think that we can remove the FQDN, the % is sufficient. However, this should be configurable in the db_server platform.

Upon removing the second grant, i get an error.

On our multi-front end system, we added user accounts for each of the front ends, and a wildcard for 64.55.119.%

When i removed the @dbhost line, i get an error on install even on my local test environment.

http://drupal.org/cvs?commit=154335 fixes this issue, mostly. I think it would still be good to add documentation regarding the fact that no host-based access control is configured by Aegir, which can be a security issue if the mysql server is publicly accessible.

Also, the issues described here by Adrian and Acbot are not related to Aegir. Acbot's issue was unreproducable, and adrian's was related to an entry in the mysql.user table like this:

mysql> select User,Host from user where Host='' or User='';
+------+-----------+
| User | Host      |
+------+-----------+
|      | localhost | 
+------+-----------+
1 row in set (0.02 sec)

If such a row is present, all clients from Host 'localhost' will be authenticated as anonymous users and have no permissions. Just dropping the row is sufficient to restore proper access.

Leaving this as 'needs work' as I think we need to update the documentation.

Also note that the committed patch doesn't update existing users (since it can't through update.php), so that may also be something that needs to be documented in the release notes or something.

See also http://drupal.org/node/337485

I also just changed the documentation to create the hostmaster account using @% instead of @localhost.

I think i can close this.

There's nothing we can do for existing clients created, but they won't harm or otherwise affect the running of the system.

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

I'm closing this. There's now a more specific issue regarding this in http://drupal.org/node/354050

tagging this old issue