vagrant-aws-mkubenka 0.7.2.pre.14 → 0.7.2.pre.16

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-5333e60e2d38/website/source/community.html.erb

@@ -1,106 +0,0 @@
----
-layout: "inner"
-sidebar_current: "about-community"
-page_title: "Community"
-description: |-
-  Vagrant is an open source project with a growing community. There are
-  active, dedicated users willing to help you through various mediums.
----
-
-<h1>Community</h1>
-<p>
-  Vagrant is an open source project with a growing community. There are
-  active, dedicated users willing to help you through various mediums.
-</p>
-<p>
-  <strong>IRC:</strong> <code>#vagrant</code> on Freenode
-</p>
-<p>
-  <strong>Announcement list:</strong>
-  <a href="https://groups.google.com/group/hashicorp-announce">HashiCorp Announcement Google Group</a>
-</p>
-<p>
-  <strong>Discussion list:</strong>
-  <a href="https://groups.google.com/forum/#!forum/vagrant-up">Vagrant Google Group</a>
-</p>
-<p>
-  <strong>Bug Tracker:</strong>
-  <a href="https://github.com/mitchellh/vagrant/issues">Issue tracker
-  on GitHub</a>. Please only use this for reporting bugs. Do not ask
-  for general help here. Use IRC or the mailing list for that.
-</p>
-<p>
-  <strong>Training:</strong>
-  Paid <a href="https://www.hashicorp.com/training.html">HashiCorp training courses</a>
-  are also available in a city near you. Private training courses are also available.
-</p>
-
-<h2>People</h2>
-<p>
-  The following people are some of the faces behind Vagrant. They each
-  contribute to Vagrant in some core way. Over time, faces may appear and
-  disappear from this list as contributors come and go. In addition to
-  the faces below, Vagrant is a project by
-  <a href="https://www.hashicorp.com">HashiCorp</a>, so many HashiCorp
-  employees actively contribute to Vagrant.
-</p>
-<div class="people">
-  <div class="person">
-    <img class="pull-left" src="//www.gravatar.com/avatar/54079122b67de9677c1f93933ce8b63a.png?s=125">
-    <div class="bio">
-      <h3>Mitchell Hashimoto (<a href="https://github.com/mitchellh">@mitchellh</a>)</h3>
-      <p>
-        Mitchell Hashimoto is a creator of Vagrant. He has been with the
-        Vagrant project from the very beginning. Mitchell is also the
-        creator of
-        <a href="https://www.consul.io">Consul</a>,
-        <a href="https://www.packer.io">Packer</a>,
-        <a href="https://www.serf.io">Serf</a>, and
-        <a href="https://www.ottoproject.io">Otto</a>.
-      </p>
-    </div>
-  </div>
-
-  <div class="person">
-    <img class="pull-left" src="//www.gravatar.com/avatar/2acc31dd6370a54b18f6755cd0710ce6.png?s=125">
-    <div class="bio">
-      <h3>Jack Pearkes (<a href="https://github.com/pearkes">@pearkes</a>)</h3>
-      <p>
-        Jack Pearkes created and maintains many projects at HashiCorp. He
-        is the original author of Vagrant Cloud (now
-        <a href="https://atlas.hashicorp.com">Atlas</a>). He is also a
-        core committer to <a href="https://www.packer.io">Packer</a>
-        and maintains many successful
-        <a href="https://github.com/pearkes">open source projects</a>
-        while also being an employee of
-        <a href="https://www.hashicorp.com">HashiCorp</a>.
-      </p>
-    </div>
-  </div>
-
-  <div class="person">
-    <img class="pull-left" src="//avatars1.githubusercontent.com/u/408570?v=3&amp;s=125">
-    <div class="bio">
-      <h3>Seth Vargo (<a href="https://github.com/sethvargo">@sethvargo</a>)</h3>
-      <p>
-        Seth Vargo is a core committer to Vagrant, with his main focus
-        being the core plugin system, pushes, and provisioners. Seth is
-        also a contributor to Consul, Packer, and Vault, all while being
-        an employee at <a href="https://www.hashicorp.com">HashiCorp</a>.
-      </p>
-    </div>
-  </div>
-
-  <div class="person">
-    <img class="pull-left" src="//avatars3.githubusercontent.com/u/37534?v=3&amp;s=125">
-    <div class="bio">
-      <h3>Paul Hinze (<a href="https://github.com/phinze">@phinze</a>)</h3>
-      <p>
-        Paul Hinze is a contributor to Vagrant, with his main focus being
-        provisioners and working on HashiCorp's external plugins.  He is
-        also a core committer to <a href="https://www.terraform.io">Terraform</a>,
-        all while being an employee at <a href="https://www.hashicorp.com">HashiCorp</a>.
-      </p>
-    </div>
-  </div>
-</div>

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-5333e60e2d38/website/source/docs/boxes/base.html.md

@@ -1,287 +0,0 @@
----
-layout: "docs"
-page_title: "Creating a Base Box"
-sidebar_current: "boxes-base"
-description: |-
-  There are a special category of boxes known as "base boxes." These boxes
-  contain the bare minimum required for Vagrant to function, are generally
-  not made by repackaging an existing Vagrant environment (hence the "base"
-  in the "base box").
----
-
-# Creating a Base Box
-
-There are a special category of boxes known as "base boxes." These boxes
-contain the bare minimum required for Vagrant to function, are generally
-not made by repackaging an existing Vagrant environment (hence the "base"
-in the "base box").
-
-For example, the Ubuntu boxes provided by the Vagrant project (such as
-"precise64") are base boxes. They were created from a minimal Ubuntu install
-from an ISO, rather than repackaging an existing environment.
-
-Base boxes are extremely useful for having a clean slate starting point from
-which to build future development environments. The Vagrant project hopes
-in the future to be able to provide base boxes for many more operating systems.
-Until then, this page documents how you can create your own base box.
-
-<div class="alert alert-warning">
-  <strong>Advanced topic!</strong> Creating a base box can be a time consuming
-  and tedious process, and is not recommended for new Vagrant users. If you are
-  just getting started with Vagrant, we recommend trying to find existing
-  base boxes to use first.
-</div>
-
-## What's in a Base Box?
-
-A base box typically consists of only a bare minimum set of software
-for Vagrant to function. As an example, a Linux box may contain only the
-following:
-
-* Package manager
-* SSH
-* SSH user so Vagrant can connect
-* Perhaps Chef, Puppet, etc. but not strictly required.
-
-In addition to this, each [provider](/docs/providers/) may require
-additional software. For example, if you are making a base box for VirtualBox,
-you will want to include the VirtualBox guest additions so that shared folders
-work properly. But if you are making an AWS base box, this is not required.
-
-## Creating a Base Box
-
-Creating a base box is actually provider-specific. This means that depending
-on if you are using VirtualBox, VMware, AWS, etc. the process for creating
-a base box is different. Because of this, this one document cannot be a
-full guide to creating a base box.
-
-This page will document some general guidelines for creating base boxes,
-however, and will link to provider-specific guides for creating base
-boxes.
-
-Provider-specific guides for creating base boxes are linked below:
-
-* [Docker Base Boxes](/docs/docker/boxes.html)
-* [Hyper-V Base Boxes](/docs/hyperv/boxes.html)
-* [VMware Base Boxes](/docs/vmware/boxes.html)
-* [VirtualBox Base Boxes](/docs/virtualbox/boxes.html)
-
-### Packer and Atlas
-
-We strongly recommend using [Packer](https://www.packer.io) to create reproducible
-builds for your base boxes, as well as automating the builds with
-[Atlas](/docs/other/atlas.html). Read more about
-[Creating Vagrant Boxes with Packer](https://atlas.hashicorp.com/help/packer/artifacts/creating-vagrant-boxes)
-in the Atlas documentation.
-
-### Disk Space
-
-When creating a base box, make sure the user will have enough disk space
-to do interesting things, without being annoying. For example, in VirtualBox,
-you should create a dynamically resizing drive with a large maximum size.
-This causes the actual footprint of the drive to be small initially, but
-to dynamically grow towards the max size as disk space is needed, providing
-the most flexibility for the end user.
-
-If you are creating an AWS base box, do not force the AMI to allocate
-terabytes of EBS storage, for example, since the user can do that on their
-own. But you should default to mounting ephemeral drives, because they're
-free and provide a lot of disk space.
-
-### Memory
-
-Like disk space, finding the right balance of the default amount of memory
-is important. For most providers, the user can modify the memory with
-the Vagrantfile, so do not use too much by default. It would be a poor
-user experience (and mildly shocking) if a `vagrant up` from a base box
-instantly required many gigabytes of RAM. Instead, choose a value such
-as 512MB, which is usually enough to play around and do interesting things
-with a Vagrant machine, but can easily be increased when needed.
-
-### Peripherals (Audio, USB, etc.)
-
-Disable any non-necessary hardware in a base box such as audio and USB
-controllers. These are generally unnecessary for Vagrant usage and, again,
-can be easily added via the Vagrantfile in most cases.
-
-## Default User Settings
-
-Just about every aspect of Vagrant can be modified. However, Vagrant does
-expect some defaults which will cause your base box to "just work" out
-of the box. You should create these as defaults if you intend to publicly
-distribute your box.
-
-If you are creating a base box for private use, you should try _not_ to
-follow these, as they open up your base box to security risks (known
-users, passwords, private keys, etc.).
-
-### "vagrant" User
-
-By default, Vagrant expects a "vagrant" user to SSH into the machine as.
-This user should be setup with the
-[insecure keypair](https://github.com/mitchellh/vagrant/tree/master/keys)
-that Vagrant uses as a default to attempt to SSH. Also, even though
-Vagrant uses key-based authentication by default, it is a general convention
-to set the password for the "vagrant" user to "vagrant". This lets people
-login as that user manually if they need to.
-
-To configure SSH access with the insecure keypair, place the public
-key into the `~/.ssh/authorized_keys` file for the "vagrant" user. Note
-that OpenSSH is very picky about file permissions. Therefore, make sure
-that `~/.ssh` has `0700` permissions and the authorized keys file has
-`0600` permissions.
-
-When Vagrant boots a box and detects the insecure keypair, it will
-automatically replace it with a randomly generated keypair for additional
-security while the box is running.
-
-### Root Password: "vagrant"
-
-Vagrant does not actually use or expect any root password. However, having
-a generally well known root password makes it easier for the general public
-to modify the machine if needed.
-
-Publicly available base boxes usually use a root password of "vagrant" to
-keep things easy.
-
-### Password-less Sudo
-
-This is **important!**. Many aspects of Vagrant expect the default SSH user
-to have passwordless sudo configured. This lets Vagrant configure networks,
-mount synced folders, install software, and more.
-
-To begin, some minimal installations of operating systems do not even include
-`sudo` by default. Verify that you install `sudo` in some way.
-
-After installing sudo, configure it (usually using `visudo`) to allow
-passwordless sudo for the "vagrant" user. This can be done with the
-following line at the end of the configuration file:
-
-```
-vagrant ALL=(ALL) NOPASSWD: ALL
-```
-
-Additionally, Vagrant does not use a pty or tty by default when connected
-via SSH. You will need to make sure there is no line that has `requiretty` in
-it. Remove that if it exists. This allows sudo to work properly without a
-tty. Note that you _can_ configure Vagrant to request a pty, which lets
-you keep this configuration. But Vagrant by default does not do this.
-
-### SSH Tweaks
-
-In order to keep SSH speedy even when your machine or the Vagrant machine
-is not connected to the internet, set the `UseDNS` configuration to `no`
-in the SSH server configuration.
-
-This avoids a reverse DNS lookup on the connecting SSH client which
-can take many seconds.
-
-## Windows Boxes
-
-Supported Windows guest operating systems:
-- Windows 7
-- Windows 8
-- Windows Server 2008
-- Windows Server 2008 R2
-- Windows Server 2012
-- Windows Server 2012 R2
-
-Windows Server 2003 and Windows XP are _not_ supported, but if you are a die
-hard XP fan [this](https://stackoverflow.com/a/18593425/18475) may help you.
-
-### Base Windows Configuration
-
-  - Turn off UAC
-  - Disable complex passwords
-  - Disable "Shutdown Tracker"
-  - Disable "Server Manager" starting at login (for non-Core)
-
-In addition to disabling UAC in the control panel, you also must disable
-UAC in the registry. This may vary from Windows version to Windows version,
-but Windows 8/8.1 use the command below. This will allow some things like
-automated Puppet installs to work within Vagrant Windows base boxes.
-
-```
-reg add HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /d 0 /t REG_DWORD /f /reg:64
-```
-
-### Base WinRM Configuration
-
-To enable and configure WinRM you will need to set the WinRM service to
-auto-start and allow unencrypted basic auth (obviously this is not secure).
-Run the following commands from a regular Windows command prompt:
-
-```
-winrm quickconfig -q
-winrm set winrm/config/winrs @{MaxMemoryPerShellMB="512"}
-winrm set winrm/config @{MaxTimeoutms="1800000"}
-winrm set winrm/config/service @{AllowUnencrypted="true"}
-winrm set winrm/config/service/auth @{Basic="true"}
-sc config WinRM start= auto
-```
-
-### Additional WinRM 1.1 Configuration
-
-These additional configuration steps are specific to Windows Server 2008
-(WinRM 1.1). For Windows Server 2008 R2, Windows 7 and later versions of
-Windows you can ignore this section.
-
-1. Ensure the Windows PowerShell feature is installed
-2. Change the WinRM port to 5985 or upgrade to WinRM 2.0
-
-The following commands will change the WinRM 1.1 port to what's expected by
-Vagrant:
-
-```
-netsh firewall add portopening TCP 5985 "Port 5985"
-winrm set winrm/config/listener?Address=*+Transport=HTTP @{Port="5985"}
-```
-
-## Other Software
-
-At this point, you have all the common software you absolutely _need_ for
-your base box to work with Vagrant. However, there is some additional software
-you can install if you wish.
-
-While we plan on it in the future, Vagrant still does not install Chef
-or Puppet automatically when using those provisioners. Users can use a shell
-provisioner to do this, but if you want Chef/Puppet to just work out of the
-box, you will have to install them in the base box.
-
-Installing this is outside the scope of this page, but should be fairly
-straightforward.
-
-In addition to this, feel free to install and configure any other software
-you want available by default for this base box.
-
-## Packaging the Box
-
-Packaging the box into a `box` file is provider-specific. Please refer to
-the provider-specific documentation for creating a base box. Some
-provider-specific guides are linked to towards the top of this page.
-
-## Distributing the Box
-
-You can distribute the box file however you would like. However, if you want
-to support versioning, putting multiple providers at a single URL, pushing
-updates, analytics, and more, we recommend you add the box to
-[HashiCorp's Atlas](/docs/other/atlas.html).
-
-You can upload both public and private boxes to this service.
-
-## Testing the Box
-
-To test the box, pretend you are a new user of Vagrant and give it a shot:
-
-```
-$ vagrant box add my-box /path/to/the/new.box
-...
-$ vagrant init my-box
-...
-$ vagrant up
-...
-```
-
-If you made a box for some other provider, be sure to specify the
-`--provider` option to `vagrant up`. If the up succeeded, then your
-box worked!

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-5333e60e2d38/website/source/docs/boxes/format.html.md

@@ -1,119 +0,0 @@
----
-layout: "docs"
-page_title: "Box File Format"
-sidebar_current: "boxes-format"
-description: |-
-  The box file format for Vagrant has changed from only supporting VirtualBox to
-  supporting a number different providers and box formats.
----
-
-# Box File Format
-
-In the past, boxes were just [tar files](https://en.wikipedia.org/wiki/Tar_\(computing\))
-of VirtualBox exports. With Vagrant supporting multiple
-[providers](/docs/providers/) and [versioning](/docs/boxes/versioning.html)
-now, box files are slightly more complicated.
-
-Box files made for Vagrant 1.0.x (the VirtualBox export `tar` files) continue
-to work with Vagrant today. When Vagrant encounters one of these old boxes,
-it automatically updates it internally to the new format.
-
-Today, there are two different components:
-
-* Box File - This is a compressed (`tar`, `tar.gz`, `zip`) file that is specific
-  to a single provider and can contain anything. Vagrant core does not ever
-  use the contents of this file. Instead, they are passed to the provider.
-  Therefore, a VirtualBox box file has different contents from a VMware
-  box file and so on.
-
-* Box Catalog Metadata - This is a JSON document (typically exchanged
-  during interactions with [HashiCorp's Atlas](/docs/other/atlas.html))
-  that specifies the name of the box, a description, available
-  versions, available providers, and URLs to the actual box files
-  (next component) for each provider and version. If this catalog
-  metadata does not exist, a box file can still be added directly, but
-  it will not support versioning and updating.
-
-Each component is covered in more detail below.
-
-## Box File
-
-The actual box file is the required portion for Vagrant. It is recommended
-you always use a metadata file alongside a box file, but direct box files
-are supported for legacy reasons in Vagrant.
-
-Box files are compressed using `tar`, `tar.gz`, or `zip`. The contents of the
-archive can be anything, and is specific to each
-[provider](/docs/providers/). Vagrant core itself only unpacks
-the boxes for use later.
-
-Within the archive, Vagrant does expect a single file:
-`metadata.json`.  This is a JSON file that is completely unrelated to
-the above box catalog metadata component; there is only one
-`metadata.json` per box file (inside the box file), whereas one
-catalog metadata JSON document can describe multiple versions of the
-same box, potentially spanning multiple providers.
-
-`metadata.json` must contain at least the "provider" key with the
-provider the box is for. Vagrant uses this to verify the provider of
-the box. For example, if your box was for VirtualBox, the
-`metadata.json` would look like this:
-
-```json
-{
-  "provider": "virtualbox"
-}
-```
-
-If there is no `metadata.json` file or the file does not contain valid JSON
-with at least a "provider" key, then Vagrant will error when adding the box,
-because it cannot verify the provider.
-
-Other keys/values may be added to the metadata without issue. The value
-of the metadata file is passed opaquely into Vagrant and plugins can make
-use of it. At this point, Vagrant core does not use any other keys in this
-file.
-
-## Box Metadata
-
-The metadata is an optional component for a box (but highly recommended)
-that enables [versioning](/docs/boxes/versioning.html), updating, multiple
-providers from a single file, and more.
-
-<div class="alert alert-block alert-info">
-  <strong>You do not need to manually make the metadata.</strong> If you
-  have an account with <a href="/docs/other/atlas.html">HashiCorp's Atlas</a>, you
-  can create boxes there, and HashiCorp's Atlas automatically creates
-  the metadata for you. The format is still documented here.
-</div>
-
-It is a JSON document, structured in the following way:
-
-```json
-{
-  "name": "hashicorp/precise64",
-  "description": "This box contains Ubuntu 12.04 LTS 64-bit.",
-  "versions": [
-    {
-      "version": "0.1.0",
-      "providers": [
-        {
-          "name": "virtualbox",
-          "url": "http://somewhere.com/precise64_010_virtualbox.box",
-          "checksum_type": "sha1",
-          "checksum": "foo"
-        }
-      ]
-    }
-  ]
-}
-```
-
-As you can see, the JSON document can describe multiple versions of a box,
-multiple providers, and can add/remove providers in different versions.
-
-This JSON file can be passed directly to `vagrant box add` from the
-local filesystem using a file path or via a URL, and Vagrant will
-install the proper version of the box. In this case, the value for the
-`url` key in the JSON can also be a file path. If multiple providers
-are available, Vagrant will ask what provider you want to use.

data/vendor/bundle/ruby/2.3.0/bundler/gems/vagrant-5333e60e2d38/website/source/docs/boxes/versioning.html.md

@@ -1,107 +0,0 @@
----
-layout: "docs"
-page_title: "Box Versioning"
-sidebar_current: "boxes-versioning"
-description: |-
-  Since Vagrant 1.5, boxes support versioning. This allows the people who
-  make boxes to push updates to the box, and the people who use the box
-  have a simple workflow for checking for updates, updating their boxes,
-  and seeing what has changed.
----
-
-# Box Versioning
-
-Since Vagrant 1.5, boxes support versioning. This allows the people who
-make boxes to push updates to the box, and the people who use the box
-have a simple workflow for checking for updates, updating their boxes,
-and seeing what has changed.
-
-If you are just getting started with Vagrant, box versioning is not too
-important, and we recommend learning about some other topics first. But
-if you are using Vagrant on a team or plan on creating your own boxes,
-versioning is very important. Luckily, having versioning built right in
-to Vagrant makes it easy to use and fit nicely into the Vagrant workflow.
-
-This page will cover how to use versioned boxes. It does _not_ cover how
-to update your own custom boxes with versions. That is covered in
-[creating a base box](/docs/boxes/base.html).
-
-## Viewing Versions and Updating
-
-`vagrant box list` only shows _installed_ versions of boxes. If you want
-to see all available versions of a box, you will have to find the box
-on [HashiCorp's Atlas](/docs/other/atlas.html). An easy way to find a box
-is to use the url `https://atlas.hashicorp.com/$USER/$BOX`. For example, for
-the `hashicorp/precise64` box, you can find information about it at
-`https://atlas.hashicorp.com/hashicorp/precise64`.
-
-You can check if the box you are using is outdated with `vagrant box outdated`.
-This can check if the box in your current Vagrant environment is outdated
-as well as any other box installed on the system.
-
-Finally, you can update boxes with `vagrant box update`. This will download
-and install the new box. This _will not_ magically update running Vagrant
-environments. If a Vagrant environment is already running, you will have to
-destroy and recreate it to acquire the new updates in the box. The update
-command just downloads these updates locally.
-
-## Version Constraints
-
-You can constrain a Vagrant environment to a specific version or versions
-of a box using the [Vagrantfile](/docs/vagrantfile/) by specifying
-the `config.vm.box_version` option.
-
-If this option is not specified, the latest version is always used. This is
-equivalent to specifying a constraint of ">= 0".
-
-The box version configuration can be a specific version or a constraint of
-versions. Constraints can be any combination of the following:
-`= X`, `> X`, `< X`, `>= X`, `<= X`, `~> X`. You can combine multiple
-constraints by separating them with commas. All the constraints should be
-self explanatory except perhaps for `~>`, known as the "pessimistic constraint".
-Examples explain it best: `~> 1.0` is equivalent to `>= 1.0, < 2.0`. And
-`~> 1.1.5` is equivalent to `>= 1.1.5, < 1.2.0`.
-
-You can choose to handle versions however you see fit. However, many boxes
-in the public catalog follow [semantic versioning](http://semver.org/).
-Basically, only the first number (the "major version") breaks backwards
-compatibility. In terms of Vagrant boxes, this means that any software that
-runs in version "1.1.5" of a box should work in "1.2" and "1.4.5" and so on,
-but "2.0" might introduce big changes that break your software. By following
-this convention, the best constraint is `~> 1.0` because you know it is safe
-no matter what version is in that range.
-
-Please note that, while the semantic versioning specification allows for
-more than three points and pre-release or beta versions, Vagrant boxes must be
-of the format `X.Y.Z` where `X`, `Y`, and `Z` are all positive integers.
-
-## Automatic Update Checking
-
-Using the [Vagrantfile](/docs/vagrantfile/), you can also configure
-Vagrant to automatically check for updates during any `vagrant up`. This is
-enabled by default, but can easily be disabled with
-`config.vm.box_check_update = false` in your Vagrantfile.
-
-When this is enabled, Vagrant will check for updates on every `vagrant up`,
-not just when the machine is being created from scratch, but also when it
-is resuming, starting after being halted, etc.
-
-If an update is found, Vagrant will output a warning to the user letting
-them know an update is available. That user can choose to ignore the warning
-for now, or can update the box by running `vagrant box update`.
-
-Vagrant can not and does not automatically download the updated box and
-update the machine because boxes can be relatively large and updating the
-machine requires destroying it and recreating it, which can cause important
-data to be lost. Therefore, this process is manual to the extent that the
-user has to manually enter a command to do it.
-
-## Pruning Old Versions
-
-Vagrant does not automatically prune old versions because it does not know
-if they might be in use by other Vagrant environments. Because boxes can
-be large, you may want to actively prune them once in a while using
-`vagrant box remove`. You can see all the boxes that are installed
-using `vagrant box list`.
-
-Another option is to use `vagrant box prune` command to remove all installed boxes that are outdated and not currently in use.