vagrant-packet 0.1.2 → 0.1.3

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/installation/upgrading-from-1-0.html.md

@@ -1,33 +0,0 @@
----
-layout: "docs"
-page_title: "Upgrading from Vagrant 1.0"
-sidebar_current: "installation-1-0-upgrading"
-description: |-
-  The upgrade process from 1.0.x to 1.x is straightforward. Vagrant is
-  backwards compatible with Vagrant 1.0.x, so you can simply reinstall Vagrant
-  over your previous installation by downloading the latest package and
-  installing it using standard procedures for your operating system.
----
-
-# Upgrading From Vagrant 1.0.x
-
-The upgrade process from 1.0.x to 1.x is straightforward. Vagrant is quite
-[backwards compatible](/docs/installation/backwards-compatibility.html)
-with Vagrant 1.0.x, so you can simply reinstall Vagrant
-over your previous installation by downloading the latest package and
-installing it using standard procedures for your operating system.
-
-As the [backwards compatibility](/docs/installation/backwards-compatibility.html)
-page says, **Vagrant 1.0.x plugins will not work with Vagrant 1.1+**. Many
-of these plugins have been updated to work with newer versions of Vagrant,
-so you can look to see if they've been updated. If not however, you will have
-to remove them before upgrading.
-
-It is recommended you remove _all_ plugins before upgrading, and then slowly
-add back the plugins. This usually makes for a smoother upgrade process.
-
-<div class="alert alert-warning" role="alert">
-  <strong>If your version of Vagrant was installed via Rubygems</strong>, you
-  must uninstall the old version prior to installing the package for the
-  new version of Vagrant. The Rubygems installation is no longer supported.
-</div>

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/installation/upgrading.html.md

@@ -1,35 +0,0 @@
----
-layout: "docs"
-page_title: "Upgrading Vagrant"
-sidebar_current: "installation-upgrading"
-description: |-
-  If you are upgrading from Vagrant 1.0.x, please read the specific page
-  dedicated to that. This page covers upgrading Vagrant in general during the
-  1.x series.
----
-
-# Upgrading Vagrant
-
-If you are upgrading from Vagrant 1.0.x, please read the
-[specific page dedicated to that](/docs/installation/upgrading-from-1-0.html).
-This page covers upgrading Vagrant in general during the 1.x series.
-
-Vagrant upgrades during the 1.x release series are straightforward:
-
-1. [Download](/downloads.html) the new package
-2. Install it over the existing package
-
-The installers will properly overwrite and remove old files. It is recommended
-that no other Vagrant processes are running during the upgrade process.
-
-Note that Vagrantfile stability for the new Vagrantfile syntax is not
-promised until 2.0 final. So while Vagrantfiles made for 1.0.x will
-[continue to work](/docs/installation/backwards-compatibility.html),
-newer Vagrantfiles may have backwards incompatible changes until 2.0 final.
-
-<div class="alert alert-info alert-block">
-  <strong>Run into troubles upgrading?</strong> Please
-  <a href="https://github.com/hashicorp/vagrant/issues" class="alert-link">report an issue</a>
-  if you run into problems upgrading. Upgrades are meant to be a smooth
-  process and we consider it a bug if it was not.
-</div>

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

@@ -1,153 +0,0 @@
----
-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-04f7215b5e3f/website/source/docs/networking/basic_usage.html.md

@@ -1,48 +0,0 @@
----
-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-04f7215b5e3f/website/source/docs/networking/forwarded_ports.html.md

@@ -1,113 +0,0 @@
----
-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-04f7215b5e3f/website/source/docs/networking/index.html.md

@@ -1,42 +0,0 @@
----
-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-04f7215b5e3f/website/source/docs/networking/private_network.html.md

@@ -1,126 +0,0 @@
----
-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.