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/networking/public_network.html.md DELETED Viewed

@@ -1,162 +0,0 @@
----
-layout: "docs"
-page_title: "Public Networks - Networking"
-sidebar_current: "networking-public"
-description: |-
-  Vagrant public networks are less private than private networks, and the exact
-  meaning actually varies from provider to provider, hence the ambiguous
-  definition. The idea is that while private networks should never allow the
-  general public access to your machine, public networks can.
----
-# Public Networks
-**Network identifier: `public_network`**
-Vagrant public networks are less private than private networks, and the exact
-meaning actually varies from [provider to provider](/docs/providers/),
-hence the ambiguous definition. The idea is that while
-[private networks](/docs/networking/private_network.html) should never allow the
-general public access to your machine, public networks can.
-<div class="alert alert-info">
-  <strong>Confused?</strong> We kind of are, too. It is likely that
-  public networks will be replaced by <code>:bridged</code> in a
-  future release, since that is in general what should be done with
-  public networks, and providers that do not support bridging generally
-  do not have any other features that map to public networks either.
-</div>
-<div class="alert alert-warning">
-  <strong>Warning!</strong> Vagrant boxes are insecure by default
-  and by design, featuring public passwords, insecure keypairs
-  for SSH access, and potentially allow root access over SSH.  With
-  these known credentials, your box is easily accessible by anyone on
-  your network.  Before configuring Vagrant to use a public network,
-  consider <em>all</em> potential security implications
-  and review the <a href="/docs/boxes/base.html">default box
-  configuration</a> to identify potential security risks.
-</div>
-## DHCP
-The easiest way to use a public network is to allow the IP to be assigned
-via DHCP. In this case, defining a public network is trivially easy:
-```ruby
-Vagrant.configure("2") do |config|
-  config.vm.network "public_network"
-end
-```
-When DHCP is used, the IP can be determined by using `vagrant ssh` to
-SSH into the machine and using the appropriate command line tool to find
-the IP, such as `ifconfig`.
-### Using the DHCP Assigned Default Route
-Some cases require the DHCP assigned default route to be untouched. In these cases one
-may specify the `use_dhcp_assigned_default_route` option. As an example:
-```ruby
-Vagrant.configure("2") do |config|
-  config.vm.network "public_network",
-    use_dhcp_assigned_default_route: true
-end
-```
-## Static IP
-Depending on your setup, you may wish to manually set the IP of your
-bridged interface. To do so, add a `:ip` clause to the network definition.
-```ruby
-config.vm.network "public_network", ip: "192.168.0.17"
-```
-## Default Network Interface
-If more than one network interface is available on the host machine, Vagrant will
-ask you to choose which interface the virtual machine should bridge to. A default
-interface can be specified by adding a `:bridge` clause to the network definition.
-```ruby
-config.vm.network "public_network", bridge: "en1: Wi-Fi (AirPort)"
-```
-The string identifying the desired interface must exactly match the name of an
-available interface. If it cannot be found, Vagrant will ask you to pick
-from a list of available network interfaces.
-With some providers, it is possible to specify a list of adapters to bridge
-against:
-```ruby
-config.vm.network "public_network", bridge: [
-  "en1: Wi-Fi (AirPort)",
-  "en6: Broadcom NetXtreme Gigabit Ethernet Controller",
-]
-```
-In this example, the first network adapter that exists and can successfully be
-bridge will be used.
-## Disable Auto-Configuration
-If you want to manually configure the network interface yourself, you
-can disable auto-configuration by specifying `auto_config`:
-```ruby
-Vagrant.configure("2") do |config|
-  config.vm.network "public_network", auto_config: false
-end
-```
-Then the shell provisioner can be used to configure the ip of the interface:
-```ruby
-Vagrant.configure("2") do |config|
-  config.vm.network "public_network", auto_config: false
-  # manual ip
-  config.vm.provision "shell",
-    run: "always",
-    inline: "ifconfig eth1 192.168.0.17 netmask 255.255.255.0 up"
-  # manual ipv6
-  config.vm.provision "shell",
-    run: "always",
-    inline: "ifconfig eth1 inet6 add fc00::17/7"
-end
-```
-## Default Router
-Depending on your setup, you may wish to manually override the default
-router configuration. This is required if you need access the Vagrant box from
-other networks over the public network. To do so, you can use a shell
-provisioner script:
-```ruby
-Vagrant.configure("2") do |config|
-  config.vm.network "public_network", ip: "192.168.0.17"
-  # default router
-  config.vm.provision "shell",
-    run: "always",
-    inline: "route add default gw 192.168.0.1"
-  # default router ipv6
-  config.vm.provision "shell",
-    run: "always",
-    inline: "route -A inet6 add default gw fc00::1 eth1"
-  # delete default gw on eth0
-  config.vm.provision "shell",
-    run: "always",
-    inline: "eval `route -n | awk '{ if ($8 ==\"eth0\" && $2 != \"0.0.0.0\") print \"route del default gw \" $2; }'`"
-end
-```
-Note the above is fairly complex and may be guest OS specific, but we
-document the rough idea of how to do it because it is a common question.

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

@@ -1,70 +0,0 @@
----
-layout: "docs"
-page_title: "Debugging and Troubleshooting"
-sidebar_current: "other-debugging"
-description: |-
-  As much as we try to keep Vagrant stable and bug free, it is inevitable
-  that issues will arise and Vagrant will behave in unexpected ways. In
-  these cases, Vagrant has amazing support channels available to assist you.
----
-# Debugging
-As much as we try to keep Vagrant stable and bug free, it is inevitable
-that issues will arise and Vagrant will behave in unexpected ways.
-When using these support channels, it is generally helpful to include
-debugging logs along with any error reports. These logs can often help you
-troubleshoot any problems you may be having.
-!> **Scan for sensitive information!** Vagrant debug logs include information
-about your system including environment variables and user information. If you
-store sensitive information in the environment or in your user account, please
-scan or scrub the debug log of this information before uploading the contents to
-the public Internet.
-~> **Submit debug logs using GitHub Gist.** If you plan on submitting a bug
-report or issue that includes debug-level logs, please use a service like
-[Gist](https://gist.github.com). **Do not** paste the raw debug logs into an
-issue as it makes it very difficult to scroll and parse the information.
-To enable detailed logging, set the `VAGRANT_LOG` environmental variable
-to the desired log level name, which is one of `debug` (loud), `info` (normal),
-`warn` (quiet), and `error` (very quiet). When asking for support, please
-set this to `debug`. When troubleshooting your own issues, you should start
-with `info`, which is much quieter, but contains important information
-about the behavior of Vagrant.
-On Linux and Mac systems, this can be done by prepending the `vagrant`
-command with an environmental variable declaration:
-```
-$ VAGRANT_LOG=info vagrant up
-```
-On Windows, multiple steps are required:
-```
-$ set VAGRANT_LOG=info
-$ vagrant up
-```
-You can also get the debug level output using the `--debug` command line
-option. For example:
-```
-$ vagrant up --debug
-```
-On Linux and Mac, if you are saving the output to a file, you may need to redirect stderr and
-stdout using `&>`:
-```
-$ vagrant up --debug &> vagrant.log
-```
-On Windows in PowerShell (outputs to log and screen):
-```
-$ vagrant up --debug 2>&1 | Tee-Object -FilePath ".\vagrant.log"
-```

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

@@ -1,250 +0,0 @@
----
-layout: "docs"
-page_title: "Environmental Variables"
-sidebar_current: "other-envvars"
-description: |-
-  Vagrant has a set of environmental variables that can be used to
-  configure and control it in a global way. This page lists those environmental
-  variables.
----
-# Environmental Variables
-Vagrant has a set of environmental variables that can be used to
-configure and control it in a global way. This page lists those environmental
-variables.
-## `VAGRANT_ALIAS_FILE`
-`VAGRANT_ALIAS_FILE` can be set to change the file where Vagrant aliases are
-defined. By default, this is set to `~/.vagrant.d/aliases`.
-## `VAGRANT_DEBUG_LAUNCHER`
-For performance reasons, especially for Windows users, Vagrant uses a static
-binary to launch the actual Vagrant process. If you have _very_ early issues
-when launching Vagrant from the official installer, you can specify the
-`VAGRANT_DEBUG_LAUNCHER` environment variable to output debugging information
-about the launch process.
-## `VAGRANT_DEFAULT_PROVIDER`
-This configures the default provider Vagrant will use.
-This normally does not need to be set since Vagrant is fairly intelligent
-about how to detect the default provider. By setting this, you will force
-Vagrant to use this provider for any _new_ Vagrant environments. Existing
-Vagrant environments will continue to use the provider they came `up` with.
-Once you `vagrant destroy` existing environments, this will take effect.
-## `VAGRANT_PREFERRED_PROVIDERS`
-This configures providers that Vagrant should prefer.
-Much like the `VAGRANT_DEFAULT_PROVIDER` this environment variable normally
-does not need to be set. By setting this you will instruct Vagrant to
-_prefer_ providers defined in this environment variable for any _new_
-Vagrant environments. Existing Vagrant environments will continue to use
-the provider they came `up` with. Once you `vagrant destroy` existing environments,
-this will take effect. A single provider can be defined within this environment
-variable or a comma delimited list of providers.
-## `VAGRANT_BOX_UPDATE_CHECK_DISABLE`
-By default, Vagrant will query the metadata API server to see if a newer
-box version is available for download. This optional can be disabled on a
-per-Vagrantfile basis with `config.vm.box_check_update`, but it can also be
-disabled globally setting `VAGRANT_BOX_UPDATE_CHECK_DISABLE` to any non-empty
-value.
-This option will not affect global box functions like `vagrant box update`.
-## `VAGRANT_CHECKPOINT_DISABLE`
-Vagrant does occasional network calls to check whether the version of Vagrant
-that is running locally is up to date. We understand that software making remote
-calls over the internet for any reason can be undesirable. To suppress these
-calls, set the environment variable `VAGRANT_CHECKPOINT_DISABLE` to any
-non-empty value.
-If you use other HashiCorp tools like Packer and would prefer to configure this
-setting only once, you can set `CHECKPOINT_DISABLE` instead.
-## `VAGRANT_CWD`
-`VAGRANT_CWD` can be set to change the working directory of Vagrant. By
-default, Vagrant uses the current directory you are in. The working directory
-is important because it is where Vagrant looks for the Vagrantfile. It
-also defines how relative paths in the Vagrantfile are expanded, since they're
-expanded relative to where the Vagrantfile is found.
-This environmental variable is most commonly set when running Vagrant from
-a scripting environment in order to set the directory that Vagrant sees.
-## `VAGRANT_DOTFILE_PATH`
-`VAGRANT_DOTFILE_PATH` can be set to change the directory where Vagrant stores
-VM-specific state, such as the VirtualBox VM UUID. By default, this is set to
-`.vagrant`. If you keep your Vagrantfile in a Dropbox folder in order to share
-the folder between your desktop and laptop (for example), Vagrant will overwrite
-the files in this directory with the details of the VM on the most recently-used
-host. To avoid this, you could set `VAGRANT_DOTFILE_PATH` to `.vagrant-laptop`
-and `.vagrant-desktop` on the respective machines. (Remember to update your
-`.gitignore`!)
-## `VAGRANT_HOME`
-`VAGRANT_HOME` can be set to change the directory where Vagrant stores
-global state. By default, this is set to `~/.vagrant.d`. The Vagrant home
-directory is where things such as boxes are stored, so it can actually become
-quite large on disk.
-## `VAGRANT_LOG`
-`VAGRANT_LOG` specifies the verbosity of log messages from Vagrant.
-By default, Vagrant does not actively show any log messages.
-Log messages are very useful when troubleshooting issues, reporting
-bugs, or getting support. At the most verbose level, Vagrant outputs
-basically everything it is doing.
-Available log levels are "debug," "info," "warn," and "error." Both
-"warn" and "error" are practically useless since there are very few
-cases of these, and Vagrant generally reports them within the normal
-output.
-"info" is a good level to start with if you are having problems, because
-while it is much louder than normal output, it is still very human-readable
-and can help identify certain issues.
-"debug" output is _extremely_ verbose and can be difficult to read without
-some knowledge of Vagrant internals. It is the best output to attach to
-a support request or bug report, however.
-## `VAGRANT_NO_COLOR`
-If this is set to any value, then Vagrant will not use any colorized
-output. This is useful if you are logging the output to a file or
-on a system that does not support colors.
-The equivalent behavior can be achieved by using the `--no-color` flag
-on a command-by-command basis. This environmental variable is useful
-for setting this flag globally.
-## `VAGRANT_FORCE_COLOR`
-If this is set to any value, then Vagrant will force colored output, even
-if it detected that there is no TTY or the current environment does not
-support it.
-The equivalent behavior can be achieved by using the `--color` flag on a
-command-by-command basis. This environmental variable is useful for setting
-this flag globally.
-## `VAGRANT_NO_PLUGINS`
-If this is set to any value, then Vagrant will not load any 3rd party
-plugins. This is useful if you install a plugin and it is introducing
-instability to Vagrant, or if you want a specific Vagrant environment to
-not load plugins.
-Note that any `vagrant plugin` commands automatically do not load any
-plugins, so if you do install any unstable plugins, you can always use
-the `vagrant plugin` commands without having to worry.
-## `VAGRANT_ALLOW_PLUGIN_SOURCE_ERRORS`
-If this is set to any value, then Vagrant will not error when a configured
-plugin source is unavailable. When installing a Vagrant plugin Vagrant
-will error and halt if a plugin source is inaccessible. In some cases it
-may be desirable to ignore inaccessible sources and continue with the
-plugin installation. Enabling this value will cause Vagrant to simply log
-the plugin source error and continue.
-## `VAGRANT_NO_PARALLEL`
-If this is set, Vagrant will not perform any parallel operations (such as
-parallel box provisioning). All operations will be performed in serial.
-## `VAGRANT_DETECTED_OS`
-This environment variable may be set by the Vagrant launcher to help determine
-the current runtime platform. In general Vagrant will set this value when running
-on a Windows host using a cygwin or msys based shell. If this value is set, the
-Vagrant launcher will not modify it.
-## `VAGRANT_DETECTED_ARCH`
-This environment variable may be set by the Vagrant launcher to help determine
-the current runtime architecture in use. In general Vagrant will set this value
-when running on a Windows host using a cygwin or msys based shell. The value
-the Vagrant launcher may set in this environment variable will not always match
-the actual architecture of the platform itself. Instead it signifies the detected
-architecture of the environment it is running within. If this value is set, the
-Vagrant launcher will not modify it.
-## `VAGRANT_WINPTY_DISABLE`
-If this is set, Vagrant will _not_ wrap interactive processes with winpty where
-required.
-## `VAGRANT_PREFER_SYSTEM_BIN`
-If this is set, Vagrant will prefer using utility executables (like `ssh` and `rsync`)
-from the local system instead of those vendored within the Vagrant installation.
-Vagrant will default to using a system provided `ssh` on Windows. This
-environment variable can also be used to disable that behavior to force Vagrant to
-use the embedded `ssh` executable by setting it to `0`.
-## `VAGRANT_SKIP_SUBPROCESS_JAILBREAK`
-As of Vagrant 1.7.3, Vagrant tries to intelligently detect if it is running in
-the installer or running via Bundler. Although not officially supported, Vagrant
-tries its best to work when executed via Bundler. When Vagrant detects that you
-have spawned a subprocess that lives outside of Vagrant's installer, Vagrant
-will do its best to reset the preserved environment during the subprocess
-execution.
-If Vagrant detects it is running outside of the officially installer, the
-original environment will always be restored. You can disable this automatic
-jailbreak by setting `VAGRANT_SKIP_SUBPROCESS_JAILBREAK`.
-## `VAGRANT_VAGRANTFILE`
-This specifies the filename of the Vagrantfile that Vagrant searches for.
-By default, this is "Vagrantfile". Note that this is _not_ a file path,
-but just a filename.
-This environmental variable is commonly used in scripting environments
-where a single folder may contain multiple Vagrantfiles representing
-different configurations.
-## `VAGRANT_DISABLE_VBOXSYMLINKCREATE`
-If set, this will disable the ability to create symlinks with all virtualbox
-shared folders. Defaults to true if the option is not set. This can be overridden
-on a per-folder basis within your Vagrantfile config by settings the
-`SharedFoldersEnableSymlinksCreate` option to true.
-## `VAGRANT_ENABLE_RESOLV_REPLACE`
-Use the Ruby Resolv library in place of the libc resolver.
-## `VAGRANT_DISABLE_RESOLV_REPLACE`
-Vagrant can optionally use the Ruby Resolv library in place of the libc resolver.
-This can be disabled setting this environment variable.
-## `VAGRANT_POWERSHELL_VERSION_DETECTION_TIMEOUT`
-Vagrant will use a default timeout when checking for the installed version
-of PowerShell. Occasionally the default can be too low and Vagrant will report
-being unable to detect the installed version of PowerShell. This environment
-variable can be used to extend the timeout used during PowerShell version
-detection.
-## `VAGRANT_USE_VAGRANT_TRIGGERS`
-Vagrant will not display the warning about disabling the core trigger feature if
-the community plugin is installed.

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

@@ -1,16 +0,0 @@
----
-layout: "docs"
-page_title: "Other"
-sidebar_current: "other"
-description: |-
-  This page covers Vagrant information that does not quite fit under the other
-  categories.
----
-# Other
-This section covers other information that does not quite fit under the
-other categories.
-- [Debugging](/docs/other/debugging.html)
-- [Environment Variables](/docs/other/environmental-variables.html)

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

@@ -1,132 +0,0 @@
----
-layout: "docs"
-page_title: "Vagrant and Windows Subsystem for Linux"
-sidebar_current: "other-wsl"
-description: |-
-  An overview of using Vagrant on Windows within the Windows Subsystem
-  for Linux.
----
-# Vagrant and Windows Subsystem for Linux
-Windows has recently introduced a new feature called the Windows Subsystem
-for Linux (WSL). This is a beta feature available in developer mode on recent
-releases of Windows 10. It is important to note that this feature is still
-in _beta_ on Windows, and Vagrant support should be considered _alpha_.
-<div class="alert alert-warning">
-  <strong>Warning: Advanced Topic!</strong> Using Vagrant within the Windows
-  Subsystem for Linux is an advanced topic that only experienced Vagrant users
-  who are reasonably comfortable with Windows, WSL, and Linux should approach.
-</div>
-# Installation
-Installation requires WSL, Ubuntu on Windows, and Vagrant. Read on for installation
-instructions for each item.
-## Windows Subsystem for Linux and Ubuntu on Windows
-First install the Windows Subsystem for Linux, followed by Ubuntu on Windows. This guide
-from Microsoft walks through the process:
-* https://msdn.microsoft.com/en-us/commandline/wsl/install_guide
-## Vagrant Installation
-Vagrant _must_ be installed within Ubuntu on Windows. Even though the `vagrant.exe`
-file can be executed from within the WSL, it will not function as expected. To
-install Vagrant into the WSL, follow these steps:
-* Download the 64-bit Debian package from the downloads page.
-* Open a `cmd` or `powershell` window
-* Enter the command: `bash`
-* Install vagrant: `sudo dpkg -i vagrant_VERSION_x86_64.deb`
-```
-C:\Users\vagrant> bash
-vagrant@vagrant-10:/mnt/c/Users/vagrant$ sudo dpkg -i vagrant_VERSION_x86_64.deb
-[sudo] password for vagrant:
-(Reading database ... 31885 files and directories currently installed.)
-Preparing to unpack vagrant_VERSION_x86_64.deb ...
-Unpacking vagrant (1:VERSION) ...
-Setting up vagrant (1:VERSION) ...
-vagrant@vagrant-10:/mnt/c/Users/vagrant$ vagrant help
-Usage: vagrant [options] <command> [<args>]
-```
-# Vagrant Usage
-Vagrant will detect when it is being run within the WSL and adjust how it
-locates and executes third party executables. For example, when using the
-VirtualBox provider Vagrant will interact with VirtualBox installed on
-the Windows system, not within the WSL. It is important to ensure that
-any required Windows executable is available within your `PATH` to allow
-Vagrant to access them.
-For example, when using the VirtualBox provider:
-```
-export PATH="$PATH:/mnt/c/Program Files/Oracle/VirtualBox"
-```
-## Windows Access
-Working within the WSL provides a layer of isolation from the actual
-Windows system. In most cases Vagrant will need access to the actual
-Windows system to function correctly. As most Vagrant providers will
-need to be installed on Windows directly (not within the WSL) Vagrant
-will require Windows access. Access to the Windows system is controlled
-via an environment variable: `VAGRANT_WSL_ENABLE_WINDOWS_ACCESS`. If
-this environment variable is set, Vagrant will access the Windows system
-to run executables and enable things like synced folders. When running
-in a bash shell within WSL, the environment variable can be setup like so:
-```
-$ export VAGRANT_WSL_ENABLE_WINDOWS_ACCESS="1"
-```
-This will enable Vagrant to access the Windows system outside of the
-WSL and properly interact with Windows executables. This will automatically
-modify the `VAGRANT_HOME` environment variable if it is not already defined,
-setting it to be within the user's home directory on Windows.
-It is important to note that paths shared with the Windows system will
-not have Linux permissions enforced. For example, when a directory within
-the WSL is synced to a guest using the VirtualBox provider, any local
-permissions defined on that directory (or its contents) will not be
-visible from the guest. Likewise, any files created from the guest within
-the synced folder will be world readable/writeable in WSL.
-Other useful WSL related environment variables:
-* `VAGRANT_WSL_WINDOWS_ACCESS_USER` - Override current Windows username
-* `VAGRANT_WSL_DISABLE_VAGRANT_HOME` - Do not modify the `VAGRANT_HOME` variable
-* `VAGRANT_WSL_WINDOWS_ACCESS_USER_HOME_PATH` - Custom Windows system home path
-If a Vagrant project directory is not within the user's home directory on the
-Windows system, certain actions that include permission checks may fail (like
-`vagrant ssh`). When accessing Vagrant projects outside the WSL Vagrant will
-skip these permission checks when the project path is within the path defined
-in the `VAGRANT_WSL_WINDOWS_ACCESS_USER_HOME_PATH` environment variable. For
-example, if a user wants to run a Vagrant project from the WSL that is located
-at `C:\TestDir\vagrant-project`:
-```
-C:\Users\vagrant> cd C:\TestDir\vagrant-project
-C:\TestDir\vagrant-project> bash
-vagrant@vagrant-10:/mnt/c/TestDir/vagrant-project$ export VAGRANT_WSL_WINDOWS_ACCESS_USER_HOME_PATH="/mnt/c/TestDir"
-vagrant@vagrant-10:/mnt/c/TestDir/vagrant-project$ vagrant ssh
-```
-## Using Docker
-The docker daemon cannot be run inside the Windows Subsystem for Linux. However,
-the daemon _can_ be run on Windows and accessed by Vagrant while running in the
-WSL. Once docker is installed and running on Windows, export the following
-environment variable to give Vagrant access:
-```
-vagrant@vagrant-10:/mnt/c/Users/vagrant$ export DOCKER_HOST=tcp://127.0.0.1:2375
-```