Bedrock-ansible and vagrant share problems

bedrock
1

Hello.

TL;DR. I want to make bedrock-ansible’s nginx server available to devices on my local network for testing purposes, and thought that vagrant share would be quick & convenient.

Nope. I’m also open to alternative methods for solving this problem.

Using a vanilla bedrock-ansible install plus a vanilla group_vars/development, I can’t get vagrant share working.

vagrant share

produces an error:

Vagrant was unable to detect an HTTP port for your machine.
Your Vagrant machine is reporting that it is accessible at
the address: '192.168.50.5'.

Vagrant tries some common HTTP ports to try to find a listening
HTTP server, but all the attempts failed. There are a few options
to fix this error:

  1. Turn off HTTP sharing with the `--disable-http` flag.

  2. Have your HTTP server listen on port 80, 3000, 4567, 8000,
     or 8080. Vagrant will automatically try these.

  3. Specify an HTTP port explicitly to vagrant share with the
     `--http` flag.

  4. Make sure that the address above along with your HTTP port
     are accessible from this machine. Sometimes firewalls or
     binding to the wrong IP cause it to become inaccessible.

Trying again with:

vagrant share --http 80

gets me a bit further…

==> default: Detecting network information for machine...
    default: Local machine address: 192.168.50.5
    default: Local HTTP port: 80
    default: Local HTTPS port: disabled
==> default: Checking authentication and authorization...
==> default: Creating Vagrant Share session...
    default: Share will be at: XXXXX-XXXXXX-0000
==> default: Your Vagrant Share is running! Name: XXXXX-XXXXXX-0000
==> default: URL: http://XXXXX-XXXXXX-0000.vagrantshare.com

OK. Testing local site with curl -IL mysite.dev:

HTTP/1.1 200 OK
Server: nginx
Date: Fri, 23 Jan 2015 10:19:56 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/5.6.4-1+deb.sury.org~trusty+1
X-Pingback: http://plannabel.dev/wp/xmlrpc.php
Link: <http://plannabel.dev/>; rel=shortlink
X-UA-Compatible: IE=Edge

But not so good with the vagrant share URL:

HTTP/1.1 500 Internal Server Error
Content-Type: text/plain; charset=utf-8
Date: Fri, 23 Jan 2015 10:23:53 GMT
Connection: keep-alive

I checked srv/www/mysite.dev/logs/mysite.dev.access.log and the vagrant share request didn’t trouble nginx at all, so perhaps its a firewall or other networking problem.

I have had a good look around the usual sources, but with no luck. My setup is Mac OS X 10.9.5, Vagrant 1.7.2, Virtualbox 4.3.20-96996, Ansible 1.8.2, connecting to local network via Airport and router is configured not to isolate wireless stations.

I would welcome your thoughts.

—Ajay.

1 Like
2

Just curious if you’ve ever tried this feature and had it working?

I’m going to give it a try myself to test this out. There’s a chance some of the firewall/security we have could be causing this but it definitely allows for port 80.

1 Like
3

I was able to get vagrant share working and saw that external requests were hitting the box. The problem is that Nginx doesn’t know which vhost (your WordPress site) to serve.

1 Like
4

How did everybody end up solving this problem? How do I make Nginx know which vhost to serve?

Thanks!
Jason

5

This is definitely an nginx config issue. I started up vagrant share with the HTTP flag and then added in the domain name it spits out. After I did this I could see the HTML. Still an issue with styles and scripts though.

Noticed in the vagrant documentation that vagrant share can take a name flag and have some control over the domain name. Maybe this in combination with a small ansible tweak would get this to 100%?

6

any updates on this?
thanks

1 Like
7

vagrant share also accepts --name as a parameter. Here is what you can do:

  1. Backup site’s database. For example this way:
  • vagrant up
  • vagrant ssh
  • cd /srv/www/{sitename}/current
  • wp db export db.sql
  1. Edit trellis/group_vars/development/wordpress_sites.yml, change site_hosts: value from {hostname}.dev to {hostname}.vagrantshare.com
  2. Execute vagrant reload --provision to set up nginx
  3. Execute vagrant share --http 80 --name {hostname}

where default {sitename} is example.com and default {hostname} is {example}

Keep in mind, that you cannot reach vagrant cloud by {hostname}.vagrantshare.com locally, you will always see your local instance, because of the record in hosts file. It shouldn’t be a problem in most cases.

If you lose your database during the process, like me, you can restore it by executing

  • vagrant ssh
  • cd /srv/www/{sitename}/current
  • wp db import db.sql

Finally you may wish to get rid of remains of old site: old database, /etc/nginx/sites-available/{hostame}.dev, /srv/www/{hostame}.dev. In that case it’s probably better to use vagrant destroy && vagrant up instead of vagrant reload --provision at the 3rd step (db backup is absolutely must in that case).

2 Likes