` - Adds a 1, 5 or 10 second pause before
+ sending any additional keys. This is useful if you have to generally wait
+ for the UI to update before typing more.
In addition to the special keys, each command to type is treated as a
[configuration template](/docs/templates/configuration-templates.html). The
available variables are:
-- `HTTPIP` and `HTTPPort` - The IP and port, respectively of an HTTP server that
- is started serving the directory specified by the `http_directory`
- configuration parameter. If `http_directory` isn't specified, these will be
- blank!
+- `HTTPIP` and `HTTPPort` - The IP and port, respectively of an HTTP server
+ that is started serving the directory specified by the `http_directory`
+ configuration parameter. If `http_directory` isn't specified, these will be
+ blank!
Example boot command. This is actually a working boot command used to start an
Ubuntu 12.04 installer:
@@ -332,12 +336,12 @@ Within the template, a handful of variables are available so that your template
can continue working with the rest of the Packer machinery. Using these
variables isn't required, however.
-- `Name` - The name of the virtual machine.
-- `GuestOS` - The VMware-valid guest OS type.
-- `DiskName` - The filename (without the suffix) of the main virtual disk.
-- `ISOPath` - The path to the ISO to use for the OS installation.
-- `Version` - The Hardware version VMWare will execute this vm under. Also known
- as the `virtualhw.version`.
+- `Name` - The name of the virtual machine.
+- `GuestOS` - The VMware-valid guest OS type.
+- `DiskName` - The filename (without the suffix) of the main virtual disk.
+- `ISOPath` - The path to the ISO to use for the OS installation.
+- `Version` - The Hardware version VMWare will execute this vm under. Also
+ known as the `virtualhw.version`.
## Building on a Remote vSphere Hypervisor
@@ -367,23 +371,23 @@ connections.
To use a remote VMware vSphere Hypervisor to build your virtual machine, fill in
the required `remote_*` configurations:
-- `remote_type` - This must be set to "esx5".
+- `remote_type` - This must be set to "esx5".
-- `remote_host` - The host of the remote machine.
+- `remote_host` - The host of the remote machine.
Additionally, there are some optional configurations that you'll likely have to
modify as well:
-- `remote_datastore` - The path to the datastore where the VM will be stored on
- the ESXi machine.
+- `remote_datastore` - The path to the datastore where the VM will be stored
+ on the ESXi machine.
-- `remote_cache_datastore` - The path to the datastore where supporting files
- will be stored during the build on the remote machine.
+- `remote_cache_datastore` - The path to the datastore where supporting files
+ will be stored during the build on the remote machine.
-- `remote_cache_directory` - The path where the ISO and/or floppy files will be
- stored during the build on the remote machine. The path is relative to the
- `remote_cache_datastore` on the remote machine.
+- `remote_cache_directory` - The path where the ISO and/or floppy files will
+ be stored during the build on the remote machine. The path is relative to
+ the `remote_cache_datastore` on the remote machine.
-- `remote_username` - The SSH username used to access the remote machine.
+- `remote_username` - The SSH username used to access the remote machine.
-- `remote_password` - The SSH password for access to the remote machine.
+- `remote_password` - The SSH password for access to the remote machine.
diff --git a/website/source/docs/builders/vmware-vmx.html.markdown b/website/source/docs/builders/vmware-vmx.html.markdown
index bd1afb83c..da3a418b3 100644
--- a/website/source/docs/builders/vmware-vmx.html.markdown
+++ b/website/source/docs/builders/vmware-vmx.html.markdown
@@ -53,99 +53,100 @@ builder.
### Required:
-- `source_path` (string) - Path to the source VMX file to clone.
+- `source_path` (string) - Path to the source VMX file to clone.
-- `ssh_username` (string) - The username to use to SSH into the machine once the
- OS is installed.
+- `ssh_username` (string) - The username to use to SSH into the machine once
+ the OS is installed.
### Optional:
-- `boot_command` (array of strings) - This is an array of commands to type when
- the virtual machine is first booted. The goal of these commands should be to
- type just enough to initialize the operating system installer. Special keys
- can be typed as well, and are covered in the section below on the
- boot command. If this is not specified, it is assumed the installer will
- start itself.
+- `boot_command` (array of strings) - This is an array of commands to type
+ when the virtual machine is first booted. The goal of these commands should
+ be to type just enough to initialize the operating system installer. Special
+ keys can be typed as well, and are covered in the section below on the
+ boot command. If this is not specified, it is assumed the installer will
+ start itself.
-- `boot_wait` (string) - The time to wait after booting the initial virtual
- machine before typing the `boot_command`. The value of this should be
- a duration. Examples are "5s" and "1m30s" which will cause Packer to wait five
- seconds and one minute 30 seconds, respectively. If this isn't specified, the
- default is 10 seconds.
+- `boot_wait` (string) - The time to wait after booting the initial virtual
+ machine before typing the `boot_command`. The value of this should be
+ a duration. Examples are "5s" and "1m30s" which will cause Packer to wait
+ five seconds and one minute 30 seconds, respectively. If this isn't
+ specified, the default is 10 seconds.
-- `floppy_files` (array of strings) - A list of files to place onto a floppy
- disk that is attached when the VM is booted. This is most useful for
- unattended Windows installs, which look for an `Autounattend.xml` file on
- removable media. By default, no floppy will be attached. All files listed in
- this setting get placed into the root directory of the floppy and the floppy
- is attached as the first floppy device. Currently, no support exists for
- creating sub-directories on the floppy. Wildcard characters (\*, ?, and \[\])
- are allowed. Directory names are also allowed, which will add all the files
- found in the directory to the floppy.
+- `floppy_files` (array of strings) - A list of files to place onto a floppy
+ disk that is attached when the VM is booted. This is most useful for
+ unattended Windows installs, which look for an `Autounattend.xml` file on
+ removable media. By default, no floppy will be attached. All files listed in
+ this setting get placed into the root directory of the floppy and the floppy
+ is attached as the first floppy device. Currently, no support exists for
+ creating sub-directories on the floppy. Wildcard characters (\*, ?,
+ and \[\]) are allowed. Directory names are also allowed, which will add all
+ the files found in the directory to the floppy.
-- `fusion_app_path` (string) - Path to "VMware Fusion.app". By default this is
- "/Applications/VMware Fusion.app" but this setting allows you to
- customize this.
+- `fusion_app_path` (string) - Path to "VMware Fusion.app". By default this is
+ "/Applications/VMware Fusion.app" but this setting allows you to
+ customize this.
-- `headless` (boolean) - Packer defaults to building VMware virtual machines by
- launching a GUI that shows the console of the machine being built. When this
- value is set to true, the machine will start without a console. For VMware
- machines, Packer will output VNC connection information in case you need to
- connect to the console to debug the build process.
+- `headless` (boolean) - Packer defaults to building VMware virtual machines
+ by launching a GUI that shows the console of the machine being built. When
+ this value is set to true, the machine will start without a console. For
+ VMware machines, Packer will output VNC connection information in case you
+ need to connect to the console to debug the build process.
-- `http_directory` (string) - Path to a directory to serve using an HTTP server.
- The files in this directory will be available over HTTP that will be
- requestable from the virtual machine. This is useful for hosting kickstart
- files and so on. By default this is "", which means no HTTP server will
- be started. The address and port of the HTTP server will be available as
- variables in `boot_command`. This is covered in more detail below.
+- `http_directory` (string) - Path to a directory to serve using an
+ HTTP server. The files in this directory will be available over HTTP that
+ will be requestable from the virtual machine. This is useful for hosting
+ kickstart files and so on. By default this is "", which means no HTTP server
+ will be started. The address and port of the HTTP server will be available
+ as variables in `boot_command`. This is covered in more detail below.
-- `http_port_min` and `http_port_max` (integer) - These are the minimum and
- maximum port to use for the HTTP server started to serve the `http_directory`.
- Because Packer often runs in parallel, Packer will choose a randomly available
- port in this range to run the HTTP server. If you want to force the HTTP
- server to be on one port, make this minimum and maximum port the same. By
- default the values are 8000 and 9000, respectively.
+- `http_port_min` and `http_port_max` (integer) - These are the minimum and
+ maximum port to use for the HTTP server started to serve the
+ `http_directory`. Because Packer often runs in parallel, Packer will choose
+ a randomly available port in this range to run the HTTP server. If you want
+ to force the HTTP server to be on one port, make this minimum and maximum
+ port the same. By default the values are 8000 and 9000, respectively.
-- `output_directory` (string) - This is the path to the directory where the
- resulting virtual machine will be created. This may be relative or absolute.
- If relative, the path is relative to the working directory when `packer`
- is executed. This directory must not exist or be empty prior to running
- the builder. By default this is "output-BUILDNAME" where "BUILDNAME" is the
- name of the build.
+- `output_directory` (string) - This is the path to the directory where the
+ resulting virtual machine will be created. This may be relative or absolute.
+ If relative, the path is relative to the working directory when `packer`
+ is executed. This directory must not exist or be empty prior to running
+ the builder. By default this is "output-BUILDNAME" where "BUILDNAME" is the
+ name of the build.
-- `shutdown_command` (string) - The command to use to gracefully shut down the
- machine once all the provisioning is done. By default this is an empty string,
- which tells Packer to just forcefully shut down the machine unless a shutdown
- command takes place inside script so this may safely be omitted. If one or
- more scripts require a reboot it is suggested to leave this blank since
- reboots may fail and specify the final shutdown command in your last script.
+- `shutdown_command` (string) - The command to use to gracefully shut down the
+ machine once all the provisioning is done. By default this is an empty
+ string, which tells Packer to just forcefully shut down the machine unless a
+ shutdown command takes place inside script so this may safely be omitted. If
+ one or more scripts require a reboot it is suggested to leave this blank
+ since reboots may fail and specify the final shutdown command in your
+ last script.
-- `shutdown_timeout` (string) - The amount of time to wait after executing the
- `shutdown_command` for the virtual machine to actually shut down. If it
- doesn't shut down in this time, it is an error. By default, the timeout is
- "5m", or five minutes.
+- `shutdown_timeout` (string) - The amount of time to wait after executing the
+ `shutdown_command` for the virtual machine to actually shut down. If it
+ doesn't shut down in this time, it is an error. By default, the timeout is
+ "5m", or five minutes.
-- `skip_compaction` (boolean) - VMware-created disks are defragmented and
- compacted at the end of the build process using `vmware-vdiskmanager`. In
- certain rare cases, this might actually end up making the resulting disks
- slightly larger. If you find this to be the case, you can disable compaction
- using this configuration value.
+- `skip_compaction` (boolean) - VMware-created disks are defragmented and
+ compacted at the end of the build process using `vmware-vdiskmanager`. In
+ certain rare cases, this might actually end up making the resulting disks
+ slightly larger. If you find this to be the case, you can disable compaction
+ using this configuration value.
-- `vm_name` (string) - This is the name of the VMX file for the new virtual
- machine, without the file extension. By default this is "packer-BUILDNAME",
- where "BUILDNAME" is the name of the build.
+- `vm_name` (string) - This is the name of the VMX file for the new virtual
+ machine, without the file extension. By default this is "packer-BUILDNAME",
+ where "BUILDNAME" is the name of the build.
-- `vmx_data` (object of key/value strings) - Arbitrary key/values to enter into
- the virtual machine VMX file. This is for advanced users who want to set
- properties such as memory, CPU, etc.
+- `vmx_data` (object of key/value strings) - Arbitrary key/values to enter
+ into the virtual machine VMX file. This is for advanced users who want to
+ set properties such as memory, CPU, etc.
-- `vmx_data_post` (object of key/value strings) - Identical to `vmx_data`,
- except that it is run after the virtual machine is shutdown, and before the
- virtual machine is exported.
+- `vmx_data_post` (object of key/value strings) - Identical to `vmx_data`,
+ except that it is run after the virtual machine is shutdown, and before the
+ virtual machine is exported.
-- `vnc_port_min` and `vnc_port_max` (integer) - The minimum and maximum port to
- use for VNC access to the virtual machine. The builder uses VNC to type the
- initial `boot_command`. Because Packer generally runs in parallel, Packer uses
- a randomly chosen port in this range that appears available. By default this
- is 5900 to 6000. The minimum and maximum ports are inclusive.
+- `vnc_port_min` and `vnc_port_max` (integer) - The minimum and maximum port
+ to use for VNC access to the virtual machine. The builder uses VNC to type
+ the initial `boot_command`. Because Packer generally runs in parallel,
+ Packer uses a randomly chosen port in this range that appears available. By
+ default this is 5900 to 6000. The minimum and maximum ports are inclusive.
diff --git a/website/source/docs/builders/vmware.html.markdown b/website/source/docs/builders/vmware.html.markdown
index e77fe574a..e8486ca4c 100644
--- a/website/source/docs/builders/vmware.html.markdown
+++ b/website/source/docs/builders/vmware.html.markdown
@@ -15,14 +15,14 @@ Packer actually comes with multiple builders able to create VMware machines,
depending on the strategy you want to use to build the image. Packer supports
the following VMware builders:
-- [vmware-iso](/docs/builders/vmware-iso.html) - Starts from an ISO file,
- creates a brand new VMware VM, installs an OS, provisions software within the
- OS, then exports that machine to create an image. This is best for people who
- want to start from scratch.
+- [vmware-iso](/docs/builders/vmware-iso.html) - Starts from an ISO file,
+ creates a brand new VMware VM, installs an OS, provisions software within
+ the OS, then exports that machine to create an image. This is best for
+ people who want to start from scratch.
-- [vmware-vmx](/docs/builders/vmware-vmx.html) - This builder imports an
- existing VMware machine (from a VMX file), runs provisioners on top of that
- VM, and exports that machine to create an image. This is best if you have an
- existing VMware VM you want to use as the source. As an additional benefit,
- you can feed the artifact of this builder back into Packer to iterate on
- a machine.
+- [vmware-vmx](/docs/builders/vmware-vmx.html) - This builder imports an
+ existing VMware machine (from a VMX file), runs provisioners on top of that
+ VM, and exports that machine to create an image. This is best if you have an
+ existing VMware VM you want to use as the source. As an additional benefit,
+ you can feed the artifact of this builder back into Packer to iterate on
+ a machine.
diff --git a/website/source/docs/command-line/build.html.markdown b/website/source/docs/command-line/build.html.markdown
index 92afda570..ba4421293 100644
--- a/website/source/docs/command-line/build.html.markdown
+++ b/website/source/docs/command-line/build.html.markdown
@@ -17,24 +17,26 @@ artifacts that are created will be outputted at the end of the build.
## Options
-- `-color=false` - Disables colorized output. Enabled by default.
+- `-color=false` - Disables colorized output. Enabled by default.
-- `-debug` - Disables parallelization and enables debug mode. Debug mode flags
- the builders that they should output debugging information. The exact behavior
- of debug mode is left to the builder. In general, builders usually will stop
- between each step, waiting for keyboard input before continuing. This will
- allow the user to inspect state and so on.
+- `-debug` - Disables parallelization and enables debug mode. Debug mode flags
+ the builders that they should output debugging information. The exact
+ behavior of debug mode is left to the builder. In general, builders usually
+ will stop between each step, waiting for keyboard input before continuing.
+ This will allow the user to inspect state and so on.
-- `-except=foo,bar,baz` - Builds all the builds except those with the given
- comma-separated names. Build names by default are the names of their builders,
- unless a specific `name` attribute is specified within the configuration.
+- `-except=foo,bar,baz` - Builds all the builds except those with the given
+ comma-separated names. Build names by default are the names of their
+ builders, unless a specific `name` attribute is specified within
+ the configuration.
-- `-force` - Forces a builder to run when artifacts from a previous build
- prevent a build from running. The exact behavior of a forced build is left to
- the builder. In general, a builder supporting the forced build will remove the
- artifacts from the previous build. This will allow the user to repeat a build
- without having to manually clean these artifacts beforehand.
+- `-force` - Forces a builder to run when artifacts from a previous build
+ prevent a build from running. The exact behavior of a forced build is left
+ to the builder. In general, a builder supporting the forced build will
+ remove the artifacts from the previous build. This will allow the user to
+ repeat a build without having to manually clean these artifacts beforehand.
-- `-only=foo,bar,baz` - Only build the builds with the given
- comma-separated names. Build names by default are the names of their builders,
- unless a specific `name` attribute is specified within the configuration.
+- `-only=foo,bar,baz` - Only build the builds with the given
+ comma-separated names. Build names by default are the names of their
+ builders, unless a specific `name` attribute is specified within
+ the configuration.
diff --git a/website/source/docs/command-line/fix.html.markdown b/website/source/docs/command-line/fix.html.markdown
index eb383fec6..ec18b69bc 100644
--- a/website/source/docs/command-line/fix.html.markdown
+++ b/website/source/docs/command-line/fix.html.markdown
@@ -19,7 +19,7 @@ The fix command will output the changed template to standard out, so you should
redirect standard using standard OS-specific techniques if you want to save it
to a file. For example, on Linux systems, you may want to do this:
- $ packer fix old.json > new.json
+\$ packer fix old.json > new.json
If fixing fails for any reason, the fix command will exit with a non-zero exit
status. Error messages appear on standard error, so if you're redirecting
diff --git a/website/source/docs/command-line/machine-readable.html.markdown b/website/source/docs/command-line/machine-readable.html.markdown
index 550a14f35..fa9fe3cac 100644
--- a/website/source/docs/command-line/machine-readable.html.markdown
+++ b/website/source/docs/command-line/machine-readable.html.markdown
@@ -53,20 +53,22 @@ timestamp,target,type,data...
Each component is explained below:
-- **timestamp** is a Unix timestamp in UTC of when the message was printed.
+- **timestamp** is a Unix timestamp in UTC of when the message was printed.
-- **target** is the target of the following output. This is empty if the message
- is related to Packer globally. Otherwise, this is generally a build name so
- you can relate output to a specific build while parallel builds are running.
+- **target** is the target of the following output. This is empty if the
+ message is related to Packer globally. Otherwise, this is generally a build
+ name so you can relate output to a specific build while parallel builds
+ are running.
-- **type** is the type of machine-readable message being outputted. There are a
- set of standard types which are covered later, but each component of Packer
- (builders, provisioners, etc.) may output their own custom types as well,
- allowing the machine-readable output to be infinitely flexible.
+- **type** is the type of machine-readable message being outputted. There are
+ a set of standard types which are covered later, but each component of
+ Packer (builders, provisioners, etc.) may output their own custom types as
+ well, allowing the machine-readable output to be infinitely flexible.
-- **data** is zero or more comma-seperated values associated with the
- prior type. The exact amount and meaning of this data is type-dependent, so
- you must read the documentation associated with the type to understand fully.
+- **data** is zero or more comma-seperated values associated with the
+ prior type. The exact amount and meaning of this data is type-dependent, so
+ you must read the documentation associated with the type to
+ understand fully.
Within the format, if data contains a comma, it is replaced with
`%!(PACKER_COMMA)`. This was preferred over an escape character such as `\'`
diff --git a/website/source/docs/command-line/push.html.markdown b/website/source/docs/command-line/push.html.markdown
index 0cc9699f5..764333967 100644
--- a/website/source/docs/command-line/push.html.markdown
+++ b/website/source/docs/command-line/push.html.markdown
@@ -26,16 +26,16 @@ configuration](/docs/templates/push.html) must be completed within the template.
## Options
-- `-message` - A message to identify the purpose or changes in this Packer
- template much like a VCS commit message. This message will be passed to the
- Packer build service. This option is also available as a short option `-m`.
+- `-message` - A message to identify the purpose or changes in this Packer
+ template much like a VCS commit message. This message will be passed to the
+ Packer build service. This option is also available as a short option `-m`.
-- `-token` - An access token for authenticating the push to the Packer build
- service such as Atlas. This can also be specified within the push
- configuration in the template.
+- `-token` - An access token for authenticating the push to the Packer build
+ service such as Atlas. This can also be specified within the push
+ configuration in the template.
-- `-name` - The name of the build in the service. This typically looks like
- `hashicorp/precise64`.
+- `-name` - The name of the build in the service. This typically looks like
+ `hashicorp/precise64`.
## Examples
diff --git a/website/source/docs/command-line/validate.html.markdown b/website/source/docs/command-line/validate.html.markdown
index e17f23dc4..c49e6587d 100644
--- a/website/source/docs/command-line/validate.html.markdown
+++ b/website/source/docs/command-line/validate.html.markdown
@@ -29,5 +29,5 @@ Errors validating build 'vmware'. 1 error(s) occurred:
## Options
-- `-syntax-only` - Only the syntax of the template is checked. The configuration
- is not validated.
+- `-syntax-only` - Only the syntax of the template is checked. The
+ configuration is not validated.
diff --git a/website/source/docs/extend/developing-plugins.html.markdown b/website/source/docs/extend/developing-plugins.html.markdown
index 0d86df3d2..8af8a241d 100644
--- a/website/source/docs/extend/developing-plugins.html.markdown
+++ b/website/source/docs/extend/developing-plugins.html.markdown
@@ -52,19 +52,19 @@ the following two packages, you're encouraged to use whatever packages you want.
Because plugins are their own processes, there is no danger of colliding
dependencies.
-- `github.com/mitchellh/packer` - Contains all the interfaces that you have to
- implement for any given plugin.
+- `github.com/mitchellh/packer` - Contains all the interfaces that you have to
+ implement for any given plugin.
-- `github.com/mitchellh/packer/plugin` - Contains the code to serve the plugin.
- This handles all the inter-process communication stuff.
+- `github.com/mitchellh/packer/plugin` - Contains the code to serve
+ the plugin. This handles all the inter-process communication stuff.
There are two steps involved in creating a plugin:
-1. Implement the desired interface. For example, if you're building a builder
- plugin, implement the `packer.Builder` interface.
+1. Implement the desired interface. For example, if you're building a builder
+ plugin, implement the `packer.Builder` interface.
-2. Serve the interface by calling the appropriate plugin serving method in your
- main method. In the case of a builder, this is `plugin.ServeBuilder`.
+2. Serve the interface by calling the appropriate plugin serving method in your
+ main method. In the case of a builder, this is `plugin.ServeBuilder`.
A basic example is shown below. In this example, assume the `Builder` struct
implements the `packer.Builder` interface:
diff --git a/website/source/docs/extend/plugins.html.markdown b/website/source/docs/extend/plugins.html.markdown
index 98249de5d..9f18ca138 100644
--- a/website/source/docs/extend/plugins.html.markdown
+++ b/website/source/docs/extend/plugins.html.markdown
@@ -51,21 +51,21 @@ Once the plugin is named properly, Packer automatically discovers plugins in the
following directories in the given order. If a conflicting plugin is found
later, it will take precedence over one found earlier.
-1. The directory where `packer` is, or the executable directory.
+1. The directory where `packer` is, or the executable directory.
-2. `~/.packer.d/plugins` on Unix systems or `%APPDATA%/packer.d/plugins`
- on Windows.
+2. `~/.packer.d/plugins` on Unix systems or `%APPDATA%/packer.d/plugins`
+ on Windows.
-3. The current working directory.
+3. The current working directory.
The valid types for plugins are:
-- `builder` - Plugins responsible for building images for a specific platform.
+- `builder` - Plugins responsible for building images for a specific platform.
-- `command` - A CLI sub-command for `packer`.
+- `command` - A CLI sub-command for `packer`.
-- `post-processor` - A post-processor responsible for taking an artifact from a
- builder and turning it into something else.
+- `post-processor` - A post-processor responsible for taking an artifact from
+ a builder and turning it into something else.
-- `provisioner` - A provisioner to install software on images created by
- a builder.
+- `provisioner` - A provisioner to install software on images created by
+ a builder.
diff --git a/website/source/docs/extend/post-processor.html.markdown b/website/source/docs/extend/post-processor.html.markdown
index 1120bc31d..9067e19d8 100644
--- a/website/source/docs/extend/post-processor.html.markdown
+++ b/website/source/docs/extend/post-processor.html.markdown
@@ -79,11 +79,11 @@ creating a new artifact with a single file: the compressed archive.
The result signature of this method is `(Artifact, bool, error)`. Each return
value is explained below:
-- `Artifact` - The newly created artifact if no errors occurred.
-- `bool` - If true, the input artifact will forcefully be kept. By default,
- Packer typically deletes all input artifacts, since the user doesn't generally
- want intermediary artifacts. However, some post-processors depend on the
- previous artifact existing. If this is `true`, it forces packer to keep the
- artifact around.
-- `error` - Non-nil if there was an error in any way. If this is the case, the
- other two return values are ignored.
+- `Artifact` - The newly created artifact if no errors occurred.
+- `bool` - If true, the input artifact will forcefully be kept. By default,
+ Packer typically deletes all input artifacts, since the user doesn't
+ generally want intermediary artifacts. However, some post-processors depend
+ on the previous artifact existing. If this is `true`, it forces packer to
+ keep the artifact around.
+- `error` - Non-nil if there was an error in any way. If this is the case, the
+ other two return values are ignored.
diff --git a/website/source/docs/machine-readable/command-build.html.markdown b/website/source/docs/machine-readable/command-build.html.markdown
index 7472b7bfc..7b7b27993 100644
--- a/website/source/docs/machine-readable/command-build.html.markdown
+++ b/website/source/docs/machine-readable/command-build.html.markdown
@@ -12,8 +12,10 @@ These are the machine-readable types that exist as part of the output of
`packer build`.
- - artifact (>= 2)
- -
+
-
+artifact (>= 2)
+
+-
Information about an artifact of the targeted item. This is a
fairly complex (but uniform!) machine-readable type that contains
@@ -37,10 +39,12 @@ These are the machine-readable types that exist as part of the output of
data points related to the subtype. The exact count and meaning
of this subtypes comes from the subtype documentation.
-
- - artifact-count (1)
- -
+
+-
+artifact-count (1)
+
+-
The number of artifacts associated with the given target. This
will always be outputted _before_ any other artifact information,
@@ -51,10 +55,12 @@ These are the machine-readable types that exist as part of the output of
Data 1: count - The number of artifacts as
a base 10 integer.
-
- - artifact subtype: builder-id (1)
- -
+
+-
+artifact subtype: builder-id (1)
+
+-
The unique ID of the builder that created this artifact.
@@ -62,19 +68,23 @@ These are the machine-readable types that exist as part of the output of
Data 1: id - The unique ID of the builder.
-
- - artifact subtype: end (0)
- -
+
+-
+artifact subtype: end (0)
+
+-
The last machine-readable output line outputted for an artifact.
This is a sentinel value so you know that no more data related to
the targetted artifact will be outputted.
-
- - artifact subtype: file (2)
- -
+
+-
+artifact subtype: file (2)
+
+-
A single file associated with the artifact. There are 0 to
"files-count" of these entries to describe every file that is
@@ -89,10 +99,12 @@ These are the machine-readable types that exist as part of the output of
Data 2: filename - The filename.
-
- - artifact subtype: files-count (1)
- -
+
+-
+artifact subtype: files-count (1)
+
+-
The number of files associated with this artifact. Not all
artifacts have files associated with it.
@@ -101,10 +113,12 @@ These are the machine-readable types that exist as part of the output of
Data 1: count - The number of files.
-
- - artifact subtype: id (1)
- -
+
+-
+artifact subtype: id (1)
+
+-
The ID (if any) of the artifact that was built. Not all artifacts
have associated IDs. For example, AMIs built have IDs associated
@@ -115,18 +129,22 @@ These are the machine-readable types that exist as part of the output of
Data 1: id - The ID of the artifact.
-
- - artifact subtype: nil (0)
- -
+
+-
+artifact subtype: nil (0)
+
+-
If present, this means that the artifact was nil, or that the targeted
build completed successfully but no artifact was created.
-
- - artifact subtype: string (1)
- -
+
+-
+artifact subtype: string (1)
+
+-
The human-readable string description of the artifact provided by
the artifact itself.
@@ -135,10 +153,12 @@ These are the machine-readable types that exist as part of the output of
Data 1: string - The string output for the artifact.
-
- - error-count (1)
- -
+
+-
+error-count (1)
+
+-
The number of errors that occurred during the build. This will
always be outputted before any errors so you know how many are coming.
@@ -148,10 +168,12 @@ These are the machine-readable types that exist as part of the output of
Data 1: count - The number of build errors as
a base 10 integer.
-
- - error (1)
- -
+
+-
+error (1)
+
+-
A build error that occurred. The target of this output will be
the build that had the error.
@@ -160,6 +182,6 @@ These are the machine-readable types that exist as part of the output of
Data 1: error - The error message as a string.
-
+
diff --git a/website/source/docs/machine-readable/command-inspect.html.markdown b/website/source/docs/machine-readable/command-inspect.html.markdown
index 4a5d68876..a75b892f3 100644
--- a/website/source/docs/machine-readable/command-inspect.html.markdown
+++ b/website/source/docs/machine-readable/command-inspect.html.markdown
@@ -12,8 +12,10 @@ These are the machine-readable types that exist as part of the output of
`packer inspect`.
- - template-variable (3)
- -
+
-
+template-variable (3)
+
+-
A user variable
defined within the template.
@@ -32,10 +34,12 @@ These are the machine-readable types that exist as part of the output of
Data 3: required - If non-zero, then this variable
is required.
-
- - template-builder (2)
- -
+
+-
+template-builder (2)
+
+-
A builder defined within the template
@@ -48,10 +52,12 @@ These are the machine-readable types that exist as part of the output of
generally be the same as the name unless you explicitly override
the name.
-
- - template-provisioner (1)
- -
+
+-
+template-provisioner (1)
+
+-
A provisioner defined within the template. Multiple of these may
exist. If so, they are outputted in the order they would run.
@@ -60,6 +66,6 @@ These are the machine-readable types that exist as part of the output of
Data 1: name - The name/type of the provisioner.
-
+
diff --git a/website/source/docs/machine-readable/command-version.html.markdown b/website/source/docs/machine-readable/command-version.html.markdown
index 8b32b2540..4d7be6d23 100644
--- a/website/source/docs/machine-readable/command-version.html.markdown
+++ b/website/source/docs/machine-readable/command-version.html.markdown
@@ -12,8 +12,10 @@ These are the machine-readable types that exist as part of the output of
`packer version`.
- - version (1)
- -
+
-
+version (1)
+
+-
The version number of Packer running.
@@ -21,19 +23,23 @@ These are the machine-readable types that exist as part of the output of
only including the major, minor, and patch versions. Example:
"0.2.4".
-
- - version-commit (1)
- -
+
+-
+version-commit (1)
+
+-
The SHA1 of the Git commit that built this version of Packer.
Data 1: commit SHA1 - The SHA1 of the commit.
-
- - version-prerelease (1)
- -
+
+-
+version-prerelease (1)
+
+-
The prerelease tag (if any) for the running version of Packer. This
can be "beta", "dev", "alpha", etc. If this is empty, you can assume
@@ -44,6 +50,6 @@ These are the machine-readable types that exist as part of the output of
Data 1: prerelease name - The name of the
prerelease tag.
-
+
diff --git a/website/source/docs/machine-readable/general.html.markdown b/website/source/docs/machine-readable/general.html.markdown
index b29ae053f..721406d7a 100644
--- a/website/source/docs/machine-readable/general.html.markdown
+++ b/website/source/docs/machine-readable/general.html.markdown
@@ -12,8 +12,10 @@ These are the machine-readable types that can appear in almost any
machine-readable output and are provided by Packer core itself.
- - ui (2)
- -
+
-
+ui (2)
+
+-
Specifies the output and type of output that would've normally
gone to the console if Packer were running in human-readable
@@ -28,6 +30,6 @@ machine-readable output and are provided by Packer core itself.
Data 2: output - The UI message that would have
been outputted.
-
+
diff --git a/website/source/docs/machine-readable/index.html.markdown b/website/source/docs/machine-readable/index.html.markdown
index 161bda001..cde344947 100644
--- a/website/source/docs/machine-readable/index.html.markdown
+++ b/website/source/docs/machine-readable/index.html.markdown
@@ -24,12 +24,14 @@ Within each section, the format of the documentation is the following:
- - type-name (data-count)
- -
+
-
+type-name (data-count)
+
+-
Description of the type.
Data 1: name - Description.
-
+
diff --git a/website/source/docs/other/core-configuration.html.markdown b/website/source/docs/other/core-configuration.html.markdown
index db1f75ab7..a112801e8 100644
--- a/website/source/docs/other/core-configuration.html.markdown
+++ b/website/source/docs/other/core-configuration.html.markdown
@@ -32,13 +32,13 @@ The format of the configuration file is basic JSON.
Below is the list of all available configuration parameters for the core
configuration file. None of these are required, since all have sane defaults.
-- `plugin_min_port` and `plugin_max_port` (integer) - These are the minimum and
- maximum ports that Packer uses for communication with plugins, since plugin
- communication happens over TCP connections on your local host. By default
- these are 10,000 and 25,000, respectively. Be sure to set a fairly wide range
- here, since Packer can easily use over 25 ports on a single run.
+- `plugin_min_port` and `plugin_max_port` (integer) - These are the minimum
+ and maximum ports that Packer uses for communication with plugins, since
+ plugin communication happens over TCP connections on your local host. By
+ default these are 10,000 and 25,000, respectively. Be sure to set a fairly
+ wide range here, since Packer can easily use over 25 ports on a single run.
-- `builders`, `commands`, `post-processors`, and `provisioners` are objects that
- are used to install plugins. The details of how exactly these are set is
- covered in more detail in the [installing plugins documentation
- page](/docs/extend/plugins.html).
+- `builders`, `commands`, `post-processors`, and `provisioners` are objects
+ that are used to install plugins. The details of how exactly these are set
+ is covered in more detail in the [installing plugins documentation
+ page](/docs/extend/plugins.html).
diff --git a/website/source/docs/other/environmental-variables.html.markdown b/website/source/docs/other/environmental-variables.html.markdown
index 7d455c708..8827ea5d9 100644
--- a/website/source/docs/other/environmental-variables.html.markdown
+++ b/website/source/docs/other/environmental-variables.html.markdown
@@ -9,28 +9,28 @@ page_title: Environmental Variables for Packer
Packer uses a variety of environmental variables. A listing and description of
each can be found below:
-- `PACKER_CACHE_DIR` - The location of the packer cache.
+- `PACKER_CACHE_DIR` - The location of the packer cache.
-- `PACKER_CONFIG` - The location of the core configuration file. The format of
- the configuration file is basic JSON. See the [core configuration
- page](/docs/other/core-configuration.html).
+- `PACKER_CONFIG` - The location of the core configuration file. The format of
+ the configuration file is basic JSON. See the [core configuration
+ page](/docs/other/core-configuration.html).
-- `PACKER_LOG` - Setting this to any value will enable the logger. See the
- [debugging page](/docs/other/debugging.html).
+- `PACKER_LOG` - Setting this to any value will enable the logger. See the
+ [debugging page](/docs/other/debugging.html).
-- `PACKER_LOG_PATH` - The location of the log file. Note: `PACKER_LOG` must be
- set for any logging to occur. See the [debugging
- page](/docs/other/debugging.html).
+- `PACKER_LOG_PATH` - The location of the log file. Note: `PACKER_LOG` must be
+ set for any logging to occur. See the [debugging
+ page](/docs/other/debugging.html).
-- `PACKER_NO_COLOR` - Setting this to any value will disable color in
- the terminal.
+- `PACKER_NO_COLOR` - Setting this to any value will disable color in
+ the terminal.
-- `PACKER_PLUGIN_MAX_PORT` - The maximum port that Packer uses for communication
- with plugins, since plugin communication happens over TCP connections on your
- local host. The default is 25,000. See the [core configuration
- page](/docs/other/core-configuration.html).
+- `PACKER_PLUGIN_MAX_PORT` - The maximum port that Packer uses for
+ communication with plugins, since plugin communication happens over TCP
+ connections on your local host. The default is 25,000. See the [core
+ configuration page](/docs/other/core-configuration.html).
-- `PACKER_PLUGIN_MIN_PORT` - The minimum port that Packer uses for communication
- with plugins, since plugin communication happens over TCP connections on your
- local host. The default is 10,000. See the [core configuration
- page](/docs/other/core-configuration.html).
+- `PACKER_PLUGIN_MIN_PORT` - The minimum port that Packer uses for
+ communication with plugins, since plugin communication happens over TCP
+ connections on your local host. The default is 10,000. See the [core
+ configuration page](/docs/other/core-configuration.html).
diff --git a/website/source/docs/post-processors/atlas.html.markdown b/website/source/docs/post-processors/atlas.html.markdown
index 18211c313..4f2cb3640 100644
--- a/website/source/docs/post-processors/atlas.html.markdown
+++ b/website/source/docs/post-processors/atlas.html.markdown
@@ -25,14 +25,14 @@ location in Atlas.
Here is an example workflow:
-1. Packer builds an AMI with the [Amazon AMI
- builder](/docs/builders/amazon.html)
-2. The `atlas` post-processor takes the resulting AMI and uploads it to Atlas.
- The `atlas` post-processor is configured with the name of the AMI, for example
- `hashicorp/foobar`, to create the artifact in Atlas or update the version if
- the artifact already exists
-3. The new version is ready and available to be used in deployments with a tool
- like [Terraform](https://terraform.io)
+1. Packer builds an AMI with the [Amazon AMI
+ builder](/docs/builders/amazon.html)
+2. The `atlas` post-processor takes the resulting AMI and uploads it to Atlas.
+ The `atlas` post-processor is configured with the name of the AMI, for
+ example `hashicorp/foobar`, to create the artifact in Atlas or update the
+ version if the artifact already exists
+3. The new version is ready and available to be used in deployments with a tool
+ like [Terraform](https://terraform.io)
## Configuration
@@ -40,32 +40,33 @@ The configuration allows you to specify and access the artifact in Atlas.
### Required:
-- `token` (string) - Your access token for the Atlas API. This can be generated
- on your [tokens page](https://atlas.hashicorp.com/settings/tokens).
- Alternatively you can export your Atlas token as an environmental variable and
- remove it from the configuration.
+- `token` (string) - Your access token for the Atlas API. This can be
+ generated on your [tokens
+ page](https://atlas.hashicorp.com/settings/tokens). Alternatively you can
+ export your Atlas token as an environmental variable and remove it from
+ the configuration.
-- `artifact` (string) - The shorthand tag for your artifact that maps to Atlas,
- i.e `hashicorp/foobar` for `atlas.hashicorp.com/hashicorp/foobar`. You must
- have access to the organization, hashicorp in this example, in order to add an
- artifact to the organization in Atlas.
+- `artifact` (string) - The shorthand tag for your artifact that maps to
+ Atlas, i.e `hashicorp/foobar` for `atlas.hashicorp.com/hashicorp/foobar`.
+ You must have access to the organization, hashicorp in this example, in
+ order to add an artifact to the organization in Atlas.
-- `artifact_type` (string) - For uploading AMIs to Atlas, `artifact_type` will
- always be `amazon.ami`. This field must be defined because Atlas can host
- other artifact types, such as Vagrant boxes.
+- `artifact_type` (string) - For uploading AMIs to Atlas, `artifact_type` will
+ always be `amazon.ami`. This field must be defined because Atlas can host
+ other artifact types, such as Vagrant boxes.
-> **Note:** If you want to upload Vagrant boxes to Atlas, use the [Atlas
post-processor](/docs/post-processors/atlas.html).
### Optional:
-- `atlas_url` (string) - Override the base URL for Atlas. This is useful if
- you're using Atlas Enterprise in your own network. Defaults to
- `https://atlas.hashicorp.com/api/v1`.
+- `atlas_url` (string) - Override the base URL for Atlas. This is useful if
+ you're using Atlas Enterprise in your own network. Defaults to
+ `https://atlas.hashicorp.com/api/v1`.
-- `metadata` (map) - Send metadata about the artifact. If the artifact type is
- "vagrant.box", you must specify a "provider" metadata about what provider
- to use.
+- `metadata` (map) - Send metadata about the artifact. If the artifact type is
+ "vagrant.box", you must specify a "provider" metadata about what provider
+ to use.
### Example Configuration
diff --git a/website/source/docs/post-processors/compress.html.markdown b/website/source/docs/post-processors/compress.html.markdown
index 716e4e866..ad78a9315 100644
--- a/website/source/docs/post-processors/compress.html.markdown
+++ b/website/source/docs/post-processors/compress.html.markdown
@@ -20,25 +20,25 @@ VMware or VirtualBox) and compresses the artifact into a single archive.
You must specify the output filename. The archive format is derived from the
filename.
-- `output` (string) - The path to save the compressed archive. The archive
- format is inferred from the filename. E.g. `.tar.gz` will be a
- gzipped tarball. `.zip` will be a zip file. If the extension can't be detected
- packer defaults to `.tar.gz` behavior but will not change the filename.
+- `output` (string) - The path to save the compressed archive. The archive
+ format is inferred from the filename. E.g. `.tar.gz` will be a
+ gzipped tarball. `.zip` will be a zip file. If the extension can't be
+ detected packer defaults to `.tar.gz` behavior but will not change
+ the filename.
- If you are executing multiple builders in parallel you should make sure
- `output` is unique for each one. For example
- `packer_{{.BuildName}}_{{.Provider}}.zip`.
+If you are executing multiple builders in parallel you should make sure `output`
+is unique for each one. For example `packer_{{.BuildName}}_{{.Provider}}.zip`.
### Optional:
If you want more control over how the archive is created you can specify the
following settings:
-- `compression_level` (integer) - Specify the compression level, for algorithms
- that support it, from 1 through 9 inclusive. Typically higher compression
- levels take longer but produce smaller files. Defaults to `6`
+- `compression_level` (integer) - Specify the compression level, for
+ algorithms that support it, from 1 through 9 inclusive. Typically higher
+ compression levels take longer but produce smaller files. Defaults to `6`
-- `keep_input_artifact` (boolean) - Keep source files; defaults to `false`
+- `keep_input_artifact` (boolean) - Keep source files; defaults to `false`
### Supported Formats
diff --git a/website/source/docs/post-processors/docker-import.html.markdown b/website/source/docs/post-processors/docker-import.html.markdown
index 0c3855622..968705f4b 100644
--- a/website/source/docs/post-processors/docker-import.html.markdown
+++ b/website/source/docs/post-processors/docker-import.html.markdown
@@ -24,9 +24,9 @@ registry.
The configuration for this post-processor is extremely simple. At least a
repository is required.
-- `repository` (string) - The repository of the imported image.
+- `repository` (string) - The repository of the imported image.
-- `tag` (string) - The tag for the imported image. By default this is not set.
+- `tag` (string) - The tag for the imported image. By default this is not set.
## Example
diff --git a/website/source/docs/post-processors/docker-push.html.markdown b/website/source/docs/post-processors/docker-push.html.markdown
index 72793b735..9657e27b7 100644
--- a/website/source/docs/post-processors/docker-push.html.markdown
+++ b/website/source/docs/post-processors/docker-push.html.markdown
@@ -18,16 +18,16 @@ pushes it to a Docker registry.
This post-processor has only optional configuration:
-- `login` (boolean) - Defaults to false. If true, the post-processor will login
- prior to pushing.
+- `login` (boolean) - Defaults to false. If true, the post-processor will
+ login prior to pushing.
-- `login_email` (string) - The email to use to authenticate to login.
+- `login_email` (string) - The email to use to authenticate to login.
-- `login_username` (string) - The username to use to authenticate to login.
+- `login_username` (string) - The username to use to authenticate to login.
-- `login_password` (string) - The password to use to authenticate to login.
+- `login_password` (string) - The password to use to authenticate to login.
-- `login_server` (string) - The server address to login to.
+- `login_server` (string) - The server address to login to.
-> **Note:** If you login using the credentials above, the post-processor
will automatically log you out afterwards (just the server specified).
diff --git a/website/source/docs/post-processors/docker-save.html.markdown b/website/source/docs/post-processors/docker-save.html.markdown
index 8f758755c..27b9b7533 100644
--- a/website/source/docs/post-processors/docker-save.html.markdown
+++ b/website/source/docs/post-processors/docker-save.html.markdown
@@ -25,7 +25,7 @@ familiar with this and vice versa.
The configuration for this post-processor is extremely simple.
-- `path` (string) - The path to save the image.
+- `path` (string) - The path to save the image.
## Example
diff --git a/website/source/docs/post-processors/docker-tag.html.markdown b/website/source/docs/post-processors/docker-tag.html.markdown
index 42c480676..ea9fccad1 100644
--- a/website/source/docs/post-processors/docker-tag.html.markdown
+++ b/website/source/docs/post-processors/docker-tag.html.markdown
@@ -27,12 +27,12 @@ that this works with committed resources, rather than exported.
The configuration for this post-processor is extremely simple. At least a
repository is required.
-- `repository` (string) - The repository of the image.
+- `repository` (string) - The repository of the image.
-- `tag` (string) - The tag for the image. By default this is not set.
+- `tag` (string) - The tag for the image. By default this is not set.
-- `force` (boolean) - If true, this post-processor forcibly tag the image even
- if tag name is collided. Default to `false`.
+- `force` (boolean) - If true, this post-processor forcibly tag the image even
+ if tag name is collided. Default to `false`.
## Example
diff --git a/website/source/docs/post-processors/vagrant-cloud.html.markdown b/website/source/docs/post-processors/vagrant-cloud.html.markdown
index 4891797e8..237684aa1 100644
--- a/website/source/docs/post-processors/vagrant-cloud.html.markdown
+++ b/website/source/docs/post-processors/vagrant-cloud.html.markdown
@@ -36,16 +36,16 @@ and deliver them to your team in some fashion.
Here is an example workflow:
-1. You use Packer to build a Vagrant Box for the `virtualbox` provider
-2. The `vagrant-cloud` post-processor is configured to point to the box
- `hashicorp/foobar` on Vagrant Cloud via the `box_tag` configuration
-3. The post-processor receives the box from the `vagrant` post-processor
-4. It then creates the configured version, or verifies the existence of it, on
- Vagrant Cloud
-5. A provider matching the name of the Vagrant provider is then created
-6. The box is uploaded to Vagrant Cloud
-7. The upload is verified
-8. The version is released and available to users of the box
+1. You use Packer to build a Vagrant Box for the `virtualbox` provider
+2. The `vagrant-cloud` post-processor is configured to point to the box
+ `hashicorp/foobar` on Vagrant Cloud via the `box_tag` configuration
+3. The post-processor receives the box from the `vagrant` post-processor
+4. It then creates the configured version, or verifies the existence of it, on
+ Vagrant Cloud
+5. A provider matching the name of the Vagrant provider is then created
+6. The box is uploaded to Vagrant Cloud
+7. The upload is verified
+8. The version is released and available to users of the box
## Configuration
@@ -54,35 +54,35 @@ on Vagrant Cloud, as well as authentication and version information.
### Required:
-- `access_token` (string) - Your access token for the Vagrant Cloud API. This
- can be generated on your [tokens
- page](https://vagrantcloud.com/account/tokens).
+- `access_token` (string) - Your access token for the Vagrant Cloud API. This
+ can be generated on your [tokens
+ page](https://vagrantcloud.com/account/tokens).
-- `box_tag` (string) - The shorthand tag for your box that maps to Vagrant
- Cloud, i.e `hashicorp/precise64` for `vagrantcloud.com/hashicorp/precise64`
+- `box_tag` (string) - The shorthand tag for your box that maps to Vagrant
+ Cloud, i.e `hashicorp/precise64` for `vagrantcloud.com/hashicorp/precise64`
-- `version` (string) - The version number, typically incrementing a
- previous version. The version string is validated based on [Semantic
- Versioning](http://semver.org/). The string must match a pattern that could be
- semver, and doesn't validate that the version comes after your
- previous versions.
+- `version` (string) - The version number, typically incrementing a
+ previous version. The version string is validated based on [Semantic
+ Versioning](http://semver.org/). The string must match a pattern that could
+ be semver, and doesn't validate that the version comes after your
+ previous versions.
### Optional:
-- `no_release` (string) - If set to true, does not release the version on
- Vagrant Cloud, making it active. You can manually release the version via the
- API or Web UI. Defaults to false.
+- `no_release` (string) - If set to true, does not release the version on
+ Vagrant Cloud, making it active. You can manually release the version via
+ the API or Web UI. Defaults to false.
-- `vagrant_cloud_url` (string) - Override the base URL for Vagrant Cloud. This
- is useful if you're using Vagrant Private Cloud in your own network. Defaults
- to `https://vagrantcloud.com/api/v1`
+- `vagrant_cloud_url` (string) - Override the base URL for Vagrant Cloud. This
+ is useful if you're using Vagrant Private Cloud in your own network.
+ Defaults to `https://vagrantcloud.com/api/v1`
-- `version_description` (string) - Optionally markdown text used as a
- full-length and in-depth description of the version, typically for denoting
- changes introduced
+- `version_description` (string) - Optionally markdown text used as a
+ full-length and in-depth description of the version, typically for denoting
+ changes introduced
-- `box_download_url` (string) - Optional URL for a self-hosted box. If this is
- set the box will not be uploaded to the Vagrant Cloud.
+- `box_download_url` (string) - Optional URL for a self-hosted box. If this is
+ set the box will not be uploaded to the Vagrant Cloud.
## Use with Vagrant Post-Processor
diff --git a/website/source/docs/post-processors/vagrant.html.markdown b/website/source/docs/post-processors/vagrant.html.markdown
index da1b8daa9..3e55e2549 100644
--- a/website/source/docs/post-processors/vagrant.html.markdown
+++ b/website/source/docs/post-processors/vagrant.html.markdown
@@ -29,13 +29,13 @@ certain builders into proper boxes for their respective providers.
Currently, the Vagrant post-processor can create boxes for the following
providers.
-- AWS
-- DigitalOcean
-- Hyper-V
-- Parallels
-- QEMU
-- VirtualBox
-- VMware
+- AWS
+- DigitalOcean
+- Hyper-V
+- Parallels
+- QEMU
+- VirtualBox
+- VMware
-> **Support for additional providers** is planned. If the Vagrant
post-processor doesn't support creating boxes for a provider you care about,
@@ -51,28 +51,28 @@ However, if you want to configure things a bit more, the post-processor does
expose some configuration options. The available options are listed below, with
more details about certain options in following sections.
-- `compression_level` (integer) - An integer representing the compression level
- to use when creating the Vagrant box. Valid values range from 0 to 9, with 0
- being no compression and 9 being the best compression. By default, compression
- is enabled at level 6.
+- `compression_level` (integer) - An integer representing the compression
+ level to use when creating the Vagrant box. Valid values range from 0 to 9,
+ with 0 being no compression and 9 being the best compression. By default,
+ compression is enabled at level 6.
-- `include` (array of strings) - Paths to files to include in the Vagrant box.
- These files will each be copied into the top level directory of the Vagrant
- box (regardless of their paths). They can then be used from the Vagrantfile.
+- `include` (array of strings) - Paths to files to include in the Vagrant box.
+ These files will each be copied into the top level directory of the Vagrant
+ box (regardless of their paths). They can then be used from the Vagrantfile.
-- `keep_input_artifact` (boolean) - If set to true, do not delete the
- `output_directory` on a successful build. Defaults to false.
+- `keep_input_artifact` (boolean) - If set to true, do not delete the
+ `output_directory` on a successful build. Defaults to false.
-- `output` (string) - The full path to the box file that will be created by
- this post-processor. This is a [configuration
- template](/docs/templates/configuration-templates.html). The variable
- `Provider` is replaced by the Vagrant provider the box is for. The variable
- `ArtifactId` is replaced by the ID of the input artifact. The variable
- `BuildName` is replaced with the name of the build. By default, the value of
- this config is `packer_{{.BuildName}}_{{.Provider}}.box`.
+- `output` (string) - The full path to the box file that will be created by
+ this post-processor. This is a [configuration
+ template](/docs/templates/configuration-templates.html). The variable
+ `Provider` is replaced by the Vagrant provider the box is for. The variable
+ `ArtifactId` is replaced by the ID of the input artifact. The variable
+ `BuildName` is replaced with the name of the build. By default, the value of
+ this config is `packer_{{.BuildName}}_{{.Provider}}.box`.
-- `vagrantfile_template` (string) - Path to a template to use for the
- Vagrantfile that is packaged with the box.
+- `vagrantfile_template` (string) - Path to a template to use for the
+ Vagrantfile that is packaged with the box.
## Provider-Specific Overrides
diff --git a/website/source/docs/post-processors/vsphere.html.markdown b/website/source/docs/post-processors/vsphere.html.markdown
index f0fd9588e..300155773 100644
--- a/website/source/docs/post-processors/vsphere.html.markdown
+++ b/website/source/docs/post-processors/vsphere.html.markdown
@@ -21,35 +21,36 @@ each category, the available configuration keys are alphabetized.
Required:
-- `cluster` (string) - The cluster to upload the VM to.
+- `cluster` (string) - The cluster to upload the VM to.
-- `datacenter` (string) - The name of the datacenter within vSphere to add the
- VM to.
+- `datacenter` (string) - The name of the datacenter within vSphere to add the
+ VM to.
-- `datastore` (string) - The name of the datastore to store this VM. This is
- *not required* if `resource_pool` is specified.
+- `datastore` (string) - The name of the datastore to store this VM. This is
+ *not required* if `resource_pool` is specified.
-- `host` (string) - The vSphere host that will be contacted to perform the
- VM upload.
+- `host` (string) - The vSphere host that will be contacted to perform the
+ VM upload.
-- `password` (string) - Password to use to authenticate to the vSphere endpoint.
+- `password` (string) - Password to use to authenticate to the
+ vSphere endpoint.
-- `resource_pool` (string) - The resource pool to upload the VM to. This is *not
- required*.
+- `resource_pool` (string) - The resource pool to upload the VM to. This is
+ *not required*.
-- `username` (string) - The username to use to authenticate to the
- vSphere endpoint.
+- `username` (string) - The username to use to authenticate to the
+ vSphere endpoint.
-- `vm_name` (string) - The name of the VM once it is uploaded.
+- `vm_name` (string) - The name of the VM once it is uploaded.
Optional:
-- `disk_mode` (string) - Target disk format. See `ovftool` manual for
- available options. By default, "thick" will be used.
+- `disk_mode` (string) - Target disk format. See `ovftool` manual for
+ available options. By default, "thick" will be used.
-- `insecure` (boolean) - Whether or not the connection to vSphere can be done
- over an insecure connection. By default this is false.
+- `insecure` (boolean) - Whether or not the connection to vSphere can be done
+ over an insecure connection. By default this is false.
-- `vm_folder` (string) - The folder within the datastore to store the VM.
+- `vm_folder` (string) - The folder within the datastore to store the VM.
-- `vm_network` (string) - The name of the VM network this VM will be added to.
+- `vm_network` (string) - The name of the VM network this VM will be added to.
diff --git a/website/source/docs/provisioners/ansible-local.html.markdown b/website/source/docs/provisioners/ansible-local.html.markdown
index 5682043c9..7fd084c0a 100644
--- a/website/source/docs/provisioners/ansible-local.html.markdown
+++ b/website/source/docs/provisioners/ansible-local.html.markdown
@@ -35,83 +35,70 @@ The reference of available configuration options is listed below.
Required:
-- `playbook_file` (string) - The playbook file to be executed by ansible. This
- file must exist on your local system and will be uploaded to the
- remote machine.
+- `playbook_file` (string) - The playbook file to be executed by ansible. This
+ file must exist on your local system and will be uploaded to the
+ remote machine.
Optional:
-- `command` (string) - The command to invoke ansible. Defaults
- to "ansible-playbook".
+- `command` (string) - The command to invoke ansible. Defaults
+ to "ansible-playbook".
-- `extra_arguments` (array of strings) - An array of extra arguments to pass to
- the ansible command. By default, this is empty.
+- `extra_arguments` (array of strings) - An array of extra arguments to pass
+ to the ansible command. By default, this is empty.
-- `inventory_groups` (string) - A comma-separated list of groups to which packer
- will assign the host `127.0.0.1`. A value of `my_group_1,my_group_2` will
- generate an Ansible inventory like:
+- `inventory_groups` (string) - A comma-separated list of groups to which
+ packer will assign the host `127.0.0.1`. A value of `my_group_1,my_group_2`
+ will generate an Ansible inventory like:
- ``` {.text}
- [my_group_1]
- 127.0.0.1
- [my_group_2]
- 127.0.0.1
- ```
+`{.text} [my_group_1] 127.0.0.1 [my_group_2] 127.0.0.1`
-- `inventory_file` (string) - The inventory file to be used by ansible. This
- file must exist on your local system and will be uploaded to the
- remote machine.
+- `inventory_file` (string) - The inventory file to be used by ansible. This
+ file must exist on your local system and will be uploaded to the
+ remote machine.
- When using an inventory file, it's also required to `--limit` the hosts to the
- specified host you're buiding. The `--limit` argument can be provided in the
- `extra_arguments` option.
+When using an inventory file, it's also required to `--limit` the hosts to the
+specified host you're buiding. The `--limit` argument can be provided in the
+`extra_arguments` option.
- An example inventory file may look like:
+An example inventory file may look like:
- ``` {.text}
- [chi-dbservers]
- db-01 ansible_connection=local
- db-02 ansible_connection=local
+\`\`\` {.text} \[chi-dbservers\] db-01 ansible\_connection=local db-02
+ansible\_connection=local
- [chi-appservers]
- app-01 ansible_connection=local
- app-02 ansible_connection=local
+\[chi-appservers\] app-01 ansible\_connection=local app-02
+ansible\_connection=local
- [chi:children]
- chi-dbservers
- chi-appservers
+\[chi:children\] chi-dbservers chi-appservers
- [dbservers:children]
- chi-dbservers
+\[dbservers:children\] chi-dbservers
- [appservers:children]
- chi-appservers
- ```
+\[appservers:children\] chi-appservers \`\`\`
-- `playbook_dir` (string) - a path to the complete ansible directory structure
- on your local system to be copied to the remote machine as the
- `staging_directory` before all other files and directories.
+- `playbook_dir` (string) - a path to the complete ansible directory structure
+ on your local system to be copied to the remote machine as the
+ `staging_directory` before all other files and directories.
-- `playbook_paths` (array of strings) - An array of paths to playbook files on
- your local system. These will be uploaded to the remote machine under
- `staging_directory`/playbooks. By default, this is empty.
+- `playbook_paths` (array of strings) - An array of paths to playbook files on
+ your local system. These will be uploaded to the remote machine under
+ `staging_directory`/playbooks. By default, this is empty.
-- `group_vars` (string) - a path to the directory containing ansible group
- variables on your local system to be copied to the remote machine. By default,
- this is empty.
+- `group_vars` (string) - a path to the directory containing ansible group
+ variables on your local system to be copied to the remote machine. By
+ default, this is empty.
-- `host_vars` (string) - a path to the directory containing ansible host
- variables on your local system to be copied to the remote machine. By default,
- this is empty.
+- `host_vars` (string) - a path to the directory containing ansible host
+ variables on your local system to be copied to the remote machine. By
+ default, this is empty.
-- `role_paths` (array of strings) - An array of paths to role directories on
- your local system. These will be uploaded to the remote machine under
- `staging_directory`/roles. By default, this is empty.
+- `role_paths` (array of strings) - An array of paths to role directories on
+ your local system. These will be uploaded to the remote machine under
+ `staging_directory`/roles. By default, this is empty.
-- `staging_directory` (string) - The directory where all the configuration of
- Ansible by Packer will be placed. By default this
- is "/tmp/packer-provisioner-ansible-local". This directory doesn't need to
- exist but must have proper permissions so that the SSH user that Packer uses
- is able to create directories and write into this folder. If the permissions
- are not correct, use a shell provisioner prior to this to configure
- it properly.
+- `staging_directory` (string) - The directory where all the configuration of
+ Ansible by Packer will be placed. By default this
+ is "/tmp/packer-provisioner-ansible-local". This directory doesn't need to
+ exist but must have proper permissions so that the SSH user that Packer uses
+ is able to create directories and write into this folder. If the permissions
+ are not correct, use a shell provisioner prior to this to configure
+ it properly.
diff --git a/website/source/docs/provisioners/chef-client.html.markdown b/website/source/docs/provisioners/chef-client.html.markdown
index 81d097b7e..aca1a2717 100644
--- a/website/source/docs/provisioners/chef-client.html.markdown
+++ b/website/source/docs/provisioners/chef-client.html.markdown
@@ -40,70 +40,71 @@ is running must have knife on the path and configured globally, i.e,
The reference of available configuration options is listed below. No
configuration is actually required.
-- `chef_environment` (string) - The name of the chef\_environment sent to the
- Chef server. By default this is empty and will not use an environment.
+- `chef_environment` (string) - The name of the chef\_environment sent to the
+ Chef server. By default this is empty and will not use an environment.
-- `config_template` (string) - Path to a template that will be used for the Chef
- configuration file. By default Packer only sets configuration it needs to
- match the settings set in the provisioner configuration. If you need to set
- configurations that the Packer provisioner doesn't support, then you should
- use a custom configuration template. See the dedicated "Chef Configuration"
- section below for more details.
+- `config_template` (string) - Path to a template that will be used for the
+ Chef configuration file. By default Packer only sets configuration it needs
+ to match the settings set in the provisioner configuration. If you need to
+ set configurations that the Packer provisioner doesn't support, then you
+ should use a custom configuration template. See the dedicated "Chef
+ Configuration" section below for more details.
-- `execute_command` (string) - The command used to execute Chef. This has
- various [configuration template
- variables](/docs/templates/configuration-templates.html) available. See below
- for more information.
+- `execute_command` (string) - The command used to execute Chef. This has
+ various [configuration template
+ variables](/docs/templates/configuration-templates.html) available. See
+ below for more information.
-- `install_command` (string) - The command used to install Chef. This has
- various [configuration template
- variables](/docs/templates/configuration-templates.html) available. See below
- for more information.
+- `install_command` (string) - The command used to install Chef. This has
+ various [configuration template
+ variables](/docs/templates/configuration-templates.html) available. See
+ below for more information.
-- `json` (object) - An arbitrary mapping of JSON that will be available as node
- attributes while running Chef.
+- `json` (object) - An arbitrary mapping of JSON that will be available as
+ node attributes while running Chef.
-- `node_name` (string) - The name of the node to register with the Chef Server.
- This is optional and by default is packer-{{uuid}}.
+- `node_name` (string) - The name of the node to register with the
+ Chef Server. This is optional and by default is packer-{{uuid}}.
-- `prevent_sudo` (boolean) - By default, the configured commands that are
- executed to install and run Chef are executed with `sudo`. If this is true,
- then the sudo will be omitted.
+- `prevent_sudo` (boolean) - By default, the configured commands that are
+ executed to install and run Chef are executed with `sudo`. If this is true,
+ then the sudo will be omitted.
-- `run_list` (array of strings) - The [run
- list](http://docs.opscode.com/essentials_node_object_run_lists.html) for Chef.
- By default this is empty, and will use the run list sent down by the
- Chef Server.
+- `run_list` (array of strings) - The [run
+ list](http://docs.opscode.com/essentials_node_object_run_lists.html)
+ for Chef. By default this is empty, and will use the run list sent down by
+ the Chef Server.
-- `server_url` (string) - The URL to the Chef server. This is required.
+- `server_url` (string) - The URL to the Chef server. This is required.
-- `skip_clean_client` (boolean) - If true, Packer won't remove the client from
- the Chef server after it is done running. By default, this is false.
+- `skip_clean_client` (boolean) - If true, Packer won't remove the client from
+ the Chef server after it is done running. By default, this is false.
-- `skip_clean_node` (boolean) - If true, Packer won't remove the node from the
- Chef server after it is done running. By default, this is false.
+- `skip_clean_node` (boolean) - If true, Packer won't remove the node from the
+ Chef server after it is done running. By default, this is false.
-- `skip_install` (boolean) - If true, Chef will not automatically be installed
- on the machine using the Opscode omnibus installers.
+- `skip_install` (boolean) - If true, Chef will not automatically be installed
+ on the machine using the Opscode omnibus installers.
-- `staging_directory` (string) - This is the directory where all the
- configuration of Chef by Packer will be placed. By default this
- is "/tmp/packer-chef-client". This directory doesn't need to exist but must
- have proper permissions so that the SSH user that Packer uses is able to
- create directories and write into this folder. If the permissions are not
- correct, use a shell provisioner prior to this to configure it properly.
+- `staging_directory` (string) - This is the directory where all the
+ configuration of Chef by Packer will be placed. By default this
+ is "/tmp/packer-chef-client". This directory doesn't need to exist but must
+ have proper permissions so that the SSH user that Packer uses is able to
+ create directories and write into this folder. If the permissions are not
+ correct, use a shell provisioner prior to this to configure it properly.
-- `client_key` (string) - Path to client key. If not set, this defaults to a
- file named client.pem in `staging_directory`.
+- `client_key` (string) - Path to client key. If not set, this defaults to a
+ file named client.pem in `staging_directory`.
-- `validation_client_name` (string) - Name of the validation client. If not set,
- this won't be set in the configuration and the default that Chef uses will
- be used.
+- `validation_client_name` (string) - Name of the validation client. If not
+ set, this won't be set in the configuration and the default that Chef uses
+ will be used.
-- `validation_key_path` (string) - Path to the validation key for communicating
- with the Chef Server. This will be uploaded to the remote machine. If this is
- NOT set, then it is your responsibility via other means (shell
- provisioner, etc.) to get a validation key to where Chef expects it.
+- `validation_key_path` (string) - Path to the validation key for
+ communicating with the Chef Server. This will be uploaded to the
+ remote machine. If this is NOT set, then it is your responsibility via other
+ means (shell provisioner, etc.) to get a validation key to where Chef
+ expects it.
## Chef Configuration
@@ -135,9 +136,9 @@ This template is a [configuration
template](/docs/templates/configuration-templates.html) and has a set of
variables available to use:
-- `NodeName` - The node name set in the configuration.
-- `ServerUrl` - The URL of the Chef Server set in the configuration.
-- `ValidationKeyPath` - Path to the validation key, if it is set.
+- `NodeName` - The node name set in the configuration.
+- `ServerUrl` - The URL of the Chef Server set in the configuration.
+- `ValidationKeyPath` - Path to the validation key, if it is set.
## Execute Command
@@ -155,10 +156,10 @@ This command can be customized using the `execute_command` configuration. As you
can see from the default value above, the value of this configuration can
contain various template variables, defined below:
-- `ConfigPath` - The path to the Chef configuration file. file.
-- `JsonPath` - The path to the JSON attributes file for the node.
-- `Sudo` - A boolean of whether to `sudo` the command or not, depending on the
- value of the `prevent_sudo` configuration.
+- `ConfigPath` - The path to the Chef configuration file. file.
+- `JsonPath` - The path to the JSON attributes file for the node.
+- `Sudo` - A boolean of whether to `sudo` the command or not, depending on the
+ value of the `prevent_sudo` configuration.
## Install Command
diff --git a/website/source/docs/provisioners/chef-solo.html.markdown b/website/source/docs/provisioners/chef-solo.html.markdown
index 03b55c066..9534c32f1 100644
--- a/website/source/docs/provisioners/chef-solo.html.markdown
+++ b/website/source/docs/provisioners/chef-solo.html.markdown
@@ -36,71 +36,72 @@ directory relative to your working directory.
The reference of available configuration options is listed below. No
configuration is actually required, but at least `run_list` is recommended.
-- `chef_environment` (string) - The name of the `chef_environment` sent to the
- Chef server. By default this is empty and will not use an environment
+- `chef_environment` (string) - The name of the `chef_environment` sent to the
+ Chef server. By default this is empty and will not use an environment
-- `config_template` (string) - Path to a template that will be used for the Chef
- configuration file. By default Packer only sets configuration it needs to
- match the settings set in the provisioner configuration. If you need to set
- configurations that the Packer provisioner doesn't support, then you should
- use a custom configuration template. See the dedicated "Chef Configuration"
- section below for more details.
+- `config_template` (string) - Path to a template that will be used for the
+ Chef configuration file. By default Packer only sets configuration it needs
+ to match the settings set in the provisioner configuration. If you need to
+ set configurations that the Packer provisioner doesn't support, then you
+ should use a custom configuration template. See the dedicated "Chef
+ Configuration" section below for more details.
-- `cookbook_paths` (array of strings) - This is an array of paths to "cookbooks"
- directories on your local filesystem. These will be uploaded to the remote
- machine in the directory specified by the `staging_directory`. By default,
- this is empty.
+- `cookbook_paths` (array of strings) - This is an array of paths to
+ "cookbooks" directories on your local filesystem. These will be uploaded to
+ the remote machine in the directory specified by the `staging_directory`. By
+ default, this is empty.
-- `data_bags_path` (string) - The path to the "data\_bags" directory on your
- local filesystem. These will be uploaded to the remote machine in the
- directory specified by the `staging_directory`. By default, this is empty.
+- `data_bags_path` (string) - The path to the "data\_bags" directory on your
+ local filesystem. These will be uploaded to the remote machine in the
+ directory specified by the `staging_directory`. By default, this is empty.
-- `encrypted_data_bag_secret_path` (string) - The path to the file containing
- the secret for encrypted data bags. By default, this is empty, so no secret
- will be available.
+- `encrypted_data_bag_secret_path` (string) - The path to the file containing
+ the secret for encrypted data bags. By default, this is empty, so no secret
+ will be available.
-- `environments_path` (string) - The path to the "environments" directory on
- your local filesystem. These will be uploaded to the remote machine in the
- directory specified by the `staging_directory`. By default, this is empty.
+- `environments_path` (string) - The path to the "environments" directory on
+ your local filesystem. These will be uploaded to the remote machine in the
+ directory specified by the `staging_directory`. By default, this is empty.
-- `execute_command` (string) - The command used to execute Chef. This has
- various [configuration template
- variables](/docs/templates/configuration-templates.html) available. See below
- for more information.
+- `execute_command` (string) - The command used to execute Chef. This has
+ various [configuration template
+ variables](/docs/templates/configuration-templates.html) available. See
+ below for more information.
-- `install_command` (string) - The command used to install Chef. This has
- various [configuration template
- variables](/docs/templates/configuration-templates.html) available. See below
- for more information.
+- `install_command` (string) - The command used to install Chef. This has
+ various [configuration template
+ variables](/docs/templates/configuration-templates.html) available. See
+ below for more information.
-- `json` (object) - An arbitrary mapping of JSON that will be available as node
- attributes while running Chef.
+- `json` (object) - An arbitrary mapping of JSON that will be available as
+ node attributes while running Chef.
-- `prevent_sudo` (boolean) - By default, the configured commands that are
- executed to install and run Chef are executed with `sudo`. If this is true,
- then the sudo will be omitted.
+- `prevent_sudo` (boolean) - By default, the configured commands that are
+ executed to install and run Chef are executed with `sudo`. If this is true,
+ then the sudo will be omitted.
-- `remote_cookbook_paths` (array of strings) - A list of paths on the remote
- machine where cookbooks will already exist. These may exist from a previous
- provisioner or step. If specified, Chef will be configured to look for
- cookbooks here. By default, this is empty.
+- `remote_cookbook_paths` (array of strings) - A list of paths on the remote
+ machine where cookbooks will already exist. These may exist from a previous
+ provisioner or step. If specified, Chef will be configured to look for
+ cookbooks here. By default, this is empty.
-- `roles_path` (string) - The path to the "roles" directory on your
- local filesystem. These will be uploaded to the remote machine in the
- directory specified by the `staging_directory`. By default, this is empty.
+- `roles_path` (string) - The path to the "roles" directory on your
+ local filesystem. These will be uploaded to the remote machine in the
+ directory specified by the `staging_directory`. By default, this is empty.
-- `run_list` (array of strings) - The [run
- list](https://docs.chef.io/run_lists.html) for Chef. By default this is empty.
+- `run_list` (array of strings) - The [run
+ list](https://docs.chef.io/run_lists.html) for Chef. By default this
+ is empty.
-- `skip_install` (boolean) - If true, Chef will not automatically be installed
- on the machine using the Chef omnibus installers.
+- `skip_install` (boolean) - If true, Chef will not automatically be installed
+ on the machine using the Chef omnibus installers.
-- `staging_directory` (string) - This is the directory where all the
- configuration of Chef by Packer will be placed. By default this
- is "/tmp/packer-chef-solo". This directory doesn't need to exist but must have
- proper permissions so that the SSH user that Packer uses is able to create
- directories and write into this folder. If the permissions are not correct,
- use a shell provisioner prior to this to configure it properly.
+- `staging_directory` (string) - This is the directory where all the
+ configuration of Chef by Packer will be placed. By default this
+ is "/tmp/packer-chef-solo". This directory doesn't need to exist but must
+ have proper permissions so that the SSH user that Packer uses is able to
+ create directories and write into this folder. If the permissions are not
+ correct, use a shell provisioner prior to this to configure it properly.
## Chef Configuration
@@ -119,14 +120,14 @@ This template is a [configuration
template](/docs/templates/configuration-templates.html) and has a set of
variables available to use:
-- `ChefEnvironment` - The current enabled environment. Only non-empty if the
- environment path is set.
-- `CookbookPaths` is the set of cookbook paths ready to embedded directly into a
- Ruby array to configure Chef.
-- `DataBagsPath` is the path to the data bags folder.
-- `EncryptedDataBagSecretPath` - The path to the encrypted data bag secret
-- `EnvironmentsPath` - The path to the environments folder.
-- `RolesPath` - The path to the roles folder.
+- `ChefEnvironment` - The current enabled environment. Only non-empty if the
+ environment path is set.
+- `CookbookPaths` is the set of cookbook paths ready to embedded directly into
+ a Ruby array to configure Chef.
+- `DataBagsPath` is the path to the data bags folder.
+- `EncryptedDataBagSecretPath` - The path to the encrypted data bag secret
+- `EnvironmentsPath` - The path to the environments folder.
+- `RolesPath` - The path to the roles folder.
## Execute Command
@@ -144,10 +145,10 @@ This command can be customized using the `execute_command` configuration. As you
can see from the default value above, the value of this configuration can
contain various template variables, defined below:
-- `ConfigPath` - The path to the Chef configuration file. file.
-- `JsonPath` - The path to the JSON attributes file for the node.
-- `Sudo` - A boolean of whether to `sudo` the command or not, depending on the
- value of the `prevent_sudo` configuration.
+- `ConfigPath` - The path to the Chef configuration file. file.
+- `JsonPath` - The path to the JSON attributes file for the node.
+- `Sudo` - A boolean of whether to `sudo` the command or not, depending on the
+ value of the `prevent_sudo` configuration.
## Install Command
diff --git a/website/source/docs/provisioners/file.html.markdown b/website/source/docs/provisioners/file.html.markdown
index 3439b4dd6..7799721a5 100644
--- a/website/source/docs/provisioners/file.html.markdown
+++ b/website/source/docs/provisioners/file.html.markdown
@@ -32,19 +32,19 @@ The file provisioner can upload both single files and complete directories.
The available configuration options are listed below. All elements are required.
-- `source` (string) - The path to a local file or directory to upload to
- the machine. The path can be absolute or relative. If it is relative, it is
- relative to the working directory when Packer is executed. If this is a
- directory, the existence of a trailing slash is important. Read below on
- uploading directories.
+- `source` (string) - The path to a local file or directory to upload to
+ the machine. The path can be absolute or relative. If it is relative, it is
+ relative to the working directory when Packer is executed. If this is a
+ directory, the existence of a trailing slash is important. Read below on
+ uploading directories.
-- `destination` (string) - The path where the file will be uploaded to in
- the machine. This value must be a writable location and any parent directories
- must already exist.
+- `destination` (string) - The path where the file will be uploaded to in
+ the machine. This value must be a writable location and any parent
+ directories must already exist.
-- `direction` (string) - The direction of the file transfer. This defaults to
- "upload." If it is set to "download" then the file "source" in the machine wll
- be downloaded locally to "destination"
+- `direction` (string) - The direction of the file transfer. This defaults to
+ "upload." If it is set to "download" then the file "source" in the machine
+ wll be downloaded locally to "destination"
## Directory Uploads
diff --git a/website/source/docs/provisioners/powershell.html.markdown b/website/source/docs/provisioners/powershell.html.markdown
index ebc56ec4c..4cd862616 100644
--- a/website/source/docs/provisioners/powershell.html.markdown
+++ b/website/source/docs/provisioners/powershell.html.markdown
@@ -32,52 +32,53 @@ required element is either "inline" or "script". Every other option is optional.
Exactly *one* of the following is required:
-- `inline` (array of strings) - This is an array of commands to execute. The
- commands are concatenated by newlines and turned into a single file, so they
- are all executed within the same context. This allows you to change
- directories in one command and use something in the directory in the next and
- so on. Inline scripts are the easiest way to pull off simple tasks within
- the machine.
+- `inline` (array of strings) - This is an array of commands to execute. The
+ commands are concatenated by newlines and turned into a single file, so they
+ are all executed within the same context. This allows you to change
+ directories in one command and use something in the directory in the next
+ and so on. Inline scripts are the easiest way to pull off simple tasks
+ within the machine.
-- `script` (string) - The path to a script to upload and execute in the machine.
- This path can be absolute or relative. If it is relative, it is relative to
- the working directory when Packer is executed.
+- `script` (string) - The path to a script to upload and execute in
+ the machine. This path can be absolute or relative. If it is relative, it is
+ relative to the working directory when Packer is executed.
-- `scripts` (array of strings) - An array of scripts to execute. The scripts
- will be uploaded and executed in the order specified. Each script is executed
- in isolation, so state such as variables from one script won't carry on to
- the next.
+- `scripts` (array of strings) - An array of scripts to execute. The scripts
+ will be uploaded and executed in the order specified. Each script is
+ executed in isolation, so state such as variables from one script won't
+ carry on to the next.
Optional parameters:
-- `binary` (boolean) - If true, specifies that the script(s) are binary files,
- and Packer should therefore not convert Windows line endings to Unix line
- endings (if there are any). By default this is false.
+- `binary` (boolean) - If true, specifies that the script(s) are binary files,
+ and Packer should therefore not convert Windows line endings to Unix line
+ endings (if there are any). By default this is false.
-- `environment_vars` (array of strings) - An array of key/value pairs to inject
- prior to the execute\_command. The format should be `key=value`. Packer
- injects some environmental variables by default into the environment, as well,
- which are covered in the section below.
+- `environment_vars` (array of strings) - An array of key/value pairs to
+ inject prior to the execute\_command. The format should be `key=value`.
+ Packer injects some environmental variables by default into the environment,
+ as well, which are covered in the section below.
-- `execute_command` (string) - The command to use to execute the script. By
- default this is `powershell "& { {{.Vars}}{{.Path}}; exit $LastExitCode}"`.
- The value of this is treated as [configuration
- template](/docs/templates/configuration-templates.html). There are two
- available variables: `Path`, which is the path to the script to run, and
- `Vars`, which is the list of `environment_vars`, if configured.
+- `execute_command` (string) - The command to use to execute the script. By
+ default this is `powershell "& { {{.Vars}}{{.Path}}; exit $LastExitCode}"`.
+ The value of this is treated as [configuration
+ template](/docs/templates/configuration-templates.html). There are two
+ available variables: `Path`, which is the path to the script to run, and
+ `Vars`, which is the list of `environment_vars`, if configured.
-- `elevated_user` and `elevated_password` (string) - If specified, the
- PowerShell script will be run with elevated privileges using the given
- Windows user.
+- `elevated_user` and `elevated_password` (string) - If specified, the
+ PowerShell script will be run with elevated privileges using the given
+ Windows user.
-- `remote_path` (string) - The path where the script will be uploaded to in
- the machine. This defaults to "/tmp/script.sh". This value must be a writable
- location and any parent directories must already exist.
+- `remote_path` (string) - The path where the script will be uploaded to in
+ the machine. This defaults to "/tmp/script.sh". This value must be a
+ writable location and any parent directories must already exist.
-- `start_retry_timeout` (string) - The amount of time to attempt to *start* the
- remote process. By default this is "5m" or 5 minutes. This setting exists in
- order to deal with times when SSH may restart, such as a system reboot. Set
- this to a higher value if reboots take a longer amount of time.
+- `start_retry_timeout` (string) - The amount of time to attempt to *start*
+ the remote process. By default this is "5m" or 5 minutes. This setting
+ exists in order to deal with times when SSH may restart, such as a
+ system reboot. Set this to a higher value if reboots take a longer amount
+ of time.
-- `valid_exit_codes` (list of ints) - Valid exit codes for the script. By
- default this is just 0.
+- `valid_exit_codes` (list of ints) - Valid exit codes for the script. By
+ default this is just 0.
diff --git a/website/source/docs/provisioners/puppet-masterless.html.markdown b/website/source/docs/provisioners/puppet-masterless.html.markdown
index ac5f4f628..7ef13265e 100644
--- a/website/source/docs/provisioners/puppet-masterless.html.markdown
+++ b/website/source/docs/provisioners/puppet-masterless.html.markdown
@@ -45,59 +45,58 @@ The reference of available configuration options is listed below.
Required parameters:
-- `manifest_file` (string) - This is either a path to a puppet manifest
- (`.pp` file) *or* a directory containing multiple manifests that puppet will
- apply (the ["main
- manifest"](https://docs.puppetlabs.com/puppet/latest/reference/dirs_manifest.html)).
- These file(s) must exist on your local system and will be uploaded to the
- remote machine.
+- `manifest_file` (string) - This is either a path to a puppet manifest
+ (`.pp` file) *or* a directory containing multiple manifests that puppet will
+ apply (the ["main
+ manifest"](https://docs.puppetlabs.com/puppet/latest/reference/dirs_manifest.html)).
+ These file(s) must exist on your local system and will be uploaded to the
+ remote machine.
Optional parameters:
-- `execute_command` (string) - The command used to execute Puppet. This has
- various [configuration template
- variables](/docs/templates/configuration-templates.html) available. See below
- for more information.
+- `execute_command` (string) - The command used to execute Puppet. This has
+ various [configuration template
+ variables](/docs/templates/configuration-templates.html) available. See
+ below for more information.
-- `facter` (object of key/value strings) - Additional
- [facts](http://puppetlabs.com/puppet/related-projects/facter) to make
- available when Puppet is running.
+- `facter` (object of key/value strings) - Additional
+ [facts](http://puppetlabs.com/puppet/related-projects/facter) to make
+ available when Puppet is running.
-- `hiera_config_path` (string) - The path to a local file with hiera
- configuration to be uploaded to the remote machine. Hiera data directories
- must be uploaded using the file provisioner separately.
+- `hiera_config_path` (string) - The path to a local file with hiera
+ configuration to be uploaded to the remote machine. Hiera data directories
+ must be uploaded using the file provisioner separately.
-- `manifest_dir` (string) - The path to a local directory with manifests to be
- uploaded to the remote machine. This is useful if your main manifest file
- uses imports. This directory doesn't necessarily contain the `manifest_file`.
- It is a separate directory that will be set as the "manifestdir" setting
- on Puppet.
+- `manifest_dir` (string) - The path to a local directory with manifests to be
+ uploaded to the remote machine. This is useful if your main manifest file
+ uses imports. This directory doesn't necessarily contain the
+ `manifest_file`. It is a separate directory that will be set as the
+ "manifestdir" setting on Puppet.
- \~> `manifest_dir` is passed to `puppet apply` as the
- `--manifestdir` option. This option was deprecated in puppet 3.6, and removed
- in puppet 4.0. If you have multiple manifests you should use
- `manifest_file` instead.
+\~> `manifest_dir` is passed to `puppet apply` as the `--manifestdir` option.
+This option was deprecated in puppet 3.6, and removed in puppet 4.0. If you have
+multiple manifests you should use `manifest_file` instead.
-- `module_paths` (array of strings) - This is an array of paths to module
- directories on your local filesystem. These will be uploaded to the
- remote machine. By default, this is empty.
+- `module_paths` (array of strings) - This is an array of paths to module
+ directories on your local filesystem. These will be uploaded to the
+ remote machine. By default, this is empty.
-- `prevent_sudo` (boolean) - By default, the configured commands that are
- executed to run Puppet are executed with `sudo`. If this is true, then the
- sudo will be omitted.
+- `prevent_sudo` (boolean) - By default, the configured commands that are
+ executed to run Puppet are executed with `sudo`. If this is true, then the
+ sudo will be omitted.
-- `staging_directory` (string) - This is the directory where all the
- configuration of Puppet by Packer will be placed. By default this
- is "/tmp/packer-puppet-masterless". This directory doesn't need to exist but
- must have proper permissions so that the SSH user that Packer uses is able to
- create directories and write into this folder. If the permissions are not
- correct, use a shell provisioner prior to this to configure it properly.
+- `staging_directory` (string) - This is the directory where all the
+ configuration of Puppet by Packer will be placed. By default this
+ is "/tmp/packer-puppet-masterless". This directory doesn't need to exist but
+ must have proper permissions so that the SSH user that Packer uses is able
+ to create directories and write into this folder. If the permissions are not
+ correct, use a shell provisioner prior to this to configure it properly.
-- `working_directory` (string) - This is the directory from which the puppet
- command will be run. When using hiera with a relative path, this option allows
- to ensure that the paths are working properly. If not specified, defaults to
- the value of specified `staging_directory` (or its default value if not
- specified either).
+- `working_directory` (string) - This is the directory from which the puppet
+ command will be run. When using hiera with a relative path, this option
+ allows to ensure that the paths are working properly. If not specified,
+ defaults to the value of specified `staging_directory` (or its default value
+ if not specified either).
## Execute Command
@@ -119,15 +118,15 @@ This command can be customized using the `execute_command` configuration. As you
can see from the default value above, the value of this configuration can
contain various template variables, defined below:
-- `WorkingDir` - The path from which Puppet will be executed.
-- `FacterVars` - Shell-friendly string of environmental variables used to set
- custom facts configured for this provisioner.
-- `HieraConfigPath` - The path to a hiera configuration file.
-- `ManifestFile` - The path on the remote machine to the manifest file for
- Puppet to use.
-- `ModulePath` - The paths to the module directories.
-- `Sudo` - A boolean of whether to `sudo` the command or not, depending on the
- value of the `prevent_sudo` configuration.
+- `WorkingDir` - The path from which Puppet will be executed.
+- `FacterVars` - Shell-friendly string of environmental variables used to set
+ custom facts configured for this provisioner.
+- `HieraConfigPath` - The path to a hiera configuration file.
+- `ManifestFile` - The path on the remote machine to the manifest file for
+ Puppet to use.
+- `ModulePath` - The paths to the module directories.
+- `Sudo` - A boolean of whether to `sudo` the command or not, depending on the
+ value of the `prevent_sudo` configuration.
## Default Facts
@@ -135,10 +134,10 @@ In addition to being able to specify custom Facter facts using the `facter`
configuration, the provisioner automatically defines certain commonly useful
facts:
-- `packer_build_name` is set to the name of the build that Packer is running.
- This is most useful when Packer is making multiple builds and you want to
- distinguish them in your Hiera hierarchy.
+- `packer_build_name` is set to the name of the build that Packer is running.
+ This is most useful when Packer is making multiple builds and you want to
+ distinguish them in your Hiera hierarchy.
-- `packer_builder_type` is the type of the builder that was used to create the
- machine that Puppet is running on. This is useful if you want to run only
- certain parts of your Puppet code on systems built with certain builders.
+- `packer_builder_type` is the type of the builder that was used to create the
+ machine that Puppet is running on. This is useful if you want to run only
+ certain parts of your Puppet code on systems built with certain builders.
diff --git a/website/source/docs/provisioners/puppet-server.html.markdown b/website/source/docs/provisioners/puppet-server.html.markdown
index 32bcadbe8..bf469956b 100644
--- a/website/source/docs/provisioners/puppet-server.html.markdown
+++ b/website/source/docs/provisioners/puppet-server.html.markdown
@@ -41,36 +41,36 @@ The reference of available configuration options is listed below.
The provisioner takes various options. None are strictly required. They are
listed below:
-- `client_cert_path` (string) - Path to the client certificate for the node on
- your disk. This defaults to nothing, in which case a client cert won't
- be uploaded.
+- `client_cert_path` (string) - Path to the client certificate for the node on
+ your disk. This defaults to nothing, in which case a client cert won't
+ be uploaded.
-- `client_private_key_path` (string) - Path to the client private key for the
- node on your disk. This defaults to nothing, in which case a client private
- key won't be uploaded.
+- `client_private_key_path` (string) - Path to the client private key for the
+ node on your disk. This defaults to nothing, in which case a client private
+ key won't be uploaded.
-- `facter` (object of key/value strings) - Additional Facter facts to make
- available to the Puppet run.
+- `facter` (object of key/value strings) - Additional Facter facts to make
+ available to the Puppet run.
-- `ignore_exit_codes` (boolean) - If true, Packer will never consider the
- provisioner a failure.
+- `ignore_exit_codes` (boolean) - If true, Packer will never consider the
+ provisioner a failure.
-- `options` (string) - Additional command line options to pass to `puppet agent`
- when Puppet is ran.
+- `options` (string) - Additional command line options to pass to
+ `puppet agent` when Puppet is ran.
-- `prevent_sudo` (boolean) - By default, the configured commands that are
- executed to run Puppet are executed with `sudo`. If this is true, then the
- sudo will be omitted.
+- `prevent_sudo` (boolean) - By default, the configured commands that are
+ executed to run Puppet are executed with `sudo`. If this is true, then the
+ sudo will be omitted.
-- `puppet_node` (string) - The name of the node. If this isn't set, the fully
- qualified domain name will be used.
+- `puppet_node` (string) - The name of the node. If this isn't set, the fully
+ qualified domain name will be used.
-- `puppet_server` (string) - Hostname of the Puppet server. By default "puppet"
- will be used.
+- `puppet_server` (string) - Hostname of the Puppet server. By default
+ "puppet" will be used.
-- `staging_directory` (string) - This is the directory where all the
- configuration of Puppet by Packer will be placed. By default this
- is "/tmp/packer-puppet-server". This directory doesn't need to exist but must
- have proper permissions so that the SSH user that Packer uses is able to
- create directories and write into this folder. If the permissions are not
- correct, use a shell provisioner prior to this to configure it properly.
+- `staging_directory` (string) - This is the directory where all the
+ configuration of Puppet by Packer will be placed. By default this
+ is "/tmp/packer-puppet-server". This directory doesn't need to exist but
+ must have proper permissions so that the SSH user that Packer uses is able
+ to create directories and write into this folder. If the permissions are not
+ correct, use a shell provisioner prior to this to configure it properly.
diff --git a/website/source/docs/provisioners/salt-masterless.html.markdown b/website/source/docs/provisioners/salt-masterless.html.markdown
index cc1ab1f7b..84171a071 100644
--- a/website/source/docs/provisioners/salt-masterless.html.markdown
+++ b/website/source/docs/provisioners/salt-masterless.html.markdown
@@ -31,28 +31,28 @@ required argument is the path to your local salt state tree.
Optional:
-- `bootstrap_args` (string) - Arguments to send to the bootstrap script. Usage
- is somewhat documented on
- [github](https://github.com/saltstack/salt-bootstrap), but the [script
- itself](https://github.com/saltstack/salt-bootstrap/blob/develop/bootstrap-salt.sh)
- has more detailed usage instructions. By default, no arguments are sent to
- the script.
+- `bootstrap_args` (string) - Arguments to send to the bootstrap script. Usage
+ is somewhat documented on
+ [github](https://github.com/saltstack/salt-bootstrap), but the [script
+ itself](https://github.com/saltstack/salt-bootstrap/blob/develop/bootstrap-salt.sh)
+ has more detailed usage instructions. By default, no arguments are sent to
+ the script.
-- `local_pillar_roots` (string) - The path to your local [pillar
- roots](http://docs.saltstack.com/ref/configuration/master.html#pillar-configuration).
- This will be uploaded to the `/srv/pillar` on the remote.
+- `local_pillar_roots` (string) - The path to your local [pillar
+ roots](http://docs.saltstack.com/ref/configuration/master.html#pillar-configuration).
+ This will be uploaded to the `/srv/pillar` on the remote.
-- `local_state_tree` (string) - The path to your local [state
- tree](http://docs.saltstack.com/ref/states/highstate.html#the-salt-state-tree).
- This will be uploaded to the `/srv/salt` on the remote.
+- `local_state_tree` (string) - The path to your local [state
+ tree](http://docs.saltstack.com/ref/states/highstate.html#the-salt-state-tree).
+ This will be uploaded to the `/srv/salt` on the remote.
-- `minion_config` (string) - The path to your local [minion
- config](http://docs.saltstack.com/topics/configuration.html). This will be
- uploaded to the `/etc/salt` on the remote.
+- `minion_config` (string) - The path to your local [minion
+ config](http://docs.saltstack.com/topics/configuration.html). This will be
+ uploaded to the `/etc/salt` on the remote.
-- `skip_bootstrap` (boolean) - By default the salt provisioner runs [salt
- bootstrap](https://github.com/saltstack/salt-bootstrap) to install salt. Set
- this to true to skip this step.
+- `skip_bootstrap` (boolean) - By default the salt provisioner runs [salt
+ bootstrap](https://github.com/saltstack/salt-bootstrap) to install salt. Set
+ this to true to skip this step.
-- `temp_config_dir` (string) - Where your local state tree will be copied before
- moving to the `/srv/salt` directory. Default is `/tmp/salt`.
+- `temp_config_dir` (string) - Where your local state tree will be copied
+ before moving to the `/srv/salt` directory. Default is `/tmp/salt`.
diff --git a/website/source/docs/provisioners/shell.html.markdown b/website/source/docs/provisioners/shell.html.markdown
index 97015a847..9cd05ef12 100644
--- a/website/source/docs/provisioners/shell.html.markdown
+++ b/website/source/docs/provisioners/shell.html.markdown
@@ -37,55 +37,56 @@ required element is either "inline" or "script". Every other option is optional.
Exactly *one* of the following is required:
-- `inline` (array of strings) - This is an array of commands to execute. The
- commands are concatenated by newlines and turned into a single file, so they
- are all executed within the same context. This allows you to change
- directories in one command and use something in the directory in the next and
- so on. Inline scripts are the easiest way to pull off simple tasks within
- the machine.
+- `inline` (array of strings) - This is an array of commands to execute. The
+ commands are concatenated by newlines and turned into a single file, so they
+ are all executed within the same context. This allows you to change
+ directories in one command and use something in the directory in the next
+ and so on. Inline scripts are the easiest way to pull off simple tasks
+ within the machine.
-- `script` (string) - The path to a script to upload and execute in the machine.
- This path can be absolute or relative. If it is relative, it is relative to
- the working directory when Packer is executed.
+- `script` (string) - The path to a script to upload and execute in
+ the machine. This path can be absolute or relative. If it is relative, it is
+ relative to the working directory when Packer is executed.
-- `scripts` (array of strings) - An array of scripts to execute. The scripts
- will be uploaded and executed in the order specified. Each script is executed
- in isolation, so state such as variables from one script won't carry on to
- the next.
+- `scripts` (array of strings) - An array of scripts to execute. The scripts
+ will be uploaded and executed in the order specified. Each script is
+ executed in isolation, so state such as variables from one script won't
+ carry on to the next.
Optional parameters:
-- `binary` (boolean) - If true, specifies that the script(s) are binary files,
- and Packer should therefore not convert Windows line endings to Unix line
- endings (if there are any). By default this is false.
+- `binary` (boolean) - If true, specifies that the script(s) are binary files,
+ and Packer should therefore not convert Windows line endings to Unix line
+ endings (if there are any). By default this is false.
-- `environment_vars` (array of strings) - An array of key/value pairs to inject
- prior to the execute\_command. The format should be `key=value`. Packer
- injects some environmental variables by default into the environment, as well,
- which are covered in the section below.
+- `environment_vars` (array of strings) - An array of key/value pairs to
+ inject prior to the execute\_command. The format should be `key=value`.
+ Packer injects some environmental variables by default into the environment,
+ as well, which are covered in the section below.
-- `execute_command` (string) - The command to use to execute the script. By
- default this is `chmod +x {{ .Path }}; {{ .Vars }} {{ .Path }}`. The value of
- this is treated as [configuration
- template](/docs/templates/configuration-templates.html). There are two
- available variables: `Path`, which is the path to the script to run, and
- `Vars`, which is the list of `environment_vars`, if configured.
+- `execute_command` (string) - The command to use to execute the script. By
+ default this is `chmod +x {{ .Path }}; {{ .Vars }} {{ .Path }}`. The value
+ of this is treated as [configuration
+ template](/docs/templates/configuration-templates.html). There are two
+ available variables: `Path`, which is the path to the script to run, and
+ `Vars`, which is the list of `environment_vars`, if configured.
-- `inline_shebang` (string) - The
- [shebang](http://en.wikipedia.org/wiki/Shebang_%28Unix%29) value to use when
- running commands specified by `inline`. By default, this is `/bin/sh -e`. If
- you're not using `inline`, then this configuration has no effect.
- **Important:** If you customize this, be sure to include something like the
- `-e` flag, otherwise individual steps failing won't fail the provisioner.
+- `inline_shebang` (string) - The
+ [shebang](http://en.wikipedia.org/wiki/Shebang_%28Unix%29) value to use when
+ running commands specified by `inline`. By default, this is `/bin/sh -e`. If
+ you're not using `inline`, then this configuration has no effect.
+ **Important:** If you customize this, be sure to include something like the
+ `-e` flag, otherwise individual steps failing won't fail the provisioner.
-- `remote_path` (string) - The path where the script will be uploaded to in
- the machine. This defaults to "/tmp/script.sh". This value must be a writable
- location and any parent directories must already exist.
+- `remote_path` (string) - The path where the script will be uploaded to in
+ the machine. This defaults to "/tmp/script.sh". This value must be a
+ writable location and any parent directories must already exist.
-- `start_retry_timeout` (string) - The amount of time to attempt to *start* the
- remote process. By default this is "5m" or 5 minutes. This setting exists in
- order to deal with times when SSH may restart, such as a system reboot. Set
- this to a higher value if reboots take a longer amount of time.
+- `start_retry_timeout` (string) - The amount of time to attempt to *start*
+ the remote process. By default this is "5m" or 5 minutes. This setting
+ exists in order to deal with times when SSH may restart, such as a
+ system reboot. Set this to a higher value if reboots take a longer amount
+ of time.
## Execute Command Example
@@ -128,13 +129,13 @@ In addition to being able to specify custom environmental variables using the
`environment_vars` configuration, the provisioner automatically defines certain
commonly useful environmental variables:
-- `PACKER_BUILD_NAME` is set to the name of the build that Packer is running.
- This is most useful when Packer is making multiple builds and you want to
- distinguish them slightly from a common provisioning script.
+- `PACKER_BUILD_NAME` is set to the name of the build that Packer is running.
+ This is most useful when Packer is making multiple builds and you want to
+ distinguish them slightly from a common provisioning script.
-- `PACKER_BUILDER_TYPE` is the type of the builder that was used to create the
- machine that the script is running on. This is useful if you want to run only
- certain parts of the script on systems built with certain builders.
+- `PACKER_BUILDER_TYPE` is the type of the builder that was used to create the
+ machine that the script is running on. This is useful if you want to run
+ only certain parts of the script on systems built with certain builders.
## Handling Reboots
@@ -181,46 +182,41 @@ provisioner](/docs/provisioners/file.html) (more secure) or using `ssh-keyscan`
to populate the file (less secure). An example of the latter accessing github
would be:
- {
- "type": "shell",
- "inline": [
- "sudo apt-get install -y git",
- "ssh-keyscan github.com >> ~/.ssh/known_hosts",
- "git clone git@github.com:exampleorg/myprivaterepo.git"
- ]
- }
+{ "type": "shell", "inline": \[ "sudo apt-get install -y git", "ssh-keyscan
+github.com >> \~/.ssh/known\_hosts", "git clone
+git@github.com:exampleorg/myprivaterepo.git" \] }
## Troubleshooting
*My shell script doesn't work correctly on Ubuntu*
-- On Ubuntu, the `/bin/sh` shell is
- [dash](http://en.wikipedia.org/wiki/Debian_Almquist_shell). If your script has
- [bash](http://en.wikipedia.org/wiki/Bash_(Unix_shell))-specific commands in
- it, then put `#!/bin/bash` at the top of your script. Differences between dash
- and bash can be found on the
- [DashAsBinSh](https://wiki.ubuntu.com/DashAsBinSh) Ubuntu wiki page.
+- On Ubuntu, the `/bin/sh` shell is
+ [dash](http://en.wikipedia.org/wiki/Debian_Almquist_shell). If your script
+ has [bash](http://en.wikipedia.org/wiki/Bash_(Unix_shell))-specific commands
+ in it, then put `#!/bin/bash` at the top of your script. Differences between
+ dash and bash can be found on the
+ [DashAsBinSh](https://wiki.ubuntu.com/DashAsBinSh) Ubuntu wiki page.
*My shell works when I login but fails with the shell provisioner*
-- See the above tip. More than likely, your login shell is using `/bin/bash`
- while the provisioner is using `/bin/sh`.
+- See the above tip. More than likely, your login shell is using `/bin/bash`
+ while the provisioner is using `/bin/sh`.
*My installs hang when using `apt-get` or `yum`*
-- Make sure you add a `-y` to the command to prevent it from requiring user
- input before proceeding.
+- Make sure you add a `-y` to the command to prevent it from requiring user
+ input before proceeding.
*How do I tell what my shell script is doing?*
-- Adding a `-x` flag to the shebang at the top of the script (`#!/bin/sh -x`)
- will echo the script statements as it is executing.
+- Adding a `-x` flag to the shebang at the top of the script (`#!/bin/sh -x`)
+ will echo the script statements as it is executing.
*My builds don't always work the same*
-- Some distributions start the SSH daemon before other core services which can
- create race conditions. Your first provisioner can tell the machine to wait
- until it completely boots.
+- Some distributions start the SSH daemon before other core services which can
+ create race conditions. Your first provisioner can tell the machine to wait
+ until it completely boots.
``` {.javascript}
{
diff --git a/website/source/docs/templates/configuration-templates.html.markdown b/website/source/docs/templates/configuration-templates.html.markdown
index 9bc8f835e..c78f13956 100644
--- a/website/source/docs/templates/configuration-templates.html.markdown
+++ b/website/source/docs/templates/configuration-templates.html.markdown
@@ -57,17 +57,17 @@ While some configuration settings have local variables specific to only that
configuration, a set of functions are available globally for use in *any string*
in Packer templates. These are listed below for reference.
-- `build_name` - The name of the build being run.
-- `build_type` - The type of the builder being used currently.
-- `isotime [FORMAT]` - UTC time, which can be
- [formatted](http://golang.org/pkg/time/#example_Time_Format). See more
- examples below.
-- `lower` - Lowercases the string.
-- `pwd` - The working directory while executing Packer.
-- `template_dir` - The directory to the template for the build.
-- `timestamp` - The current Unix timestamp in UTC.
-- `uuid` - Returns a random UUID.
-- `upper` - Uppercases the string.
+- `build_name` - The name of the build being run.
+- `build_type` - The type of the builder being used currently.
+- `isotime [FORMAT]` - UTC time, which can be
+ [formatted](http://golang.org/pkg/time/#example_Time_Format). See more
+ examples below.
+- `lower` - Lowercases the string.
+- `pwd` - The working directory while executing Packer.
+- `template_dir` - The directory to the template for the build.
+- `timestamp` - The current Unix timestamp in UTC.
+- `uuid` - Returns a random UUID.
+- `upper` - Uppercases the string.
### isotime Format
@@ -112,7 +112,8 @@ Timezone
Numeric
--
+-
+
|
01
@@ -147,19 +148,24 @@ Monday (Mon)
January (Jan)
|
--
+-
+
|
--
+-
+
|
--
+-
+
|
--
+-
+
|
--
+-
+
|
MST
@@ -205,6 +211,6 @@ Please note that double quote characters need escaping inside of templates:
Specific to Amazon builders:
-- `clean_ami_name` - AMI names can only contain certain characters. This
- function will replace illegal characters with a '-" character. Example usage
- since ":" is not a legal AMI name is: `{{isotime | clean_ami_name}}`.
+- `clean_ami_name` - AMI names can only contain certain characters. This
+ function will replace illegal characters with a '-" character. Example usage
+ since ":" is not a legal AMI name is: `{{isotime | clean_ami_name}}`.
diff --git a/website/source/docs/templates/introduction.html.markdown b/website/source/docs/templates/introduction.html.markdown
index 1d67ea196..c48dc6c73 100644
--- a/website/source/docs/templates/introduction.html.markdown
+++ b/website/source/docs/templates/introduction.html.markdown
@@ -27,40 +27,41 @@ A template is a JSON object that has a set of keys configuring various
components of Packer. The available keys within a template are listed below.
Along with each key, it is noted whether it is required or not.
-- `builders` (*required*) is an array of one or more objects that defines the
- builders that will be used to create machine images for this template, and
- configures each of those builders. For more information on how to define and
- configure a builder, read the sub-section on [configuring builders in
- templates](/docs/templates/builders.html).
+- `builders` (*required*) is an array of one or more objects that defines the
+ builders that will be used to create machine images for this template, and
+ configures each of those builders. For more information on how to define and
+ configure a builder, read the sub-section on [configuring builders in
+ templates](/docs/templates/builders.html).
-- `description` (optional) is a string providing a description of what the
- template does. This output is used only in the [inspect
- command](/docs/command-line/inspect.html).
+- `description` (optional) is a string providing a description of what the
+ template does. This output is used only in the [inspect
+ command](/docs/command-line/inspect.html).
-- `min_packer_version` (optional) is a string that has a minimum Packer version
- that is required to parse the template. This can be used to ensure that proper
- versions of Packer are used with the template. A max version can't be
- specified because Packer retains backwards compatibility with `packer fix`.
+- `min_packer_version` (optional) is a string that has a minimum Packer
+ version that is required to parse the template. This can be used to ensure
+ that proper versions of Packer are used with the template. A max version
+ can't be specified because Packer retains backwards compatibility with
+ `packer fix`.
-- `post-processors` (optional) is an array of one or more objects that defines
- the various post-processing steps to take with the built images. If not
- specified, then no post-processing will be done. For more information on what
- post-processors do and how they're defined, read the sub-section on
- [configuring post-processors in
- templates](/docs/templates/post-processors.html).
+- `post-processors` (optional) is an array of one or more objects that defines
+ the various post-processing steps to take with the built images. If not
+ specified, then no post-processing will be done. For more information on
+ what post-processors do and how they're defined, read the sub-section on
+ [configuring post-processors in
+ templates](/docs/templates/post-processors.html).
-- `provisioners` (optional) is an array of one or more objects that defines the
- provisioners that will be used to install and configure software for the
- machines created by each of the builders. If it is not specified, then no
- provisioners will be run. For more information on how to define and configure
- a provisioner, read the sub-section on [configuring provisioners in
- templates](/docs/templates/provisioners.html).
+- `provisioners` (optional) is an array of one or more objects that defines
+ the provisioners that will be used to install and configure software for the
+ machines created by each of the builders. If it is not specified, then no
+ provisioners will be run. For more information on how to define and
+ configure a provisioner, read the sub-section on [configuring provisioners
+ in templates](/docs/templates/provisioners.html).
-- `variables` (optional) is an array of one or more key/value strings that
- defines user variables contained in the template. If it is not specified, then
- no variables are defined. For more information on how to define and use user
- variables, read the sub-section on [user variables in
- templates](/docs/templates/user-variables.html).
+- `variables` (optional) is an array of one or more key/value strings that
+ defines user variables contained in the template. If it is not specified,
+ then no variables are defined. For more information on how to define and use
+ user variables, read the sub-section on [user variables in
+ templates](/docs/templates/user-variables.html).
## Comments
diff --git a/website/source/docs/templates/push.html.markdown b/website/source/docs/templates/push.html.markdown
index 3ca2c2de2..b46bef3e8 100644
--- a/website/source/docs/templates/push.html.markdown
+++ b/website/source/docs/templates/push.html.markdown
@@ -37,31 +37,31 @@ each category, the available configuration keys are alphabetized.
### Required
-- `name` (string) - Name of the build configuration in the build service. If
- this doesn't exist, it will be created (by default).
+- `name` (string) - Name of the build configuration in the build service. If
+ this doesn't exist, it will be created (by default).
### Optional
-- `address` (string) - The address of the build service to use. By default this
- is `https://atlas.hashicorp.com`.
+- `address` (string) - The address of the build service to use. By default
+ this is `https://atlas.hashicorp.com`.
-- `base_dir` (string) - The base directory of the files to upload. This will be
- the current working directory when the build service executes your template.
- This path is relative to the template.
+- `base_dir` (string) - The base directory of the files to upload. This will
+ be the current working directory when the build service executes
+ your template. This path is relative to the template.
-- `include` (array of strings) - Glob patterns to include relative to the
- `base_dir`. If this is specified, only files that match the include pattern
- are included.
+- `include` (array of strings) - Glob patterns to include relative to the
+ `base_dir`. If this is specified, only files that match the include pattern
+ are included.
-- `exclude` (array of strings) - Glob patterns to exclude relative to the
- `base_dir`.
+- `exclude` (array of strings) - Glob patterns to exclude relative to the
+ `base_dir`.
-- `token` (string) - An access token to use to authenticate to the
- build service.
+- `token` (string) - An access token to use to authenticate to the
+ build service.
-- `vcs` (boolean) - If true, Packer will detect your VCS (if there is one) and
- only upload the files that are tracked by the VCS. This is useful for
- automatically excluding ignored files. This defaults to false.
+- `vcs` (boolean) - If true, Packer will detect your VCS (if there is one) and
+ only upload the files that are tracked by the VCS. This is useful for
+ automatically excluding ignored files. This defaults to false.
## Examples
diff --git a/website/source/intro/platforms.html.markdown b/website/source/intro/platforms.html.markdown
index 586c0c4ec..86d71545e 100644
--- a/website/source/intro/platforms.html.markdown
+++ b/website/source/intro/platforms.html.markdown
@@ -33,40 +33,42 @@ is noted. They are listed in alphabetical order. For more detailed information
on supported configuration parameters and usage, please see the appropriate
[documentation page within the documentation section](/docs).
-- ***Amazon EC2 (AMI)***. Both EBS-backed and instance-store AMIs within
- [EC2](http://aws.amazon.com/ec2/), optionally distributed to multiple regions.
+- ***Amazon EC2 (AMI)***. Both EBS-backed and instance-store AMIs within
+ [EC2](http://aws.amazon.com/ec2/), optionally distributed to
+ multiple regions.
-- ***DigitalOcean***. Snapshots for [DigitalOcean](http://www.digitalocean.com/)
- that can be used to start a pre-configured DigitalOcean instance of any size.
+- ***DigitalOcean***. Snapshots for
+ [DigitalOcean](http://www.digitalocean.com/) that can be used to start a
+ pre-configured DigitalOcean instance of any size.
-- ***Docker***. Snapshots for [Docker](http://www.docker.io/) that can be used
- to start a pre-configured Docker instance.
+- ***Docker***. Snapshots for [Docker](http://www.docker.io/) that can be used
+ to start a pre-configured Docker instance.
-- ***Google Compute Engine***. Snapshots for [Google Compute
- Engine](https://cloud.google.com/products/compute-engine) that can be used to
- start a pre-configured Google Compute Engine instance.
+- ***Google Compute Engine***. Snapshots for [Google Compute
+ Engine](https://cloud.google.com/products/compute-engine) that can be used
+ to start a pre-configured Google Compute Engine instance.
-- ***OpenStack***. Images for [OpenStack](http://www.openstack.org/) that can be
- used to start pre-configured OpenStack servers.
+- ***OpenStack***. Images for [OpenStack](http://www.openstack.org/) that can
+ be used to start pre-configured OpenStack servers.
-- ***Parallels (PVM)***. Exported virtual machines for
- [Parallels](http://www.parallels.com/downloads/desktop/), including virtual
- machine metadata such as RAM, CPUs, etc. These virtual machines are portable
- and can be started on any platform Parallels runs on.
+- ***Parallels (PVM)***. Exported virtual machines for
+ [Parallels](http://www.parallels.com/downloads/desktop/), including virtual
+ machine metadata such as RAM, CPUs, etc. These virtual machines are portable
+ and can be started on any platform Parallels runs on.
-- ***QEMU***. Images for [KVM](http://www.linux-kvm.org/) or
- [Xen](http://www.xenproject.org/) that can be used to start pre-configured KVM
- or Xen instances.
+- ***QEMU***. Images for [KVM](http://www.linux-kvm.org/) or
+ [Xen](http://www.xenproject.org/) that can be used to start pre-configured
+ KVM or Xen instances.
-- ***VirtualBox (OVF)***. Exported virtual machines for
- [VirtualBox](https://www.virtualbox.org/), including virtual machine metadata
- such as RAM, CPUs, etc. These virtual machines are portable and can be started
- on any platform VirtualBox runs on.
+- ***VirtualBox (OVF)***. Exported virtual machines for
+ [VirtualBox](https://www.virtualbox.org/), including virtual machine
+ metadata such as RAM, CPUs, etc. These virtual machines are portable and can
+ be started on any platform VirtualBox runs on.
-- ***VMware (VMX)***. Exported virtual machines for
- [VMware](http://www.vmware.com/) that can be run within any desktop products
- such as Fusion, Player, or Workstation, as well as server products such
- as vSphere.
+- ***VMware (VMX)***. Exported virtual machines for
+ [VMware](http://www.vmware.com/) that can be run within any desktop products
+ such as Fusion, Player, or Workstation, as well as server products such
+ as vSphere.
As previously mentioned, these are just the target image types that Packer ships
with out of the box. You can always [extend Packer through
|