devopsgroup-io/vagrant-hostmanager

:pencil: A Vagrant plugin that manages hosts files within a multi-machine environment.

vagrant-hostmanager's Issues

Guest vm hostname duplicated in /etc/hosts

I'm not sure if this is intentional or not but the hostname of the guest end up duplicated in /etc/hosts. See the Vagrantfile and the resulting /etc/hosts below. Notice how vm.local is present in both the 127.0.0.1 and 192.168.200.100 line. I was expecting/hoping that vm.local and vm would be removed from 127.0.0.1 and both would end up on 192.168.200.100. I do understand that I could add an alias to get vm on 192.168.200.100.

A potential suggestion could be to add a config option like
config.hostmanager.manage_guest_localhost = true
This would result in the 127.0.0.1 line being "cleansed" of values from config.vm.hostname.

For now I added a shell provisioner that does this
sed -i 's/\(127\.0\.0\.1\)\s*.*\s*\(localhost\)\s/\1\t\2 /' /etc/hosts

Perhaps there is a better way I should be doing this.

These are my versions.

Vagrant: 1.4.3
vagrant-hostmanager (1.3.0)

This is my Vagrantfile.

VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "centos"
  config.vm.box_url = "http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.4-x86_64-v20130427.box"
  config.vm.hostname = "vm.local"
  config.vm.network :private_network, ip: "192.168.200.100"
  config.hostmanager.enabled = true
end

This is the resulting /etc/hosts on my guest vm.

127.0.0.1   vm.local vm localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.200.100 vm.local    # VAGRANT ID: 812be983-648d-4313-b4f8-10fa673bcb98

call remove hosts on vagrant halt

Hi,

I'd suggest to call the hosts cleanup task also on vagrant halt in addition to vagrant destroy. Because if the vm is down, the host entries don't make sense (in my opinion)

This would be similar to vagrant's core behaviour for the host entry.

Thanks for sharing this ext! ;)

kind regards

Vagrant keeps looking for 'app', but there is no app?

Hey!

I am receiving the following error when trying to use this plugin:

"The machine with the name 'app' was not found configured for this Vagrant environment."

This is a multi-vm setup, so perhaps that is part of it? I am new to Vagrant, so it's entirely possible I am just missing something basic here.

Thanks!

My VagrantFile:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  config.vm.box = "centos-64-x64-nocm"

  # Vagrant hostmanager settings
  config.hostmanager.enabled = true
  config.hostmanager.manage_host = true
  config.hostmanager.ignore_private_ip = false
  config.hostmanager.include_offline = true

  # Vagrant box sources
  config.vm.provider :virtualbox do |v, override|
    override.vm.box_url = "http://puppet-vagrant-boxes.puppetlabs.com/centos-64-x64-vbox4210-nocm.box"
  end
  config.vm.provider :vmware_fusion do |v, override|
    override.vm.box_url = "http://puppet-vagrant-boxes.puppetlabs.com/centos-64-x64-fusion503-nocm.box"
  end

  # App server
  config.vm.define :backend_app do |app_config|
    app_config.vm.hostname = "local-backend.my.com"

    # Networking
    app_config.vm.network :private_network, ip: "192.168.35.20"

    # NFS was not working on my machine. YMMV.
    app_config.vm.synced_folder "..", "/src/backend" #, :nfs => true, nfs_version: "4"

    # VM customizations
    app_config.vm.provider :virtualbox do |v|
      v.name = "backend_app"
      v.customize ["modifyvm", :id, "--memory", "2048",
                   "--cpus", "2", "--ioapic", "on", "--name", "backend_app"]
    end

    app_config.vm.provider :vmware_fusion do |v|
      v.name = "backend_app"
      v.customize ["modifyvm", :id, "--name", "backend_app"]
      v.vmx["memsize"] = "2048"
      v.vmx["numvcpus"] = "2"
    end

    # Setup puppet
    # from https://github.com/phips/c6vagrant/blob/master/Vagrantfile
    app_config.vm.provision :shell, :path => "centos6.sh"

    # Provision
    app_config.vm.provision :puppet do |puppet|

      # The basics
      puppet.manifests_path = "puppet"
      puppet.manifest_file = "backend-app.pp"
      puppet.module_path  = "puppet/modules"

      puppet.options = "--verbose --debug"

      ## custom facts provided to Puppet
      puppet.facter = {
          ## tells puppet that we're running in Vagrant
          "is_vagrant" => true,
      }
    end
  end

  # Mongodb instance
  config.vm.define :backend_mongodb do |db_config|
    db_config.vm.hostname = "local-backend-db.my.com"

    # Networking
    db_config.vm.network :private_network, ip: "192.168.35.25"

    # VM customizations
    db_config.vm.provider :virtualbox do |v|
      v.name = "backend_mongodb"
      v.customize ["modifyvm", :id, "--memory", "2048",
                   "--cpus", "2", "--ioapic", "on", "--name", "backend_mongodb"]
    end
    db_config.vm.provider :vmware_fusion do |v|
      v.name = "backend_mongodb"
      v.customize ["modifyvm", :id, "--name", "backend_mongodb"]
      v.vmx["memsize"] = "2048"
      v.vmx["numvcpus"] = "2"
    end

    # Setup puppet
    # from https://github.com/phips/c6vagrant/blob/master/Vagrantfile
    db_config.vm.provision :shell, :path => "centos6.sh"

    # Provisioning
    db_config.vm.provision :puppet do |puppet|

      # The basics
      puppet.manifests_path = "puppet"
      puppet.manifest_file = "backend-mongodb.pp"
      puppet.module_path  = "puppet/modules"

      puppet.options = "--verbose --debug"

      ## custom facts provided to Puppet
      puppet.facter = {
          ## tells puppet that we're running in Vagrant
          "is_vagrant" => true,
      }
    end
  end
end

vagrant-hostmanager don't support override feature ?

I've this configuration, with hostmanager configured only for "virtualbox"

Vagrant.configure("2") do |config|
    config.vm.hostname = "foobar"
    config.ssh.forward_agent = true

    config.vm.provider "virtualbox" do |v, override|
        override.vm.box = "debian-wheezy64"
        override.vm.box_url = "...."
        override.hostmanager.enabled = true
        override.hostmanager.manage_host = true
        override.hostmanager.ignore_private_ip = false
        override.hostmanager.include_offline = true
        override.hostmanager.aliases = ["foobar.example.com", "example.com"]

        override.cache.auto_detect = true
        override.vm.network :private_network, ip: "192.168.33.10"
    end
    config.vm.provider :lxc do |v, override|
        override.vm.box = "fgrehm/wheezy64-lxc"
        override.vm.box_url = "https://vagrantcloud.com/fgrehm/wheezy64-lxc"
    end
    config.vm.provider :lxc do |lxc|
        lxc.customize "network.type", "veth"
        lxc.customize "network.link", "lxcbr0"
        lxc.customize "network.hwaddr", "22:90:e8:45:3c:34"
    end
end

If I launch "vagrant up" on this configuration, I've no hostname configured in /etc/hosts

But it's work with this configuration :

Vagrant.configure("2") do |config|
    config.vm.hostname = "foobar"
    config.ssh.forward_agent = true
    config.hostmanager.enabled = true
    config.hostmanager.manage_host = true
    config.hostmanager.ignore_private_ip = false
    config.hostmanager.include_offline = true
    config.hostmanager.aliases = ["foobar.example.com", "example.com"]

    config.vm.provider "virtualbox" do |v, override|
        override.vm.box = "debian-wheezy64"
        override.vm.box_url = "...."

        override.cache.auto_detect = true
        override.vm.network :private_network, ip: "192.168.33.10"
    end
    config.vm.provider :lxc do |v, override|
        override.vm.box = "fgrehm/wheezy64-lxc"
        override.vm.box_url = "https://vagrantcloud.com/fgrehm/wheezy64-lxc"
    end
    config.vm.provider :lxc do |lxc|
        lxc.customize "network.type", "veth"
        lxc.customize "network.link", "lxcbr0"
        lxc.customize "network.hwaddr", "22:90:e8:45:3c:34"
    end
end

I think that vagrant-hostmanager don't support override feature ?

Best regards,
Stephane

Implement default IP resolving as a `ip_resolver` Proc

I'd like to have the IP resolving logic always use the ip_resolver Proc, and implement the default behavior (of using private_network or ssh_info) as a Proc itself. This way we can eventually have built-in resolvers for different use-cases.

For example, as in #86, reading an interface's ip address in a DHCP scenario could look something like this:

config.hostmanager.ip_resolver = :dhcp, interface: "eth1"

This would find the dhcp resolver and instantiate it with the option interface: "eth1".

Before implementing this, I'd like do some refactoring as per #99. I'm just putting this here so it's not forgotten.

Adding multiple virtual hosts

I've enabled multiple virtual hosts on the VM by adding the following to a file called default in /etc/apache2/sites-available/. This file is symlinked to /etc/apache2/sites-enabled/000-default.

NameVirtualHost *:80

<VirtualHost *:80>
   ServerName default.com
   DocumentRoot "/vagrant/vhosts/default/httpdocs"
   <Directory />
      Options Indexes FollowSymLinks
      AllowOverride All
   </Directory>
</VirtualHost>

<VirtualHost *:80>
   ServerName dev.default.com
   DocumentRoot "/vagrant/vhosts/default/dev"
   <Directory />
      Options Indexes FollowSymLinks
      AllowOverride All
   </Directory>
</VirtualHost>

Manually editing my host /etc/hosts/ file to add these two line, I can access both virtual hosts at http://default.com:8080 and http://dev.default.com:8080 respectively. However, for this to work, I have to manually edit my host hosts file.

Lines manually added to /etc/hosts on host computer:

127.0.0.1 default.com
127.0.0.1 dev.default.com

vagrant-hostmanager does add this line to /etc/hosts on host computer:

127.0.0.1 default #bunch of numbers

Is there a way to have multiple virtual hosts added to /etc/hosts automatically ?

My Vagrantfile looks like so, maybe I should be adding something ?

Vagrant.configure("2") do |config|
  config.vm.box = "precise32"
  config.vm.box_url = "http://files.vagrantup.com/precise32.box"

  config.vm.network :forwarded_port, guest: 80, host: 8080

  config.hostmanager.enabled = true
  config.hostmanager.manage_host = true

  config.vm.provision :puppet do |puppet|
    puppet.manifests_path = "puppet/manifests"
    puppet.module_path = "puppet/modules"
    puppet.manifest_file  = "init.pp"
    puppet.options="--verbose --debug"
  end
end

Thanks!

Issue with PR #52

I'm running into the same issue with PR #52 that I resolved in PR #71. Since the code has changed significantly, it doesn't make sense for me to re-open #71.

Here's my current /etc/hosts file after destroying and recreating a Vagrant instance using a cloud-based provider (meaning: not VirtualBox):

## vagrant-hostmanager-start id: 5e9eb0e2-4ccd-42ad-8a03-d02ca77f0d96
        foo.example.com
## vagrant-hostmanager-end

## vagrant-hostmanager-start id: c1de7447-209f-4300-bf06-7148f6b6ace2
10.0.0.135      foo.example.com
## vagrant-hostmanager-end

What's happening is that when vagrant destroy is called, the cloud instance is terminated and the IP address is no longer obtainable. The plugin is then unable to make a correct match to the hosts entry and so just recreates the entry but without the IP address.

hostmanager incompatible with :public_network

When I set my configuration to :private_network, I get the following in /etc/hosts on each VM:

192.168.199.202 paul paul.test.com
192.168.199.201 john john.test.com
192.168.199.203 george george.test.com

However, if I set vm.network to :public_network, changing nothing else, I get this:

127.0.0.1 paul paul.test.com
127.0.0.1 john john.test.com
127.0.0.1 george george.test.com

Not sure what's going wrong there.

Deactivate host

Hi guys,

I'd like an easy way to deactivate the host. I currently host a vagrant machine that points to myhost.com, and the stage server is in myhost.com as well.

Upon deployment, I have to vim /etc/hosts/and add a # to the vagrant entry created by hostmanager.

Is there an easy way to do this using vagrant hostmanager that could work as a workaround?

machine with name 'default' not configured

The machine with the name 'default' was not found configured for this Vagrant environment.

ok... why would I have a default configured? why does vagrant up error out because of this? what is the resolution?

probably worth noting that I do have a vm enabled by default. config.vm.define "oracle", primary: true do |oracle|

Windows Support

Are there plans to get this to work with Windows as well?

Incompatible with Vagrant 1.2.x?

I tried the plugin with Vagrant 1.2.1 but kept getting the following error whether the values were set or not. If I comment out all hostmanager. lines so that the hostnames shouldn't be getting synced at all, I still get the error. I can only bring up VMs by uninstalling the plugin.

 
Bringing machine 'server' up with 'virtualbox' provider...
There are errors in the configuration of this machine. Please fix
the following errors and try again:

HostManager configuration:
* A value for hostmanager.auto_update can be true or false.
* A value for hostmanager.ignore_private_ip can be true or false.

Example Vagrantfile with the hostmanager. lines present (I just commented them out to disable hostname syncing):

Vagrant::Config.run do |config|
  
  # Every Vagrant virtual environment requires a box to build off of.
  config.vm.box = "centos-6.3-amd64-minial"
  config.hostmanager.auto_update = true
  config.hostmanager.ignore_private_ip = false  

  #Jira server
  config.vm.define :server do |server_config|
    server_config.vm.box = "centos-6.3-amd64-minial"
    server_config.vm.host_name = "server"
    server_config.vm.network :hostonly, "10.0.1.80"
    server_config.vm.customize ["modifyvm", :id, "--memory", 1024]
    server_config.vm.share_folder "server-packages", "/packages", "packages", :nfs=> true
  end   
end

Need proper Gemfile to help onboard contributions.

$ vagrant status
Vagrant appears to be running in a Bundler environment. Your
existing Gemfile will be used. Vagrant will not auto-load any plugins
installed with `vagrant plugin`. Vagrant will autoload any plugins in
the 'plugins' group in your Gemfile. You can force Vagrant to take over
with VAGRANT_FORCE_BUNDLER.

Make hostmanager work with DHCP addresses

It seems like vagrant-hostmanager is reading the IP address of a host from the Vagrantfile. However, when using DHCP, that does not work.

Error if hostmanager configuration option missing in Vagrantfile. My suggest => consider as enable=false

Hi,

if vagrant-hostmanager is installed and I haven't config.hostmanager.enabled present in my Vagrantfile, then I've this error :

Bringing machine 'default' up with 'virtualbox' provider...
There are errors in the configuration of this machine. Please fix
the following errors and try again:

HostManager configuration:
* A value for hostmanager.enabled can only be true or false, not type 'Object'
* A value for hostmanager.manage_host can only be true or false, not type 'Object'
* A value for hostmanager.ignore_private_ip can only be true or false, not type 'Object'
* A value for hostmanager.include_offline can only be true or false, not type 'Object'

This is my Vagrantfile content :

Vagrant.configure("2") do |config|
  config.vm.box = "debian-wheezy64"
end

This is my plugin list :

$ vagrant plugin list
vagrant-cachier (0.1.0)
vagrant-hostmanager (1.0.1)
vagrant-hostsupdater (0.0.9)

Vagrant version : 1.2.2

My suggestion : consider hostmanager.enabled missing like hostmanager.enabled=false

What do you think about my suggest ?

Best regards,
Stéphane

hostmanager hangs forever on vagrant-aws

Here's what I'm seeing right now:

1. set up hostmanager with vagant-aws and a CentOS 6.5 image, creating 5 instances.
2. run
3. hostmanager adds the aliases to the first image. Then it hangs forever; I have to ^C out of vagrant up.

Thoughts on how to investigate what's causing he hang?

Hostmanager not removing /etc/hosts entries after a destroy (or halt / suspend)

I've got my code set up like so:

    config.hostmanager.enabled = true
    config.hostmanager.manage_host = true
    config.hostmanager.ignore_private_ip = false
    config.hostmanager.include_offline = true
    config.vm.define project_name do |node|
      node.vm.hostname = project_name + ".dev"
      node.vm.network :private_network, ip: ip_address
      node.hostmanager.aliases = [ "www." + project_name + ".dev" ]
    end
    config.vm.provision :hostmanager

where ip_address and project_name are defined above this block. The entries get assigned fine in my /etc/hosts file (I think, even though they are doubled?), specifically in this case:

192.168.50.4  lempstack.dev  # VAGRANT: 5bf830d44c27687964d1eae9d863a11e (lempstack) / 59fe8ec5-56a3-422c-8d13-4e1c136b61b6
192.168.50.4    lempstack.dev www.lempstack.dev # VAGRANT ID: 59fe8ec5-56a3-422c-8d13-4e1c136b61b6

Not sure why it's on 2 lines -- anyway. When I go to destroy it, I'm left with this:

192.168.50.4  lempstack.dev  # VAGRANT: 5bf830d44c27687964d1eae9d863a11e (lempstack) / 59fe8ec5-56a3-422c-8d13-4e1c136b61b6
192.168.50.4    lempstack.dev www.lempstack.dev # VAGRANT ID: 

So, the VAGRANT ID in the last line got cleared. However, shouldn't ALL of the lines be getting cleared? Am I doing something wrong?

"manage_host = true" not doing anything

I use vagrant-hostmanager with this config:

config.hostmanager.enabled = true
config.hostmanager.manage_host = true

The guests /etc/hosts is updated correctly but it does nothing to my host machines /etc/hosts

When I execute vagrant hostmanger I only get the following output:

[devbox] Updating /etc/hosts file...

So, my guess is that there is no attempt at all to modify my hosts /etc/hosts.

I'm running this on Mac OSX 10.8.4 with Vagrant 1.2.7 and VirtualBox 4.2.16

hostname allways assigned to 127.0.0.1

Hi,
I have a problem regarding setting the hostname for a IP with a custom ip resolver. I use the following configuration on a debian 6 virtualbox vagrant. allthough the ip is detected properly, the /etc/hosts is allways set to 127.0.0.1. I tried this with a static IP configuration and with dhcp for a private network, but it allways fails.

  config.vm.hostname = 'myhost'
  config.hostmanager.enabled = true
  config.hostmanager.manage_host = true
  config.hostmanager.ignore_private_ip = false
  config.hostmanager.include_offline = true
  config.hostmanager.ip_resolver = proc do |vm,resolving_vm|
    ip = /inet addr:(\d+\.\d+\.\d+\.\d+)/.match(`vagrant ssh -c "sudo ifconfig eth1"`)
    if (!ip.nil?)
        ip[1]
    end
    puts ip[1] 
  end

Setting hostname is failing without error

I'm setting up my first VM with Vagrant and Hostmanager (based on this: https://github.com/MiniCodeMonkey/Vagrant-LAMP-Stack), but whenever I vagrant up this happens:

[mctv] Preparing network interfaces based on configuration...
[mctv] Forwarding ports...
[mctv] -- 22 => 2222 (adapter 1)
[mctv] Booting VM...
[mctv] Waiting for machine to boot. This may take a few minutes...
[mctv] Machine booted and ready!
[mctv] Setting hostname...
No error message

When I inspect my /private/etc/hosts no adjustments have been made.

This is the relevant part of my Vagrantfile:

 config.vm.define project_name do |node|
    node.vm.hostname = project_name + '.local'
    node.vm.network :private_network, ip: '172.90.90.90'
    node.hostmanager.aliases = [ "www." + project_name + ".local" ]
  end

Any idea what's going on here?

/etc/hosts still has 127.0.0.1 reference.

I'm not sure if this issue should be resolved by hostmanager but it seems OK to ask. After starting my VM my hosts file looks like this:

127.0.0.1   affy-slave2 affy-slave2 localhost
127.0.1.1   affy-slave2 affy-slave2

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
10.211.55.100   affy-master     # VAGRANT ID: 7a3d122d-43a2-4d18-9533-232760e88653
10.211.55.101   affy-slave1     # VAGRANT ID: d7e45a48-ef70-4fd2-a2d8-41f02613ba24
10.211.55.102   affy-slave2     # VAGRANT ID: 04425283-abc9-48c8-be89-965ff033a7fd

The first two lines are causing a conflict with Apache Hadoop. My slave nodes are not connecting properly with the master node. If I remove the first two lines the hadoop cluster works properly.

Should hostmanager be responsible for removing these two lines? If I'm using a private_ip address is there still a reason to have them?

Getting a Vagrant error when setting include_offline to false

"The machine with the name 'default' was not found configured for this Vagrant environment."

config.hostmanager.enabled = true
config.hostmanager.ignore_private_ip = false
config.hostmanager.include_offline = false
config.vm.provision :hostmanager

The name of my machine is superbox by the way, no "default".

Any idea what I might be doing wrong?

Custom ip resolver is incorrectly merged

I have tested custom ip resolver and its incorrectly merged, the result return from the proc is not picked up when resolving ip address

Following diff fixes things:

diff --git a/lib/vagrant-hostmanager/hosts_file.rb b/lib/vagrant-hostmanager/hosts_file.rb
index 71b4e05..e7f0f80 100644
--- a/lib/vagrant-hostmanager/hosts_file.rb
+++ b/lib/vagrant-hostmanager/hosts_file.rb
@@ -107,8 +107,8 @@ module VagrantPlugins
               next if ip
             end
           end
-        end
-        ip || (machine.ssh_info ? machine.ssh_info[:host] : nil)
+          ip || (machine.ssh_info ? machine.ssh_info[:host] : nil)
+        end        
       end

       def get_machines

Issue with private network with type dhcp

I'm trying to use a private network with the type of dhcp, but the hostmanager plugin sets the ip in the hosts file to 127.0.0.1.

I've been trying to use a custom ip resolver, but I can't seem to get that to work either.

Example of the private network configuration:

config.vm.network :private_network, type: :dhcp

My custom IP resolver workaround:

# Use eth1 IP from vm
# config.hostmanager.ip_resolver = proc do |vm|
#     ip = /inet addr:(\d+\.\d+\.\d+\.\d+)/.match(`vagrant ssh -c "ifconfig eth1"`)
#     if (!ip.nil?)
#         ip[1]
#     end
# end

# Test, not sure why this one isn't working
config.hostmanager.ip_resolver = proc do |vm|
    next "10.10.1.20"
end

Hosts file does not work on newer versions of OSX

If I get some time I may work on a pull request for this, but in the meantime I want to get it documented.

Problem: OSX ignores /etc/hosts entries unless they are at the TOP of the file.
Solution: Prepend instead of append when adding entries, at least on OSX.
Reference: http://thecoredump.org/2011/09/editing-the-hosts-file-in-mac-os-x-lion/

wrong format in hosts file after vagrant up

With this configuration in my vagrantfile

config.hostmanager.enabled = true
config.hostmanager.manage_host = true
config.hostmanager.ignore_private_ip = false
config.hostmanager.include_offline = true
config.vm.define 'webdev' do |node|
node.vm.hostname = 'cqdev'
node.vm.network "private_network", ip: "2.3.4.5"
node.hostmanager.aliases = %w(example-box.localdomain example-box-alias)
end

I'll get this output in my hosts file

2.3.4.5 cqdev # VAGRANT: c58bd0f68d579c4d59213602a9b0ed8f (webdev) / 52801801-ee6f-472e-8ecc-f4c3195703e92.3.4.5 cqdev example-box.localdomain example-box-alias # VAGRANT ID: 52801801-ee6f-472e-8ecc-f4c3195703e9

it seems to be a conflict with the vagrant cores adding host routine.

I'm using: vagrant 1.3.5 with hostmanager 1.3.0 on windows 8

Sometimes getting error when destroying last machine

SometimesI get following error in "Updating /etc/hosts file" step when destroying last machine:

/home/vagrant/.rvm/gems/ruby-2.0.0-p195/gems/net-ssh-2.6.7/lib/net/ssh/ruby_compat.rb:30:in `select': closed stream (IOError)
....
from /home/vagrant/.rvm/gems/ruby-2.0.0-p195/bundler/gems/vagrant-hostmanager-ed76e4b0e356/lib/vagrant-hostmanager/hosts_file.rb:66:in
`update'
from /home/vagrant/.rvm/gems/ruby-2.0.0-p195/bundler/gems/vagrant-hostmanager-ed76e4b0e356/lib/vagrant-hostmanager/action/update_hosts_file.rb:28:in `block in call'
from /home/vagrant/.rvm/gems/ruby-2.0.0-p195/bundler/gems/vagrant-hostmanager-ed76e4b0e356/lib/vagrant-hostmanager/action/update_hosts_file.rb:28:in `each'
from /home/vagrant/.rvm/gems/ruby-2.0.0-p195/bundler/gems/vagrant-hostmanager-ed76e4b0e356/lib/vagrant-hostmanager/action/update_hosts_file.rb:28:in `call'

hostmanager should run before provisioning

hostmanager should run before provision. Some times, when running a provisioner like chef or puppet, is necessary that the VM can find themselves by the hostname. Running the hostname after provision does not allow to use this plugins in that situations

Feature Request: host-only update from command line

I would like to do something like vagrant hostmanager --host-only. This would update the host's host file, even when config.hostmanager.manage_host = false.

My grasp of Ruby is severely limited, so no pull request but a feature request :)

Rationale

When bringing up multiple boxes with Vagrant, I want all my boxes to have their host managed by this plugin – and this works great.

I also want my host's hostfile managed. However, this requires a sudo action which in my case requires a password. Having vagrant up prompt for a password halfway through the provisioning kills my Continuous Integration ambitions, so I want to have config.hostmanager.manage_host = false in my Vagrantfile.

This feature would allow me to do unsupervised vagrant up and vagrant destroy actions, while explicitly allowing me to update my host's host file

Provider AWS - Hangs on mv /tmp/hosts /etc/hosts

Environment:
Provider: AWS
OS Guests: Linux CentOS 6.5

Running vagrant hostmanager --provider=aws --debug, process hangs on this command:

mv /tmp/hosts /etc/hosts
DEBUG ssh: stdout: mv: overwrite `/etc/hosts'?

I have changed plugin file

lib\vagrant-hostmanager\hosts_file.rb

specifying:

...
else 
    realhostfile = '/etc/hosts'
    move_cmd = 'mv -f'
end
...

With "-f" flag, vagrant go on correctly.
It is a bug or I'm missing something ?

Thank you

Missing new line before hostmanager entries

After running vagrant hostmanager with hostmanager.manage_host = true, the end of my hosts file on the host looks like this

10.20.10.10 foo.dev10.1.10.15   global  # VAGRANT ID: 5603891c-638c-4268-9aa6-bdd132812df6
10.1.10.10  salt    # VAGRANT ID: 5855bbd8-cbdb-41e6-979b-f0b8530d4078

foo.dev is something I added manually, and global and salt were added by hostmanager.

I'm not sure if it's assuming that the file ends with a blank line, or if it's getting confused on line endings (LF only here)

hostmanager breaks vagrant 1.5

Vagrant v1.5.0 emits the following error message with vagrant-hostmanager v1.3.0 installed:

/Applications/Vagrant/embedded/gems/gems/vagrant-1.5.0/plugins/kernel_v2/config/vm_provisioner.rb:63:in `add_config': undefined method `new' for nil:NilClass (NoMethodError)
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.0/plugins/kernel_v2/config/vm.rb:268:in `provision'
    from /Volumes/Data/Users/ingo/Projects/Magento/solr/Vagrantfile:71:in `block in <top (required)>'
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.0/lib/vagrant/config/v2/loader.rb:37:in `call'
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.0/lib/vagrant/config/v2/loader.rb:37:in `load'
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.0/lib/vagrant/config/loader.rb:104:in `block (2 levels) in load'
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.0/lib/vagrant/config/loader.rb:98:in `each'
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.0/lib/vagrant/config/loader.rb:98:in `block in load'
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.0/lib/vagrant/config/loader.rb:95:in `each'
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.0/lib/vagrant/config/loader.rb:95:in `load'
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.0/lib/vagrant/vagrantfile.rb:28:in `initialize'
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.0/lib/vagrant/environment.rb:482:in `new'
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.0/lib/vagrant/environment.rb:482:in `vagrantfile'
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.0/lib/vagrant/environment.rb:313:in `host'
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.0/lib/vagrant/environment.rb:164:in `block in action_runner'
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.0/lib/vagrant/action/runner.rb:36:in `call'
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.0/lib/vagrant/action/runner.rb:36:in `run'
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.0/lib/vagrant/environment.rb:300:in `hook'
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.0/lib/vagrant/environment.rb:144:in `initialize'
    from /Applications/Vagrant/bin/../embedded/gems/gems/vagrant-1.5.0/bin/vagrant:138:in `new'
    from /Applications/Vagrant/bin/../embedded/gems/gems/vagrant-1.5.0/bin/vagrant:138:in `<main>'

Host OS is OS X 10.9.2

Multiple VMs, Provisioning, and Hostnames - Timing

Howdy all, I have a problem:

1. I have two VM's named "back", and "front"
2. As part of "front"s provisioning, it needs to talk to "back"
3. With vagrant-hostmanager 1.3.0, this does not work, because at the time "front" is provisioned, it has not had it's hostnames configured.

I am 99.9999% sure this used to work on a previous version, I recently updated the plugin and stupidly did not keep track of which version I had before.

1. Is this a bug that can be fixed (update hostnames on each VM before they get provisioned)
2. If this is intended behavior, was there a version that did not have this behavior that I could revert to?

As of now, I can not automatically provision my VMs, I have to do them one at a time which is takes some of the shine off this whole process.

Thank you in advance!

Unknown configuration section 'hostmanager'.

$ vagrant install vagrant-hostmanager

$ vagrant plugin list
hostmanager (1.2.2)
...
$ vagrant up xxx
Bringing machine 'coord' up with 'virtualbox' provider...
There are errors in the configuration of this machine. Please fix
the following errors and try again:

Vagrant:
* Unknown configuration section 'hostmanager'.

New Release

Windows support was added recently, and I'm really looking forward to using this plugin to manage hostnames for my Vagrant machines on windows. Is there already a planned date for the next release?

adding host entry to guest vagrant box

I am trying to get the guest vm (vagrant box) to have an entry as such:
192.168.1.35 myname.somewhere.com

BUT the following instead the following config does this:
127.0.1.1 myname.somewhere.com ubuntu-server-12042-x64-vbox4210
(I am not even sure why it's adding the second part "ubuntu-server-12042-x64-vbox4210")

This is my configuration:
config.hostmanager.enabled = true
config.hostmanager.manage_host = true
config.hostmanager.ignore_private_ip = false
config.hostmanager.include_offline = true
config.vm.define 'myUbuntu' do |node|
node.vm.hostname = 'myname.somewhere.com'
node.vm.network :private_network, ip: '192.168.1.35'
end

Any help would be appreciated

I can't install vagrant-hostmanager because I've an error around nokogiri

Since some day, I can't install vagrant-hostmanager on my OSX :

$ vagrant plugin install vagrant-hostmanager
Installing the 'vagrant-hostmanager' plugin. This can take a few minutes...
Building nokogiri using packaged libraries.
Building libxml2-2.8.0 for nokogiri with the following patches applied:
    - 0001-Fix-parser-local-buffers-size-problems.patch
    - 0002-Fix-entities-local-buffers-size-problems.patch
    - 0003-Fix-an-error-in-previous-commit.patch
    - 0004-Fix-potential-out-of-bound-access.patch
    - 0005-Detect-excessive-entities-expansion-upon-replacement.patch
    - 0006-Do-not-fetch-external-parsed-entities.patch
    - 0007-Enforce-XML_PARSER_EOF-state-handling-through-the-pa.patch
    - 0008-Improve-handling-of-xmlStopParser.patch
    - 0009-Fix-a-couple-of-return-without-value.patch
    - 0010-Keep-non-significant-blanks-node-in-HTML-parser.patch
    - 0011-Do-not-fetch-external-parameter-entities.patch
************************************************************************
IMPORTANT!  Nokogiri builds and uses a packaged version of libxml2.

If this is a concern for you and you want to use the system library
instead, abort this installation process and reinstall nokogiri as
follows:

    gem install nokogiri -- --use-system-libraries

If you are using Bundler, tell it to use the option:

    bundle config build.nokogiri --use-system-libraries
    bundle install

However, note that nokogiri does not necessarily support all versions
of libxml2.

For example, libxml2-2.9.0 and higher are currently known to be broken
and thus unsupported by nokogiri, due to compatibility problems and
XPath optimization bugs.
************************************************************************
Bundler, the underlying system Vagrant uses to install plugins,
reported an error. The error is shown below. These errors are usually
caused by misconfigured plugin installations or transient network
issues. The error from Bundler is:

An error occurred while installing nokogiri (1.6.2.1), and Bundler cannot continue.
Make sure that `gem install nokogiri -v '1.6.2.1'` succeeds before bundling.

Do you have a way to fix it ?

Vagrant 1.2 support

Consider supporting Vagrant 1.2+

Entry in host machine's /etc/hosts is never removed

I've installed vagrant-hostmanager and created Vagrantfile with the following settings:

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  # Every Vagrant virtual environment requires a box to build off of.
  config.vm.box = "ubuntu-precise-64"

  # The url from where the 'config.vm.box' box will be fetched if it
  # doesn't already exist on the user's system.
  config.vm.box_url = "http://files.vagrantup.com/precise64.box"

  # VM's host name, will be picked up by hostmanager plugin, if available
  config.vm.host_name = "testbox.dev"

  # Hostmanager plugin (vagrant-hostmanager)
  # Automatically adds entries to hosts file for host and guest systems
  if defined? VagrantPlugins::HostManager
    config.hostmanager.enabled = true
    config.hostmanager.manage_host = true
  end

  # Create a private network, which allows host-only access to the machine
  # using a specific IP.
  config.vm.network :private_network, ip: "192.168.50.51"

end

If i run vagrant up, i get an entry in the hosts file on the host machine, everything's as it should be:

vagrant up
...
[default] Updating /etc/hosts file on active guest machines...
[default] Updating /etc/hosts file on host machine (password may be required)...

cat /etc/hosts
192.168.50.51 testbox.dev   # VAGRANT ID: bb123797-0193-4738-b5b2-6261d3c81e82

But after vagrant destroy the entry is not removed:

vagrant destroy
[default] Forcing shutdown of VM...
[default] Destroying VM and associated drives...
[default] Updating /etc/hosts file on active guest machines...
[default] Updating /etc/hosts file on host machine (password may be required)...

cat /etc/hosts
192.168.50.51 testbox.dev  # VAGRANT ID: bb123797-0193-4738-b5b2-6261d3c81e82

The vagrant hostmanager command does not help, and with every vagrant up i get a new entry with a different vagrant id.

Host machine: osX v10.8.5, Vagrant 1.3.5, Hostmanager v1.2.3

Updating hosts file on guest takes a long time

I have a simple setup with two machines: a bastion server (bastion01) and a server behind that (balancer01). The provisioning order is bastion first, then the protected server (because the protected server has firewall rules that allow for connecting only via the bastion). Once the machines are up, I use SSH's ProxyCommand to tunnel through the bastion to reach the protected server.

This setup comes up fine without hostmanager. However when it's enabled the process hangs for a long time on Updating /etc/hosts file on guest machines.... I'm not sure which "guest machines" are included in this (both servers?). Eventually (i.e. ~10 minutes) the process completes and it all works fine.

My primary questions are:

• what is happening during this wait time?
• how can I speed this up?

I'm using the latest released version of hostmanager (running vagrant plugin update hostmanager indicates I'm on the latest version), v1.5.1 of Vagrant, v1.6.0 of Ansible. The guest OS is a stock Ubuntu precise64 box, host OS is MacOS Mavericks.

The relevant debug logging (i.e. VAGRANT_LOG=info) is as follows. balancer01 is listening on port 2200.

 INFO interface: info: Updating /etc/hosts file on active guest machines...
 INFO interface: info: ==> balancer01: Updating /etc/hosts file on active guest machines...
==> balancer01: Updating /etc/hosts file on active guest machines...
 INFO environment: Getting machine: balancer01 (virtualbox)
 INFO environment: Returning cached machine: balancer01 (virtualbox)
DEBUG ssh: Checking whether SSH is ready...
.
.
.
...long, long delay (ca. 10 minutes)
.
.
.
INFO ssh: Connection errored, not re-using. Will reconnect.
INFO subprocess: Starting process: ["/usr/bin/VBoxManage", "showvminfo", "219e65d3-a795-4e0d-b983-f89110a0cb1e", "--machinereadable"]
INFO subprocess: Starting process: ["/usr/bin/VBoxManage", "showvminfo", "219e65d3-a795-4e0d-b983-f89110a0cb1e", "--machinereadable"]
INFO ssh: Attempting SSH connnection...
INFO ssh: Attempting to connect to SSH...
INFO ssh:   - Host: 127.0.0.1
INFO ssh:   - Port: 2200
INFO ssh:   - Username: vagrant
INFO ssh:   - Password? false
INFO ssh:   - Key Path: ["/Users/.../.vagrant.d/insecure_private_key"]
.
.
.
...repeats several times
.
.
.
 INFO ssh: SSH not up: #<Vagrant::Errors::SSHConnectionTimeout: Vagrant timed out while attempting to connect via SSH. This usually
means that the VM booted, but there are issues with the SSH configuration
or network connectivity issues. Please try to `vagrant reload` or
`vagrant up` again.>
 INFO environment: Getting machine: bastion01 (virtualbox)
 INFO environment: Returning cached machine: bastion01 (virtualbox)
 INFO ssh: SSH is ready!
 INFO ssh: Execute: uname -s | grep SunOS (sudo=false)
 INFO ssh: Execute: test -d $Env:SystemRoot (sudo=false)
 INFO environment: Getting machine: balancer01 (virtualbox)
 INFO environment: Returning cached machine: balancer01 (virtualbox)
 INFO environment: Getting machine: bastion01 (virtualbox)
 INFO environment: Returning cached machine: bastion01 (virtualbox)
 INFO ssh: Execute: mv /tmp/hosts /etc/hosts (sudo=true)
 INFO ssh: Execute: echo; printf $SSH_AUTH_SOCK (sudo=false)
 INFO ssh: Setting SSH_AUTH_SOCK remotely: /tmp/ssh-Rndihgf879/agent.879
 INFO interface: info: Updating /etc/hosts file on host machine (password may be required)...
 INFO interface: info: ==> balancer01: Updating /etc/hosts file on host machine (password may be required)...
==> balancer01: Updating /etc/hosts file on host machine (password may be required)...
.
.
.
...continues successfully.
.
.
.

Apology

I'm sorry all, I just don't have the time the be responsible for this project. (I don't think I have made an update since last November).

I'm going to have to let it go. It's no good for the project to have me lingering around.

Love you Shawn, best wishes.

Avoid having to type the sudo password on OSX

I have used https://gist.github.com/GUI/2864683 to avoid having to type my sudo password everytime vagrant does nfs stuff.

I would like that a similar script that would work for this plugin.

Completely exclude a (single) box of being included

By setting hostmanager.disabled inside a config.vm.define block.

Support digital ocean provider

Due to an issue in Vagrant 1.1, this plugin cannot append its middleware to the end of the up and destroy commands. Instead, it must hook into specific middleware for a provider (currently supporting Virtualbox only).

Hostmanager + AWS + CentOS + Salt = BOOM

So, fixed the issue with salt-bootstrap, and now have isolated the remaining problem to vagrant-hostmanager, which is giving me a nice dump when it crashes. Here's the setup:

• vagrant-aws
• spinning up 5 hosts
• all hosts using CentOS 6.5
• using Salt as the provisioner

If I don't try to use vagrant-hostmanager, this works. If I do call vagrant-hostmanager in order to set up /etc/hosts, this happens:

An error occurred while executing multiple actions in parallel.
Any errors that occurred are shown below.

An unexpected error ocurred when executing the action on the
'testpool01' machine. Please report this as a bug:

MissingParameter => The request must contain the parameter InstanceId

/home/josh/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/middlewares/expects.rb:6:in `response_call'
/home/josh/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/middlewares/response_parser.rb:8:in `response_call'
/home/josh/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/connection.rb:361:in `response'
/home/josh/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/connection.rb:254:in `request'
/home/josh/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/middlewares/idempotent.rb:12:in `error_call'
/home/josh/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/middlewares/base.rb:10:in `error_call'
/home/josh/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/middlewares/base.rb:10:in `error_call'
/home/josh/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/connection.rb:268:in `rescue in request'
/home/josh/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/connection.rb:217:in `request'
/home/josh/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/middlewares/idempotent.rb:12:in `error_call'
/home/josh/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/middlewares/base.rb:10:in `error_call'
/home/josh/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/middlewares/base.rb:10:in `error_call'
/home/josh/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/connection.rb:268:in `rescue in request'
/home/josh/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/connection.rb:217:in `request'
/home/josh/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/middlewares/idempotent.rb:12:in `error_call'
/home/josh/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/middlewares/base.rb:10:in `error_call'
/home/josh/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/middlewares/base.rb:10:in `error_call'
/home/josh/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/connection.rb:268:in `rescue in request'
/home/josh/.vagrant.d/gems/gems/excon-0.28.0/lib/excon/connection.rb:217:in `request'
/home/josh/.vagrant.d/gems/gems/fog-1.18.0/lib/fog/xml/sax_parser_connection.rb:36:in `request'
/home/josh/.vagrant.d/gems/gems/fog-1.18.0/lib/fog/core/deprecated/connection.rb:18:in `request'
/home/josh/.vagrant.d/gems/gems/fog-1.18.0/lib/fog/aws/compute.rb:434:in `_request'
/home/josh/.vagrant.d/gems/gems/fog-1.18.0/lib/fog/aws/compute.rb:429:in `request'
/home/josh/.vagrant.d/gems/gems/fog-1.18.0/lib/fog/aws/requests/compute/describe_instances.rb:72:in `describe_instances'
/home/josh/.vagrant.d/gems/gems/fog-1.18.0/lib/fog/aws/models/compute/servers.rb:64:in `all'
/home/josh/.vagrant.d/gems/gems/fog-1.18.0/lib/fog/aws/models/compute/servers.rb:148:in `get'
/home/josh/.vagrant.d/gems/gems/vagrant-aws-0.4.1/lib/vagrant-aws/action/read_ssh_info.rb:24:in `read_ssh_info'
/home/josh/.vagrant.d/gems/gems/vagrant-aws-0.4.1/lib/vagrant-aws/action/read_ssh_info.rb:15:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.4.3/lib/vagrant/action/warden.rb:34:in `call'
/home/josh/.vagrant.d/gems/gems/vagrant-aws-0.4.1/lib/vagrant-aws/action/connect_aws.rb:41:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.4.3/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.4.3/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.4.3/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.4.3/lib/vagrant/action/builder.rb:116:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.4.3/lib/vagrant/action/runner.rb:69:in `block in run'
/opt/vagrant/embedded/gems/gems/vagrant-1.4.3/lib/vagrant/util/busy.rb:19:in `busy'
/opt/vagrant/embedded/gems/gems/vagrant-1.4.3/lib/vagrant/action/runner.rb:69:in `run'
/opt/vagrant/embedded/gems/gems/vagrant-1.4.3/lib/vagrant/machine.rb:147:in `action'
/home/josh/.vagrant.d/gems/gems/vagrant-aws-0.4.1/lib/vagrant-aws/provider.rb:24:in `ssh_info'
/opt/vagrant/embedded/gems/gems/vagrant-1.4.3/lib/vagrant/machine.rb:264:in `ssh_info'
/home/josh/.vagrant.d/gems/gems/vagrant-hostmanager-1.3.0/lib/vagrant-hostmanager/hosts_file.rb:111:in `get_ip_address'
/home/josh/.vagrant.d/gems/gems/vagrant-hostmanager-1.3.0/lib/vagrant-hostmanager/hosts_file.rb:68:in `block in update_file'
/home/josh/.vagrant.d/gems/gems/vagrant-hostmanager-1.3.0/lib/vagrant-hostmanager/hosts_file.rb:63:in `each'
/home/josh/.vagrant.d/gems/gems/vagrant-hostmanager-1.3.0/lib/vagrant-hostmanager/hosts_file.rb:63:in `update_file'
/home/josh/.vagrant.d/gems/gems/vagrant-hostmanager-1.3.0/lib/vagrant-hostmanager/hosts_file.rb:22:in `update_guest'
/home/josh/.vagrant.d/gems/gems/vagrant-hostmanager-1.3.0/lib/vagrant-hostmanager/action/update_all.rb:34:in `block in call'
/home/josh/.vagrant.d/gems/gems/vagrant-hostmanager-1.3.0/lib/vagrant-hostmanager/action/update_all.rb:31:in `each'
/home/josh/.vagrant.d/gems/gems/vagrant-hostmanager-1.3.0/lib/vagrant-hostmanager/action/update_all.rb:31:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.4.3/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.4.3/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.4.3/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.4.3/lib/vagrant/action/builder.rb:116:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.4.3/lib/vagrant/action/runner.rb:69:in `block in run'
/opt/vagrant/embedded/gems/gems/vagrant-1.4.3/lib/vagrant/util/busy.rb:19:in `busy'
/opt/vagrant/embedded/gems/gems/vagrant-1.4.3/lib/vagrant/action/runner.rb:69:in `run'
/opt/vagrant/embedded/gems/gems/vagrant-1.4.3/lib/vagrant/machine.rb:147:in `action'
/opt/vagrant/embedded/gems/gems/vagrant-1.4.3/lib/vagrant/batch_action.rb:63:in `block (2 levels) in run'

License missing from gemspec

Some companies will only use gems with a certain license.
The canonical and easy way to check is via the gemspec
via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

Bundler now generates gems with a default 'MIT' license. There is even a License Finder
to help companies ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec.
Including a license in your gemspec is a good practice, in any case.

If you need help choosing a license, github has created a license picker tool

How did I find you?

I'm using a script to collect stats on gems, originally looking for download data, but decided to collect licenses too,
and make issues for gemspecs not specifying a license as a public service :)
So far it's going pretty well.
I've written a blog post about it

vagrant 1.6 - configuration at top level is not applied to defined vm

It looks like top-level hostmanger configuration is not applied to vms defined using "config.vm.define"

Following code does not raise exception, which means ip_resolver isn't called

  config.hostmanager.ip_resolver = proc do |vm, resolving_vm|
    raise vm.inspect.to_s
  end

  config.vm.define :master, primary: true do |master|
    # ....
  end

But the following does.

  config.vm.define :master, primary: true do |master|
      master.hostmanager.ip_resolver = proc do |vm, resolving_vm|
      raise vm.inspect.to_s
    end
    # ....
  end

Refactor HostsFile logic for easier testing and future enhancements

Hi @smdahlen, I'd like to do some refactoring to make things easier for testing and adding features.

The HostsFile module deals with a few concerns at this point that could be broken up into separate classes/files:

• getting list of machines
• resolving IP address of machine
• rendering hosts file entry
• updating hosts file content
• replacing guest hosts file
• replacing host hosts file

Breaking these up should allow for some unit tests to be implemented, which I would like do. PR #98 puts the HostsFile code into its own class, decoupling instance variable dependencies. This will make it easier to start refactoring.

Any thoughts? Are you ok with this idea?

ssh config can return a hostname instead of an IP

vagrant ssh-config doesn't always return an IP address; AWS provider for example will return fully-qualified hostname.

Perhaps get_ip_address() could check if the IP is valid, and try a DNS resolution if it's not?
if !!(ip =~ Resolv::IPv4::Regex) != true ip = Resolv.getaddress(ip) end

Allow inclusion of offline boxes

I would love to have a complete hosts file, including offline boxes, so I don't need to update after bringing a new box up.

I've been looking into the code for a bit but I seem to be banging my head against the env.active_machines and env.machine_names difference.