Multisite provisioning failure

After successfully getting several single sites configured and up without issue, I’m moving up to multisite attempts. I’ve read through the wiki, the bug/issue re: multisite and thought I was on the right path. It appears not. Here’s the output I’m seeing (apologies for the length):

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'ubuntu/trusty64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'ubuntu/trusty64' is up to date...
==> default: Setting the name of the VM: multisitedev_default_1437689355580_20203
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: [landrush] Need to configure the host.
==> default: [landrush] Mometarily using sudo to put the host config in place...
==> default: [landrush] starting dns server
[landrush] Starting daemon...
[landrush] Waiting for daemon to start...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address:
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying...
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if its present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: [landrush] setting up machine's DNS to point to our server
==> default: [landrush] network: :private_network, {:ip=>"", :protocol=>"tcp", :id=>"e896702f-0cb0-4097-98f7-459afd3d54bf"}
==> default: [landrush] network: :forwarded_port, {:guest=>22, :host=>2222, :host_ip=>"", :id=>"ssh", :auto_correct=>true, :protocol=>"tcp"}
==> default: Checking for guest additions in VM...
==> default: Checking for host entries
==> default: adding to (/etc/hosts) :  # VAGRANT: f49ece5971bcd47b7c54472eb5158ed2 (default) / dd48d9ec-9a13-4f3d-812a-71d8e95670cc
==> default: Setting hostname...
==> default: Configuring and enabling network interfaces...
==> default: [landrush] adding machine entry: =>
==> default: [landrush] adding static entry: * =>
==> default: Exporting NFS shared folders...
==> default: Preparing to edit /etc/exports. Administrator privileges will be required...
==> default: Mounting NFS shared folders...
==> default: Mounting shared folders...
    default: /vagrant => /Users/alan-c/sites/
==> default: Bindfs seems to not be installed on the virtual machine
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

apt-get install -y bindfs

Stdout from the command:

Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 25.1 kB of archives.
After this operation, 89.1 kB of additional disk space will be used.
Err trusty/universe bindfs amd64 1.12.3-1
  Could not resolve ''

Stderr from the command:

stdin: is not a tty
E: Failed to fetch  Could not resolve ''

E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

Up to that point, everything, including Landrush seemed to be going ok. Any thoughts on where I’m messing up the setup?

And here’s the data from the ruby process that hangs around and block vagrant destroy/anything afterwards.


Well the error is pretty straightforward itself:

Err trusty/universe bindfs amd64 1.12.3-1
  Could not resolve ''

Stderr from the command:

stdin: is not a tty
E: Failed to fetch  Could not resolve ''

That’s an error from the VM. It can’t resolve meaning the DNS lookup failed. You can ssh into the VM and try dig

If it works you’d see output like this:

; ANSWER SECTION:	49	IN	A	49	IN	A	49	IN	A	49	IN	A	49	IN	A	49	IN	A	49	IN	A

If it doesn’t work I’d make sure networking works first of all, then check if other domains resolve (like for example).

Yeah, I get what the error is, I’m just trying to identify what’s causing it. Getting SERVFAILs on all dig attempts, +trace showing nothing. IP address pings are working.

ifconfig claims eth1 is up. /etc/network/interfaces looked correct. I took down and cleared out eth1 and brought it back up, but no success.

hostname --fqdn is giving me the canonical name.

/etc/resolve.conf shows nameserver, which I’m guessing is Landrush, but I’ll have to look closer. /etc/hosts has the correct hostname. getent hosts resolves fine, as expected.

dig @locahost are giving me (1 server found) but the connections are timing out. Same for subdomains.

Something wrong with or related to Landrush I’m guessing, but I haven’t worked out what. FWIW the only changes I’ve made to the Vagrantfile are the ones given in the wiki/instructions.

Identified the culprit. I had added:

  - ""
  - "*"

based on the discussion here. The last line is responsible for the issue. Removing the line allows vagrant up to get past that point.

Unfortunately, one problem solved only to bring me to the WP installed? failures mentioned in that same discussion. Back to the drawing board.

There are currently issues with multisite and Trellis as @austin points out in that issue you linked in the first post.

If you can help get it fixed, PR’s are accepted! :relaxed: :kissing_closed_eyes: