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/other/wsl.html.md

@@ -0,0 +1,126 @@
+---
+layout: "docs"
+page_title: "Vagrant and Windows Subsystem for Linux"
+sidebar_current: "other-wsl"
+description: |-
+  An overview of using Vagrant on Windows within the Windows Subsystem
+  for Linux.
+---
+
+# Vagrant and Windows Subsystem for Linux
+
+Windows has recently introduced a new feature called the Windows Subsystem
+for Linux (WSL). This is a beta feature available in developer mode on recent
+releases of Windows 10. It is important to note that this feature is still
+in _beta_ on Windows, and Vagrant support should be considered _alpha_.
+
+<div class="alert alert-warning">
+  <strong>Warning: Advanced Topic!</strong> Using Vagrant within the Windows
+  Subsystem for Linux is an advanced topic that only experienced Vagrant users
+  who are reasonably comfortable with Windows, WSL, and Linux should approach.
+</div>
+
+
+# Installation
+
+Installation requires WSL, Ubuntu on Windows, and Vagrant. Read on for installation
+instructions for each item.
+
+## Windows Subsystem for Linux and Ubuntu on Windows
+
+First install the Windows Subsystem for Linux, followed by Ubuntu on Windows. This guide
+from Microsoft walks through the process:
+
+* https://msdn.microsoft.com/en-us/commandline/wsl/install_guide
+
+## Vagrant Installation
+
+Vagrant _must_ be installed within Ubuntu on Windows. Even though the `vagrant.exe`
+file can be executed from within the WSL, it will not function as expected. To
+install Vagrant into the WSL, follow these steps:
+
+* Download the 64-bit Debian package from the downloads page.
+* Open a `cmd` or `powershell` window
+* Enter the command: `bash`
+* Install vagrant: `sudo dpkg -i vagrant_VERSION_x86_64.deb`
+
+```
+C:\Users\vagrant> bash
+vagrant@vagrant-10:/mnt/c/Users/vagrant$ sudo dpkg -i vagrant_VERSION_x86_64.deb
+[sudo] password for vagrant:
+(Reading database ... 31885 files and directories currently installed.)
+Preparing to unpack vagrant_VERSION_x86_64.deb ...
+Unpacking vagrant (1:VERSION) ...
+Setting up vagrant (1:VERSION) ...
+vagrant@vagrant-10:/mnt/c/Users/vagrant$ vagrant help
+Usage: vagrant [options] <command> [<args>]
+```
+
+# Vagrant Usage
+
+Vagrant will detect when it is being run within the WSL and adjust how it
+locates and executes third party executables. For example, when using the
+VirtualBox provider Vagrant will interact with VirtualBox installed on
+the Windows system, not within the WSL. It is important to ensure that
+any required Windows executable is available within your `PATH` to allow
+Vagrant to access them.
+
+## Windows Access
+
+Working within the WSL provides a layer of isolation from the actual
+Windows system. In most cases Vagrant will need access to the actual
+Windows system to function correctly. As most Vagrant providers will
+need to be installed on Windows directly (not within the WSL) Vagrant
+will require Windows access. Access to the Windows system is controlled
+via an environment variable: `VAGRANT_WSL_ENABLE_WINDOWS_ACCESS`. If
+this environment variable is set, Vagrant will access the Windows system
+to run executables and enable things like synced folders. When running
+in a bash shell within WSL, the environment variable can be setup like so:
+
+```
+$ export VAGRANT_WSL_ENABLE_WINDOWS_ACCESS="1"
+```
+
+This will enable Vagrant to access the Windows system outside of the
+WSL and properly interact with Windows executables. This will automatically
+modify the `VAGRANT_HOME` environment variable if it is not already defined,
+setting it to be within the user's home directory on Windows.
+
+It is important to note that paths shared with the Windows system will
+not have Linux permissions enforced. For example, when a directory within
+the WSL is synced to a guest using the VirtualBox provider, any local
+permissions defined on that directory (or its contents) will not be
+visible from the guest. Likewise, any files created from the guest within
+the synced folder will be world readable/writeable in WSL.
+
+Other useful WSL related environment variables:
+
+* `VAGRANT_WSL_WINDOWS_ACCESS_USER` - Override current Windows username
+* `VAGRANT_WSL_DISABLE_VAGRANT_HOME` - Do not modify the `VAGRANT_HOME` variable
+* `VAGRANT_WSL_WINDOWS_ACCESS_USER_HOME_PATH` - Custom Windows system home path
+
+If a Vagrant project directory is not within the user's home directory on the
+Windows system, certain actions that include permission checks may fail (like
+`vagrant ssh`). When accessing Vagrant projects outside the WSL Vagrant will
+skip these permission checks when the project path is within the path defined
+in the `VAGRANT_WSL_WINDOWS_ACCESS_USER_HOME_PATH` environment variable. For
+example, if a user wants to run a Vagrant project from the WSL that is located
+at `C:\TestDir\vagrant-project`:
+
+```
+C:\Users\vagrant> cd C:\TestDir\vagrant-project
+C:\TestDir\vagrant-project> bash
+vagrant@vagrant-10:/mnt/c/TestDir/vagrant-project$ export VAGRANT_WSL_WINDOWS_ACCESS_USER_HOME_PATH="/mnt/c/TestDir"
+vagrant@vagrant-10:/mnt/c/TestDir/vagrant-project$ vagrant ssh
+```
+
+## Using Docker
+
+The docker daemon cannot be run inside the Windows Subsystem for Linux. However,
+the daemon _can_ be run on Windows and accessed by Vagrant while running in the
+WSL. Once docker is installed and running on Windows, export the following
+environment variable to give Vagrant access:
+
+```
+vagrant@vagrant-10:/mnt/c/Users/vagrant$ export DOCKER_HOST=tcp://127.0.0.1:2375
+```

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

@@ -0,0 +1,151 @@
+---
+layout: "docs"
+page_title: "Ansible - Provisioning"
+sidebar_current: "provisioning-ansible"
+description: |-
+  The Vagrant Ansible provisioner allows you to provision the guest using
+  Ansible playbooks by executing "ansible-playbook" from the Vagrant host.
+---
+
+# Ansible Provisioner
+
+**Provisioner name: `ansible`**
+
+The Vagrant Ansible provisioner allows you to provision the guest using [Ansible](http://ansible.com) playbooks by executing **`ansible-playbook` from the Vagrant host**.
+
+<div class="alert alert-warning">
+  <strong>Warning:</strong>
+  If you are not familiar with Ansible and Vagrant already, I recommend starting with the <a href="/docs/provisioning/shell.html">shell provisioner</a>. However, if you are comfortable with Vagrant already, Vagrant is a great way to learn Ansible.
+</div>
+
+## Setup Requirements
+
+  - **[Install Ansible](https://docs.ansible.com/intro_installation.html#installing-the-control-machine) on your Vagrant host**.
+
+  - Your Vagrant host should ideally provide a recent version of OpenSSH that [supports ControlPersist](https://docs.ansible.com/faq.html#how-do-i-get-ansible-to-reuse-connections-enable-kerberized-ssh-or-have-ansible-pay-attention-to-my-local-ssh-config-file).
+
+If installing Ansible directly on the Vagrant host is not an option in your development environment, you might be looking for the <a href="/docs/provisioning/ansible_local.html">Ansible Local provisioner</a> alternative.
+
+## Usage
+
+This page only documents the specific parts of the `ansible` (remote) provisioner. General Ansible concepts like Playbook or Inventory are shortly explained in the [introduction to Ansible and Vagrant](/docs/provisioning/ansible_intro.html).
+
+### Simplest Configuration
+
+To run Ansible against your Vagrant guest, the basic `Vagrantfile` configuration looks like:
+
+```ruby
+Vagrant.configure("2") do |config|
+
+  #
+  # Run Ansible from the Vagrant Host
+  #
+  config.vm.provision "ansible" do |ansible|
+    ansible.playbook = "playbook.yml"
+  end
+
+end
+```
+
+##  Options
+
+This section lists the _specific_ options for the Ansible (remote) provisioner. In addition to the options listed below, this provisioner supports the [**common options** for both Ansible provisioners](/docs/provisioning/ansible_common.html).
+
+- `ask_become_pass` (boolean) - require Ansible to [prompt for a password](https://docs.ansible.com/intro_getting_started.html#remote-connection-information) when switching to another user with the [become/sudo mechanism](http://docs.ansible.com/ansible/become.html).
+
+    The default value is `false`.
+
+- `ask_sudo_pass` (boolean) - Backwards compatible alias for the [ask_become_pass](#ask_become_pass) option.
+
+    <div class="alert alert-warning">
+      <strong>Deprecation:</strong>
+      The `ask_sudo_pass` option is deprecated and will be removed in a future release. Please use the [**`ask_become_pass`**](#ask_become_pass) option instead.
+    </div>
+
+- `ask_vault_pass` (boolean) - require Ansible to [prompt for a vault password](https://docs.ansible.com/playbooks_vault.html#vault).
+
+    The default value is `false`.
+
+- `force_remote_user` (boolean) - require Vagrant to set the `ansible_ssh_user` setting in the generated inventory, or as an extra variable when a static inventory is used. All the Ansible `remote_user` parameters will then be overridden by the value of `config.ssh.username` of the [Vagrant SSH Settings](/docs/vagrantfile/ssh_settings.html).
+
+    If this option is set to `false` Vagrant will set the Vagrant SSH username as a default Ansible remote user, but `remote_user` parameters of your Ansible plays or tasks will still be taken into account and thus override the Vagrant configuration.
+
+    The default value is `true`.
+
+    <div class="alert alert-info">
+      <strong>Compatibility Note:</strong>
+      This option was introduced in Vagrant 1.8.0. Previous Vagrant versions behave like if this option was set to `false`.
+    </div>
+
+- `host_key_checking` (boolean) - require Ansible to [enable SSH host key checking](https://docs.ansible.com/intro_getting_started.html#host-key-checking).
+
+    The default value is `false`.
+
+- `raw_ssh_args` (array of strings) - require Ansible to apply a list of OpenSSH client options.
+
+    Example: `['-o ControlMaster=no']`.
+
+    It is an *unsafe wildcard* that can be used to pass additional SSH settings to Ansible via `ANSIBLE_SSH_ARGS` environment variable, overriding any other SSH arguments (e.g. defined in an [`ansible.cfg` configuration file](https://docs.ansible.com/intro_configuration.html#ssh-args)).
+
+## Tips and Tricks
+
+### Ansible Parallel Execution
+
+Vagrant is designed to provision [multi-machine environments](/docs/multi-machine) in sequence, but the following configuration pattern can be used to take advantage of Ansible parallelism:
+
+```ruby
+# Vagrant 1.7+ automatically inserts a different
+# insecure keypair for each new VM created. The easiest way
+# to use the same keypair for all the machines is to disable
+# this feature and rely on the legacy insecure key.
+# config.ssh.insert_key = false
+#
+# Note:
+# As of Vagrant 1.7.3, it is no longer necessary to disable
+# the keypair creation when using the auto-generated inventory.
+
+N = 3
+(1..N).each do |machine_id|
+  config.vm.define "machine#{machine_id}" do |machine|
+    machine.vm.hostname = "machine#{machine_id}"
+    machine.vm.network "private_network", ip: "192.168.77.#{20+machine_id}"
+
+    # Only execute once the Ansible provisioner,
+    # when all the machines are up and ready.
+    if machine_id == N
+      machine.vm.provision :ansible do |ansible|
+        # Disable default limit to connect to all the machines
+        ansible.limit = "all"
+        ansible.playbook = "playbook.yml"
+      end
+    end
+  end
+end
+```
+
+<div class="alert alert-info">
+  <strong>Tip:</strong>
+  If you apply this parallel provisioning pattern with a static Ansible inventory, you will have to organize the things so that [all the relevant private keys are provided to the `ansible-playbook` command](https://github.com/mitchellh/vagrant/pull/5765#issuecomment-120247738). The same kind of considerations applies if you are using multiple private keys for a same machine (see [`config.ssh.private_key_path` SSH setting](/docs/vagrantfile/ssh_settings.html)).
+</div>
+
+### Force Paramiko Connection Mode
+
+The Ansible provisioner is implemented with native OpenSSH support in mind, and there is no official support for [paramiko](https://github.com/paramiko/paramiko/) (A native Python SSHv2 protocol library).
+
+If you really need to use this connection mode though, it is possible to enable paramiko as illustrated in the following configuration examples:
+
+With auto-generated inventory:
+
+```
+ansible.raw_arguments = ["--connection=paramiko"]
+```
+
+With a custom inventory, the private key must be specified (e.g. via an `ansible.cfg` configuration file, `--private-key` argument, or as part of your inventory file):
+
+```
+ansible.inventory_path = "./my-inventory"
+ansible.raw_arguments  = [
+  "--connection=paramiko",
+  "--private-key=/home/.../.vagrant/machines/.../private_key"
+]
+```

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

@@ -0,0 +1,202 @@
+---
+layout: "docs"
+page_title: "Common Ansible Options - Provisioning"
+sidebar_current: "provisioning-ansible-common"
+description: |-
+  This page details the common options to the Vagrant Ansible provisioners.
+---
+
+# Shared Ansible Options
+
+The following options are available to both Vagrant Ansible provisioners:
+
+ - [`ansible`](/docs/provisioning/ansible.html)
+ - [`ansible_local`](/docs/provisioning/ansible_local.html)
+
+These options get passed to the `ansible-playbook` command that ships with Ansible, either via command line arguments or environment variables, depending on Ansible own capabilities.
+
+Some of these options are for advanced usage only and should not be used unless you understand their purpose.
+
+- `become` (boolean) - Perform all the Ansible playbook tasks [as another user](http://docs.ansible.com/ansible/become.html), different from the user used to log into the guest system.
+
+    The default value is `false`.
+
+- `become_user` (string) - Set the default username to be used by the Ansible `become` [privilege escalation](http://docs.ansible.com/ansible/become.html) mechanism.
+
+    By default this option is not set, and the Ansible default value (`root`) will be used.
+
+- `compatibility_mode` (string) - Set the **minimal** version of Ansible to be supported. Vagrant will only use parameters that are compatible with the given version.
+
+    Possible values:
+
+    - `"auto"` _(Vagrant will automatically select the optimal compatibilty mode by checking the Ansible version currently available)_
+    - `"1.8"` _(Ansible versions prior to 1.8 should mostly work well, but some options might not be supported)_
+    - `"2.0"` _(The generated Ansible inventory will be incompatible with Ansible 1.x)_
+
+    By default this option is set to `"auto"`. If Vagrant is not able to detect any supported Ansible version, it will fall back on the compatibility mode `"1.8"` with a warning.
+
+    Vagrant will error if the specified compatibility mode is incompatible with the current Ansible version.
+
+    <div class="alert alert-warning">
+      <strong>Attention:</strong>
+      Vagrant doesn't perform any validation between the `compatibility_mode` value and the value of the [`version`](#version) option.
+    </div>
+
+    <div class="alert alert-info">
+      <strong>Compatibility Note:</strong>
+      This option was introduced in Vagrant 2.0. The behavior of previous Vagrant versions can be simulated by setting the `compatibility_mode` to `"1.8"`.
+    </div>
+
+- `config_file` (string) - The path to an [Ansible Configuration file](https://docs.ansible.com/intro_configuration.html).
+
+    By default, this option is not set, and Ansible will [search for a possible configuration file in some default locations](/docs/provisioning/ansible_intro.html#ANSIBLE_CONFIG).
+
+- `extra_vars` (string or hash) - Pass additional variables (with highest priority) to the playbook.
+
+    This parameter can be a path to a JSON or YAML file, or a hash.
+
+    Example:
+
+    ```ruby
+    ansible.extra_vars = {
+      ntp_server: "pool.ntp.org",
+      nginx: {
+        port: 8008,
+        workers: 4
+      }
+    }
+    ```
+    These variables take the highest precedence over any other variables.
+
+- `galaxy_command` (template string) - The command pattern used to install Galaxy roles when `galaxy_role_file` is set.
+
+    The following (optional) placeholders can be used in this command pattern:
+    - `%{role_file}` is replaced by the absolute path to the `galaxy_role_file` option
+    - `%{roles_path}` is
+      - replaced by the absolute path to the `galaxy_roles_path` option when such option is defined, or
+      - replaced by the absolute path to a `roles` subdirectory sitting in the `playbook` parent directory.
+
+    By default, this option is set to
+
+    `ansible-galaxy install --role-file=%{role_file} --roles-path=%{roles_path} --force`
+
+- `galaxy_role_file` (string) - The path to the Ansible Galaxy role file.
+
+    By default, this option is set to `nil` and Galaxy support is then disabled.
+
+    Note: if an absolute path is given, the `ansible_local` provisioner will assume that it corresponds to the exact location on the guest system.
+
+- `galaxy_roles_path` (string) - The path to the directory where Ansible Galaxy roles must be installed
+
+    By default, this option is set to `nil`, which means that the Galaxy roles will be installed in a `roles` subdirectory located in the parent directory of the `playbook` file.
+
+- `groups` (hash) - Set of inventory groups to be included in the [auto-generated inventory file](/docs/provisioning/ansible_intro.html).
+
+    Example:
+
+    ```ruby
+    ansible.groups = {
+      "web" => ["vm1", "vm2"],
+      "db"  => ["vm3"]
+    }
+    ```
+    Example with [group variables](https://docs.ansible.com/ansible/intro_inventory.html#group-variables):
+
+    ```ruby
+    ansible.groups = {
+      "atlanta" => ["host1", "host2"],
+      "atlanta:vars" => {"ntp_server" => "ntp.atlanta.example.com",
+                         "proxy" => "proxy.atlanta.example.com"}
+    }
+    ```
+
+    Notes:
+
+    - Alphanumeric patterns are not supported (e.g. `db-[a:f]`, `vm[01:10]`).
+    - This option has no effect when the `inventory_path` option is defined.
+
+- `host_vars` (hash) - Set of inventory host variables to be included in the [auto-generated inventory file](https://docs.ansible.com/ansible/intro_inventory.html#host-variables).
+
+    Example:
+
+    ```ruby
+    ansible.host_vars = {
+      "host1" => {"http_port" => 80,
+                  "maxRequestsPerChild" => 808},
+                  "comments" => "text with spaces",
+      "host2" => {"http_port" => 303,
+                  "maxRequestsPerChild" => 909}
+    }
+    ```
+
+    Note: This option has no effect when the `inventory_path` option is defined.
+
+- `inventory_path` (string) - The path to an Ansible inventory resource (e.g. a [static inventory file](https://docs.ansible.com/intro_inventory.html), a [dynamic inventory script](https://docs.ansible.com/intro_dynamic_inventory.html) or even [multiple inventories stored in the same directory](https://docs.ansible.com/intro_dynamic_inventory.html#using-multiple-inventory-sources)).
+
+    By default, this option is disabled and Vagrant generates an inventory based on the `Vagrantfile` information.
+
+- `limit` (string or array of strings) - Set of machines or groups from the inventory file to further control which hosts [are affected](https://docs.ansible.com/glossary.html#limit-groups).
+
+    The default value is set to the machine name (taken from `Vagrantfile`) to ensure that `vagrant provision` command only affect the expected machine.
+
+    Setting `limit = "all"` can be used to make Ansible connect to all machines from the inventory file.
+
+- `playbook_command` (string) - The command used to run playbooks.
+
+    The default value is `ansible-playbook`
+
+- `raw_arguments` (array of strings) - a list of additional `ansible-playbook` arguments.
+
+    It is an *unsafe wildcard* that can be used to apply Ansible options that are not (yet) supported by this Vagrant provisioner. As of Vagrant 1.7, `raw_arguments` has the highest priority and its values can potentially override or break other Vagrant settings.
+
+    Examples:
+    - `['--check', '-M', '/my/modules']`
+    - `["--connection=paramiko", "--forks=10"]`
+
+    <div class="alert alert-warn">
+      <strong>Attention:</strong>
+      The `ansible` provisioner does not support whitespace characters in `raw_arguments` elements. Therefore **don't write** something like `["-c paramiko"]`, which will result with an invalid `" parmiko"` parameter value.
+    </div>
+
+- `skip_tags` (string or array of strings) - Only plays, roles and tasks that [*do not match* these values will be executed](https://docs.ansible.com/playbooks_tags.html).
+
+- `start_at_task` (string) - The task name where the [playbook execution will start](https://docs.ansible.com/playbooks_startnstep.html#start-at-task).
+
+- `sudo` (boolean) - Backwards compatible alias for the [`become`](#become) option.
+
+    <div class="alert alert-warning">
+      <strong>Deprecation:</strong>
+      The `sudo` option is deprecated and will be removed in a future release. Please use the [**`become`**](#become) option instead.
+    </div>
+
+- `sudo_user` (string) - Backwards compatible alias for the [`become_user`](#become_user) option.
+
+    <div class="alert alert-warning">
+      <strong>Deprecation:</strong>
+      The `sudo_user` option is deprecated and will be removed in a future release. Please use the [**`become_user`**](#become_user) option instead.
+    </div>
+
+- `tags` (string or array of strings) - Only plays, roles and tasks [tagged with these values will be executed](https://docs.ansible.com/playbooks_tags.html) .
+
+- `vault_password_file` (string) - The path of a file containing the password used by [Ansible Vault](https://docs.ansible.com/playbooks_vault.html#vault).
+
+- `verbose` (boolean or string) - Set Ansible's verbosity to obtain detailed logging
+
+    Default value is `false` (minimal verbosity).
+
+    Examples: `true` (equivalent to `v`), `-vvv` (equivalent to `vvv`), `vvvv`.
+
+    Note that when the `verbose` option is enabled, the `ansible-playbook` command used by Vagrant will be displayed.
+
+- `version` (string) - The expected Ansible version.
+
+    This option is disabled by default.
+
+    When an Ansible version is defined (e.g. `"2.1.6.0"`), the Ansible provisioner will be executed only if Ansible is installed at the requested version.
+
+    When this option is set to `"latest"`, no version check is applied.
+
+    <div class="alert alert-info">
+      <strong>Tip:</strong>
+      With the `ansible_local` provisioner, it is currently possible to use this option to specify which version of Ansible must be automatically installed, but <strong>only</strong> in combination with the [**`install_mode`**](/docs/provisioning/ansible_local.html#install_mode)  set to <strong>`:pip`</strong>.
+    </div>