vagrant-aws-mkubenka 0.7.2.pre.22 → 0.7.2.pre.24

data/vendor/bundle/ruby/2.7.0/bundler/gems/vagrant-22795b161bf6/website/pages/docs/provisioning/puppet_apply.mdx

@@ -0,0 +1,236 @@
+---
+layout: docs
+page_title: Puppet Apply - Provisioning
+sidebar_title: Puppet Apply
+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.
+
+~> **Warning:** If you are not familiar with Puppet and Vagrant already,
+it is recommended to start with the [shell provisioner](/docs/provisioning/shell).
+However, if you are comfortable with Vagrant already, Vagrant
+is the best way to learn Puppet.
+
+## 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 or array of strings) - Path or paths, 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.
+
+```shell-session
+$ 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.7.0/bundler/gems/vagrant-22795b161bf6/website/pages/docs/provisioning/salt.mdx

@@ -0,0 +1,203 @@
+---
+layout: docs
+page_title: Salt - Provisioning
+sidebar_title: 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 = "bionic64"
+
+  ## 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
+
+The Salt provisioner uses the [Salt bootstrap script](https://github.com/saltstack/salt-bootstrap)
+for installing Salt on your guest. These options build up the arguments used to
+for the bootstrap script.
+
+- `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) - Version of minion to be installed. Defaults to latest version. When specifying `version` you must also specify a `install_type`.
+
+- `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.
+
+- `minion_json_config` (string) - Valid json for configuring the salt minion
+  (`-j` in bootstrap-salt.sh). Not supported on Windows.
+
+- `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}`
+
+- `master_json_config` (string) - Valid json for configuring the salt master
+  (`-J` in bootstrap-salt.sh). Not supported on Windows.
+
+- `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
+```
+
+On Windows guests, this requires PowerShell 3.0 or higher.
+
+## 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 an example of a more advanced setup, look at the original
+[plugin](https://github.com/saltstack/salty-vagrant/tree/develop/example).

data/vendor/bundle/ruby/2.7.0/bundler/gems/vagrant-22795b161bf6/website/pages/docs/provisioning/shell.mdx

@@ -0,0 +1,248 @@
+---
+layout: docs
+page_title: Shell Scripts - Provisioning
+sidebar_title: Shell
+description: |-
+  The Vagrant Shell provisioner allows you to upload and execute a script within
+  the guest machine.
+---
+
+# Shell Provisioner
+
+**Provisioner name: `"shell"`**
+
+The Vagrant Shell provisioner allows you to upload and execute a script within
+the guest machine.
+
+Shell provisioning is ideal for users new to Vagrant who want to get up
+and running quickly and provides a strong alternative for users who are not
+comfortable with a full configuration management system such as Chef or
+Puppet.
+
+For POSIX-like machines, the shell provisioner executes scripts with
+SSH. For Windows guest machines that are configured to use WinRM, the
+shell provisioner executes PowerShell and Batch scripts over WinRM.
+
+## Options
+
+The shell provisioner takes various options. One of `inline` or `path`
+is required:
+
+- `inline` (string) - Specifies a shell command inline to execute on the
+  remote machine. See the [inline scripts](#inline-scripts) section below
+  for more information.
+
+- `path` (string) - Path to a shell script to upload and execute. It can be a
+  script relative to the project Vagrantfile or a remote script (like a [gist](https://gist.github.com)).
+
+The remainder of the available options are optional:
+
+- `args` (string or array) - Arguments to pass to the shell script when executing it
+  as a single string. These arguments must be written as if they were typed
+  directly on the command line, so be sure to escape characters, quote,
+  etc. as needed. You may also pass the arguments in using an array. In this
+  case, Vagrant will handle quoting for you.
+
+- `binary` (boolean) - Vagrant automatically replaces Windows line endings with
+  Unix line endings. If this is false, then Vagrant will not do this. By default
+  this is "false". If the shell provisioner is communicating over WinRM, this
+  defaults to "true".
+
+- `env` (hash) - List of key-value pairs to pass in as environment variables to
+  the script. Vagrant will handle quoting for environment variable values, but
+  the keys remain untouched.
+
+- `keep_color` (boolean) - Vagrant automatically colors output in green and
+  red depending on whether the output is from stdout or stderr. If this is
+  true, Vagrant will not do this, allowing the native colors from the script
+  to be outputted.
+
+- `md5` (string) - MD5 checksum used to validate remotely downloaded shell files.
+
+- `name` (string) - This value will be displayed in the output so that
+  identification by the user is easier when many shell provisioners are present.
+
+- `powershell_args` (string) - Extra arguments to pass to `PowerShell`
+  if you are provisioning with PowerShell on Windows.
+
+- `powershell_elevated_interactive` (boolean) - Run an elevated script in interactive mode
+  on Windows. By default this is "false". Must also be `privileged`. Be sure to
+  enable auto-login for Windows as the user must be logged in for interactive
+  mode to work.
+
+- `privileged` (boolean) - Specifies whether to execute the shell script
+  as a privileged user or not (`sudo`). By default this is "true". Windows
+  guests use a scheduled task to run as a true administrator without the
+  WinRM limitations.
+
+- `reboot` (boolean) - Reboot the guest. This requires the guest to have a
+  reboot capability implemented.
+
+- `reset` (boolean) - Reset the communicator to the machine after completion. This
+  is useful when a shell may need to be reloaded.
+
+- `sha1` (string) - SHA1 checksum used to validate remotely downloaded shell files.
+
+- `sha256` (string) - SHA256 checksum used to validate remotely downloaded shell files.
+
+- `sha384` (string) - SHA384 checksum used to validate remotely downloaded shell files.
+
+- `sha512` (string) - SHA512 checksum used to validate remotely downloaded shell files.
+
+- `sensitive` (boolean) - Marks the Hash values used in the `env` option as sensitive
+  and hides them from output. By default this is "false".
+
+- `upload_path` (string) - Is the remote path where the shell script will
+  be uploaded to. The script is uploaded as the SSH user over SCP, so this
+  location must be writable to that user. By default this is
+  "/tmp/vagrant-shell". On Windows, this will default to
+  "C:\tmp\vagrant-shell".
+
+## Inline Scripts
+
+Perhaps the easiest way to get started is with an inline script. An
+inline script is a script that is given to Vagrant directly within
+the Vagrantfile. An example is best:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "shell",
+    inline: "echo Hello, World"
+end
+```
+
+This causes `echo Hello, World` to be run within the guest machine when
+provisioners are run.
+
+Combined with a little bit more Ruby, this makes it very easy to embed
+your shell scripts directly within your Vagrantfile. Another example below:
+
+```ruby
+$script = <<-SCRIPT
+echo I am provisioning...
+date > /etc/vagrant_provisioned_at
+SCRIPT
+
+Vagrant.configure("2") do |config|
+  config.vm.provision "shell", inline: $script
+end
+```
+
+In the code block above, the script block starts with `<<-SCRIPT` and ends with `SCRIPT`.
+This is known as a "Here Document" or a "heredoc". Additionally, if your script
+relies on quotes and you do not wish for Ruby to escape your quotes, you may
+want to use this style of heredoc where `SCRIPT` is surrounded in single quotes:
+
+```ruby
+$script = <<-'SCRIPT'
+echo "These are my \"quotes\"! I am provisioning my guest."
+date > /etc/vagrant_provisioned_at
+SCRIPT
+
+Vagrant.configure("2") do |config|
+  config.vm.provision "shell", inline: $script
+end
+```
+
+Now that our "heredoc" is quoted, our script will preserve the quotes in the string to `echo`:
+
+```
+==> default: Running provisioner: shell...
+    default: Running: inline script
+    default: These are my "quotes"! I am provisioning my guest.
+```
+
+For more examples of how to use "heredoc" in Ruby, please refer to the
+[Ruby documentation](https://ruby-doc.org/core-2.5.0/doc/syntax/literals_rdoc.html#label-Here+Documents).
+
+It is understandable that if you are not familiar with Ruby, the above may seem very
+advanced or foreign. But do not fear, what it is doing is quite simple:
+the script is assigned to a global variable `$script`. This global variable
+contains a string which is then passed in as the inline script to the
+Vagrant configuration.
+
+Of course, if any Ruby in your Vagrantfile outside of basic variable assignment
+makes you uncomfortable, you can use an actual script file, documented in
+the next section.
+
+For Windows guest machines, the supported inline script is dependent upon the
+communicator in use. When using the `winrm` communicator, the inline script
+_must_ be PowerShell. Batch scripts are not allowed as inline scripts when
+using the `winrm` communicator. When using the `winssh` communicator, the
+inline script will be run using the configured `shell` which defaults to
+PowerShell.
+
+## External Script
+
+The shell provisioner can also take an option specifying a path to
+a shell script on the host machine. Vagrant will then upload this script
+into the guest and execute it. An example:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "shell", path: "script.sh"
+end
+```
+
+Relative paths, such as above, are expanded relative to the location
+of the root Vagrantfile for your project. Absolute paths can also be used,
+as well as shortcuts such as `~` (home directory) and `..` (parent directory).
+
+If you use a remote script as part of your provisioning process, you can pass in
+its URL as the `path` argument as well:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "shell", path: "https://example.com/provisioner.sh"
+end
+```
+
+If you are running a Batch or PowerShell script for Windows, make sure
+that the external path has the proper extension (".bat" or ".ps1"), because
+Windows uses this to determine what kind of file it is to execute. Additionally,
+if you are running Vagrant on something like Cygwin or WSL where bash is
+available, then you should be able to use an extension like ".sh".
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "shell", path: "scripts/PowershellScript.ps1"
+end
+```
+
+To run a script already available on the guest you can use an inline script to
+invoke the remote script on the guest.
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "shell",
+    inline: "/bin/sh /path/to/the/script/already/on/the/guest.sh"
+end
+```
+
+## Script Arguments
+
+You can parameterize your scripts as well like any normal shell script.
+These arguments can be specified to the shell provisioner. They should
+be specified as a string as they'd be typed on the command line, so
+be sure to properly escape anything:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "shell" do |s|
+    s.inline = "echo $1"
+    s.args   = "'hello, world!'"
+  end
+end
+```
+
+You can also specify arguments as an array if you do not want to worry about
+quoting:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "shell" do |s|
+    s.inline = "echo $1"
+    s.args   = ["hello, world!"]
+  end
+end
+```