Deploy unable to clone git repo

Hi,

Been working through the documentation on git and some of the threads on here, but I am unable to make a deployment, it fails at the cloning git repo point.

I am running a Linode box, and I was able to run the server setup without any issue. However when I come to make the deploy I get a Permission Denied (publickey) error on the task Clone Project Files.

I have set up my key in my GitHub account, I can manually clone the repo via ssh on both the local machine and the server itself. So as far as I can tell I have everything set up. I have added github_ssh_keys: to my staging group_vars.

I’m a bit stuck for other things to try. Any tips on what might not be working here?

Also would it matter if the repo was on bitbucket as opposed to github? I have tried cloning from both.

You could double-check a few things:

  • You have defined your repo, vs left the default (leaving the default has caused the Permission denied error for a user in the past), and have defined it such that it will clone via ssh (vs https):
    Like this: repo: git@bitbucket.org:user/repo.git
    Not this : repo: https://bitbucket.org/user/repo.git

  • Your ansible.cfg isn’t somehow missing this ForwardAgent=yes setting.

  • Your ssh-agent isn’t giving you trouble (e.g., like this) – but I doubt it is because if you’re able to manually clone the repo from the server, your ssh forwarding seems to be working.

You might share a verbose log with us (showing error info) by running the long-form deploy command with the -vvvv flag:
ansible-playbook -i hosts/staging deploy.yml -e "site=mysitename.com" -vvvv

2 Likes

Thanks for the tips @fullyint. I have it working now.

I think I assumed the problem was something to do with ssh forwarding. So I checked my ansible.cfg to ensure it had the ForwardAgent=yes setting.

It seemed to be the addition of the ssh key to the keychain was the step I needed to do:

/usr/bin/ssh-add -K yourkey

Now that my key is in there, the deploys are working. I found the detail of this in this thread. If you are on OSX then it makes sense to do this.

Just one other thing (this may not be a deploy issue), when I do my deployment, and then check the staging url, the page doesn’t render. However I can go into wp-admin and then view the site from there, after that it works fine. Is this normal for a deploy?

@achubb Thanks for telling us how you solved it. “Adding the ssh key to the keychain” just got bumped a little higher in my mental list of troubleshooting steps for OSX users.

After a site’s initial deploy, you’d typically see the WordPress install screen at the site url. However, on some occasions I’ve seen the page not load and resolved it by running sudo service nginx reload on the server (or was it sudo service php5-fpm reload ?). For subsequent deploys, the site’s page always seems to load. I think I’ve heard others mention this but I haven’t looked into it.

Thanks for the reply @fullyint.

The initial deploy seems to work fine. I get the WordPress setup page and was able to go through it. It just seems to be on subsequent deploys, sometimes I will visit the url and there is no page being loaded. Normally I can get back into the WordPress admin and then it is fine.

I suspect it is an nginx issue. So I will try restarting it as you suggested on my next deploy.

When the page doesn’t load, what is the http status code (e.g., 404, 502, etc, viewable in Chrome dev tools network tab)? You might also check the nginx error log for the site, which is probably at /srv/www/mysitename.com/logs/error.log

@achubb I was just reading about some people getting a white screen after cap deploy because template_root or stylesheet_root wasn’t updating (see here and resulting PR here).

Next time you get a white screen after deploy, I’d sure be interested to know if template_root or stylesheet_root in your wp_options table have the old release absolute path (e.g., /srv/www/example.com/releases/etc) instead of just the relative path /themes.

@achubb I was able to reproduce the issue of the white screen after subsequent deploys, which fixes itself if I navigate to wp-admin then back to the front-end (like you said). I noticed that after a deploy the values for _site_transient_theme_roots in the wp_options table had the old release path and that navigating to wp-admin updated these values to the new release path.

If you’re interested, I invite you to experiment with me on two adjustments:

  1. Adjust the post_build_commands task to use the shell module instead of the command module
- command: "{{ item.cmd }}"
+ shell: "{{ item.cmd }}"
  1. Add a default post_build_command that replaces the old release path with the new release path in the database:
 project_post_build_commands:
   - cmd: "composer install --no-ansi --no-dev --no-interaction --no-progress --optimize-autoloader --no-scripts"
+  - cmd: if wp core is-installed; then wp search-replace "{{ deploy_helper.previous_release_path }}" "{{ deploy_helper.new_release_path }}" --skip-columns=guid; fi

I’m going to test this for a while. @swalkinshaw I anticipate it might be a good trellis default generally, but I think it would also handle trellis’s potential issue with release paths (as seen in bedrock-capistrano).

EDIT: Of course, as with any testing manipulating your dataset, please take a backup of your data first. :relaxed:

2 Likes

Hi @fullyint,

Thanks for this. I have changed these settings now and made a deployment to our staging environment, but it didn’t seem to make a difference. I will keep those settings in there though and continue to test with subsequent deploys.

The one consistency that I have found is that, disabling the theme and then reactivating it always seems to kick it back into life, so I’m not sure if that sheds any more light on it.

Thanks again for your help with this… :smile:

@achubb Thanks for testing. I came across the “white screen after deploy” issue again while testing some different stuff, so I looked into it further.

I think I’ve hit upon a solid solution this time. If you’re interested, I’d love your testing and feedback over at https://github.com/roots/trellis/pull/275

Ran into the same problem. Is ‘yourkey’ my local id_rsa file? The key copied from my Github keys? Neither of those worked for me. I already have keys generated and added to Github.

@fullyint tagging you too since you seemed to help everyone else with this issue too. Thanks in advance.

yourkey to use with ssh-add is the path to the private key on your local machine. For OSX users this is usually at ~/.ssh/id_rsa.

ssh-add – adds private key identities to the authentication agent

This is the private key that forms a pair with the public key you have uploaded to your GitHub account, the same public key that you’ve specified in the users hash.

There is more info in the ssh-keys docs, if you haven’t seen it already.

Feel free to ask more questions if that info doesn’t help resolve the issue. :key:

Makes sense, I was doing the public key instead… I got it to deploy but now I’m seeing a partial white page (http://staging.coreybruyere.com/). And I can’t login with the username and password I’ve been using. Any pointers on that and where I can get my staging and produciton credentials? Don’t remember ever setting those. Such a tease I finally got a successful deployment only to see a blank page and not being able to login.

Did you use the same database from dev, or did you set up Trellis to install the site automatically?

It’s either in your Trellis config or the database, nowhere else your WP login could be…

I used Trellis to set up, but the only place I set admin credentials is in development wordpress_sites and that’s not it

Sorry, perhaps I wasnt clear. The staging/production servers can only get a database in a few ways:

a) manually import it
b) Set site_install to true in the Trellis config for that environment, and set all the admin info there as well.
c) don’t recall off the top of my head, but there is a database_import directive you can use to point to a database dump

In all cases, it’s up to you. And just to note, by default, the only place the site is installed by default is in dev, and uses these credentials: https://github.com/roots/trellis/blob/master/group_vars/development/wordpress_sites.yml#L11

Trellis had not modified your database in any way if you moved it

Thanks, I set site_install to true and set my staging db name, user, and pw found in staging/wordpress_sites.yml – wordpress_sites.env to my dev environment credentials hoping it’d replicate my local environment. That didn’t work but I was brought to the WP install page on my staging site and now have that up and running, but it’s just my theme with no content.

What’s the easiest way to import my db from my local to staging at this point now? I tried searching for the database_import option you mentioned in the forums but didn’t find anything. And I’m not familiar with db or server structure, so I’m not sure where to even begin on a manual import. Where do I find my local db within my project files? Then what directory does that need to go to on my server? What would you recommend?

Sorry, it’s not database_import, it’s db_import https://github.com/roots/trellis/blob/e71c26560f4f7e05e8184302f2be18ad37499127/roles/wordpress-setup/tasks/database.yml#L25

Moving your database around is the same whether you’re working on Trellis/Bedrock or a standard WP installation. You export locally, import on staging/production, and do a search-replace of the URL.