landrush 1.0.0 → 1.1.0.beta.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: dca00c2118b83c6948f4fa0dc6ed8622578a2034
-  data.tar.gz: a7f236f3c4f9faa00693066a7abe68cb8a444909
+  metadata.gz: e6fdf85d7935a91c069c3502b4be6a10c97937e5
+  data.tar.gz: d3ee3e5dc3b09473d3a401225e97ee631d450e39
 SHA512:
-  metadata.gz: ad79c5ea216a2e430693f94a903a6b2b72811d66737032c0ca29817447aa3fa7ccec9f819f2b370f9da93185abb6c20acaa04f143396297eb87985c89f334ddf
-  data.tar.gz: d2f6bd9ab02449069f340633d8c9fdee567922c9b75a38447e82719c125fb4c7393962bb80d857a384bfcea74b9925816fff30fb89216622689db6eb1e594bd8
+  metadata.gz: 3ef9fea8ed8a474c5eb6ee8e4ee6af181c5321941c8c4a249ed9599a621daf331d4313ae436d0ccffb3d6abb2ec56b312ef0126c029c79ec44d7b2eb4c023a95
+  data.tar.gz: 6b09eba1246096affd1f44a999fb80048c84df0efc8b0f8db0df006dcd07aa5769980ce02992992a4f623a405087198bf910f029e75e35eba11cdf23b80f1237

data/.gitignore

@@ -1,22 +1,22 @@
+# Bundler
+Gemfile.lock
+.bundle
+
+# Ruby / RVM
 .ruby-gemset
 .ruby-version
-*.rbc
-.bundle
+
+# Rake / Build
 .yardoc
-InstalledFiles
 _yardoc
 coverage
 lib/bundler/man
 pkg
 rdoc
 spec/reports
-test/tmp
-test/version_tmp
 build
 tmp
-tags
-
-.vagrant
 
+# IDE
 *.iml
 .idea

data/.rubocop.yml

@@ -4,3 +4,4 @@ AllCops:
   Exclude:
     - 'build/**/*'
     - 'vendor/**/*'
+    - 'tmp/**/*'

data/.travis.yml

@@ -1,5 +1,8 @@
 language: ruby
 
+before_install:
+- gem install bundler -v 1.12.5
+
 cache: bundler
 
 rvm:

data/CHANGELOG.md

@@ -1,8 +1,8 @@
-## [Unreleased][unreleased]
+## [1.0.0] - 2016-05-18
 
 - Added: Acceptance CI tests ([#136](https://github.com/vagrant-landrush/landrush/issues/136))
-- Fixed: Making sure that the right Vagrant data dir is used ([#172](https://github.com/vagrant-landrush/landrush/pull/172))
-- Added: Getting Landrush to work on Windows ([#170](https://github.com/vagrant-landrush/landrush/pull/170))
+- Fixed: Making sure that the right Vagrant data dir is used ([#157](https://github.com/vagrant-landrush/landrush/issues/157))
+- Added: Getting Landrush to work on Windows ([#16](https://github.com/vagrant-landrush/landrush/issues/16))
 
 ## [0.19.0] - 2016-03-10
 - Added: Support for libvirt provider (#138)
@@ -19,7 +19,7 @@
 ## [0.16.0] - 2015-01-18
 - Added: Support for IN::PTR records (#98)
 
-[unreleased]: https://github.com/phinze/landrush/compare/v0.19.0...HEAD
+[1.0.0]: https://github.com/phinze/landrush/compare/v0.19.0...v1.0.0
 [0.19.0]: https://github.com/phinze/landrush/compare/v0.18.0...v0.19.0
 [0.18.0]: https://github.com/phinze/landrush/compare/v0.17.0...v0.18.0
 [0.17.0]: https://github.com/phinze/landrush/compare/v0.16.0...v0.17.0

data/CONTRIBUTING.md

@@ -1,5 +1,15 @@
 # Contributing to Landrush
 
+<!-- MarkdownTOC -->
+
+- [Working on an issue](#working-on-an-issue)
+- [Merging pull requests](#merging-pull-requests)
+- [Releasing](#releasing)
+- [Maintainers](#maintainers)
+
+<!-- /MarkdownTOC -->
+
+
 The following is a set of guidelines for contributing to Landrush.
 These are just guidelines, please use your best judgment and feel free
 to propose changes to this document in a pull request.
@@ -7,24 +17,50 @@ to propose changes to this document in a pull request.
 At this point, this document is not complete, but as decisions are made
 they will be added to this document.
 
-## Pull Requests
+<a name="working-on-an-issue"></a>
+## Working on an issue
 
-* All changes should be made by pull request (PR), even from maintainers.
+* All changes should have a matching issue in the GitHub [issue tracker](https://github.com/vagrant-landrush/landrush/issues). If there is none, create one.
+* Prepend each commit of a porposed change with the GitHub issue key, eg `Issue #xyz Fixing foo in bar`
+* All changes should be applied to master via [pull requests](https://help.github.com/articles/using-pull-requests/) (even from maintainers).
 * All changes should include documentation updates.
 * Small changes need only 1 ACK. Larger changes need 2 ACKs from
-  maintainers before they will be merged. If the author of the PR is a
-  maintainer, the submission is considered 1 of the 2 ACKs. Therefore PRs
+  maintainers before they will be merged. If the author of the pull request is a
+  maintainer, the submission is considered 1 of the 2 ACKs. Therefore pull requests
   from maintainers only require one additional ACK. By "2 ACKs" we mean
   that 2 maintainers must acknowledge that the change is a good one. The
-  2nd person to ACK the PR should merge the PR with a comment including
-  their agreement.  We default to moving forward and using revert if needed.
+  2nd person to ACK the pull request should merge the pull request with a
+  comment including their agreement. We default to moving forward and using
+  revert if needed.
+
+<a name="merging-pull-requests"></a>
+## Merging pull requests
+
+1. Merging committer should merge the pull request. Avoid using GitHub UI and
+   prefer merges over the the command line to avoid merge commits and to keep
+   a linear commit history:
+
+       ```
+       # Create a local branch for the pull request
+       $ git checkout -b <branch-name> master
+
+       # Pull the changes
+       $ git pull <remote> <branch-name>
+
+       # If necessary rebase changes on master to ensure we have a fast forward. Also resolve any conflicts
+       $ git rebase -i master
+
+       # Merge changes into master
+	   $ git checkout master
+	   $ git merge <branch-name>
 
-## Merging PRs
+	   # Update changelog in the unreleased section. Commit!
 
-1. Merging committer should first merge the PR
-2. Merging committer should update the changelog in the unreleased
-   section.  Using the github web UI is sufficient
+	   # Push to origin
+       $ git push origin master
+       ```
 
+<a name="releasing"></a>
 ## Releasing
 
 Prereqs:
@@ -35,14 +71,15 @@ Prereqs:
 Steps:
 
 1. Update `lib/landrush/version.rb` with version number.
-2. Update `CHANGELOG.md` header with version number and current date.
-3. Make release commit: `git add lib/landrush/version.rb CHANGELOG.md; git commit -m 'cut vX.Y.Z'`
-4. Make release tag: `git tag -m vX.Y.Z vX.Y.Z`
-5. Push release commit: `git push origin master`
-6. Build release: `rake build`
-7. Push released gem: `gem push pkg/landrush-X.Y.Z.gem`
-8. Update CHANGELOG to add an "Unreleased" section, commit as "clean up after vX.Y.Z".
+1. Update `CHANGELOG.md` header with version number and current date.
+1. Make release commit: `git add lib/landrush/version.rb CHANGELOG.md; git commit -m 'cut vX.Y.Z'`
+1. Make release tag: `git tag -m vX.Y.Z vX.Y.Z`
+1. Push release commit: `git push origin master`
+1. Build release: `rake build`
+1. Push released gem: `gem push pkg/landrush-X.Y.Z.gem`
+1. Update CHANGELOG to add an "Unreleased" section, commit as "clean up after vX.Y.Z".
 
+<a name="maintainers"></a>
 ## Maintainers
 
 * Brian Exelbierd (@bexelbie)

data/Gemfile

@@ -3,24 +3,20 @@ source 'https://rubygems.org'
 # Can't use `gemspec` to pull in dependencies, because the landrush gem needs
 # to be in the :plugins group for Vagrant to detect and load it in development
 
-gem 'rubydns', '0.8.5'
-gem 'rake'
-gem 'json'
+gemspec
 
 # Vagrant's special group
 group :plugins do
   gem 'landrush', path: '.'
 end
 
-group :test do
-  gem 'rubocop', '~> 0.38.0'
-end
-
 group :development do
   gem 'vagrant',
       :git => 'git://github.com/mitchellh/vagrant.git',
-      :ref => 'v1.8.1'
+      :ref => 'v1.8.4'
 
+  gem 'rake', '~> 10'
+  gem 'rubocop', '~> 0.38.0'
   gem 'byebug'
   gem 'mocha'
   gem 'minitest'

data/README.md

@@ -1,10 +1,11 @@
 # Landrush: DNS for Vagrant [![Build Status](https://travis-ci.org/vagrant-landrush/landrush.png)](https://travis-ci.org/vagrant-landrush/landrush)
 
-Simple cross-platform DNS that's visible on both the guest and the host.
+Landrush is a simple cross-platform DNS for Vagrant VMs that is visible on both,
+the guest and the host.
 
-Landrush spins up a small DNS server and redirects DNS traffic from your
+It spins up a small DNS server and redirects DNS traffic from your
 VMs to use it, automatically registering/unregistering IP addresses of guests
-as they come up and down.
+as they come up and go down.
 
 **Note**: Windows support is currently considered experimental. If you having
 problems using Landrush on Windows please let us know.
@@ -13,7 +14,7 @@ problems using Landrush on Windows please let us know.
 
 - [Installation](#installation)
 - [Usage](#usage)
-    - [Get started](#get-started)
+    - [Getting started](#getting-started)
     - [Dynamic entries](#dynamic-entries)
     - [Static entries](#static-entries)
     - [Wildcard Subdomains](#wildcard-subdomains)
@@ -25,6 +26,8 @@ problems using Landrush on Windows please let us know.
         - [Windows](#windows)
         - [Other Devices \(phone\)](#other-devices-phone)
     - [Additional CLI commands](#additional-cli-commands)
+- [Miscellaneous Tricks and Tips](#miscellaneous-tricks-and-tips)
+    - [How to avoid providing sudo password on OS X](#how-to-avoid-providing-sudo-password-on-os-x)
 - [Development](#development)
 - [Help Out!](#help-out)
 
@@ -40,35 +43,77 @@ Install under Vagrant (1.1 or later):
 <a name="usage"></a>
 ## Usage
 
-<a name="get-started"></a>
-### Get started
+<a name="getting-started"></a>
+### Getting started
 
-Enable the plugin in your `Vagrantfile`:
+1. Enable the plugin in your `Vagrantfile`:
 
-    config.landrush.enabled = true
+        config.landrush.enabled = true
 
-Bring up a machine.
+1. Bring up a machine.
 
-    $ vagrant up
+        $ vagrant up
 
-And you should be able to get your hostname from your host:
+1. You are able to get your VM's hostname resolved on your host:
 
     $ dig -p 10053 @localhost myhost.vagrant.test
 
-If you shut down your guest, the entries associated with it will be removed.
+1. If you shut down your guest, the entries associated with it will be removed.
 
-Landrush assigns your vm's hostname from either the vagrant config (see the `examples/Vagrantfile`) or system's actual hostname by running the `hostname` command. A default of "guest-vm" is assumed if hostname is otherwise not available.
+Landrush retrieves your VM's hostname from either the vagrant config
+or it uses the system's actual hostname by running the `hostname` command.
+A default of "guest-vm" is assumed if hostname is otherwise not available.
+
+A Landrush example configuration could look like this:
+
+    Vagrant.configure("2") do |config|
+      config.vm.box = "hashicorp/precise64"
+
+      config.landrush.enabled = true
+
+      config.vm.hostname = "myhost.vagrant.test"
+
+      config.landrush.host 'static1.example.com', '1.2.3.4'
+      config.landrush.host 'static2.example.com', '2.3.4.5'
+    end
 
 <a name="dynamic-entries"></a>
 ### Dynamic entries
 
-Every time a VM is started, its IP address is automatically detected and a DNS record is created that maps the hostname to its IP.
+Every time a VM is started, its IP address is automatically detected and a DNS record is created
+that maps the hostname to its IP. The detection works by listing all configured interfaces of the
+guest using [landrush-ip](https://rubygems.org/gems/landrush-ip/versions/0.2.3), picking the last
+valid IP found, while ignoring any excluded interfaces.
+
+Excluded interfaces are an array of regular expressions; the value shown here is the default used
+when no explicit value for `config.landrush.host_interface_excludes` is specified in your
+`Vagrantfile`:
+
+    config.landrush.host_interface_excludes = [/lo[0-9]*/, /docker[0-9]+/, /tun[0-9]+/]
+
+If Landrush fails to detect the correct IP address (or none at all), you can extend this exclusion
+range to exclude more interfaces.
 
-If for any reason the auto-detection detects no IP address or the wrong IP address, or you want to override it, you can do like so:
+If you need or want to select an interface explicitly and you know its name, you can also tell
+Landrush to grab that interface's IP address explicitly:
+
+    config.landrush.host_interface = 'eth0'
+
+Do note that, if you specify an interface explicitly, it will have priority over
+`config.landrush.host_interface_excludes`. In other words, if `config.landrush.host_interface_excludes`
+is set to `[/eth[0-9]*/]`, but `config.landrush.host_interface` is set to `eth0` and `eth0` exists
+as an interface, the IP address of `eth0` is returned. The interface setting takes precedence over
+the exclude setting. If the interface does not exist, the regular heuristics will apply and Landrush
+will pick the last non-excluded IP found.
+
+If all else fails, you can override it entirely:
 
     config.landrush.host_ip_address = '1.2.3.4'
 
-If you are using a multi-machine `Vagrantfile`, configure this inside each of your `config.vm.define` sections.
+This setting will override both the exclude and interface settings completely.
+
+If you are using a multi-machine `Vagrantfile`, configure this inside each of your `config.vm.define`
+sections.
 
 <a name="static-entries"></a>
 ### Static entries
@@ -77,25 +122,35 @@ You can add static host entries to the DNS server in your `Vagrantfile` like so:
 
     config.landrush.host 'myhost.example.com', '1.2.3.4'
 
-This is great for overriding production services for nodes you might be testing locally. For example, perhaps you might want to override the hostname of your puppetmaster to point to a local vagrant box instead.
+This is great for overriding production services for nodes you might be testing locally. For example,
+perhaps you might want to override the hostname of your puppetmaster to point to a local vagrant box
+instead.
 
 <a name="wildcard-subdomains"></a>
 ### Wildcard Subdomains
 
-For your convenience, any subdomain of a DNS entry known to landrush will resolve to the same IP address as the entry. For example: given `myhost.vagrant.test -> 1.2.3.4`, both `foo.myhost.vagrant.test` and `bar.myhost.vagrant.test` will also resolve to `1.2.3.4`.
+For your convenience, any subdomain of a DNS entry known to landrush will resolve to the same IP
+address as the entry. For example: given `myhost.vagrant.test -> 1.2.3.4`, both
+`foo.myhost.vagrant.test` and `bar.myhost.vagrant.test` will also resolve to `1.2.3.4`.
 
-If you would like to configure your guests to be accessible from the host as subdomains of something other than the default `vagrant.test`, you can use the `config.landrush.tld` option in your Vagrantfile like so:
+If you would like to configure your guests to be accessible from the host as subdomains of something
+other than the default `vagrant.test`, you can use the `config.landrush.tld` option in your
+Vagrantfile like so:
 
     config.landrush.tld = 'vm'
 
-Note that from the __host__, you will only be able to access subdomains of your configured TLD by default- so wildcard subdomains only apply to that space. For the __guest__, wildcard subdomains work for anything.
+Note that from the __host__, you will only be able to access subdomains of your configured TLD by
+default- so wildcard subdomains only apply to that space. For the __guest__, wildcard subdomains
+work for anything.
 
 <a name="unmatched-queries"></a>
 ### Unmatched Queries
 
-Any DNS queries that do not match will be passed through to an upstream DNS server, so this will be able to serve as the one-stop shop for your guests' DNS needs.
+Any DNS queries that do not match will be passed through to an upstream DNS server, so this will be
+able to serve as the one-stop shop for your guests' DNS needs.
 
-If you would like to configure your own upstream servers, add upstream entries to your `Vagrantfile` like so:
+If you would like to configure your own upstream servers, add upstream entries to your
+`Vagrantfile` like so:
 
     config.landrush.upstream '10.1.1.10'
     # Set the port to 1001
@@ -106,46 +161,59 @@ If you would like to configure your own upstream servers, add upstream entries t
 <a name="visibility-on-the-guest"></a>
 ### Visibility on the Guest
 
-Linux guests should automatically have their DNS traffic redirected via `iptables` rules to the Landrush DNS server. File an issue if this does not work for you.
+Linux guests should automatically have their DNS traffic redirected via `iptables` rules to the
+Landrush DNS server. File an issue if this does not work for you.
 
 To disable this functionality:
 
     config.landrush.guest_redirect_dns = false
 
-You may want to do this if you are already proxying all your DNS requests through your host (e.g. using VirtualBox's natdnshostresolver1 option) and you
-have DNS servers that you can easily set as upstreams in the daemon (e.g. DNS requests that go through the host's VPN connection).
+You may want to do this if you are already proxying all your DNS requests through your host
+(e.g. using VirtualBox's natdnshostresolver1 option) and you
+have DNS servers that you can easily set as upstreams in the daemon (e.g. DNS requests that go
+through the host's VPN connection).
 
 <a name="visibility-on-the-host"></a>
 ### Visibility on the Host
 
+Visibility on the host means that the hostname of the VMs can be resolved on the host's DNS system.
+Depending on the OS this might require some manual configuration.
+
 <a name="os-x"></a>
 #### OS X
 
-If you're on an OS X host, we use a nice trick to unobtrusively add a secondary DNS server only for specific domains.
-Landrush adds a file into `/etc/resolver` that points lookups for hostnames ending in your `config.landrush.tld` domain
-name to its DNS server. (Check out `man 5 resolver` on your Mac OS X host for more information on this file's syntax.)
-
+If you're on an OS X host, we use a nice trick to unobtrusively add a secondary DNS server only for
+specific domains. Landrush adds automatically during startup a file into `/etc/resolver`
+that points lookups for hostnames ending in your `config.landrush.tld` domain to its DNS server.
+(Check out `man 5 resolver` on your Mac OS X host for more information on this file's syntax.)
 
 <a name="linux"></a>
 #### Linux
 
-Though it's not automatically set up by landrush, similar behavior can be achieved on Linux hosts with `dnsmasq`. You
-can integrate Landrush with dnsmasq on Ubuntu like so (tested on Ubuntu 13.10):
+Though it's not automatically set up by Landrush, similar behavior can be achieved on Linux hosts
+with `dnsmasq`. You can integrate Landrush with `dnsmasq` on Ubuntu like so (tested on Ubuntu 13.10):
 
     sudo apt-get install -y resolvconf dnsmasq
     sudo sh -c 'echo "server=/vagrant.test/127.0.0.1#10053" > /etc/dnsmasq.d/vagrant-landrush'
     sudo service dnsmasq restart
 
-If you use a TLD other than the default `vagrant.test`, replace the TLD in the above instructions accordingly. Please be aware that anything ending in '.local' as TLD will not work because the `avahi` daemon reserves this TLD for its own uses.
+If you use a TLD other than the default `vagrant.test`, replace the TLD in the above instructions
+accordingly. Please be aware that anything ending in '.local' as TLD will not work because the
+`avahi` daemon reserves this TLD for its own uses.
 
 <a name="windows"></a>
 #### Windows
 
-**Note**: Windows support is currently considered experimental. If you having
-problems using Landrush on Windows please let us know.
+On Windows a secondary DNS server can be configured via the properties of the
+network adapter used by the VM. Landrush will attempt to configure the adapter automatically
+during startup. If this fails, please follow the manual setup instructions below.
+
+It is recommended to use an elevated command prompt (command prompt with full administrator
+permissions), since admin privileges are needed to make the required changes. Landrush will
+try to elevate your prompt automatically, but this requires to spawn additional processes which in
+turn loose some potentially important log messages.
 
-On Windows a secondary DNS server can be configured via the properties of a
-network adapter. This will be illustrated in the following using Windows 10 with
+In the following section manual network configuration is described using Windows 10 and
 VirtualBox.
 
 When running VirtualBox on Windows in combination with Landrush the Network
@@ -221,9 +289,44 @@ Please refer to [/doc/proxy-mobile](/doc/proxy-mobile) for instructions.
 Check out `vagrant landrush` for additional commands to monitor the DNS server daemon.
 
 
+<a name="miscellaneous-tricks-and-tips"></a>
+## Miscellaneous Tricks and Tips
+
+<a name="how-to-avoid-providing-sudo-password-on-os-x"></a>
+### How to avoid providing sudo password on OS X
+
+When using Landrush on OS X, Landrush will try to create a file in `/etc/resolver` to make the guest
+VM visible via DNS on the host (see [OS X](#os-x) in the [visibility on host](#visibility-on-the-host)
+section). To create this file sudo permissions are needed and Landrush will ask you for your sudo
+password. This can be avoided by adding the following entries to the bottom of the sudoer
+configuration. Make sure to edit your `/etc/sudoers` configuration via `sudo visudo`:
+
+    # Begin Landrush config
+    Cmnd_Alias VAGRANT_LANDRUSH_HOST_MKDIR = /bin/mkdir /etc/resolver/*
+    Cmnd_Alias VAGRANT_LANDRUSH_HOST_CP = /bin/cp /*/vagrant_landrush_host_config* /etc/resolver/*
+    Cmnd_Alias VAGRANT_LANDRUSH_HOST_CHMOD = /bin/chmod 644 /etc/resolver/*
+    %admin ALL=(ALL) NOPASSWD: VAGRANT_LANDRUSH_HOST_MKDIR, VAGRANT_LANDRUSH_HOST_CP, VAGRANT_LANDRUSH_HOST_CHMOD
+    # End Landrush config
+
 <a name="development"></a>
 ## Development
 
+The following should get you started to develop on the Landrush code base. As a prerequisite you
+will need a Ruby 2.0 environment. We recommend to use [RVM](https://rvm.io/) to create an isolated
+development environment. On Windows the [RubyInstaller for Windows](http://rubyinstaller.org/) is
+probably the easiest way to get started. In this case you will need the
+[DevKit](http://rubyinstaller.org/add-ons/devkit/) as well.
+
+Once you have a working Ruby environment it is time to
+[fork](https://help.github.com/articles/fork-a-repo/) the repository
+(refer to the [CONTRIBUTING.md](CONTRIBUTING.md) guide for more info].
+
+The following are the most important commands you will need for development:
+
+* Install [Bundler](http://bundler.io/):
+
+        $ gem install bundler
+
 * Install dependencies:
 
         $ bundle install
@@ -242,13 +345,17 @@ Check out `vagrant landrush` for additional commands to monitor the DNS server d
 
 * Run cucumber/aruba acceptance tests:
 
-        $ bundle exec cucumber
+        $ bundle exec rake features
 
   Note, that the acceptance tests currently only work out of the box on OS X.
   On Linux one has to manually configure the host visibility for the TLD
   _landrush-acceptance-test_. See for [Linux](#linux). On Windows the acceptance
   tests won't work due to a current bug in [Aruba](https://github.com/cucumber/aruba/issues/387).
 
+* Run a single cucumber/aruba acceptance tests:
+
+        $ bundle exec rake features FEATURE=features/<feature-filename>.feature
+
 * Build the Landrush gem:
 
         $ bundle exec rake install
@@ -257,14 +364,19 @@ Check out `vagrant landrush` for additional commands to monitor the DNS server d
 
         $ bundle exec rake clean clobber
 
-* Run the vagrant binary with the Landrush plugin loaded from your local
-source code:
+* Deploy to RubyGems:
+
+        $ bundle exec rake release
+
+* Run the vagrant binary with the Landrush plugin loaded from your local source code:
 
         bundle exec vagrant landrush <command>
 
 <a name="help-out"></a>
 ## Help Out!
 
-This project could use your feedback and help! Please don't hesitate to open issues or submit pull requests. NO HESITATION IS ALLOWED. NONE WHATSOEVER.  See [CONTRIBUTING.md](CONTRIBUTING.md) for more details.
+This project could use your feedback and help! Please don't hesitate to open issues or submit pull
+requests. NO HESITATION IS ALLOWED. NONE WHATSOEVER. See [CONTRIBUTING.md](CONTRIBUTING.md) for
+more details.
 
 The Maintainers try to meet periodically.  [Notes](NOTES.md) are available.

data/features/dns_resolution.feature

@@ -20,6 +20,15 @@ Feature: dns_resolution
     And the hostname "my-host.landrush-acceptance-test" should resolve to "10.10.10.123" on the host
     And the hostname "my-host.landrush-acceptance-test" should resolve to "10.10.10.123" on the guest
 
+    When I successfully run `bundle exec vagrant landrush set my-static-host.landrush-acceptance-test 42.42.42.42`
+    Then the hostname "my-static-host.landrush-acceptance-test" should resolve to "42.42.42.42" on the internal DNS server
+    And the hostname "my-static-host.landrush-acceptance-test" should resolve to "42.42.42.42" on the host
+    And the hostname "my-static-host.landrush-acceptance-test" should resolve to "42.42.42.42" on the guest
+
+    When I successfully run `bundle exec vagrant landrush set my-static-cname-host.landrush-acceptance-test my-static-host.landrush-acceptance-test`
+    Then the hostname "my-static-cname-host.landrush-acceptance-test" should resolve to "42.42.42.42" on the internal DNS server
+    And the hostname "my-static-cname-host.landrush-acceptance-test" should resolve to "42.42.42.42" on the host
+
     Examples:
       | box             | provider   |
       | debian/jessie64 | virtualbox |

data/features/landrush-ip.feature

@@ -0,0 +1,57 @@
+Feature: landrush-ip
+  Landrush should pick the desired IP, given multiple network interfaces.
+
+  Scenario Outline: booting a box and picking a specific interface
+    Given a file named "Vagrantfile" with:
+    """
+    Vagrant.configure('2') do |config|
+      config.vm.box = '<box>'
+      config.vm.hostname = 'my-host.landrush-acceptance-test'
+
+      config.vm.network :private_network, type: 'dhcp'
+      config.vm.network :private_network, type: 'dhcp'
+      config.vm.network :private_network, type: 'dhcp'
+      config.vm.network :private_network, type: 'dhcp'
+      config.vm.network :private_network, type: 'dhcp'
+
+      config.vm.synced_folder '.', '/vagrant', disabled: true
+
+      config.landrush.enabled = true
+      config.landrush.tld = 'landrush-acceptance-test'
+      config.landrush.host_interface = 'eth3'
+      config.landrush.host_interface_excludes = [/eth[0-9]+/]
+    end
+    """
+    When I successfully run `bundle exec vagrant up --provider <provider>`
+    Then the host visible IP address of the guest is the IP of interface "eth3"
+
+    Examples:
+      | box             | provider   |
+      | debian/jessie64 | virtualbox |
+
+  Scenario Outline: booting a box and excluding interfaces it should pick the last interface
+    Given a file named "Vagrantfile" with:
+    """
+    Vagrant.configure('2') do |config|
+      config.vm.box = '<box>'
+      config.vm.hostname = 'my-host.landrush-acceptance-test'
+
+      config.vm.network :private_network, type: 'dhcp'
+      config.vm.network :private_network, type: 'dhcp'
+      config.vm.network :private_network, type: 'dhcp'
+      config.vm.network :private_network, type: 'dhcp'
+      config.vm.network :private_network, type: 'dhcp'
+
+      config.vm.synced_folder '.', '/vagrant', disabled: true
+
+      config.landrush.enabled = true
+      config.landrush.tld = 'landrush-acceptance-test'
+      config.landrush.host_interface_excludes = [/eth1/, /eth2/, /eth5/]
+    end
+    """
+    When I successfully run `bundle exec vagrant up --provider <provider>`
+    Then the host visible IP address of the guest is the IP of interface "eth4"
+
+    Examples:
+      | box             | provider   |
+      | debian/jessie64 | virtualbox |

data/features/step_definitions/ip.rb

@@ -0,0 +1,13 @@
+require 'landrush/server'
+
+Then(/^the host visible IP address of the guest is the IP of interface "([^"]+)"/) do |interface|
+  cmd = "vagrant ssh -c \"ip addr list #{interface} | grep 'inet ' | cut -d' ' -f6| cut -d/ -f1\""
+  run(cmd)
+  expect(last_command_started).to have_output(/\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/)
+
+  ip = last_command_started.output.split("\n").last
+
+  run('vagrant landrush list')
+
+  expect(last_command_started).to have_output(/#{ip}$/)
+end

data/landrush.gemspec

@@ -20,7 +20,7 @@ Gem::Specification.new do |spec|
     server as well. See the README for more documentation.
   DESCRIP
   spec.summary       = %q{a vagrant plugin providing consistent DNS visible on host and guests}
-  spec.homepage      = 'https://github.com/phinze/landrush'
+  spec.homepage      = 'https://github.com/vagrant-landrush/landrush'
   spec.license       = 'MIT'
 
   spec.files         = `git ls-files`.split($/)
@@ -29,4 +29,6 @@ Gem::Specification.new do |spec|
   spec.require_paths = ['lib']
 
   spec.add_dependency 'rubydns', '0.8.5'
+  spec.add_dependency 'win32-process'
+  spec.add_dependency 'landrush-ip', '~> 0.2.3'
 end