vagrant-aws-detiber 0.7.2.pre.2

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

@@ -0,0 +1,174 @@
+---
+layout: "docs"
+page_title: "CFEngine Provisioner"
+sidebar_current: "provisioning-cfengine"
+description: |-
+  The Vagrant CFEngine provisioner allows you to provision the guest using
+  CFEngine. It can set up both CFEngine policy servers and clients. You can
+  configure both the policy server and the clients in a single multi-machine
+  Vagrantfile.
+---
+
+# CFEngine Provisioner
+
+**Provisioner name: `cfengine`**
+
+The Vagrant CFEngine provisioner allows you to provision the guest using
+[CFEngine](https://cfengine.com/). It can set up both CFEngine
+policy servers and clients. You can configure both the policy server
+and the clients in a single
+[multi-machine `Vagrantfile`](/docs/multi-machine/).
+
+<div class="alert alert-warning">
+  <strong>Warning:</strong> If you are not familiar with CFEngine 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 CFEngine.
+</div>
+
+Let us look at some common examples first. See the bottom of this
+document for a comprehensive list of options.
+
+## Setting up a CFEngine server and client
+
+The CFEngine provisioner automatically installs the latest
+[CFEngine Community packages](https://cfengine.com/cfengine-linux-distros)
+on the VM, then configures and starts CFEngine according to your
+specification.
+
+Configuring a VM as a CFEngine policy server is easy:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "cfengine" do |cf|
+    cf.am_policy_hub = true
+  end
+end
+```
+
+The host will automatically be
+[bootstrapped](https://cfengine.com/docs/3.5/manuals-architecture-networking.html#bootstrapping)
+to itself to become a policy server.
+
+If you already have a working CFEngine policy server, you can get a
+CFEngine client installed and bootstrapped by specifying its IP
+address:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "cfengine" do |cf|
+    cf.policy_server_address = "10.0.2.15"
+  end
+end
+```
+
+## Copying files to the VM
+
+If you have some policy or other files that you want to install by
+default on a VM, you can use the `files_path` attribute:
+
+```ruby
+Vagrant.configure("2") do |config|
+   config.vm.provision "cfengine" do |cf|
+      cf.am_policy_hub = true
+      cf.files_path = "cfengine_files"
+    end
+  end
+```
+
+Everything under `cfengine_files/` in the Vagrant project directory
+will be recursively copied under `/var/cfengine/` in the VM, on top of
+its default contents.
+
+A common use case is to add your own files to
+`/var/cfengine/masterfiles/` in the policy server. Assuming your extra
+files are stored under `cfengine_files/masterfiles/`, the line shown
+above will add them to the VM after CFEngine is installed, but before
+it is bootstrapped.
+
+## Modes of operation
+
+The default mode of operation is `:bootstrap`, which results in
+CFEngine being bootstrapped according to the information provided in
+the `Vagrantfile`. You can also set `mode` to `:single_run`, which
+will run `cf-agent` once on the host to execute the file specified in
+the `run_file` parameter, but will not bootstrap it, so it will not be
+executed periodically.
+
+The recommended mode of operation is `:bootstrap`, as you get the full
+benefits of CFEngine when you have it running periodically.
+
+## Running a standalone file
+
+If you want to run a standalone file, you can specify the `run_file`
+parameter. The file will be copied to the VM and executed on its own
+using `cf-agent`. Note that the file needs to be a standalone policy,
+including its own
+[`body common control`](https://cfengine.com/docs/3.5/reference-components.html#common-control).
+
+The `run_file` parameter is mandatory if `mode` is set to
+`:single_run`, but can also be specified when `mode` is set to
+`:bootstrap` - in this case the file will be executed after the host
+has been bootstrapped.
+
+## Full Alphabetical List of Configuration Options
+
+- `am_policy_hub` (boolean, default `false`) determines whether the VM will be
+  configured as a CFEngine policy hub (automatically bootstrapped to
+  its own IP address). You can combine it with `policy_server_address`
+  if the VM has multiple network interfaces and you want to bootstrap
+  to a specific one.
+- `extra_agent_args` (string, default `nil`) can be used to pass
+  additional arguments to `cf-agent` when it is executed. For example,
+  you could use it to pass the `-I` or `-v` options to enable
+  additional output from the agent.
+- `classes` (array, default `nil`) can be used to define additional
+  classes during `cf-agent` runs. These classes will be defined using
+  the `-D` option to `cf-agent`.
+- `deb_repo_file` (string, default
+  `"/etc/apt/sources.list.d/cfengine-community.list"`) specifies the
+  file in which the CFEngine repository information will be stored in
+  Debian systems.
+- `deb_repo_line` (string, default `"deb https://cfengine.com/pub/apt
+  $(lsb_release -cs) main"`) specifies the repository to use for
+  `.deb` packages.
+- `files_path` (string, default `nil`) specifies a directory that will
+  be copied to the VM on top of the default
+  `/var/cfengine/` (the contents of `/var/cfengine/` will not
+  be replaced, the files will added to it).
+- `force_bootstrap` (boolean, default `false`) specifies whether
+  CFEngine will be bootstrapped again even if the host has already
+  been bootstrapped.
+- `install` (boolean or `:force`, default `true`) specifies whether
+  CFEngine will be installed on the VM if needed. If you set this
+  parameter to `:force`, then CFEngine will be reinstalled even if
+  it is already present on the machine.
+- `mode` (`:bootstrap` or `:single_run`, default `:bootstrap`)
+  specifies whether CFEngine will be bootstrapped so that it executes
+  periodically, or will be run a single time. If `mode` is set to
+  `:single_run` you have to set `run_file`.
+- `policy_server_address` (string, no default) specifies the IP
+  address of the policy server to which CFEngine will be
+  bootstrapped. If `am_policy_hub` is set to `true`, this parameter
+  defaults to the VM's IP address, but can still be set (for
+  example, if the VM has more than one network interface).
+- `repo_gpg_key_url` (string, default
+  `"https://cfengine.com/pub/gpg.key"`) contains the URL to obtain the
+  GPG key used to verify the packages obtained from the repository.
+- `run_file` (string, default `nil`) can be used to specify a file
+  inside the Vagrant project directory that will be copied to the VM
+  and executed once using `cf-agent`. This parameter is mandatory if
+  `mode` is set to `:single_run`, but can also be specified when
+  `mode` is set to `:bootstrap` - in this case the file will be
+  executed after the host has been bootstrapped.
+- `upload_path` (string, default `"/tmp/vagrant-cfengine-file"`)
+  specifies the file to which `run_file` (if specified) will be copied
+  on the VM before being executed.
+- `yum_repo_file` (string, default
+  `"/etc/yum.repos.d/cfengine-community.repo"`) specifies the file in
+  which the CFEngine repository information will be stored in RedHat
+  systems.
+- `yum_repo_url` (string, default `"https://cfengine.com/pub/yum/"`)
+  specifies the URL of the repository to use for `.rpm` packages.
+- `package_name` (string, default `"cfengine-community"`) specifies
+  the name of the package used to install CFEngine.

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

@@ -0,0 +1,104 @@
+---
+layout: "docs"
+page_title: "Chef Apply - Provisioning"
+sidebar_current: "provisioning-chefapply"
+description: |-
+  The Vagrant Chef Apply provisioner allows you to provision the guest using
+  Chef with chef-apply.
+---
+
+# Chef Apply Provisioner
+
+**Provisioner name: `chef_apply`**
+
+The Vagrant Chef Apply provisioner allows you to provision the guest using
+[Chef](https://www.getchef.com/), specifically with
+[Chef Apply](https://docs.getchef.com/ctl_chef_apply.html).
+
+Chef Apply is ideal for people who are already experienced with Chef and the
+Chef ecosystem. Specifically, this documentation page does not cover how use
+Chef or how to write Chef recipes.
+
+<div class="alert alert-warning">
+  <strong>Warning:</strong> If you are not familiar with Chef and Vagrant already,
+  we recommend starting with the <a href="/docs/provisioning/shell.html">shell
+  provisioner</a>.
+</div>
+
+## Options
+
+This section lists the complete set of available options for the Chef Apply
+provisioner. More detailed examples of how to use the provisioner are
+available below this section.
+
+* `recipe` (string) - The raw recipe contents to execute using Chef Apply on
+  the guest.
+
+* `log_level` (string) - The log level to use while executing `chef-apply`. The
+  default value is "info".
+
+* `upload_path` (string) - **Advanced!** The location on the guest where the
+  generated recipe file should be stored. For most use cases, it is unlikely you
+  will need to customize this value. The default value is
+  `/tmp/vagrant-chef-apply-#` where `#` is a unique counter generated by
+  Vagrant to prevent collisions.
+
+In addition to all the options listed above, the Chef Apply provisioner supports
+the [common options for all Chef provisioners](/docs/provisioning/chef_common.html).
+
+## Specifying a Recipe
+
+The easiest way to get started with the Chef Apply provisioner is to just
+specify an inline
+[Chef recipe](https://docs.chef.io/recipes.html). For
+example:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "chef_apply" do |chef|
+    chef.recipe = "package[apache2]"
+  end
+end
+```
+
+This causes Vagrant to run Chef Apply with the given recipe contents. If you are
+familiar with Chef, you know this will install the apache2 package from the
+system package provider.
+
+Since single-line Chef recipes are rare, you can also specify the recipe using a
+"heredoc":
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "chef_apply" do |chef|
+    chef.recipe = <<-RECIPE
+      package "apache2"
+
+      template "/etc/apache2/my.config" do
+        # ...
+      end
+    RECIPE
+  end
+end
+```
+
+Finally, if you would prefer to store the recipe as plain-text, you can set the
+recipe to the contents of a file:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "chef_apply" do |chef|
+    chef.recipe = File.read("/path/to/my/recipe.rb")
+  end
+end
+```
+
+## Roles
+
+The Vagrant Chef Apply provisioner does not support roles. Please use a
+different Vagrant Chef provisioner if you need support for roles.
+
+## Data Bags
+
+The Vagrant Chef Apply provisioner does not support data_bags. Please use a
+different Vagrant Chef provisioner if you need support for data_bags.

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

@@ -0,0 +1,123 @@
+---
+layout: "docs"
+page_title: "Chef Client - Provisioning"
+sidebar_current: "provisioning-chefclient"
+description: |-
+  The Vagrant Chef Client provisioner allows you to provision the guest using
+  Chef, specifically by connecting to an existing Chef Server and registering
+  the Vagrant machine as a node within your infrastructure.
+---
+
+# Chef Client Provisioner
+
+**Provisioner name: `chef_client`**
+
+The Vagrant Chef Client provisioner allows you to provision the guest using
+[Chef](https://www.chef.io/chef/), specifically by connecting
+to an existing Chef Server and registering the Vagrant machine as a
+node within your infrastructure.
+
+If you are just learning Chef for the first time, you probably want
+to start with the [Chef Solo](/docs/provisioning/chef_solo.html)
+provisioner.
+
+<div class="alert alert-warning">
+  <strong>Warning:</strong> If you are not familiar with Chef and Vagrant already,
+  I recommend starting with the <a href="/docs/provisioning/shell.html">shell
+  provisioner</a>.
+</div>
+
+## Authenticating
+
+The minimum required to use provision using Chef Client is to provide
+a URL to the Chef Server as well as the path to the validation key so
+that the node can register with the Chef Server:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "chef_client" do |chef|
+    chef.chef_server_url = "http://mychefserver.com"
+    chef.validation_key_path = "validation.pem"
+  end
+end
+```
+
+The node will register with the Chef Server specified, download the
+proper run list for that node, and provision.
+
+## Specifying a Run List
+
+Normally, the Chef Server is responsible for specifying the run list
+for the node. However, you can override what the Chef Server sends
+down by manually specifying a run list:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "chef_client" do |chef|
+    # Add a recipe
+    chef.add_recipe "apache"
+
+    # Or maybe a role
+    chef.add_role "web"
+  end
+end
+```
+
+Remember, this will _override_ the run list specified on the Chef
+server itself.
+
+## Environments
+
+You can specify the [environment](https://docs.chef.io/environments.html)
+for the node to come up in using the `environment` configuration option:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "chef_client" do |chef|
+    # ...
+
+    chef.environment = "development"
+  end
+end
+```
+
+## Other Configuration Options
+
+There are a few more configuration options available. These generally do not
+need to be modified but are available if your Chef Server requires customization
+of these variables.
+
+* `client_key_path`
+* `node_name`
+* `validation_client_name`
+
+In addition to all the options listed above, the Chef Client provisioner supports
+the [common options for all Chef provisioners](/docs/provisioning/chef_common.html).
+
+## Cleanup
+
+When you provision your Vagrant virtual machine with Chef Server, it creates a
+new Chef "node" entry and Chef "client" entry on the Chef Server, using the
+hostname of the machine. After you tear down your guest machine, Vagrant can be
+configured to do it automatically with the following settings:
+
+```ruby
+chef.delete_node = true
+chef.delete_client = true
+```
+
+If you do not specify it or set it to `false`, you must explicitly delete these
+entries from the Chef Server before you provision a new one with Chef Server.
+For example, using Chef's built-in `knife` tool:
+
+```
+$ knife node delete precise64
+$ knife client delete precise64
+```
+
+If you fail to do so, you will get the following error when Vagrant
+tries to provision the machine with Chef Client:
+
+```
+HTTP Request Returned 409 Conflict: Client already exists.
+```

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

@@ -0,0 +1,136 @@
+---
+layout: "docs"
+page_title: "Common Chef Options - Provisioning"
+sidebar_current: "provisioning-chefcommon"
+description: |-
+  The following options are available to all Vagrant Chef provisioners. Many of
+  these options are for advanced users only and should not be used unless you
+  understand their purpose.
+---
+
+# Shared Chef Options
+
+## All Chef Provisioners
+
+The following options are available to all Vagrant Chef provisioners. Many of
+these options are for advanced users only and should not be used unless you
+understand their purpose.
+
+- `binary_path` (string) - The path to Chef's `bin/` directory on the guest
+  machine.
+
+- `binary_env` (string) - Arbitrary environment variables to set before running
+  the Chef provisioner command. This should be of the format `KEY=value` as a
+  string.
+
+- `install` (boolean, string) - Install Chef on the system if it does not exist.
+  The default value is "true", which will use the official Omnibus installer
+  from Chef. This is a trinary attribute (it can have three values):
+
+    - `true` (boolean) - install Chef
+    - `false` (boolean) - do not install Chef
+    - `"force"` (string) - install Chef, even if it is already installed at the
+      proper version on the guest
+
+- `installer_download_path` (string) - The path where the Chef installer will be
+  downloaded to. This option is only honored if the `install` attribute is
+  `true` or `"force"`. The default value is to use the path provided by Chef's
+  Omnibus installer, which varies between releases. This value has no effect on
+  Windows because Chef's omnibus installer lacks the option on Windows.
+
+- `log_level` (string) - The Chef log level. See the Chef docs for acceptable
+  values.
+
+- `product` (string) - The name of the Chef product to install. The default
+  value is "chef", which corresponds to the Chef Client. You can also specify
+  "chefdk", which will install the Chef Development Kit. At the time of this
+  writing, the ChefDK is only available through the "current" channel, so you
+  will need to update that value as well.
+
+- `channel` (string) - The release channel from which to pull the Chef Client
+  or the Chef Development Kit. The default value is `"stable"` which will pull
+  the latest stable version of the Chef Client. For newer versions, or if you
+  wish to install the Chef Development Kit, you may need to change the channel
+  to "current". Because Chef Software floats the versions that are contained in
+  the channel, they may change and Vagrant is unable to detect this.
+
+- `version` (string) - The version of Chef to install on the guest. If Chef is
+  already installed on the system, the installed version is compared with the
+  requested version. If they match, no action is taken. If they do not match,
+  the value specified in this attribute will be installed in favor of the
+  existing version (a message will be displayed).
+  You can also specify "latest" (default), which will install the latest
+  version of Chef on the system. In this case, Chef will use whatever
+  version is on the system. To force the newest version of Chef to be
+  installed on every provision, set the [`install`](#install) option to "force".
+
+- `omnibus_url` (string) - Location of Omnibus installation scripts.
+  This URL specifies the location of install.sh/install.ps1 for
+  Linux/Unix and Windows respectively.
+  It defaults to https://omnitruck.chef.io. The full URL is in this case:
+
+   - Linux/Unix: https://omnitruck.chef.io/install.sh
+   - Windows: https://omnitruck.chef.io/install.ps1
+
+  If you want to have https://example.com/install.sh as Omnibus script
+  for your Linux/Unix installations, you should set this option to
+  https://example.com
+
+## Runner Chef Provisioners
+
+The following options are available to any of the Chef "runner" provisioners
+which include [Chef Solo](/docs/provisioning/chef_solo.html), [Chef Zero](/docs/provisioning/chef_zero.html), and [Chef Client](/docs/provisioning/chef_client.html).
+
+* `arguments` (string) - A list of additional arguments to pass on the
+  command-line to Chef. Since these are passed in a shell-like environment,
+  be sure to properly quote and escape characters if necessary. By default,
+  no additional arguments are sent.
+
+* `attempts` (int) - The number of times Chef will be run if an error occurs.
+  This defaults to 1. This can be increased to a higher number if your Chef
+  runs take multiple runs to reach convergence.
+
+* `custom_config_path` (string) - A path to a custom Chef configuration local
+  on your machine that will be used as the Chef configuration. This Chef
+  configuration will be loaded _after_ the Chef configuration that Vagrant
+  generates, allowing you to override anything that Vagrant does. This is
+  also a great way to use new Chef features that may not be supported fully
+  by Vagrant's abstractions yet.
+
+* `encrypted_data_bag_secret_key_path` (string) - The path to the secret key
+  file to decrypt encrypted data bags. By default, this is not set.
+
+* `environment` (string) - The environment you want the Chef run to be
+  a part of.
+
+* `formatter` (string) - The formatter to use for output from Chef.
+
+* `http_proxy`, `http_proxy_user`, `http_proxy_pass`, `no_proxy` (string) - Settings
+  to configure HTTP and HTTPS proxies to use from Chef. These settings are
+  also available with `http` replaced with `https` to configure HTTPS proxies.
+
+* `json` (hash) - Custom node attributes to pass into the Chef run.
+
+* `log_level` (string) - The log level for Chef output. This defaults to
+  "info".
+
+* `node_name` (string) - The node name for the Chef Client. By default this
+  will be your hostname.
+
+* `provisioning_path` (string) - The path on the remote machine where Vagrant
+  will store all necessary files for provisioning such as cookbooks, configurations,
+  etc. This path must be world writable. By default this is
+  `/tmp/vagrant-chef-#` where "#" is replaced by a unique counter.
+
+* `run_list` (array) - The run list that will be executed on the node.
+
+* `file_cache_path` and `file_backup_path` (string) - Paths on the remote
+  machine where files will be cached and backed up. It is useful sometimes
+  to configure this to a synced folder address so that this can be shared
+  across many Vagrant runs.
+
+* `verbose_logging` (boolean) - Whether or not to enable the Chef
+  `verbose_logging` option. By default this is false.
+
+* `enable_reporting` (boolean) - Whether or not to enable the Chef
+  `enable_reporting` option. By default this is true.