Drush 9 cannot SSH into Drupal VM

[danepowell]

Issue Type

• Bug Report / Support Request

Your OS

• Linux (Ubuntu 17.10)

Summary

DrupalVM provides a template Drush alias file so that Drush knows how to access the VM via SSH:
https://github.com/geerlingguy/drupal-vm/blob/master/provisioning/templates/drupalvm.aliases.drushrc.php.j2

There are a few problems with this for Drush 9:

• drushrc files are replaced with YAML files
• the ssh-options key becomes an array key:

ssh:
  options:

• because it's a yaml file and not a php file, you can't run commands inline like drush_server_home()

BLT has started converting its own alias template for Drush 9 but I'm stuck on that last step. I figure we should decide on a collective approach to this.
https://github.com/acquia/blt/blob/9.1.x/scripts/drupal-vm/drupal-vm.aliases.yml

[geerlingguy]

Hmm... at a quick glance, I'm not sure if there's a simple backwards-compatible way to make this work well. We might have to either drop the feature (managing an alias file on the host), or make it more complicated and have two different templates for drush_version < 9 and drush_version >= 9.

[danepowell]

This is how I'm going to fix it for BLT. Might be marginally less portable, but I think it will still work in most environments: acquia/blt#2241

[oxyc]

The reason we use drush_server_home() #552 and for a long discussion and debugging session at #406.

Based on

• drush-ops/drush@a0aea36
• https://github.com/drush-ops/drush/blob/05c5a93ce127c3dfbd89d739d74f92ab4dcce653/examples/example.site.yml

I think we should use ${env.home} rather than $HOME as I'm not confident it will expand correctly in all cases.

  ssh:
    options: -o PasswordAuthentication=no -i ${env.home}/.vagrant.d/insecure_private_key

As for the getenv('VAGRANT_HOME') ternary op I think we have to drop it :/ https://github.com/grasmash/expander/blob/c8e56149469e9c0db1e153a98e14c4448fecbccf/src/Expander.php#L151:L161

Anyone want to post ternary operations as a feature request to https://github.com/grasmash/expander? :) ${env.VAGRANT_HOME?:env.home}

[geerlingguy]

Where are we with this now? Is the simple fix that we would want to use ${env.home} and that should fix things? Sorry, lost context for this issue :(

Since Drush 9.0.0 was just released, it's probably best for us to make sure it'll be fully compatible!

[geerlingguy]

I'm also just now learning about drush-launcher, and it looks like maybe the old way I globally installed drush globally on my Mac (brew install drush) is quite deprecated now.

[geerlingguy]

So, I'm now seeing new Drush-related issues in Drupal VM's automated builds, e.g.:

TASK [geerlingguy.drupal : Install Drupal with drush.] *************************
fatal: [localhost]: FAILED! => {"changed": true, "cmd": ["/var/www/drupalvm/drupal/vendor/drush/drush/drush", "site-install", "standard", "-y", "--root=/var/www/drupalvm/drupal/web", "--site-name=Drupal", "--account-name=admin", "--account-pass=admin", "--db-url=pgsql://drupal:drupal@localhost/drupal"], "delta": "0:00:00.408622", "end": "2018-01-26 04:27:38.036190", "msg": "non-zero return code", "rc": 1, "start": "2018-01-26 04:27:37.627568", "stderr": " [error]  Failed to create database: Password for user drupal:psql: fe_sendauth: no password supplied ", "stderr_lines": [" [error]  Failed to create database: Password for user drupal:psql: fe_sendauth: no password supplied "], "stdout": "\n // You are about to DROP all tables in your 'drupal' database. Do you want to  \n // continue?: yes.                                                             ", "stdout_lines": ["", " // You are about to DROP all tables in your 'drupal' database. Do you want to  ", " // continue?: yes.  

From: https://travis-ci.org/geerlingguy/drupal-vm/jobs/333562827

  [Symfony\Component\Console\Exception\CommandNotFoundException]  
  Command "@drupalvm.drupalvm.test" is not defined.               
                                                                  
Drush install fail

From: https://travis-ci.org/geerlingguy/drupal-vm/jobs/333562825

[geerlingguy]

Looks like the first problem is actually drush-ops/drush#3330

[geerlingguy]

Also related: geerlingguy/ansible-role-drush#41

[heddn]

The change for drush_server_home() seems fixable via https://github.com/drush-ops/drush/pull/3115/files

[geerlingguy]

Also see: #1672 (preliminary work before I will be able to work any further on this ticket).

[geerlingguy]

Here's some testing I've done on the host side (with Drush 9.0.0 and launcher inside the VM, as per #1672 WIP):

1. brew uninstall --force drush
2. brew install drush-launcher
3. drush status outside of docroot gives error
4. drush status inside docroot shows site info, but not connection info.
5. drush cr inside docroot gives [error] SQLSTATE[HY000] [2002] No such file or directory
6. drush site:alias-convert inside docroot gives Error: Call to undefined function drush_server_home() in include() (line 14 of /Users/jeff.geerling/.drush/drupalvm.aliases.drushrc.php).
7. After removing the VAGRANT_HOME and drush_server_home() bit, I could convert the aliases, which were stashed into my project in a drush/ directory in /Users/jeff.geerling/Sites/drupalvm/drupal/drush/sites.
   1. I also had to prepend ${env.home} as @oxyc suggested above.
8. drush @drupalvm.test status now works and sees the site, db, etc.!

So after I finish #1672 I'll work on getting the alias files up to snuff.

[geerlingguy]

Also, here's the generated alias file:

 14:09:10 ~/Sites/drupalvm/drupal/drush/sites $ cat drupalvm.site.yml 
test:
  host: drupalvm.test
  options: {  }
  paths:
    drush-script: /var/www/drupalvm/drupal/vendor/drush/drush/drush
  root: /var/www/drupalvm/drupal/web
  uri: drupalvm.test
  user: vagrant
  ssh:
    options: '-o "SendEnv PHP_IDE_CONFIG PHP_OPTIONS XDEBUG_CONFIG" -o PasswordAuthentication=no -i "${env.home}/.vagrant.d/insecure_private_key"'

[geerlingguy]

Things are getting... complicated.

Basically, Drush 9 no longer automatically looks inside your user home ~/.drush folder for aliases... instead, according to these docs, you will have to create a Drush config file (or update one if it exists) to point it at any global (non-project-specific) directories to scan:

drush:
  paths:
    alias-path:
      - '${env.home}/.drush/sites'

I'm thinking I may write those contents to the file if a config file doesn't already exist. But if it does then we'll have to ask the user to add the proper alias-path configuration. Annoying... but I guess it can work.

[geerlingguy]

Next fun problem: drush-ops/drush#3336

[geerlingguy]

For the problem linked above, the issue was having a . character in the alias name. Drush < 9 was fine with it, but 9+ can't have special characters (well, at least a .). So for a short-term fix, I'm grabbing the first part of the domain (e.g. host.split('.')[0]), so if you have:

drupalvm.test

The alias will be drupalvm, meaning when you run a command using the alias you'd need to use drush @drupalvm.drupalvm [command].

I'm hoping this won't cause too much of a problem, as it shouldn't cause alias conflicts if you use things like:

mysite.test
anothersite.test

But it would cause problems if you have multiple domains in one Drupal VM like:

local.mysite.com
local.anothersite.com

Note that automated drush alias generation from Drupal VM has always been a little awkward, and I always generate my own aliases and store them in per-project drush configs instead of using global aliases nowadays.

I've also updated the documentation to account for this change as part of #1672. This will definitely need to be a minor release... and I'm contemplating making it a major since the Drush integration is essentially different in every way :O

[geerlingguy]

This is fixed in master, will be in 4.8.0, to be released shortly.

[joelpittet]

Totally thought Greg and I fixed this the drush use seems to not pickup in drush 9. I followed the stuff above and drush @cs8.test status is working but drush use @cs8.test I'm wild guessing but think maybe something with the launcher?