vagrant-packet 0.1.2 → 0.1.3

data/vendor/bundle/ruby/2.4.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/vagrant-cloud/users/recovery.html.md

@@ -1,13 +0,0 @@
----
-layout: "vagrant-cloud"
-page_title: "Account Recovery"
-sidebar_current: "vagrant-cloud-users-recovery"
----
-
-# Account Recovery
-
-If you have lost access to your Vagrant Cloud account, use the reset
-password form on the login page to send yourself a link to reset your password.
-
-If an email is unknown, [contact us](mailto:support+vagrantcloud@hashicorp.com)
-for further help.

data/vendor/bundle/ruby/2.4.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/vagrant-cloud/vagrant-cloud-migration.html.md

@@ -1,122 +0,0 @@
----
-layout: "vagrant-cloud"
-page_title: "Vagrant Cloud Migration"
-sidebar_current: "vagrant-cloud-migration"
----
-
-# Vagrant Cloud Migration
-
-Vagrant-related functionality will be moved from Terraform Enterprise into its own product, Vagrant Cloud.
-This migration is currently planned for **June 27th, 2017** at 6PM EDT/3PM PDT/10PM UTC.
-
-All existing Vagrant boxes will be moved to the new system at that time.
-All users, organizations, and teams will be copied as well.
-
-~> If you only use Vagrant to download and run public boxes, then nothing is changing.
-~> All box names, versions, and URLs will stay the same (or redirect) with no changes to your workflow or Vagrantfiles.
-
-## Vagrant Boxes, Users, Organizations, and Teams
-
-All Vagrant boxes will be moved to the new Vagrant Cloud on June 27th.
-Additionally, all users and organizations will be copied.
-Any existing box collaborations or team ACLs will persist into the new system.
-
-All existing box names (hashicorp/precise64) and URLs will continue working as-is, or permanently redirect to the correct location.
-If you’re only using public Vagrant boxes, no changes will be required to your Vagrantfiles or workflow.
-Users of private Vagrant boxes will need to create a new authentication (see below), and activate their Vagrant Cloud account after the migration has completed.
-
-Vagrant Cloud users and organizations will be considered inactive in the future if they have not logged into Vagrant Cloud after the migration and do not have any published Vagrant boxes.
-Inactive user accounts will be deleted on or after October 1st, 2017.
-
-## Vagrant Cloud Account Activation
-
-In order to begin using Vagrant Cloud with your Atlas account, you will first need to activate your Vagrant Cloud account.
-This will require you to login to Atlas, as well as confirm your password (and 2FA credentials, if configured).
-There will be links and instructions on the Vagrant Cloud login screen directing you to do this.
-
-During Vagrant Cloud account activation, you will create a new password for Vagrant Cloud and optionally configure 2FA.
-Your pre-existing Atlas account, password, and 2FA configuration will remain unchanged within Atlas.
-
-~> New users of Vagrant Cloud can always create a new account for free, at any time.
-
-## Authentication Tokens
-
-If you are currently using an authentication token to interact with Atlas for Vagrant features, you will need to generate a new Vagrant Cloud token prior to June 27th.
-You can see your existing tokens and generate new tokens on the Tokens page of your account settings.
-
-When creating this new token, select Migrate to Vagrant Cloud.
-
-You can see which authentication tokens which will be copied to Vagrant Cloud in the token list.
-
-Only these authentication tokens will be moved to Vagrant Cloud on June 27th.
-They will also be removed from Terraform Enterprise at this time, and will no longer work for Terraform or Packer operations.
-If you do not create a token in Atlas by June 27th, you will need to create a token within Vagrant Cloud after the migration.
-
-~> Creating a token in Atlas via `vagrant login` will also mark a token as "Migrate to Vagrant Cloud".
-
-## Packer and Terraform Enterprise
-
-Packer has two post-processors which can create Vagrant boxes in Terraform Enterprise (Atlas): `atlas` and `vagrant-cloud`.
-The `atlas post-processor` will no longer create Vagrant boxes after June 27th.
-If you are currently publishing Vagrant boxes with Packer, please ensure that you are using the vagrant-cloud post-processor.
-
-For example, if your Packer post-processor JSON looks like this:
-
-```json
-{
-  "variables": {
-    "atlas_token": "{{env `ATLAS_TOKEN`}}",
-    "version": "1.0.{{timestamp}}"
-  },
-  "builders": [
-  ],
-  "post-processors": [
-    {
-      "type": "atlas",
-      "token": "{{user `atlas_token`}}",
-      "artifact": "hashicorp/example",
-      "artifact_type": "vagrant.box",
-      "metadata": {
-        "version": "{{user `version`}}"
-      }
-    }
-  ]
-}
-```
-
-You must replace the `atlas` post-processor with the `vagrant` and `vagrant-cloud` post-processors (note the nested array, which tells Packer to run these steps serially).
-
-```json
-{
-  "variables": {
-    "vagrantcloud_token": "{{env `VAGRANTCLOUD_TOKEN`}}",
-    "version": "1.0.{{timestamp}}"
-  },
-  "builders": [
-  ],
-  "post-processors": [
-    [
-      {
-        "type": "vagrant",
-        "output": "output.box"
-      },
-      {
-        "type": "vagrant-cloud",
-        "access_token": "{{user `vagrantcloud_token`}}",
-        "box_tag": "hashicorp/example",
-        "version": "{{user `version`}}"
-      }
-    ]
-  ]
-}
-```
-
-## Vagrant Share
-
-Vagrant Share via Atlas has been deprecated, and instead Vagrant supports native integration with [ngrok](https://ngrok.com).
-Users of Vagrant Share should switch to the [ngrok-powered Vagrant Share driver](https://www.vagrantup.com/docs/share) prior to June 27th, which will become the default in the next version of Vagrant
-
-## Downtime
-
-There will be a brief outage of Vagrant services within Atlas/Terraform Enterprise on June 27th at 6PM EDT/3PM PDT until the migration is complete.
-We estimate that this will take less than 30 minutes.

data/vendor/bundle/ruby/2.4.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/vagrantfile/index.html.md

@@ -1,86 +0,0 @@
----
-layout: "docs"
-page_title: "Vagrantfile"
-sidebar_current: "vagrantfile"
-description: |-
-  The primary function of the Vagrantfile is to describe the type
-  of machine required for a project, and how to configure and
-  provision these machines. Vagrantfiles are called Vagrantfiles because
-  the actual literal filename for the file is "Vagrantfile".
----
-
-# Vagrantfile
-
-The primary function of the Vagrantfile is to describe the type
-of machine required for a project, and how to configure and
-provision these machines. Vagrantfiles are called Vagrantfiles because
-the actual literal filename for the file is `Vagrantfile` (casing does not
-matter unless your file system is running in a strict case sensitive mode).
-
-Vagrant is meant to run with one Vagrantfile per project, and the Vagrantfile
-is supposed to be committed to version control. This allows other developers
-involved in the project to check out the code, run `vagrant up`, and be on
-their way. Vagrantfiles are portable across every platform Vagrant supports.
-
-The syntax of Vagrantfiles is [Ruby](http://www.ruby-lang.org), but knowledge
-of the Ruby programming language is not necessary to make modifications to the
-Vagrantfile, since it is mostly simple variable assignment. In fact, Ruby is not
-even the most popular community Vagrant is used within, which should help show
-you that despite not having Ruby knowledge, people are very successful with
-Vagrant.
-
-## Lookup Path
-
-When you run any `vagrant` command, Vagrant climbs up the directory tree
-looking for the first Vagrantfile it can find, starting first in the
-current directory. So if you run `vagrant` in `/home/mitchellh/projects/foo`,
-it will search the following paths in order for a Vagrantfile, until it
-finds one:
-
-```
-/home/mitchellh/projects/foo/Vagrantfile
-/home/mitchellh/projects/Vagrantfile
-/home/mitchellh/Vagrantfile
-/home/Vagrantfile
-/Vagrantfile
-```
-
-This feature lets you run `vagrant` from any directory in your project.
-
-You can change the starting directory where Vagrant looks for a Vagrantfile
-by setting the `VAGRANT_CWD` environmental variable to some other path.
-
-<a name="load-order"></a>
-## Load Order and Merging
-
-An important concept to understand is how Vagrant loads Vagrantfiles. Vagrant
-actually loads a series of Vagrantfiles, merging the settings as it goes. This
-allows Vagrantfiles of varying level of specificity to override prior settings.
-Vagrantfiles are loaded in the order shown below. Note that if a Vagrantfile
-is not found at any step, Vagrant continues with the next step.
-
-1. Vagrantfile packaged with the [box](/docs/boxes.html) that is to be used
-  for a given machine.
-2. Vagrantfile in your Vagrant home directory (defaults to `~/.vagrant.d`).
-  This lets you specify some defaults for your system user.
-3. Vagrantfile from the project directory. This is the Vagrantfile that you will
-  be modifying most of the time.
-4. [Multi-machine overrides](/docs/multi-machine/) if any.
-5. [Provider-specific overrides](/docs/providers/configuration.html),
-   if any.
-
-At each level, settings set will be merged with previous values. What this
-exactly means depends on the setting. For most settings, this means that
-the newer setting overrides the older one. However, for things such as defining
-networks, the networks are actually appended to each other. By default, you
-should assume that settings will override each other. If the behavior is
-different, it will be noted in the relevant documentation section.
-
-Within each Vagrantfile, you may specify multiple `Vagrant.configure` blocks.
-All configurations will be merged within a single Vagrantfile in the order
-they're defined.
-
-## Available Configuration Options
-
-You can learn more about the available configuration options by clicking
-the relevant section in the left navigational area.

data/vendor/bundle/ruby/2.4.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/vagrantfile/machine_settings.html.md

@@ -1,178 +0,0 @@
----
-layout: "docs"
-page_title: "config.vm - Vagrantfile"
-sidebar_current: "vagrantfile-machine"
-description: |-
-  The settings within "config.vm" modify the configuration of the
-  machine that Vagrant manages.
----
-
-# Machine Settings
-
-**Config namespace: `config.vm`**
-
-The settings within `config.vm` modify the configuration of the
-machine that Vagrant manages.
-
-## Available Settings
-
-`config.vm.boot_timeout` - The time in seconds that Vagrant will wait
-for the machine to boot and be accessible. By default this is 300 seconds.
-
-<hr>
-
-`config.vm.box` - This configures what [box](/docs/boxes.html) the
-machine will be brought up against. The value here should be the name
-of an installed box or a shorthand name of a box in
-[HashiCorp's Vagrant Cloud](/docs/vagrant-cloud).
-
-This option requires Vagrant 1.5 or higher. You can download the latest version
-of Vagrant from the [Vagrant installers page](/downloads.html).
-
-<hr>
-
-`config.vm.box_check_update` - If true, Vagrant will check for updates to
-the configured box on every `vagrant up`. If an update is found, Vagrant
-will tell the user. By default this is true. Updates will only be checked
-for boxes that properly support updates (boxes from
-[HashiCorp's Vagrant Cloud](/docs/vagrant-cloud)
-or some other versioned box).
-
-<hr>
-
-`config.vm.box_download_checksum` - The checksum of the box specified by
-`config.vm.box_url`. If not specified, no checksum comparison will be done.
-If specified, Vagrant will compare the checksum of the downloaded box to
-this value and error if they do not match. Checksum checking is only done
-when Vagrant must download the box.
-
-If this is specified, then `config.vm.box_download_checksum_type` must
-also be specified.
-
-<hr>
-
-`config.vm.box_download_checksum_type` - The type of checksum specified
-by `config.vm.box_download_checksum` (if any). Supported values are
-currently "md5", "sha1", and "sha256".
-
-<hr>
-
-`config.vm.box_download_client_cert` - Path to a client certificate to
-use when downloading the box, if it is necessary. By default, no client
-certificate is used to download the box.
-
-<hr>
-
-`config.vm.box_download_ca_cert` - Path to a CA cert bundle to use when
-downloading a box directly. By default, Vagrant will use the Mozilla CA cert
-bundle.
-
-<hr>
-
-`config.vm.box_download_ca_path` - Path to a directory containing
-CA certificates for downloading a box directly. By default, Vagrant will
-use the Mozilla CA cert bundle.
-
-<hr>
-
-`config.vm.box_download_insecure` - If true, then SSL certificates
-from the server will not be verified. By default, if the URL is an HTTPS
-URL, then SSL certs will be verified.
-
-<hr>
-
-`config.vm.box_download_location_trusted` - If true, then all HTTP redirects will be
-treated as trusted. That means credentials used for initial URL will be used for
-all subsequent redirects. By default, redirect locations are untrusted so credentials
-(if specified) used only for initial HTTP request.
-
-<hr>
-
-`config.vm.box_url` - The URL that the configured box can be found at.
-If `config.vm.box` is a shorthand to a box in [HashiCorp's Vagrant Cloud](/docs/vagrant-cloud)
-then this value does not need to be specified. Otherwise, it should
-point to the proper place where the box can be found if it is not
-installed.
-
-This can also be an array of multiple URLs. The URLs will be tried in
-order. Note that any client certificates, insecure download settings, and
-so on will apply to all URLs in this list.
-
-The URLs can also be local files by using the `file://` scheme. For
-example: "file:///tmp/test.box".
-
-<hr>
-
-`config.vm.box_version` - The version of the box to use. This defaults to
-">= 0" (the latest version available). This can contain an arbitrary list
-of constraints, separated by commas, such as: `>= 1.0, < 1.5`. When constraints
-are given, Vagrant will use the latest available box satisfying these
-constraints.
-
-<hr>
-
-`config.vm.communicator` - The communicator type to use to connect to the
-guest box. By default this is `"ssh"`, but should be changed to `"winrm"` for
-Windows guests.
-
-<hr>
-
-`config.vm.graceful_halt_timeout` - The time in seconds that Vagrant will
-wait for the machine to gracefully halt when `vagrant halt` is called.
-Defaults to 60 seconds.
-
-<hr>
-
-`config.vm.guest` - The guest OS that will be running within this
-machine. This defaults to `:linux`, and Vagrant will auto-detect the
-proper distro. Vagrant needs to know this information to perform some
-guest OS-specific things such as mounting folders and configuring
-networks.
-
-<hr>
-
-`config.vm.hostname` - The hostname the machine should have. Defaults
-to nil. If nil, Vagrant will not manage the hostname. If set to a string,
-the hostname will be set on boot.
-
-<hr>
-
-`config.vm.network` - Configures [networks](/docs/networking/) on
-the machine. Please see the networking page for more information.
-
-<hr>
-
-`config.vm.post_up_message` - A message to show after `vagrant up`. This
-will be shown to the user and is useful for containing instructions
-such as how to access various components of the development environment.
-
-<hr>
-
-`config.vm.provider` - Configures [provider-specific configuration](/docs/providers/configuration.html),
-which is used to modify settings which are specific to a certain
-[provider](/docs/providers/). If the provider you are configuring
-does not exist or is not setup on the system of the person who runs
-`vagrant up`, Vagrant will ignore this configuration block. This allows
-a Vagrantfile that is configured for many providers to be shared among
-a group of people who may not have all the same providers installed.
-
-<hr>
-
-`config.vm.provision` - Configures [provisioners](/docs/provisioning/)
-on the machine, so that software can be automatically installed and configured
-when the machine is created. Please see the page on provisioners for more
-information on how this setting works.
-
-<hr>
-
-`config.vm.synced_folder` - Configures [synced folders](/docs/synced-folders/)
-on the machine, so that folders on your host machine can be synced to
-and from the guest machine. Please see the page on synced folders for
-more information on how this setting works.
-
-<hr>
-
-`config.vm.usable_port_range` - A range of ports Vagrant can use for
-handling port collisions and such. Defaults to `2200..2250`.
-
-<hr>

data/vendor/bundle/ruby/2.4.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/vagrantfile/ssh_settings.html.md

@@ -1,183 +0,0 @@
----
-layout: "docs"
-page_title: "config.ssh - Vagrantfile"
-sidebar_current: "vagrantfile-ssh"
-description: |-
-  The settings within "config.ssh" relate to configuring how Vagrant
-  will access your machine over SSH. As with most Vagrant settings, the
-  defaults are typically fine, but you can fine tune whatever you would like.
----
-
-# SSH Settings
-
-**Config namespace: `config.ssh`**
-
-The settings within `config.ssh` relate to configuring how Vagrant
-will access your machine over SSH. As with most Vagrant settings, the
-defaults are typically fine, but you can fine tune whatever you would like.
-
-## Available Settings
-
-`config.ssh.username` - This sets the username that Vagrant will SSH
-as by default. Providers are free to override this if they detect a more
-appropriate user. By default this is "vagrant", since that is what most
-public boxes are made as.
-
-<hr>
-
-`config.ssh.password` - This sets a password that Vagrant will use to
-authenticate the SSH user. Note that Vagrant recommends you use key-based
-authentication rather than a password (see `private_key_path`) below. If
-you use a password, Vagrant will automatically insert a keypair if
-`insert_key` is true.
-
-<hr>
-
-`config.ssh.host` - The hostname or IP to SSH into. By default this is
-empty, because the provider usually figures this out for you.
-
-<hr>
-
-`config.ssh.port` - The port to SSH into. By default this is port 22.
-
-<hr>
-
-`config.ssh.guest_port` - The port on the guest that SSH is running on. This
-is used by some providers to detect forwarded ports for SSH. For example, if
-this is set to 22 (the default), and Vagrant detects a forwarded port to
-port 22 on the guest from port 4567 on the host, Vagrant will attempt
-to use port 4567 to talk to the guest if there is no other option.
-
-<hr>
-
-`config.ssh.private_key_path` - The path to the private key to use to
-SSH into the guest machine. By default this is the insecure private key
-that ships with Vagrant, since that is what public boxes use. If you make
-your own custom box with a custom SSH key, this should point to that
-private key.
-
-You can also specify multiple private keys by setting this to be an array.
-This is useful, for example, if you use the default private key to bootstrap
-the machine, but replace it with perhaps a more secure key later.
-
-<hr>
-
-`config.ssh.keys_only` - Only use Vagrant-provided SSH private keys (do not use
-any keys stored in ssh-agent). The default value is `true`.
-
-<hr>
-
-`config.ssh.verify_host_key` - Perform strict host-key verification. The default
-value is `false`.
-
-<hr>
-
-`config.ssh.paranoid` - Perform strict host-key verification. The default value
-is `false`.
-
-__Deprecation:__
-The `config.ssh.paranoid` option is deprecated and will be removed in a future release.
-Please use the `config.ssh.verify_host_key` option instead.
-
-<hr>
-
-`config.ssh.forward_agent` - If `true`, agent forwarding over SSH
-connections is enabled. Defaults to false.
-
-<hr>
-
-`config.ssh.forward_x11` - If `true`, X11 forwarding over SSH connections
-is enabled. Defaults to false.
-
-<hr>
-
-`config.ssh.forward_env` - An array of host environment variables to forward to
-the guest. If you are familiar with OpenSSH, this corresponds to the `SendEnv`
-parameter.
-
-```ruby
-config.ssh.forward_env = ["CUSTOM_VAR"]
-```
-
-<hr>
-
-`config.ssh.insert_key` - If `true`, Vagrant will automatically insert
-a keypair to use for SSH, replacing Vagrant's default insecure key
-inside the machine if detected. By default, this is true.
-
-This only has an effect if you do not already use private keys for
-authentication or if you are relying on the default insecure key.
-If you do not have to care about security in your project and want to
-keep using the default insecure key, set this to `false`.
-
-<hr>
-
-`config.ssh.proxy_command` - A command-line command to execute that receives
-the data to send to SSH on stdin. This can be used to proxy the SSH connection.
-`%h` in the command is replaced with the host and `%p` is replaced with
-the port.
-
-<hr>
-
-`config.ssh.pty` - If `true`, pty will be used for provisioning. Defaults to false.
-
-This setting is an _advanced feature_ that should not be enabled unless
-absolutely necessary. It breaks some other features of Vagrant, and is
-really only exposed for cases where it is absolutely necessary. If you can find
-a way to not use a pty, that is recommended instead.
-
-When pty is enabled, it is important to note that command output will _not_ be
-streamed to the UI. Instead, the output will be delivered in full to the UI
-once the command has completed.
-
-<hr>
-
-`config.ssh.keep_alive` If `true`, this setting SSH will send keep-alive packets
-every 5 seconds by default to keep connections alive.
-
-<hr>
-
-`config.ssh.shell` - The shell to use when executing SSH commands from
-Vagrant. By default this is `bash -l`. Note that this has no effect on
-the shell you get when you run `vagrant ssh`. This configuration option
-only affects the shell to use when executing commands internally in Vagrant.
-
-<hr>
-
-`config.ssh.export_command_template` - The template used to generate
-exported environment variables in the active session. This can be useful
-when using a Bourne incompatible shell like C shell. The template supports
-two variables which are replaced with the desired environment variable key and
-environment variable value: `%ENV_KEY%` and `%ENV_VALUE%`. The default template
-is:
-
-```ruby
-config.ssh.export_command_template = 'export %ENV_KEY%="%ENV_VALUE%"'
-```
-
-<hr>
-
-`config.ssh.sudo_command` - The command to use when executing a command
-with `sudo`. This defaults to `sudo -E -H %c`. The `%c` will be replaced by
-the command that is being executed.
-
-<hr>
-
-`config.ssh.compression` - If `false`, this setting will not include the
-compression setting when ssh'ing into a machine. If this is not set, it will
-default to `true` and `Compression=yes` will be enabled with ssh.
-
-<hr>
-
-`config.ssh.dsa_authentication` - If `false`, this setting  will not include
-`DSAAuthentication` when ssh'ing into a machine. If this is not set, it will
-default to `true` and `DSAAuthentication=yes` will be used with ssh.
-
-<hr>
-
-`config.ssh.extra_args` - This settings value is passed directly into the
-ssh executable. This allows you to pass any arbitrary commands to do things such
-as reverse tunneling down into the ssh program. These options can either be
-single flags set as strings such as `"-6"` for IPV6 or an array of arguments
-such as `["-L", "8008:localhost:80"]` for enabling a tunnel from host port 8008
-to port 80 on guest.

data/vendor/bundle/ruby/2.4.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/vagrantfile/tips.html.md

@@ -1,72 +0,0 @@
----
-layout: "docs"
-page_title: "Tips & Tricks - Vagrantfile"
-sidebar_current: "vagrantfile-tips"
-description: |-
-  The Vagrantfile is a very flexible configuration format. Since it is just
-  Ruby, there is a lot you can do with it. However, in that same vein, since
-  it is Ruby, there are a lot of ways you can shoot yourself in the foot. When
-  using some of the tips and tricks on this page, please take care to use them
-  correctly.
----
-
-# Tips & Tricks
-
-The Vagrantfile is a very flexible configuration format. Since it is just
-Ruby, there is a lot you can do with it. However, in that same vein, since
-it is Ruby, there are a lot of ways you can shoot yourself in the foot. When
-using some of the tips and tricks on this page, please take care to use them
-correctly.
-
-## Loop Over VM Definitions
-
-If you want to apply a slightly different configuration to many
-multi-machine machines, you can use a loop to do this. For example, if
-you wanted to create three machines:
-
-```ruby
-(1..3).each do |i|
-  config.vm.define "node-#{i}" do |node|
-    node.vm.provision "shell",
-      inline: "echo hello from node #{i}"
-  end
-end
-```
-
-~> **Warning:** The inner portion of multi-machine definitions
-and provider overrides are lazy-loaded. This can cause issues if you change
-the value of a variable used within the configs. For example, the loop below
-<em>does not work</em>:
-
-```ruby
-# THIS DOES NOT WORK!
-for i in 1..3 do
-  config.vm.define "node-#{i}" do |node|
-    node.vm.provision "shell",
-      inline: "echo hello from node #{i}"
-  end
-end
-```
-
-The `for i in  ...` construct in Ruby actually modifies the value of `i`
-for each iteration, rather than making a copy. Therefore, when you run this,
-every node will actually provision with the same text.
-
-This is an easy mistake to make, and Vagrant cannot really protect against it,
-so the best we can do is mention it here.
-
-## Overwrite host locale in ssh session
-
-Usually, host locale environment variables are passed to guest. It may cause
-failures if the guest software do not support host locale. One possible solution
-is override locale in the `Vagrantfile`:
-
-```ruby
-ENV["LC_ALL"] = "en_US.UTF-8"
-
-Vagrant.configure("2") do |config|
-  # ...
-end
-```
-
-The change is only visible within the `Vagrantfile`.

data/vendor/bundle/ruby/2.4.0/bundler/gems/vagrant-04f7215b5e3f/website/source/docs/vagrantfile/vagrant_settings.html.md

@@ -1,31 +0,0 @@
----
-layout: "docs"
-page_title: "config.vagrant - Vagrantfile"
-sidebar_current: "vagrantfile-vagrant"
-description: |-
-  The settings within "config.vagrant" modify the behavior of Vagrant
-  itself.
----
-
-# Vagrant Settings
-
-**Config namespace: `config.vagrant`**
-
-The settings within `config.vagrant` modify the behavior of Vagrant
-itself.
-
-## Available Settings
-
-`config.vagrant.host` - This sets the type of host machine that is running
-Vagrant. By default this is `:detect`, which causes Vagrant to auto-detect
-the host. Vagrant needs to know this information in order to perform some
-host-specific things, such as preparing NFS folders if they're enabled.
-You should only manually set this if auto-detection fails.
-
-`config.vagrant.sensitive` - (string, array) - Value or list of values that
-should not be displayed in Vagrant's output. Value(s) will be removed from
-Vagrant's normal UI output as well as logger output.
-
-```ruby
-config.vagrant.sensitive = ["MySecretPassword", ENV["MY_TOKEN"]]
-```