tnargav 1.2.3 → 1.3.3

data/website/docs/source/v2/provisioning/index.html.md

@@ -0,0 +1,28 @@
+---
+page_title: "Provisioning"
+sidebar_current: "provisioning"
+---
+
+# Provisioning
+
+Provisioners in Vagrant allow you to automatically install software, alter configurations,
+and more on the machine as part of the `vagrant up` process.
+
+This is useful since [boxes](/v2/boxes.html) typically aren't
+built _perfectly_ for your use case. Of course, if you want to just use
+`vagrant ssh` and install the software by hand, that works. But by using
+the provisioning systems built-in to Vagrant, it automates the process so
+that it is repeatable. Most importantly, it requires no human interaction,
+so you can `vagrant destroy` and `vagrant up` and have a fully ready-to-go
+work environment with a single command. Powerful.
+
+Vagrant gives you multiple options for provisioning the machine, from
+simple shell scripts to more complex, industry-standard configuration
+management systems.
+
+If you've never used a configuration management system before, it is
+recommended you start with basic [shell scripts](/v2/provisioning/shell.html)
+for provisioning.
+
+You can find the full list of built-in provisioners and usage of these
+provisioners in the navigational area to the left.

data/website/docs/source/v2/provisioning/puppet_agent.html.md

@@ -0,0 +1,70 @@
+---
+page_title: "Puppet Agent - Provisioning"
+sidebar_current: "provisioning-puppetagent"
+---
+
+# Puppet Agent Provisioner
+
+**Provisioner name: `puppet_server`**
+
+The Puppet agent provisioner allows you to provision the guest using
+[Puppet](http://www.puppetlabs.com/puppet), specifically by
+calling `puppet agent`, connecting to a Puppet master, and retrieving
+the set of modules and manifests from there.
+
+<div class="alert alert-warn">
+	<p>
+		<strong>Warning:</strong> If you're not familiar with Puppet and Vagrant already,
+		I recommend starting with the <a href="/v2/provisioning/shell.html">shell
+		provisioner</a>. However, if you're comfortable with Vagrant already, Vagrant
+		is the best way to learn Puppet.
+	</p>
+</div>
+
+## Specifying the Puppet Master
+
+The quickest way to get started with the Puppet agent provisioner is to just
+specify the location of the Puppet master:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "puppet_server" do |puppet|
+    puppet.puppet_server = "puppet.example.com"
+  end
+end
+```
+
+By default, Vagrant will look for the host named "puppet" on the
+local domain of the guest machine.
+
+## Configuring the Node Name
+
+The node name that the agent registers as can be customized. Remember
+this is important because Puppet uses the node name as part of the process
+to compile the catalog the node will run.
+
+The node name defaults to the hostname of the guest machine, but can
+be customized using the Vagrantfile:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.provision "puppet_server" do |puppet|
+    puppet.puppet_node = "node.example.com"
+  end
+end
+```
+
+## Additional Options
+
+Puppet supports a lot of command-line flags. Basically any setting can
+be overriden 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_server" do |puppet|
+    puppet.options = "--verbose --debug"
+  end
+end
+```

data/website/docs/source/v2/provisioning/puppet_apply.html.md

@@ -0,0 +1,114 @@
+---
+page_title: "Puppet Apply - Provisioning"
+sidebar_current: "provisioning-puppetapply"
+---
+
+# Puppet Apply Provisioner
+
+**Provisioner name: `puppet`**
+
+The Puppet provisioner allows you to provision the guest using
+[Puppet](http://www.puppetlabs.com/puppet), specifically by
+calling `puppet apply`, without a Puppet Master.
+
+<div class="alert alert-warn">
+	<p>
+		<strong>Warning:</strong> If you're not familiar with Puppet and Vagrant already,
+		I recommend starting with the <a href="/v2/provisioning/shell.html">shell
+		provisioner</a>. However, if you're comfortable with Vagrant already, Vagrant
+		is the best way to learn Puppet.
+	</p>
+</div>
+
+## 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
+```
+
+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're able to put and name your manifests whatever you'd
+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.
+
+## Modules
+
+Vagrant also supports provisioning with [Puppet modules](http://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](http://puppetlabs.com/puppet/related-projects/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".
+
+## Additional Options
+
+Puppet supports a lot of command-line flags. Basically any setting can
+be overriden 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/website/docs/source/v2/provisioning/shell.html.md

@@ -0,0 +1,88 @@
+---
+page_title: "Shell Scripts - Provisioning"
+sidebar_current: "provisioning-shell"
+---
+
+# Shell Provisioner
+
+**Provisioner name: `"shell"`**
+
+The shell provisioner allows you to upload and execute a script as
+the root user 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 aren't
+comfortable with a full configuration management system such as Chef or
+Puppet.
+
+## 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 if you're not familiar with Ruby, the above may seem very
+advanced or foreign. But don't 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.
+
+## 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).
+
+## 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
+```

data/website/docs/source/v2/synced-folders/basic_usage.html.md

@@ -0,0 +1,53 @@
+---
+page_title: "Basic Usage - Synced Folders"
+sidebar_current: "syncedfolder-basic"
+---
+
+# Basic Usage
+
+## Configuration
+
+Synced folders are configured within your Vagrantfile using the
+`config.vm.synced_folder` method. Usage of the configuration directive
+is very simple:
+
+```ruby
+Vagrant.configure("2") do |config|
+  # other config here
+
+  config.vm.synced_folder "src/", "/srv/website"
+end
+```
+
+The first parameter is a path to a directory on the host machine. If
+the path is relative, it is relative to the project root. The second
+parameter must be an absolute path of where to share the folder within
+the guest machine. This folder will be created (recursively, if it must)
+if it doesn't exist.
+
+## Enabling
+
+Synced folders are automatically setup during `vagrant up` and
+`vagrant reload`.
+
+## Disabling
+
+Shared folders can be disabled by adding the `disabled` option to
+any definition:
+
+```ruby
+Vagrant.configure("2") do |config|
+  config.vm.synced_folder "src/", "/srv/website", disabled: true
+end
+```
+
+## Modifying the Owner/Group
+
+By default, Vagrant mounts the synced folders with the owner/group set
+to the SSH user. Sometimes it is preferable to mount folders with a different
+owner and group. It is possible to set these options:
+
+```ruby
+config.vm.synced_folder "src/", "/srv/website",
+  owner: "root", group: "root"
+```

data/website/docs/source/v2/synced-folders/index.html.md

@@ -0,0 +1,17 @@
+---
+page_title: "Synced Folders"
+sidebar_current: "syncedfolder"
+---
+
+# Synced Folders
+
+Synced folders enable Vagrant to sync a folder on the host machine to the
+guest machine, allowing you to continue working on your project's files
+on your host machine, but use the resources in the guest machine to
+compile or run your project.
+
+By default, Vagrant will share your project directory (the directory
+with the [Vagrantfile](/v2/vagrantfile/index.html)) to `/vagrant`.
+
+Read the [basic usage](/v2/synced-folders/basic_usage.html) page to get started
+with synced folders.

data/website/docs/source/v2/synced-folders/nfs.html.md

@@ -0,0 +1,53 @@
+---
+page_title: "NFS - Synced Folders"
+sidebar_current: "syncedfolder-nfs"
+---
+
+# NFS
+
+In some cases the default shared folder implementations (such as VirtualBox
+shared folders) have high performance penalties. If you're seeing less
+than ideal performance with synced folders, [NFS](http://en.wikipedia.org/wiki/Network_File_System_%28protocol%29)
+can offer a solution. Vagrant has built-in support to orchestrate the
+configuration of the NFS server on the host and guest for you.
+
+<div class="alert alert-info">
+	<p>
+		<strong>Windows users:</strong> NFS folders do not work on Windows
+		hosts. Vagrant will ignore your request for NFS synced folders on
+		Windows.
+	</p>
+</div>
+
+## Prerequisites
+
+Before using synced folders backed by NFS, the host machine must have
+`nfsd` installed, the NFS server daemon. This comes pre-installed on Mac
+OS X, and is typically a simple package install on Linux.
+
+Additionally, the guest machine must have NFS support installed. This is
+also usually a simple package installation away.
+
+## Root Privilege Requirement
+
+To configure NFS, Vagrant must modify system files on the host. Therefore,
+at some point during the `vagrant up` sequence, you may be prompted for
+administrative privileges (via the typical `sudo` program). These
+privileges are used to modify `/etc/exports` as well as to start and
+stop the NFS server daemon.
+
+
+## Enabling NFS Synced Folders
+
+To enable NFS, just add the `nfs: true` flag onto your synced folder:
+
+```ruby
+Vagrant.configure("2") do |config|
+  # ...
+
+  config.vm.synced_folder ".", "/vagrant", nfs: true
+end
+```
+
+If you add this to an existing Vagrantfile that has a running guest machine,
+be sure to `vagrant reload` to see your changes.

data/website/docs/source/v2/vagrantfile/index.html.md

@@ -0,0 +1,75 @@
+---
+page_title: "Vagrantfile"
+sidebar_current: "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 doesn't
+matter).
+
+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 isn't
+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. Built-in default Vagrantfile that ships with Vagrant. This has default
+  settings and should never be changed by any user of Vagrant.
+2. Vagrantfile packaged with the [box](/v2/boxes.html) that is to be used
+  for a given machine.
+3. Vagrantfile in your Vagrant home directory (defaults to `~/.vagrant.d`).
+  This lets you specify some defaults for your system user.
+4. Vagrantfile from the project directory. This is the Vagrantfile that you'll
+  be modifying most of the time.
+
+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.
+
+## Available Configuration Options
+
+You can learn more about the available configuration options by clicking
+the relevant section in the left navigational area.