vagrant-aws-mkubenka 0.7.2.pre.14 → 0.7.2.pre.16

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-1ee58c40e3f5/website/source/docs/cli/rsync-auto.html.md

@@ -0,0 +1,52 @@
+---
+layout: "docs"
+page_title: "vagrant rsync-auto - Command-Line Interface"
+sidebar_current: "cli-rsyncauto"
+description: |-
+  The "vagrant rsync-auto" command watches all local directories of any rsync
+  configured synced folders and automatically initiates an rsync transfer when
+  changes are detected.
+---
+
+# rsync-auto
+
+**Command: `vagrant rsync-auto`**
+
+This command watches all local directories of any
+[rsync synced folders](/docs/synced-folders/rsync.html) and automatically
+initiates an rsync transfer when changes are detected. This command does
+not exit until an interrupt is received.
+
+The change detection is optimized to use platform-specific APIs to listen
+for filesystem changes, and does not simply poll the directory.
+
+## Options
+
+* `--[no-]poll` - Force Vagrant to watch for changes using filesystem
+    polling instead of filesystem events. This is required for some filesystems
+    that do not support events. Warning: enabling this will make `rsync-auto`
+    _much_ slower. By default, polling is disabled.
+
+## Machine State Changes
+
+The `rsync-auto` command does not currently handle machine state changes
+gracefully. For example, if you start the `rsync-auto` command, then
+halt the guest machine, then make changes to some files, then boot it
+back up, `rsync-auto` will not attempt to resync.
+
+To ensure that the command works properly, you should start `rsync-auto`
+only when the machine is running, and shut it down before any machine
+state changes.
+
+You can always force a resync with the [rsync](/docs/cli/rsync.html) command.
+
+## Vagrantfile Changes
+
+If you change or move your Vagrantfile, the `rsync-auto` command will have
+to be restarted. For example, if you add synced folders to the Vagrantfile,
+or move the directory that contains the Vagrantfile, the `rsync-auto`
+command will either not pick up the changes or may begin experiencing
+strange behavior.
+
+Before making any such changes, it is recommended that you turn off
+`rsync-auto`, then restart it afterwards.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-1ee58c40e3f5/website/source/docs/cli/snapshot.html.md

@@ -0,0 +1,94 @@
+---
+layout: "docs"
+page_title: "vagrant snapshot - Command-Line Interface"
+sidebar_current: "cli-snapshot"
+description: |-
+  The "vagrant snapshot" command is used to manage snapshots of the guest
+  machine.
+---
+
+# Snapshot
+
+**Command: `vagrant snapshot`**
+
+This is the command used to manage snapshots with the guest machine.
+Snapshots record a point-in-time state of a guest machine. You can then
+quickly restore to this environment. This lets you experiment and try things
+and quickly restore back to a previous state.
+
+Snapshotting is not supported by every provider. If it is not supported,
+Vagrant will give you an error message.
+
+The main functionality of this command is exposed via even more subcommands:
+
+* [`push`](#snapshot-push)
+* [`pop`](#snapshot-pop)
+* [`save`](#snapshot-save)
+* [`restore`](#snapshot-restore)
+* [`list`](#snapshot-list)
+* [`delete`](#snapshot-delete)
+
+# Snapshot Push
+
+**Command: `vagrant snapshot push`**
+
+This takes a snapshot and pushes it onto the snapshot stack.
+
+This is a shorthand for `vagrant snapshot save` where you do not need
+to specify a name. When you call the inverse `vagrant snapshot pop`, it will
+restore the pushed state.
+
+~> **Warning:** If you are using `push` and `pop`, avoid using `save`
+   and `restore` which are unsafe to mix.
+
+# Snapshot Pop
+
+**Command: `vagrant snapshot pop`**
+
+This command is the inverse of `vagrant snapshot push`: it will restore
+the pushed state.
+
+## Options
+
+* `--[no-]provision` - Force the provisioners to run (or prevent them
+    from doing so).
+
+* `--no-delete` - Prevents deletion of the snapshot after restoring
+    (so that you can restore to the same point again later).
+
+# Snapshot Save
+
+**Command: `vagrant snapshot save [vm-name] NAME`**
+
+This command saves a new named snapshot. If this command is used, the
+`push` and `pop` subcommands cannot be safely used.
+
+# Snapshot Restore
+
+**Command: `vagrant snapshot restore [vm-name] NAME`**
+
+This command restores the named snapshot.
+
+* `--[no-]provision` - Force the provisioners to run (or prevent them
+    from doing so).
+
+# Snapshot List
+
+**Command: `vagrant snapshot list`**
+
+This command will list all the snapshots taken.
+
+# Snapshot Delete
+
+**Command: `vagrant snapshot delete NAME`**
+
+This command will delete the named snapshot.
+
+Some providers require all "child" snapshots to be deleted first. Vagrant
+itself does not track what these children are. If this is the case (such
+as with VirtualBox), then you must be sure to delete the snapshots in the
+reverse order they were taken.
+
+This command is typically _much faster_ if the machine is halted prior to
+snapshotting. If this is not an option, or is not ideal, then the deletion
+can also be done online with most providers.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-1ee58c40e3f5/website/source/docs/hyperv/usage.html.md

@@ -0,0 +1,25 @@
+---
+layout: "docs"
+page_title: "Usage - Hyper-V Provider"
+sidebar_current: "providers-hyperv-usage"
+description: |-
+  The Hyper-V provider is used just like any other provider. Please read the
+  general basic usage page for providers.
+---
+
+# Usage
+
+The Vagrant Hyper-V provider is used just like any other provider. Please
+read the general [basic usage](/docs/providers/basic_usage.html) page for
+providers.
+
+The value to use for the `--provider` flag is `hyperv`.
+
+Hyper-V also requires that you execute Vagrant with administrative
+privileges. Creating and managing virtual machines with Hyper-V requires
+admin rights. Vagrant will show you an error if it does not have the proper
+permissions.
+
+Boxes for Hyper-V can be easily found on
+[HashiCorp's Vagrant Cloud](https://vagrantcloud.com/boxes/search). To get started, you might
+want to try the `hashicorp/precise64` box.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-1ee58c40e3f5/website/source/docs/installation/uninstallation.html.md

@@ -0,0 +1,55 @@
+---
+layout: "docs"
+page_title: "Uninstalling Vagrant"
+sidebar_current: "installation-uninstallation"
+description: |-
+  Uninstalling Vagrant is easy and straightforward. You can either uninstall
+  the Vagrant binary, the user data, or both. The sections below cover how to
+  do this on every platform.
+---
+
+# Uninstalling Vagrant
+
+Uninstalling Vagrant is easy and straightforward. You can either uninstall
+the Vagrant binary, the user data, or both. The sections below cover how to
+do this on every platform.
+
+## Removing the Vagrant Program
+
+Removing the Vagrant program will remove the `vagrant` binary and all
+dependencies from your machine. After uninstalling the program, you can
+always [reinstall](/docs/installation/) again using standard
+methods.
+
+On **Windows**
+
+> Uninstall using the add/remove programs section of the control panel
+
+On **Mac OS X**:
+
+```sh
+rm -rf /opt/vagrant
+rm -f /usr/local/bin/vagrant
+sudo pkgutil --forget com.vagrant.vagrant
+```
+
+On **Linux**:
+
+```sh
+rm -rf /opt/vagrant
+rm -f /usr/bin/vagrant
+```
+
+## Removing User Data
+
+Removing the user data will remove all [boxes](/docs/boxes.html),
+[plugins](/docs/plugins/), license files, and any stored state that may be used
+by Vagrant. Removing the user data effectively makes Vagrant think it
+is a fresh install.
+
+On all platforms, remove the `~/.vagrant.d` directory to delete the user
+data. When debugging, the Vagrant support team may ask you to remove this
+directory. Before removing this directory, please make a backup.
+
+Running Vagrant will automatically regenerate any data necessary to run,
+so it is safe to remove the user data at any time.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-1ee58c40e3f5/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-1ee58c40e3f5/website/source/docs/other/environmental-variables.html.md

@@ -0,0 +1,213 @@
+---
+layout: "docs"
+page_title: "Environmental Variables"
+sidebar_current: "other-envvars"
+description: |-
+  Vagrant has a set of environmental variables that can be used to
+  configure and control it in a global way. This page lists those environmental
+  variables.
+---
+
+# Environmental Variables
+
+Vagrant has a set of environmental variables that can be used to
+configure and control it in a global way. This page lists those environmental
+variables.
+
+## `VAGRANT_DEBUG_LAUNCHER`
+
+For performance reasons, especially for Windows users, Vagrant uses a static
+binary to launch the actual Vagrant process. If you have _very_ early issues
+when launching Vagrant from the official installer, you can specify the
+`VAGRANT_DEBUG_LAUNCHER` environment variable to output debugging information
+about the launch process.
+
+## `VAGRANT_DEFAULT_PROVIDER`
+
+This configures the default provider Vagrant will use.
+
+This normally does not need to be set since Vagrant is fairly intelligent
+about how to detect the default provider. By setting this, you will force
+Vagrant to use this provider for any _new_ Vagrant environments. Existing
+Vagrant environments will continue to use the provider they came `up` with.
+Once you `vagrant destroy` existing environments, this will take effect.
+
+## `VAGRANT_PREFERRED_PROVIDERS`
+
+This configures providers that Vagrant should prefer.
+
+Much like the `VAGRANT_DEFAULT_PROVIDER` this environment variable normally
+does not need to be set. By setting this you will instruct Vagrant to
+_prefer_ providers defined in this environment variable for any _new_
+Vagrant environments. Existing Vagrant environments will continue to use
+the provider they came `up` with. Once you `vagrant destroy` existing environments,
+this will take effect. A single provider can be defined within this environment
+variable or a comma delimited list of providers.
+
+## `VAGRANT_BOX_UPDATE_CHECK_DISABLE`
+
+By default, Vagrant will query the metadata API server to see if a newer
+box version is available for download. This optional can be disabled on a
+per-Vagrantfile basis with `config.vm.box_check_update`, but it can also be
+disabled globally setting `VAGRANT_BOX_UPDATE_CHECK_DISABLE` to any non-empty
+value.
+
+This option will not affect global box functions like `vagrant box update`.
+
+## `VAGRANT_CHECKPOINT_DISABLE`
+
+Vagrant does occasional network calls to check whether the version of Vagrant
+that is running locally is up to date. We understand that software making remote
+calls over the internet for any reason can be undesirable. To suppress these
+calls, set the environment variable `VAGRANT_CHECKPOINT_DISABLE` to any
+non-empty value.
+
+If you use other HashiCorp tools like Packer and would prefer to configure this
+setting only once, you can set `CHECKPOINT_DISABLE` instead.
+
+## `VAGRANT_CWD`
+
+`VAGRANT_CWD` can be set to change the working directory of Vagrant. By
+default, Vagrant uses the current directory you are in. The working directory
+is important because it is where Vagrant looks for the Vagrantfile. It
+also defines how relative paths in the Vagrantfile are expanded, since they're
+expanded relative to where the Vagrantfile is found.
+
+This environmental variable is most commonly set when running Vagrant from
+a scripting environment in order to set the directory that Vagrant sees.
+
+## `VAGRANT_DOTFILE_PATH`
+
+`VAGRANT_DOTFILE_PATH` can be set to change the directory where Vagrant stores
+VM-specific state, such as the VirtualBox VM UUID. By default, this is set to
+`.vagrant`. If you keep your Vagrantfile in a Dropbox folder in order to share
+the folder between your desktop and laptop (for example), Vagrant will overwrite
+the files in this directory with the details of the VM on the most recently-used
+host. To avoid this, you could set `VAGRANT_DOTFILE_PATH` to `.vagrant-laptop`
+and `.vagrant-desktop` on the respective machines. (Remember to update your
+`.gitignore`!)
+
+## `VAGRANT_HOME`
+
+`VAGRANT_HOME` can be set to change the directory where Vagrant stores
+global state. By default, this is set to `~/.vagrant.d`. The Vagrant home
+directory is where things such as boxes are stored, so it can actually become
+quite large on disk.
+
+## `VAGRANT_LOG`
+
+`VAGRANT_LOG` specifies the verbosity of log messages from Vagrant.
+By default, Vagrant does not actively show any log messages.
+
+Log messages are very useful when troubleshooting issues, reporting
+bugs, or getting support. At the most verbose level, Vagrant outputs
+basically everything it is doing.
+
+Available log levels are "debug," "info," "warn," and "error." Both
+"warn" and "error" are practically useless since there are very few
+cases of these, and Vagrant generally reports them within the normal
+output.
+
+"info" is a good level to start with if you are having problems, because
+while it is much louder than normal output, it is still very human-readable
+and can help identify certain issues.
+
+"debug" output is _extremely_ verbose and can be difficult to read without
+some knowledge of Vagrant internals. It is the best output to attach to
+a support request or bug report, however.
+
+## `VAGRANT_NO_COLOR`
+
+If this is set to any value, then Vagrant will not use any colorized
+output. This is useful if you are logging the output to a file or
+on a system that does not support colors.
+
+The equivalent behavior can be achieved by using the `--no-color` flag
+on a command-by-command basis. This environmental variable is useful
+for setting this flag globally.
+
+## `VAGRANT_FORCE_COLOR`
+
+If this is set to any value, then Vagrant will force colored output, even
+if it detected that there is no TTY or the current environment does not
+support it.
+
+The equivalent behavior can be achieved by using the `--color` flag on a
+command-by-command basis. This environmental variable is useful for setting
+this flag globally.
+
+## `VAGRANT_NO_PLUGINS`
+
+If this is set to any value, then Vagrant will not load any 3rd party
+plugins. This is useful if you install a plugin and it is introducing
+instability to Vagrant, or if you want a specific Vagrant environment to
+not load plugins.
+
+Note that any `vagrant plugin` commands automatically do not load any
+plugins, so if you do install any unstable plugins, you can always use
+the `vagrant plugin` commands without having to worry.
+
+## `VAGRANT_ALLOW_PLUGIN_SOURCE_ERRORS`
+
+If this is set to any value, then Vagrant will not error when a configured
+plugin source is unavailable. When installing a Vagrant plugin Vagrant
+will error and halt if a plugin source is inaccessible. In some cases it
+may be desirable to ignore inaccessible sources and continue with the
+plugin installation. Enabling this value will cause Vagrant to simply log
+the plugin source error and continue.
+
+## `VAGRANT_NO_PARALLEL`
+
+If this is set, Vagrant will not perform any parallel operations (such as
+parallel box provisioning). All operations will be performed in serial.
+
+## `VAGRANT_DETECTED_OS`
+
+This environment variable may be set by the Vagrant launcher to help determine
+the current runtime platform. In general Vagrant will set this value when running
+on a Windows host using a cygwin or msys based shell. If this value is set, the
+Vagrant launcher will not modify it.
+
+## `VAGRANT_DETECTED_ARCH`
+
+This environment variable may be set by the Vagrant launcher to help determine
+the current runtime architecture in use. In general Vagrant will set this value
+when running on a Windows host using a cygwin or msys based shell. The value
+the Vagrant launcher may set in this environment variable will not always match
+the actual architecture of the platform itself. Instead it signifies the detected
+architecture of the environment it is running within. If this value is set, the
+Vagrant launcher will not modify it.
+
+## `VAGRANT_WINPTY_DISABLE`
+
+If this is set, Vagrant will _not_ wrap interactive processes with winpty where
+required.
+
+## `VAGRANT_PREFER_SYSTEM_BIN`
+
+If this is set, Vagrant will prefer using utility executables (like `ssh` and `rsync`)
+from the local system instead of those vendored within the Vagrant installation.
+This currently only applies to Windows systems.
+
+## `VAGRANT_SKIP_SUBPROCESS_JAILBREAK`
+
+As of Vagrant 1.7.3, Vagrant tries to intelligently detect if it is running in
+the installer or running via Bundler. Although not officially supported, Vagrant
+tries its best to work when executed via Bundler. When Vagrant detects that you
+have spawned a subprocess that lives outside of Vagrant's installer, Vagrant
+will do its best to reset the preserved environment dring the subprocess
+execution.
+
+If Vagrant detects it is running outside of the officially installer, the
+original environment will always be restored. You can disable this automatic
+jailbreak by setting `VAGRANT_SKIP_SUBPROCESS_JAILBREAK`.
+
+## `VAGRANT_VAGRANTFILE`
+
+This specifies the filename of the Vagrantfile that Vagrant searches for.
+By default, this is "Vagrantfile". Note that this is _not_ a file path,
+but just a filename.
+
+This environmental variable is commonly used in scripting environments
+where a single folder may contain multiple Vagrantfiles representing
+different configurations.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-1ee58c40e3f5/website/source/docs/other/index.html.md

@@ -0,0 +1,16 @@
+---
+layout: "docs"
+page_title: "Other"
+sidebar_current: "other"
+description: |-
+  This page covers Vagrant information that does not quite fit under the other
+  categories.
+---
+
+# Other
+
+This section covers other information that does not quite fit under the
+other categories.
+
+- [Debugging](/docs/other/debugging.html)
+- [Environment Variables](/docs/other/environmental-variables.html)