New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lando drush sql-sync uses www-data user not host user #1082

Closed
tanc opened this Issue Jul 5, 2018 · 6 comments

Comments

Projects
None yet
3 participants
@tanc
Copy link
Contributor

tanc commented Jul 5, 2018

Bug Report

v3.0.0-beta.47 on MacOS 10.13.5

.lando.yml file:

name: testd8
recipe: drupal8
config:
  webroot: gitroot/web

Command I was trying to run:

lando drush sql-sync @remote.production @self

Error produced:

 [error]  The external command could not be executed due to an application error. [1.21 sec, 7.57 MB]
 [error]  The command could not be executed successfully (returned: Permission denied (publickey).
, code: 255) [1.21 sec, 7.57 MB]
 [error]  Error: no database record could be found for source @remote.prod [1.22 sec, 7.59 MB]

While ssh keys are being forwarded properly the drush command sql-sync falls back to using the container's user www-data and not the host system user running the command.

One way around that is to specify the remote-user in the drush alias file but this would then render the alias incompatible with other team members.

Can you think of any way of getting Lando to use the host user name when running sql-sync and other ssh commands?

@lslinnet

This comment has been minimized.

Copy link

lslinnet commented Jul 6, 2018

I am running into something similar where I require my local ssh key that is passphrase protected to be available inside the container, I would really like to see an ssh-agent inside lando so that this can become an easy task instead of working around it using something like:

services:
  appserver:
    type: php:7.1
    run:
      - "if [ ! -f ~/.ssh/id_rsa ]; then ln -s /user/.ssh/id_rsa ~/.ssh/id_rsa; fi"
      - "if [ ! -f ~/.ssh/id_rsa ]; then ln -s /user/.ssh/id_rsa.pub ~/.ssh/id_rsa.pub; fi"
      - "cd $LANDO_MOUNT && composer install"

Which I would classify as a hackish work around :/ And yes I have set loadPassphraseProtectedKeys: true in the ~/.lando/config.yml file (which do not seem to affect anything).

@tanc

This comment has been minimized.

Copy link
Contributor Author

tanc commented Jul 10, 2018

A solution to my issue is to pass through an environment variable in a .env file:

LANDO_HOST_USER=tanc

Then modify the drush aliases for the remote site to use the environment variable:

stage:
  host: stage.mycustomsite.org
  root: /var/www/stage.mycustomsite.org/gitroot/web/
  uri: default
  user: ${env.LANDO_HOST_USER}

It would be great if the host user name could automatically be available as an environment variable within containers without having to specify it in an .env file.

@tanc

This comment has been minimized.

Copy link
Contributor Author

tanc commented Jul 10, 2018

A slightly nicer solution is to add a USER global environment variable to config.yml (~/.lando/config.yml):

USER=tanc

This is then available in any container and as it is the same as the host system's environment variable it can be used in a more flexible way in drush alias files (e.g. drush/sites/remote.site.yml):

stage:
  host: stage.mycustomsite.org
  root: /var/www/stage.mycustomsite.org/gitroot/web/
  uri: default
  user: ${env.USER}

This will then work:
lando drush sql-sync @remote.stage @self

As will this (if you aren't using Lando):
drush sql-sync @remote.stage @self

@tanc

This comment has been minimized.

Copy link
Contributor Author

tanc commented Sep 6, 2018

@lslinnet I just came across your problem on one of our developer's laptops with a passphrase protected ssh key. I posted the solution in #1143

Ideally there would be an ssh-agent in the container to make this stuff smoother.

@stale

This comment has been minimized.

Copy link

stale bot commented Jan 31, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions and please check out this if you are wondering why we auto close issues.

@stale stale bot added the wontfix label Jan 31, 2019

@pirog pirog self-assigned this Feb 2, 2019

@pirog pirog added this to the 3.0.0-rc.4 milestone Feb 2, 2019

pirog added a commit that referenced this issue Feb 2, 2019

@pirog

This comment has been minimized.

Copy link
Member

pirog commented Feb 2, 2019

Alright some updates here:

  1. password protected keys are now going to be loaded by default
  2. LANDO_HOST_USER will be defined in all containers
  3. by default SSH will try to use LANDO_HOST_USER instead of the containers "meUser"

@pirog pirog closed this Feb 2, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment