vagrant-aws-detiber 0.7.2.pre.2

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/docs/multi-machine/index.html.md

@@ -0,0 +1,153 @@
+---
+layout: "docs"
+page_title: "Multi-Machine"
+sidebar_current: "multimachine"
+description: |-
+  Vagrant is able to define and control multiple guest machines per
+  Vagrantfile. This is known as a "multi-machine" environment.
+---
+
+# Multi-Machine
+
+Vagrant is able to define and control multiple guest machines per
+Vagrantfile. This is known as a "multi-machine" environment.
+
+These machines are generally able to work together or are somehow associated
+with each other. Here are some use-cases people are using multi-machine
+environments for today:
+
+* Accurately modeling a multi-server production topology, such as separating
+  a web and database server.
+* Modeling a distributed system and how they interact with each other.
+* Testing an interface, such as an API to a service component.
+* Disaster-case testing: machines dying, network partitions, slow networks,
+  inconsistent world views, etc.
+
+Historically, running complex environments such as these was done by
+flattening them onto a single machine. The problem with that is that it is
+an inaccurate model of the production setup, which can behave far differently.
+
+Using the multi-machine feature of Vagrant, these environments can be modeled
+in the context of a single Vagrant environment without losing any of the
+benefits of Vagrant.
+
+## Defining Multiple Machines
+
+Multiple machines are defined within the same project [Vagrantfile](/docs/vagrantfile/)
+using the `config.vm.define` method call. This configuration directive
+is a little funny, because it creates a Vagrant configuration within a
+configuration. An example shows this best:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "shell", inline: "echo Hello"
+
+  config.vm.define "web" do |web|
+    web.vm.box = "apache"
+  end
+
+  config.vm.define "db" do |db|
+    db.vm.box = "mysql"
+  end
+end
+```
+
+As you can see, `config.vm.define` takes a block with another variable. This
+variable, such as `web` above, is the _exact_ same as the `config` variable,
+except any configuration of the inner variable applies only to the machine
+being defined. Therefore, any configuration on `web` will only affect the
+`web` machine.
+
+And importantly, you can continue to use the `config` object as well. The
+configuration object is loaded and merged before the machine-specific configuration,
+just like other Vagrantfiles within the
+[Vagrantfile load order](/docs/vagrantfile/#load-order).
+
+If you are familiar with programming, this is similar to how languages have
+different variable scopes.
+
+When using these scopes, order of execution for things such as
+provisioners becomes important. Vagrant enforces ordering outside-in, in
+the order listed in the Vagrantfile. For example, with the Vagrantfile
+below:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision :shell, inline: "echo A"
+
+  config.vm.define :testing do |test|
+    test.vm.provision :shell, inline: "echo B"
+  end
+
+  config.vm.provision :shell, inline: "echo C"
+end
+```
+
+The provisioners in this case will output "A", then "C", then "B". Notice
+that "B" is last. That is because the ordering is outside-in, in
+the order of the file.
+
+If you want to apply a slightly different configuration to multiple machines,
+see [this tip](/docs/vagrantfile/tips.html#loop-over-vm-definitions).
+
+## Controlling Multiple Machines
+
+The moment more than one machine is defined within a Vagrantfile, the
+usage of the various `vagrant` commands changes slightly. The change should
+be mostly intuitive.
+
+Commands that only make sense to target a single machine, such as
+`vagrant ssh`, now _require_ the name of the machine to control. Using
+the example above, you would say `vagrant ssh web` or `vagrant ssh db`.
+
+Other commands, such as `vagrant up`, operate on _every_ machine by
+default. So if you ran `vagrant up`, Vagrant would bring up both the
+web and DB machine. You could also optionally be specific and say
+`vagrant up web` or `vagrant up db`.
+
+Additionally, you can specify a regular expression for matching only
+certain machines. This is useful in some cases where you specify many similar
+machines, for example if you are testing a distributed service you may have
+a `leader` machine as well as a `follower0`, `follower1`, `follower2`, etc. If you
+want to bring up all the followers but not the leader, you can just do
+`vagrant up /follower[0-9]/`. If Vagrant sees a machine name within forward
+slashes, it assumes you are using a regular expression.
+
+## Communication Between Machines
+
+In order to facilitate communication within machines in a multi-machine setup,
+the various [networking](/docs/networking/) options should be used.
+In particular, the [private network](/docs/networking/private_network.html) can
+be used to make a private network between multiple machines and the host.
+
+## Specifying a Primary Machine
+
+You can also specify a _primary machine_. The primary machine will be the
+default machine used when a specific machine in a multi-machine environment
+is not specified.
+
+To specify a default machine, just mark it primary when defining it. Only
+one primary machine may be specified.
+
+```ruby
+config.vm.define "web", primary: true do |web|
+  # ...
+end
+```
+
+## Autostart Machines
+
+By default in a multi-machine environment, `vagrant up` will start
+all of the defined machines. The `autostart` setting allows you to tell
+Vagrant to _not_ start specific machines. Example:
+
+```ruby
+config.vm.define "web"
+config.vm.define "db"
+config.vm.define "db_follower", autostart: false
+```
+
+When running `vagrant up` with the settings above, Vagrant will automatically
+start the "web" and "db" machines, but will not start the "db\_follower" machine.
+You can manually force the "db\_follower" machine to start by running
+`vagrant up db_follower`.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/docs/networking/basic_usage.html.md

@@ -0,0 +1,48 @@
+---
+layout: "docs"
+page_title: "Basic Usage - Networking"
+sidebar_current: "networking-basic"
+description: |-
+  Vagrant offers multiple options for how you are able to connect your
+  guest machines to the network, but there is a standard usage pattern as
+  well as some points common to all network configurations that
+  are important to know.
+---
+
+# Basic Usage of Networking
+
+Vagrant offers multiple options for how you are able to connect your
+guest machines to the network, but there is a standard usage pattern as
+well as some points common to all network configurations that
+are important to know.
+
+## Configuration
+
+All networks are configured within your [Vagrantfile](/docs/vagrantfile/)
+using the `config.vm.network` method call. For example, the Vagrantfile
+below defines some port forwarding:
+
+```ruby
+Vagrant.configure("2") do |config|
+  # ...
+  config.vm.network "forwarded_port", guest: 80, host: 8080
+end
+```
+
+Every network type has an identifier such as `"forwarded_port"` in the above
+example. Following this is a set of configuration arguments that can differ
+for each network type. In the case of forwarded ports, two numeric arguments
+are expected: the port on the guest followed by the port on the host that
+the guest port can be accessed by.
+
+## Multiple Networks
+
+Multiple networks can be defined by having multiple `config.vm.network`
+calls within the Vagrantfile. The exact meaning of this can differ for
+each [provider](/docs/providers/), but in general the order specifies
+the order in which the networks are enabled.
+
+## Enabling Networks
+
+Networks are automatically configured and enabled after they've been defined
+in the Vagrantfile as part of the `vagrant up` or `vagrant reload` process.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/docs/networking/forwarded_ports.html.md

@@ -0,0 +1,113 @@
+---
+layout: "docs"
+page_title: "Forwarded Ports - Networking"
+sidebar_current: "networking-fp"
+description: |-
+  Vagrant forwarded ports allow you to access a port on your host machine and
+  have all data forwarded to a port on the guest machine, over either TCP or
+  UDP.
+---
+
+# Forwarded Ports
+
+**Network identifier: `forwarded_port`**
+
+Vagrant forwarded ports allow you to access a port on your host machine and have
+all data forwarded to a port on the guest machine, over either TCP or UDP.
+
+For example: If the guest machine is running a web server listening on port 80,
+you can make a forwarded port mapping to port 8080 (or anything) on your host
+machine. You can then open your browser to `localhost:8080` and browse the
+website, while all actual network data is being sent to the guest.
+
+## Defining a Forwarded Port
+
+The forwarded port configuration expects two parameters, the port on the
+guest and the port on the host. Example:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.network "forwarded_port", guest: 80, host: 8080
+end
+```
+
+This will allow accessing port 80 on the guest via port 8080 on the host.
+
+For most providers, forwarded ports by default bind to all interfaces. This
+means that other devices on your network can access the forwarded ports.
+If you want to restrict access, see the `guest_ip` and `host_ip` settings
+below.
+
+## Options Reference
+
+This is a complete list of the options that are available for forwarded
+ports. Only the `guest` and `host` options are required. Below this section,
+there are more detailed examples of using these options.
+
+* `auto_correct` (boolean) - If true, the host port will be changed 
+  automatically in case it collides with a port already in use. By 
+  default, this is false.
+  
+* `guest` (int) - The port on the guest that you want to be exposed on
+  the host. This can be any port.
+
+* `guest_ip` (string) - The guest IP to bind the forwarded port to. If
+  this is not set, the port will go to every IP interface. By default,
+  this is empty.
+
+* `host` (int) - The port on the host that you want to use to access the
+  port on the guest. This must be greater than port 1024 unless Vagrant
+  is running as root (which is not recommended).
+
+* `host_ip` (string) - The IP on the host you want to bind the forwarded
+  port to. If not specified, it will be bound to every IP. By default,
+  this is empty.
+
+* `protocol` (string) - Either "udp" or "tcp". This specifies the protocol
+  that will be allowed through the forwarded port. By default this is "tcp".
+
+* `id` (string) - Name of the rule (can be visible in VirtualBox). By 
+  default this is "protocol""guest" (example : "tcp123").
+
+## Forwarded Port Protocols
+
+By default, any defined port will only forward the TCP protocol. As an optional
+third parameter, you may specify `protocol: 'udp'` in order to pass UDP
+traffic. If a given port needs to be able to listen to the same port on both
+protocols, you must define the port twice with each protocol specified, like
+so:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.network "forwarded_port", guest: 2003, host: 12003, protocol: "tcp"
+  config.vm.network "forwarded_port", guest: 2003, host: 12003, protocol: "udp"
+end
+```
+
+## Port Collisions and Correction
+
+It is common when running multiple Vagrant machines to unknowingly create
+forwarded port definitions that collide with each other (two separate
+Vagrant projects forwarded to port 8080, for example). Vagrant includes
+built-in mechanism to detect this and correct it, automatically.
+
+Port collision detection is always done. Vagrant will not allow you to
+define a forwarded port where the port on the host appears to be accepting
+traffic or connections.
+
+Port collision auto-correction must be manually enabled for each forwarded
+port, since it is often surprising when it occurs and can lead the Vagrant
+user to think that the port was not properly forwarded. Enabling auto correct
+is easy:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.network "forwarded_port", guest: 80, host: 8080,
+    auto_correct: true
+end
+```
+
+The final `:auto_correct` parameter set to true tells Vagrant to auto
+correct any collisions. During a `vagrant up` or `vagrant reload`, Vagrant
+will output information about any collisions detections and auto corrections
+made, so you can take notice and act accordingly.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/docs/networking/index.html.md

@@ -0,0 +1,42 @@
+---
+layout: "docs"
+page_title: "Networking"
+sidebar_current: "networking"
+description: |-
+  In order to access the Vagrant environment created, Vagrant exposes
+  some high-level networking options for things such as forwarded ports,
+  connecting to a public network, or creating a private network.
+---
+
+# Networking
+
+In order to access the Vagrant environment created, Vagrant exposes
+some high-level networking options for things such as forwarded ports,
+connecting to a public network, or creating a private network.
+
+The high-level networking options are meant to define an abstraction that
+works across multiple [providers](/docs/providers/). This means that
+you can take your Vagrantfile you used to spin up a VirtualBox machine and
+you can reasonably expect that Vagrantfile to behave the same with something
+like VMware.
+
+You should first read the [basic usage](/docs/networking/basic_usage.html) page
+and then continue by reading the documentation for a specific networking
+primitive by following the navigation to the left.
+
+## Advanced Configuration
+
+In some cases,
+these options are _too_ high-level, and you may want to more finely tune
+and configure the network interfaces of the underlying machine. Most
+providers expose [provider-specific configuration](/docs/providers/configuration.html)
+to do this, so please read the documentation for your specific provider
+to see what options are available.
+
+<div class="alert alert-info">
+  <strong>For beginners:</strong> It is strongly recommended you use
+  only the high-level networking options until you are comfortable
+  with the Vagrant workflow and have things working at a basic level.
+  Provider-specific network configuration can very quickly lock you out
+  of your guest machine if improperly done.
+</div>

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/docs/networking/private_network.html.md

@@ -0,0 +1,126 @@
+---
+layout: "docs"
+page_title: "Private Networks - Networking"
+sidebar_current: "networking-private"
+description: |-
+  Vagrant private networks allow you to access your guest machine by some
+  address that is not publicly accessible from the global internet. In general,
+  this means your machine gets an address in the private address space.
+---
+
+# Private Networks
+
+**Network identifier: `private_network`**
+
+Vagrant private networks allow you to access your guest machine by some address
+that is not publicly accessible from the global internet. In general, this
+means your machine gets an address in the [private address space](https://en.wikipedia.org/wiki/Private_network#Private_IPv4_address_spaces).
+
+Multiple machines within the same private network (also usually with the
+restriction that they're backed by the same [provider](/docs/providers/))
+can communicate with each other on private networks.
+
+<div class="alert alert-info">
+  <strong>Guest operating system support.</strong> Private networks
+  generally require configuring the network adapters on the guest
+  machine. This process varies from OS to OS. Vagrant ships with
+  knowledge of how to configure networks on a variety of guest
+  operating systems, but it is possible if you are using a particularly
+  old or new operating system that private networks will not properly
+  configure.
+</div>
+
+## DHCP
+
+The easiest way to use a private network is to allow the IP to be assigned
+via DHCP.
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.network "private_network", type: "dhcp"
+end
+```
+
+This will automatically assign an IP address from the reserved address space.
+The IP address can be determined by using `vagrant ssh` to SSH into the
+machine and using the appropriate command line tool to find the IP,
+such as `ifconfig`.
+
+## Static IP
+
+You can also specify a static IP address for the machine. This lets you
+access the Vagrant managed machine using a static, known IP. The
+Vagrantfile for a static IP looks like this:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.network "private_network", ip: "192.168.50.4"
+end
+```
+
+It is up to the users to make sure that the static IP does not collide
+with any other machines on the same network.
+
+While you can choose any IP you would like, you _should_ use an IP from
+the [reserved private address space](https://en.wikipedia.org/wiki/Private_network#Private_IPv4_address_spaces). These IPs are guaranteed to never be publicly routable,
+and most routers actually block traffic from going to them from the
+outside world.
+
+For some operating systems, additional configuration options for the static
+IP address are available such as setting the default gateway or MTU.
+
+<div class="alert alert-warning">
+  <strong>Warning!</strong> Do not choose an IP that overlaps with any
+  other IP space on your system. This can cause the network to not be
+  reachable.
+</div>
+
+## IPv6
+
+You can specify a static IP via IPv6. DHCP for IPv6 is not supported.
+To use IPv6, just specify an IPv6 address as the IP:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.network "private_network", ip: "fde4:8dba:82e1::c4"
+end
+```
+
+This will assign that IP to the machine. The entire `/64` subnet will
+be reserved. Please make sure to use the reserved local addresses approved
+for IPv6.
+
+You can also modify the prefix length by changing the `netmask` option
+(defaults to 64):
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.network "private_network",
+    ip: "fde4:8dba:82e1::c4",
+    netmask: "96"
+end
+```
+
+IPv6 supports for private networks was added in Vagrant 1.7.5 and may
+not work with every provider.
+
+## Disable Auto-Configuration
+
+If you want to manually configure the network interface yourself, you
+can disable Vagrant's auto-configure feature by specifying `auto_config`:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.network "private_network", ip: "192.168.50.4",
+    auto_config: false
+end
+```
+
+If you already started the Vagrant environment before setting `auto_config`,
+the files it initially placed there will stay there. You will have to remove
+those files manually or destroy and recreate the machine.
+
+The files created by Vagrant depend on the OS. For example, for many
+Linux distros, this is `/etc/network/interfaces`. In general you should
+look in the normal location that network interfaces are configured for your
+distro.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-419afb4dcffe/website/source/docs/networking/public_network.html.md

@@ -0,0 +1,162 @@
+---
+layout: "docs"
+page_title: "Public Networks - Networking"
+sidebar_current: "networking-public"
+description: |-
+  Vagrant public networks are less private than private networks, and the exact
+  meaning actually varies from provider to provider, hence the ambiguous
+  definition. The idea is that while private networks should never allow the
+  general public access to your machine, public networks can.
+---
+
+# Public Networks
+
+**Network identifier: `public_network`**
+
+Vagrant public networks are less private than private networks, and the exact
+meaning actually varies from [provider to provider](/docs/providers/),
+hence the ambiguous definition. The idea is that while
+[private networks](/docs/networking/private_network.html) should never allow the
+general public access to your machine, public networks can.
+
+<div class="alert alert-info">
+  <strong>Confused?</strong> We kind of are, too. It is likely that
+  public networks will be replaced by <code>:bridged</code> in a
+  future release, since that is in general what should be done with
+  public networks, and providers that do not support bridging generally
+  do not have any other features that map to public networks either.
+</div>
+
+<div class="alert alert-warning">
+  <strong>Warning!</strong> Vagrant boxes are insecure by default
+  and by design, featuring public passwords, insecure keypairs
+  for SSH access, and potentially allow root access over SSH.  With
+  these known credentials, your box is easily accessible by anyone on
+  your network.  Before configuring Vagrant to use a public network,
+  consider <em>all</em> potential security implications
+  and review the <a href="/docs/boxes/base.html">default box
+  configuration</a> to identify potential security risks.
+</div>
+
+## DHCP
+
+The easiest way to use a public network is to allow the IP to be assigned
+via DHCP. In this case, defining a public network is trivially easy:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.network "public_network"
+end
+```
+
+When DHCP is used, the IP can be determined by using `vagrant ssh` to
+SSH into the machine and using the appropriate command line tool to find
+the IP, such as `ifconfig`.
+
+### Using the DHCP Assigned Default Route
+
+Some cases require the DHCP assigned default route to be untouched. In these cases one
+may specify the `use_dhcp_assigned_default_route` option. As an example:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.network "public_network",
+    use_dhcp_assigned_default_route: true
+end
+```
+
+## Static IP
+
+Depending on your setup, you may wish to manually set the IP of your
+bridged interface. To do so, add a `:ip` clause to the network definition.
+
+```ruby
+config.vm.network "public_network", ip: "192.168.0.17"
+```
+
+## Default Network Interface
+
+If more than one network interface is available on the host machine, Vagrant will
+ask you to choose which interface the virtual machine should bridge to. A default
+interface can be specified by adding a `:bridge` clause to the network definition.
+
+```ruby
+config.vm.network "public_network", bridge: "en1: Wi-Fi (AirPort)"
+```
+
+The string identifying the desired interface must exactly match the name of an
+available interface. If it cannot be found, Vagrant will ask you to pick
+from a list of available network interfaces.
+
+With some providers, it is possible to specify a list of adapters to bridge
+against:
+
+```ruby
+config.vm.network "public_network", bridge: [
+  "en1: Wi-Fi (AirPort)",
+  "en6: Broadcom NetXtreme Gigabit Ethernet Controller",
+]
+```
+
+In this example, the first network adapter that exists and can successfully be
+bridge will be used.
+
+## Disable Auto-Configuration
+
+If you want to manually configure the network interface yourself, you
+can disable auto-configuration by specifying `auto_config`:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.network "public_network", auto_config: false
+end
+```
+
+Then the shell provisioner can be used to configure the ip of the interface:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.network "public_network", auto_config: false
+
+  # manual ip
+  config.vm.provision "shell",
+    run: "always",
+    inline: "ifconfig eth1 192.168.0.17 netmask 255.255.255.0 up"
+
+  # manual ipv6
+  config.vm.provision "shell",
+    run: "always",
+    inline: "ifconfig eth1 inet6 add fc00::17/7"
+end
+```
+
+## Default Router
+
+Depending on your setup, you may wish to manually override the default
+router configuration. This is required if you need access the Vagrant box from
+other networks over the public network. To do so, you can use a shell
+provisioner script:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.network "public_network", ip: "192.168.0.17"
+
+  # default router
+  config.vm.provision "shell",
+    run: "always",
+    inline: "route add default gw 192.168.0.1"
+
+  # default router ipv6
+  config.vm.provision "shell",
+    run: "always",
+    inline: "route -A inet6 add default gw fc00::1 eth1"
+
+  # delete default gw on eth0
+  config.vm.provision "shell",
+    run: "always",
+    inline: "eval `route -n | awk '{ if ($8 ==\"eth0\" && $2 != \"0.0.0.0\") print \"route del default gw \" $2; }'`"
+end
+```
+
+Note the above is fairly complex and may be guest OS specific, but we
+document the rough idea of how to do it because it is a common question.