vagrant-aws-detiber 0.7.2.pre.2

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

@@ -0,0 +1,101 @@
+---
+layout: "docs"
+page_title: "Puppet Agent - Provisioning"
+sidebar_current: "provisioning-puppetagent"
+description: |-
+  The Vagrant Puppet agent provisioner allows you to provision the guest using
+  Puppet, specifically by calling "puppet agent", connecting to a Puppet master,
+  and retrieving the set of modules and manifests from there.
+---
+
+# Puppet Agent Provisioner
+
+**Provisioner name: `puppet_server`**
+
+The Vagrant Puppet agent provisioner allows you to provision the guest using
+[Puppet](https://www.puppetlabs.com/puppet), specifically by
+calling `puppet agent`, connecting to a Puppet master, and retrieving
+the set of modules and manifests from there.
+
+<div class="alert alert-warning">
+  <strong>Warning:</strong> If you are not familiar with Puppet 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 the best way to learn Puppet.
+</div>
+
+## Options
+
+The `puppet_server` provisioner takes various options. None are strictly
+required. They are listed below:
+
+* `binary_path` (string) - Path on the guest to Puppet's `bin/` directory.
+
+* `client_cert_path` (string) - Path to the client certificate for the
+  node on your disk. This defaults to nothing, in which case a client
+  cert will not be uploaded.
+
+* `client_private_key_path` (string) - Path to the client private key for
+  the node on your disk. This defaults to nothing, in which case a client
+  private key will not be uploaded.
+
+* `facter` (hash) - Additional Facter facts to make available to the
+  Puppet run.
+
+* `options` (string or array) - Additional command line options to pass
+  to `puppet agent` when Puppet is ran.
+
+* `puppet_node` (string) - The name of the node. If this is not set,
+  this will attempt to use a hostname if set via `config.vm.hostname`.
+  Otherwise, the box name will be used.
+
+* `puppet_server` (string) - Hostname of the Puppet server. By default
+  "puppet" will be used.
+
+## Specifying the Puppet Master
+
+The quickest way to get started with the Puppet agent provisioner is to just
+specify the location of the Puppet master:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "puppet_server" do |puppet|
+    puppet.puppet_server = "puppet.example.com"
+  end
+end
+```
+
+By default, Vagrant will look for the host named "puppet" on the
+local domain of the guest machine.
+
+## Configuring the Node Name
+
+The node name that the agent registers as can be customized. Remember
+this is important because Puppet uses the node name as part of the process
+to compile the catalog the node will run.
+
+The node name defaults to the hostname of the guest machine, but can
+be customized using the Vagrantfile:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "puppet_server" do |puppet|
+    puppet.puppet_node = "node.example.com"
+  end
+end
+```
+
+## Additional Options
+
+Puppet supports a lot of command-line flags. Basically any setting can
+be overridden on the command line. To give you the most power and flexibility
+possible with Puppet, Vagrant allows you to specify custom command line
+flags to use:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "puppet_server" do |puppet|
+    puppet.options = "--verbose --debug"
+  end
+end
+```

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

@@ -0,0 +1,238 @@
+---
+layout: "docs"
+page_title: "Puppet Apply - Provisioning"
+sidebar_current: "provisioning-puppetapply"
+description: |-
+  The Vagrant Puppet provisioner allows you to provision the guest using
+  Puppet, specifically by calling "puppet apply", without a Puppet Master.
+---
+
+# Puppet Apply Provisioner
+
+**Provisioner name: `puppet`**
+
+The Vagrant Puppet provisioner allows you to provision the guest using
+[Puppet](https://www.puppetlabs.com/puppet), specifically by
+calling `puppet apply`, without a Puppet Master.
+
+<div class="alert alert-warning">
+  <strong>Warning:</strong> If you are not familiar with Puppet 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 the best way to learn Puppet.
+</div>
+
+## Options
+
+This section lists the complete set of available options for the Puppet
+provisioner. More detailed examples of how to use the provisioner are
+available below this section.
+
+* `binary_path` (string) - Path on the guest to Puppet's `bin/` directory.
+
+* `facter` (hash) - A hash of data to set as available facter variables
+  within the Puppet run.
+
+* `hiera_config_path` (string) - Path to the Hiera configuration on
+  the host. Read the section below on how to use Hiera with Vagrant.
+
+* `manifest_file` (string) - The name of the manifest file that will serve
+  as the entrypoint for the Puppet run. This manifest file is expected to
+  exist in the configured `manifests_path` (see below). This defaults
+  to "default.pp"
+
+* `manifests_path` (string) - The path to the directory which contains the
+  manifest files. This defaults to "manifests"
+
+* `module_path` (string) - Path, on the host, to the directory which
+  contains Puppet modules, if any.
+
+* `environment` (string) - Name of the Puppet environment.
+
+* `environment_path` (string) - Path to the directory that contains environment
+  files on the host disk.
+
+* `environment_variables` (hash) - A hash of string key/value pairs to be set as
+  environment variables before the puppet apply run.
+
+* `options` (array of strings) - Additionally options to pass to the
+  Puppet executable when running Puppet.
+
+* `synced_folder_type` (string) - The type of synced folders to use when
+  sharing the data required for the provisioner to work properly. By default
+  this will use the default synced folder type. For example, you can set this
+  to "nfs" to use NFS synced folders.
+
+* `synced_folder_args` (array) - Arguments that are passed to the folder sync.
+  For example ['-a', '--delete', '--exclude=fixtures'] for the rsync sync
+  command.
+
+* `temp_dir` (string) - The directory where all the data associated with
+  the Puppet run (manifest files, modules, etc.) will be stored on the
+  guest machine.
+
+* `working_directory` (string) - Path in the guest that will be the working
+  directory when Puppet is executed. This is usually only set because relative
+  paths are used in the Hiera configuration.
+
+~> If only `environment` and `environment_path` are specified, it will parse
+and use the manifest specified in the `environment.conf` file. If
+`manifests_path` and `manifest_file` is specified along with the environment
+options, the manifest from the environment will be overridden by the specified `manifest_file`. If `manifests_path` and `manifest_file` are specified without
+environments, the old non-environment mode will be used (which will fail on
+Puppet 4+).
+
+## Bare Minimum
+
+The quickest way to get started with the Puppet provisioner is to just
+enable it:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "puppet"
+end
+```
+
+~> `puppet` need to be installed in the guest vm.
+
+By default, Vagrant will configure Puppet to look for manifests in the
+"manifests" folder relative to the project root, and will use the
+"default.pp" manifest as an entry-point. This means, if your directory
+tree looks like the one below, you can get started with Puppet with
+just that one line in your Vagrantfile.
+
+```
+$ tree
+.
+|-- Vagrantfile
+|-- manifests
+|   |-- default.pp
+```
+
+## Custom Manifest Settings
+
+Of course, you are able to put and name your manifests whatever you would
+like. You can override both the directory where Puppet looks for
+manifests with `manifests_path`, and the manifest file used as the
+entry-point with `manifest_file`:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "puppet" do |puppet|
+    puppet.manifests_path = "my_manifests"
+    puppet.manifest_file = "default.pp"
+  end
+end
+```
+
+The path can be relative or absolute. If it is relative, it is relative
+to the project root.
+
+You can also specify a manifests path that is on the remote machine
+already, perhaps put in place by a shell provisioner. In this case, Vagrant
+will not attempt to upload the manifests directory. To specify a remote
+manifests path, use the following syntax:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "puppet" do |puppet|
+    puppet.manifests_path = ["vm", "/path/to/manifests"]
+    puppet.manifest_file = "default.pp"
+  end
+end
+```
+
+It is a somewhat odd syntax, but the tuple (two-element array) says
+that the path is located in the "vm" at "/path/to/manifests".
+
+## Environments
+
+If you are using Puppet 4 or higher, you can provision using
+[Puppet Environments](https://docs.puppetlabs.com/puppet/latest/reference/environments.html) by specifying the name of the environment and the path on the
+local disk to the environment files:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "puppet" do |puppet|
+    puppet.environment_path = "../puppet/environments"
+    puppet.environment = "testenv"
+  end
+end
+```
+
+The default manifest is the environment's `manifests` directory.
+If the environment has an `environment.conf` the manifest path is parsed
+from there. Relative paths are assumed to be relative to the directory of
+the environment. If the manifest setting in `environment.conf` use
+the Puppet variables `$codedir` or `$environment` they are resolved to
+the parent directory of `environment_path` and `environment` respectively.
+
+## Modules
+
+Vagrant also supports provisioning with [Puppet modules](https://docs.puppetlabs.com/guides/modules.html).
+This is done by specifying a path to a modules folder where modules are located.
+The manifest file is still used as an entry-point.
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "puppet" do |puppet|
+    puppet.module_path = "modules"
+  end
+end
+```
+
+Just like the manifests path, the modules path is relative to the project
+root if a relative path is given.
+
+## Custom Facts
+
+Custom facts to be exposed by [Facter](https://puppetlabs.com/facter)
+can be specified as well:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "puppet" do |puppet|
+    puppet.facter = {
+      "vagrant" => "1"
+    }
+  end
+end
+```
+
+Now, the `$vagrant` variable in your Puppet manifests will equal "1".
+
+## Configuring Hiera
+
+[Hiera](https://docs.puppetlabs.com/hiera/1/) configuration is also supported.
+`hiera_config_path` specifies the path to the Hiera configuration file stored on
+the host. If the `:datadir` setting in the Hiera configuration file is a
+relative path, `working_directory` should be used to specify the directory in
+the guest that path is relative to.
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "puppet" do |puppet|
+    puppet.hiera_config_path = "hiera.yaml"
+    puppet.working_directory = "/tmp/vagrant-puppet"
+  end
+end
+```
+
+`hiera_config_path` can be relative or absolute. If it is relative, it is
+relative to the project root. `working_directory` is an absolute path within the
+guest.
+
+## Additional Options
+
+Puppet supports a lot of command-line flags. Basically any setting can
+be overridden on the command line. To give you the most power and flexibility
+possible with Puppet, Vagrant allows you to specify custom command line
+flags to use:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "puppet" do |puppet|
+    puppet.options = "--verbose --debug"
+  end
+end
+```

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

@@ -0,0 +1,189 @@
+---
+layout: "docs"
+page_title: "Salt - Provisioning"
+sidebar_current: "provisioning-salt"
+description: |-
+  The Vagrant Salt provisioner allows you to provision the guest using
+  Salt states.
+---
+# Salt Provisioner
+
+**Provisioner name: `salt`**
+
+The Vagrant Salt provisioner allows you to provision the guest using
+[Salt](http://saltstack.com/) states.
+
+Salt states are  [YAML](https://en.wikipedia.org/wiki/YAML) documents
+that describes the current state a machine should be in, e.g. what
+packages should be installed, which services are running, and the
+contents of arbitrary files.
+
+_NOTE: The Salt provisioner is builtin to Vagrant. If the `vagrant-salt`
+plugin is installed, it should be uninstalled to ensure expected behavior._
+
+## Masterless Quickstart
+
+What follows is a basic Vagrantfile that will get salt working
+on a single minion, without a master:
+
+
+```ruby
+  Vagrant.configure("2") do |config|
+    ## Choose your base box
+    config.vm.box = "precise64"
+
+    ## For masterless, mount your salt file root
+    config.vm.synced_folder "salt/roots/", "/srv/salt/"
+
+    ## Use all the defaults:
+    config.vm.provision :salt do |salt|
+
+      salt.masterless = true
+      salt.minion_config = "salt/minion"
+      salt.run_highstate = true
+
+    end
+  end
+```
+
+This sets up a shared folder for the salt root, and copies
+the minion file over, then runs `state.highstate` on the
+machine. Your minion file must contain the line
+`file_client: local`  in order to work in a
+masterless setup.
+
+## Install Options
+
+* `install_master`  (boolean) - Should vagrant install the salt-master
+on this machine. Not supported on Windows guest machines.
+
+* `no_minion`  (boolean) - Do not install the minion, default `false`. Not supported on Windows guest machines.
+
+* `install_syndic`   (boolean) - Install the salt-syndic, default
+`false`. Not supported on Windows guest machines.
+
+* `install_type`  (stable | git | daily | testing) - Whether to install from a
+distribution's stable package manager, git tree-ish, daily ppa, or testing repository. Not supported on Windows guest machines.
+
+* `install_args` (string, default: "develop") - When performing a git install, you can specify a branch, tag, or any treeish. Not supported on Windows.
+
+* `always_install`   (boolean) - Installs salt binaries even
+ if they are already detected, default `false`
+
+* `bootstrap_script` (string) - Path to your customized salt-bootstrap.sh script. Not supported on Windows guest machines.
+
+* `bootstrap_options` (string) - Additional command-line options to
+  pass to the bootstrap script.
+
+* `version`  (string, default: "2017.7.1") - Version of minion to be installed. Only supported on Windows guest machines.
+
+* `python_version`  (string, default: "2") - Major Python version of minion to be installed. Only valid for minion versions >= 2017.7.0. Only supported on Windows guest machines.
+
+## Minion Options
+These only make sense when `no_minion` is `false`.
+
+* `minion_config`    (string, default: "salt/minion") - Path to
+a custom salt minion config file.
+
+* `minion_key`  (string, default: "salt/key/minion.key") - Path to your minion key
+
+* `minion_id`  (string) - Unique identifier for minion. Used for masterless and preseeding keys.
+
+* `minion_pub`  (string, default: "salt/key/minion.pub") - Path to your minion
+public key
+
+* `grains_config`  (string) - Path to a custom salt grains file. On Windows, the minion needs `ipc_mode: tcp` set otherwise it will [fail to communicate](https://github.com/saltstack/salt/issues/22796) with the master.
+
+* `masterless`  (boolean) - Calls state.highstate in local mode. Uses `minion_id` and `pillar_data` when provided.
+
+* `salt_call_args` (array) - An array of additional command line flag arguments to be passed to the `salt-call` command when provisioning with masterless.
+
+## Master Options
+These only make sense when `install_master` is `true`. Not supported on Windows guest machines.
+
+* `master_config` (string, default: "salt/master")
+  Path to a custom salt master config file.
+
+* `master_key` (string, default: "salt/key/master.pem") - Path to your master key.
+
+* `master_pub` (string, default: "salt/key/master.pub") - Path to your master public key.
+
+* `seed_master`  (dictionary) - Upload keys to master, thereby
+pre-seeding it before use. Example: `{minion_name:/path/to/key.pub}`
+
+* `salt_args` (array) - An array of additional command line flag arguments to be passed to the `salt` command when provisioning with masterless.
+
+## Execute States
+
+Either of the following may be used to actually execute states
+during provisioning.
+
+* `run_highstate` - (boolean) Executes `state.highstate` on
+vagrant up. Can be applied to any machine.
+
+## Execute Runners
+
+Either of the following may be used to actually execute runners
+during provisioning.
+
+* `run_overstate` - (boolean) Executes `state.over` on
+vagrant up. Can be applied to the master only. This is superseded by
+orchestrate. Not supported on Windows guest machines.
+
+* `orchestrations` - (array of strings) Executes `state.orchestrate` on
+vagrant up. Can be applied to the master only. This is superseded by
+run_overstate. Not supported on Windows guest machines.
+
+## Output Control
+
+These may be used to control the output of state execution:
+
+* `colorize` (boolean) - If true, output is colorized. Defaults to false.
+
+* `log_level` (string) - The verbosity of the outputs. Defaults to "debug".
+  Can be one of "all", "garbage", "trace", "debug", "info", or
+  "warning". Requires `verbose` to be set to "true".
+
+* `verbose` (boolean) - The verbosity of the outputs. Defaults to "false".
+  Must be true for log_level taking effect and the output of the salt-commands being displayed.
+
+## Pillar Data
+
+You can export pillar data for use during provisioning by using the ``pillar``
+command. Each call will merge the data so you can safely call it multiple
+times. The data passed in should only be hashes and lists. Here is an example::
+
+```ruby
+      config.vm.provision :salt do |salt|
+
+        # Export hostnames for webserver config
+        salt.pillar({
+          "hostnames" => {
+            "www" => "www.example.com",
+            "intranet" => "intranet.example.com"
+          }
+        })
+
+        # Export database credentials
+        salt.pillar({
+          "database" => {
+            "user" => "jdoe",
+            "password" => "topsecret"
+          }
+        })
+
+        salt.run_highstate = true
+
+      end
+```
+
+## Preseeding Keys
+
+Preseeding keys is the recommended way to handle provisioning
+using a master.
+On a machine with salt installed, run
+`salt-key --gen-keys=[minion_id]` to generate the necessary
+.pub and .pem files
+
+For a an example of a more advanced setup, look at the original
+[plugin](https://github.com/saltstack/salty-vagrant/tree/develop/example).