RubyGems - vagrant-packet - Versions diffs - 0.1.2 → 0.1.3 - Mend

vagrant-packet 0.1.2 → 0.1.3

Files changed (4567) hide show

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/provisioning/puppet_apply.html.md DELETED Viewed

@@ -1,238 +0,0 @@
----
-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-04f7215b5e3f/website/source/docs/provisioning/salt.html.md DELETED Viewed

@@ -1,195 +0,0 @@
----
-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.
-* `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
-```
-## 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).

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/provisioning/shell.html.md DELETED Viewed

@@ -1,199 +0,0 @@
----
-layout: "docs"
-page_title: "Shell Scripts - Provisioning"
-sidebar_current: "provisioning-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.
-* `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.
-* `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".
-* `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.
-* `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".
-* `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.
-* `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.
-* `md5` (string) - MD5 checksum used to validate remotely downloaded shell files.
-* `sha1` (string) - SHA1 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".
-<a name="inline-scripts"></a>
-## 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
-```
-I understand 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 inline script _must_ be PowerShell. Batch
-scripts are not allowed as inline scripts.
-## 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. If you
-exclude this extension, it likely will not work.
-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
-```

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/push/ftp.html.md DELETED Viewed

@@ -1,64 +0,0 @@
----
-layout: "docs"
-page_title: "Vagrant Push - FTP & SFTP Strategy"
-sidebar_current: "push-ftp"
-description: |-
-  Vagrant Push FTP and SFTP strategy pushes the code in your Vagrant development
-  environment to a remote FTP or SFTP server.
----
-# Vagrant Push
-## FTP & SFTP Strategy
-Vagrant Push FTP and SFTP strategy pushes the code in your Vagrant development
-environment to a remote FTP or SFTP server.
-The Vagrant Push FTP And SFTP strategy supports the following configuration
-options:
-- `host` - The address of the remote (S)FTP server. If the (S)FTP server is
-  running on a non-standard port, you can specify the port after the address
-  (`host:port`).
-- `username` - The username to use for authentication with the (S)FTP server.
-- `password` - The password to use for authentication with the (S)FTP server.
-- `passive` - Use passive FTP (default is true).
-- `secure` - Use secure (SFTP) (default is false).
-- `destination` - The root destination on the target system to sync the files
-  (default is `/`).
-- `exclude` - Add a file or file pattern to exclude from the upload, relative to
-  the `dir`. This value may be specified multiple times and is additive.
-  `exclude` take precedence over `include` values.
-- `include` - Add a file or file pattern to include in the upload, relative to
-  the `dir`. This value may be specified multiple times and is additive.
-- `dir` - The base directory containing the files to upload. By default this is
-  the same directory as the Vagrantfile, but you can specify this if you have
-  a `src` folder or `bin` folder or some other folder you want to upload.
-### Usage
-The Vagrant Push FTP and SFTP strategy is defined in the `Vagrantfile` using the
-`ftp` key:
-```ruby
-config.push.define "ftp" do |push|
-  push.host = "ftp.company.com"
-  push.username = "username"
-  push.password = "password"
-end
-```
-And then push the application to the FTP or SFTP server:
-```shell
-$ vagrant push
-```