Since the dev-server_node branch went into master, there's a couple issues regarding the db server.

I had to GRANT ALL PRIVILEGES ON *.* TO aegir_root@(hostname) ie the FQDN of my server, as localhost no longer worked and the initial Platform verify task couldn't connect to mysql.

After that, the verify task worked, but when provisioning new sites, Provision is defaulting the db_host to 'localhost' I think because drush_get_option('db_host') is NULL. And so it grants to localhost, but the system expects it to be the FQDN and the install task fails.

Am I right in understanding that the dbserver hostname is now taken from the general 'server' node, as it's kind of grouped with the webserver somehow? I'm a bit fuzzy on the new system, only just starting to look at it.

Should db_host be in the drushrc.php of the platform? As it isn't, in fact no db settings are.

CommentFileSizeAuthor
#6 712016_hostmaster.patch652 bytesmig5
#6 712016_provision.patch438 bytesmig5
#2 712016.patch854 bytesmig5
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anonymous’s picture

11:00 <@Vertice> db host is missing
11:00 <@Vertice> it needs to be passed
11:00 <@Vertice> external db servers _DO_NOT_WORK_
11:00 <@Vertice> at the moment
11:00 <@Vertice> they should work when configured by hand
11:00 <@Vertice> but they aren't picked up by default
11:00 <@Vertice> and the db_host needs to be passed (one line fix)

Anonymous’s picture

Status: Active » Needs review
FileSize
854 bytes

A possible patch for the install task. I don't think this will fix the initial platform verify expecting the FQDN as the host for the aegir_root user - that's master_db which is taken from $this->db_url

adrian’s picture

Status: Needs review » Needs work

committed.

adrian’s picture

Status: Needs work » Fixed

fixed.

Annakan’s picture

I may be fully wrong because I don't understand the full picture but on my new Aegir install the platform verify of a foreign server was not working because the generated command option was :

[master_db] => mysqli://aegir:dbPassword@aegir.xxxx.com<c/ode> where aegir.xxxx.com is the host were Aegir hosting is and NOT the one the platform to check is (the target).

playing a bit with the part of the code the above patch impact, I am not sure I get the following test:
<code>
if ($web_server->nid == $this->server->nid) {
      $db_host = 'localhost';
    }
    else {
      $db_host = $this->server->title;
    }

part ..
either the $this->server is wrongly set in another place to the main aegir server when checking platform or I really don't get it.

Anyway for me (as in "in my case", not as in following my nonexistent expertise) the check is unneeded since [master_db] => mysqli://aegir:dbPassword@localhost works perfectly, contrarily to the case mig5 quoted. (probably because I have wider permission on the aegir database than he has on @localhost on the "target" server)

So for me suppressing the test works better.

I don't know if it helps or if my platform is so wrongly configured that I am leaded to false conclusions.

Thanks a lot for your time.

Anonymous’s picture

Status: Fixed » Needs review
FileSize
438 bytes
652 bytes

Please review the two attached patches where I fix the case we've been discussing for days in IRC, and which Annakan's noted in #5.

There were two underlying issues:

1) We need to pass master_db_host arguments in hosting_db_server.service.inc or else when Provision does its mysql_connect in provision/db_server/provision.mysql.inc, it uses the settings from the platform's drushrc.php and thus connects to localhost (this is why the database, while meant for the remote server, gets created on the locahost machine)

2) I needed to change $grant = $web_host to $grant = gethostbyname($web_host) in _provision_mysql_grant_host()
In other words, I am forcing the grant to be on the IP address of the web server. I found if I didn't do this, the GRANT stage would fail as it would be @ the web server title ($this->server->title) but MySQL expected @IP (and the error thrown back was the FQDN reverse address of my IP which was what was throwing me for a while).

For 2), I could set $task->options['web_host'] = gethostbyname($web_server->title) in hosting_db_server.service.inc but I feel this isn't the right place for this.
In _provision_mysql_new_site_db(), we pass the $web_host as a drush_get_option argument to _provision_mysql_grant_host(), and it is getting that $web_host value from the drushrc.php of the platform.

Maybe that's ok, but why then does the GRANT fail expecting the IP of the web host? The value changes somewhere there, causing MySQL to throw 'Access denied for '$site_user'@$fqdn_and_thus_IP_of_the_web_server' , as opposed to $site_user@$server->title. So I force the IP with gethostbyname, in _provision_mysql_grant_host and it works.

Feeling a bit overwhelmed by this issue.. it's probably a really simple thing to sort out but feels exhausting. At least these patches partially fix it if not completely. I have a feeling that 2) is ugly, and if so at least at that point it is only a matter of fixing the GRANT web host. With 1), the database is being created on the remote server for the first time because the initial mysql_connect is fixed.

anarcat’s picture

Status: Needs review » Needs work

I don't think there's a simple fix here. The server verification task (which is right now platform verification) will need to keep an *array* of available mysql servers, and choose the right one depending on the mysql server chosen by the user during the install (so passed to the install task).

As for the domain resolution, this *used* (I swear!) to be performed in the frontend, when the webserver node was saved. Since the webserver node was refactored, this is broken, probably because adrian didn't port that code.

I do think that the frontend should have both the server's FQDN and the IP of the server. This way we do some guessing, but we allow the user to override the IP setttings if DNS is broken. Also, some people *may* want to have name-based grants. I think it's a bad idea as it's a performance hit and is an extra attack vector, but it's a policy we shouldn't just discard like this. So my vote goes for provision to respecting the ip/name settings set in the frontend, which means not doing DNS resolution in the backend (which can make things slower too).

So I'm pushing this back to needs work. I think the IP lookup should be done in the frontend. I'm also not sure about the master_db_* settings, seems to me those should be already passed somewhere anyways... Otherwise platform verification would just not work.

anarcat’s picture

Oh and of course if the suggested patches fix the issue for now, it's probably better than nothing... I haven't tested them, but if they work, let's commit them as a workaround and fix the issue in the long run.... :)

adrian’s picture

i don't think the second part is necessary ..

ie the provision path.

but i can see us using the hosting patch for now.

adrian’s picture

there is still ip lookup happening on the front end.

Anonymous’s picture

I'm also not sure about the master_db_* settings, seems to me those should be already passed somewhere anyways... Otherwise platform verification would just not work

I totally don't understand Drush at all, but what I was seeing was that it *was* looking up the master_db settings from the platform's drushrc.php . That precisely was the problem because such settings contained @localhost settings (the other database server). Therein lies the problem, I think, in that a platform isn't tied down to a specific db server, and we have no concept of 'default' db server, yet it is the Platorm storing and handing 'master' db settings to provision for site installs.

So what I end up doing is forcing the correct settings to be handed in the task. I think that's what's happening anyway.

adrian’s picture

Status: Needs work » Fixed

Ok. I committed these patches .. but i had sme trouble testing them .. due to the networking situation vmware was creating.

I have determined that name based grants is just a no-go , and i've also determined that we need the IP address we are connecting from the perspective of the database server, not from the drush/web server side.

We are actually incapable of doing these lookups ourselves, but we are lucky in that mysql provides the 'current_user' function.

I have replaced the create grant logic with the following -

function _provision_mysql_grant_host($db_host, $web_ip, $web_host) {
  $result = provision_db_result(provision_db_query("select current_user();"));
  preg_match('/^.*@(.*)$/', $result, $matches);
  return $matches[1];
}

Which involves no extra lookups, no extra variables needing to be passed , no arbitrary conditions and no information that needs to be stored and passed across servers.

This will work for both local, and external servers, and will work for servers behind DMZ's that can't actually resolve or connect to the web server we are granting access to.

Status: Fixed » Closed (fixed)

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

jerodfritz’s picture

Status: Closed (fixed) » Needs work

If I import an existing site by manually importing the db and then placing the file structure at $platform/sites/<> Aegir will assign the database server to the server that aegir is installed on rather than what I have specified in the settings.php file on platform verify.

My manual workaround for now is to alter the server variable in vhost.d file for the site to the correct database server but when I run verify on the site that file is overwritten with the wrong db server again.

- Aegir Front End lives at aegir.example.com
- Aegir manages sites that are install on the server boucher.example.com
- I import a site on boucher.example.com by verifying the platform after manually creating db and filesystem
- Aegir sets the database server to aegir.example.com and not boucher.example.com

adrian’s picture

Status: Needs work » Closed (fixed)

the last update is a support request, please make a new issue.

  • Commit a60f1ca on debian, dev-dns, dev-envobject, dev-koumbit, dev-log_directory, dev-migrate_aliases, dev-multiserver-install, dev-newhooks, dev-nginx, dev-ports, dev-purgebackup, dev-restore, dev-services, dev-simplerinstaller, dev-site_rename, dev-ssl, dev_dns, dev_server_verify, prod-koumbit, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-subdir-multiserver, 6.x-2.x-backports, dev-helmo-3.x by adrian:
    #712016 - Install to an external db server.