hashicorp / packer-plugin-chef

This Packer provisioner is no longer being maintained and has been archived. Users are encouraged to use the shell or shell-local provisioner to run the provisioning tools made available by this plugin. If interested in maintaining this plugin please reach out to us at [email protected].

Packer Plugin Chef

The Chef multi-component plugin can be used with HashiCorp Packer to create custom images. For the full list of available features for this plugin see docs.

Installation

Using pre-built releases

Using the packer init command

Starting from version 1.7, Packer supports a new packer init command allowing automatic installation of Packer plugins. Read the Packer documentation for more information.

To install this plugin, copy and paste this code into your Packer configuration . Then, run packer init.

packer {
  required_plugins {
    chef = {
      version = ">= 1.0.0"
      source  = "github.com/hashicorp/chef"
    }
  }
}

Manual installation

You can find pre-built binary releases of the plugin here. Once you have downloaded the latest archive corresponding to your target OS, uncompress it to retrieve the plugin binary file corresponding to your platform. To install the plugin, please follow the Packer documentation on installing a plugin.

From Sources

If you prefer to build the plugin from sources, clone the GitHub repository locally and run the command go build from the root directory. Upon successful compilation, a packer-plugin-chef plugin binary file can be found in the root directory. To install the compiled plugin, please follow the official Packer documentation on installing a plugin.

Configuration

For more information on how to configure the plugin, please read the documentation located in the docs/ directory.

Contributing

• If you think you've found a bug in the code or you have a question regarding the usage of this software, please reach out to us by opening an issue in this GitHub repository.
• Contributions to this project are welcome: if you want to add a feature or a fix a bug, please do so by opening a Pull Request in this GitHub repository. In case of feature contribution, we kindly ask you to open an issue to discuss it beforehand.

packer-plugin-chef's Issues

Unable to connect from chef-client to chef-server using packer chef-client provisioner Packer

This issue was originally opened by @sushantifi as hashicorp/packer#10510. It was migrated here as a result of the Packer plugin split. The original body of the issue is below.

---

i have been trying to install chef-client using packer in azure vm windows 2016 datacenter image but after creating image i checked in chef workstation that the image with chef-client configuration machine is not connected to chef server.

Is it necessary to perform knife command manually? but knife commands need private IP of vm so how can image with chef-client configuration will auto connect to the chef server?

Here is template code that i have tried:

{

"type": "chef-client",

"install_command": "powershell.exe -Command (New-Object System.Net.WebClient).DownloadFile('http://chef.io/chef/install.msi', 'C:\\Windows\\Temp\\chef.msi');Start-Process 'msiexec' -ArgumentList '/qb /i C:\\Windows\\Temp\\chef.msi' -NoNewWindow -Wait",

"Server_Url": "https://api.chef.io/organizations/xyz",

"Guest_Os_Type": "Windows",

"Chef_Environment": "",

"Ssl_Verify_Mode": "Verify_None",

"chef_license": "accept",

"Validation_Client_Name": "xyz94",

"Validation_Key_Path": "C:/packer/packer-repo/packer-master/DE/setup_files/xyz94.pem",

"Skip_Clean_Client": "True",

"Skip_Clean_Node": "False"

    

},

Help with unmaintained community provisioner plugins

This issue was originally opened by @nywilken as hashicorp/packer#10901. It was migrated here as a result of the Packer plugin split. The original body of the issue is below.

---

Hello Packer Community,

For some time, the best practice amongst Packer users has been to use shell and shell-local provisioners to execute Chef, Salt and Puppet, but due to early first-class integrations we have maintained the plugins below for over four years. The Packer team is currently supportive of 3rd parties maintaining first-class plugins for these, but in absence of that recommends the more common approach of installing and running these tools are via the shell or shell-local provisioners.

We are reaching out today to inform you that the following popular community plugins are unmaintained:

• chef-client
• chef-solo
• puppet-masterless
• puppet-server
• salt-masterless

Unmaintained plugins are no longer under active development and are only being updated by the Packer team on a best effort basis.

In the v1.8.0 release of Packer, we will be extracting all non-core plugins currently bundled with Packer to improve the overall user experience of installing and working with third-party plugins. An issue that is being tracked in hashicorp/packer#8610.

During the extraction any plugin that is found to be unmaintained will be archived to let users know that the plugin is no longer being maintained.

We understand that these plugins may be critical to existing user workflows so we are seeking maintainers who can continue developing and releasing these plugins. If you are interested in maintaining one or more of the plugins listed above please reach out to us at [email protected].

FAQs

1. What are the responsibilities in maintaining a community plugin?

Community plugins are made available by the community, for the community to be used with Packer. By maintaining a plugin, you will be responsible for the development, release, and ongoing support of the plugin.
The responsibilities of development include:
1. Assisting with the migration of the plugin code base, and git history, into a GitHub repository under your respective organization (e.g github.com//packer-plugin-).
1. Updating the code base to work with new versions of Packer.
1. Reviewing issues and pull-requests opened against the plugin repository in a timely manner.
1. Releasing new versions of the plugin binary that are compatible with Packer - See Creating a Release for more details.

2. How do I as a new plugin maintainer gain access to the code base?

The Packer team will provide a document, along with the accompanying script(s) for extracting a community plugin (with all relevant Git history) out of hashicorp/packer into a new GitHub repository. If necessary there may be an intermediate step where a plugin is extracted into a repository under the HashiCorp GitHub organization, and then transferred to the new repository.

Due to GitHub permission issues, the transferring of issues will need to be done separately.

3. What happens to an active plugin that is no longer being maintained?

Plugins that are not actively maintained will be marked as unmaintained on their respective documentation pages, and scheduled for archival. We will try to find a new owner. If no owner can be found then HashiCorp will follow the process for archiving a plugin that has no owner.

4. What does it mean for a plugin to be archived?

A plugin that does not have an owner will be broken out into its own repository under the HashiCorp GitHub organization. The new repository will then be archived to let users know that the plugin is no longer being maintained. Upon the initial breakout, a final compatible release of the plugin will be made, but it will not be actively maintained or monitored for new issues. Critical security-related issues will be reviewed and addressed where possible.

Chef provisioner key/value validation happens too early and out of order

This issue was originally opened by @heathsnow as hashicorp/packer#8002. It was migrated here as a result of the Packer plugin split. The original body of the issue is below.

---

• Packer version: 1.4.3 and 1.3.3 (maybe all versions?)
• Host platform: Ubuntu
• Debug log output from PACKER_LOG=1 packer build template.json: https://gist.github.com/heathsnow/f8f4a3607d5caf158d9afca3398f3935

The provisioners documentation states that "The provisioners will be run in the order they are defined within the template.". I have a shell provisioner that creates the encrypted_data_bag_secret_path key value used by the chef-client provisioner.

However there seems to be some validation happening early on that checks to ensure the value entered for that key exists and it causes packer to fail with the error: "* Bad encrypted data bag secret '/etc/chef/encrypted_data_bag_secret': stat /etc/chef/encrypted_data_bag_secret: no such file or directory".

It doesn't exist because the shell provisioner right before the chef-client provisioner isn't getting a chance to run. I'd like to get my encrypted key from AWS Parameter Store with the shell script and then have the chef-client provisioner use it.

Policyfile Support for chef-solo provisioner

This issue was originally opened by @DWSR as hashicorp/packer#6992. It was migrated here as a result of the Packer plugin split. The original body of the issue is below.

---

Similar to hashicorp/packer#5574

Policyfile support should be added to the chef-solo provisioner, similar to how it is supported by the chef-client provisioner. I believe the reason the original PR didn't address the deficiency in the Solo provisioner was due to some uncertainty around using Policyfiles with it. There is an example here on how this works (also illustrating how to use chef export to bundle everything up). Additionally, since chef-solo is now just chef-client in Local Mode, there is definitely support for Policyfiles.

Ideally, it would be nice to be able to use the same control mechanisms in both my provisioning pipeline and my actual production environment.

chef-solo provision fails on ubuntu after downloading partial installer

This issue was originally opened by @seven10builder as hashicorp/packer#5796. It was migrated here as a result of the Packer plugin split. The original body of the issue is below.

---

when using the chef-solo provisioner and the vsphere builder (from here), I get a consistent error when trying to download the chef installer on the newly spun up host. The error is always the same:
vsphere: curl: (23) Failed writing body (1755 != 2759)
The log gist (see below) contains the greater body of the error, but it appears it is encountering an error when writing to stderr.

• Packer version: 1.1.3

• Host platform: Ubuntu 16.04

• Debug log output from PACKER_LOG=1 packer build template.json:
  https://gist.github.com/seven10builder/cbb11dafddf2d51ee9977feeb35d16da

• The simplest example template and scripts needed to reproduce the bug.
  in previous gist.

If a reboot resource is used in a chef provisioner packer fails

This issue was originally opened by @tas50 as hashicorp/packer#6346. It was migrated here as a result of the Packer plugin split. The original body of the issue is below.

---

Chef includes a reboot resource which allows rebooting a system (imagine that). When the reboot resource runs it exits the Chef client with an exit code of 35. This code is considered a non-fatal code in Chef, but packer is picking that up as a failure and fails the whole build.

    virtualbox-iso:   * reboot[now] action reboot_now[2018-06-05T15:50:17-07:00] WARN: Rebooting system immediately, requested by 'now'
    virtualbox-iso: [2018-06-05T15:50:17-07:00] WARN: Rebooting system immediately, requested by 'now'
    virtualbox-iso:
    virtualbox-iso:
    virtualbox-iso:     Running handlers:
    virtualbox-iso:     Running handlers complete
    virtualbox-iso:     Chef Client finished, 30/38 resources updated in 02 minutes 52 seconds
    virtualbox-iso: [2018-06-05T15:50:17-07:00] WARN: Rebooting server at a recipe's request. Details: {:delay_mins=>0, :reason=>"Reboot by Chef", :timestamp=>2018-06-05 15:50:17 -0700, :requested_by=>"now"}
    virtualbox-iso: [2018-06-05T15:50:17-07:00] WARN: Rebooting server at a recipe's request. Details: {:delay_mins=>0, :reason=>"Reboot by Chef", :timestamp=>2018-06-05 15:50:17 -0700, :requested_by=>"now"}
    virtualbox-iso:
    virtualbox-iso:     Running handlers:
    virtualbox-iso: [2018-06-05T15:50:17-07:00] ERROR: Running exception handlers
    virtualbox-iso: [2018-06-05T15:50:17-07:00] ERROR: Running exception handlers
    virtualbox-iso:     Running handlers complete
    virtualbox-iso: [2018-06-05T15:50:17-07:00] ERROR: Exception handlers complete
    virtualbox-iso: [2018-06-05T15:50:17-07:00] ERROR: Exception handlers complete
    virtualbox-iso:     Chef Client failed. 30 resources updated in 02 minutes 52 seconds
    virtualbox-iso: [2018-06-05T15:50:17-07:00] FATAL: Stacktrace dumped to c:/windows/temp/packer-chef-solo/local-mode-cache/cache/chef-stacktrace.out
    virtualbox-iso: [2018-06-05T15:50:17-07:00] FATAL: Stacktrace dumped to c:/windows/temp/packer-chef-solo/local-mode-cache/cache/chef-stacktrace.out
    virtualbox-iso: [2018-06-05T15:50:17-07:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
    virtualbox-iso: [2018-06-05T15:50:17-07:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
    virtualbox-iso: [2018-06-05T15:50:17-07:00] FATAL: Chef::Exceptions::Reboot: Rebooting server at a recipe's request. Details: {:delay_mins=>0, :reason=>"Reboot by Chef", :timestamp=>2018-06-05 15:50:17 -0700, :requested_by=>"now"}
    virtualbox-iso: [2018-06-05T15:50:17-07:00] FATAL: Chef::Exceptions::Reboot: Rebooting server at a recipe's request. Details: {:delay_mins=>0, :reason=>"Reboot by Chef", :timestamp=>2018-06-05 15:50:17 -0700, :requested_by=>"now"}
==> virtualbox-iso: Deregistering and deleting VM...
==> virtualbox-iso: Deleting output directory...
Build 'virtualbox-iso' errored: Error executing Chef: Non-zero exit status: 35

==> Some builds didn't complete successfully and had errors:
--> virtualbox-iso: Error executing Chef: Non-zero exit status: 35

==> Builds finished but no artifacts were created.

Feature: chef-stacktrace.out difficult to retrieve

This issue was originally opened by @tehlers320 as hashicorp/packer#4793. It was migrated here as a result of the Packer plugin split. The original body of the issue is below.

---

Packer should by default output the chef stacktrace on this provisioner.

chef-solo builder multiple cookbooks in the chef_run_list

This issue was originally opened by @johnypony3 as hashicorp/packer#10788. It was migrated here as a result of the Packer plugin split. The original body of the issue is below.

---

Hi,
In the documentation, it shows that chef_run_list is an array of strings. I have tried every single combination of strings that make sense and I get one of three errors:

• go unmarshalling error
• chef-solo error where it doesnt understand the list of cookbooks
• chef-solo error where the run list is empty

I have had to resort tomaking a role.
If possible, please provide the proper syntax for passing in a runlist of two cookbooks ie:

• bingo::default
• bongo::default

or

• recipe[bingo]
• recipe[bongo]

thank you, its really appreciated!

Implement json_string attribute on chef-client provisioner

This issue was originally opened by @justme1121 as hashicorp/packer#10871. It was migrated here as a result of the Packer plugin split. The original body of the issue is below.

---

Overview of the Issue

This the same as hashicorp/packer#10532 except this is for the chef-client provisioner instead of chef-solo.

Packer version
1.7.1

Feature request: "overlay" property similar to "override"

This issue was originally opened by @curiositycasualty as hashicorp/packer#7239. It was migrated here as a result of the Packer plugin split. The original body of the issue is below.

---

    {
      "node_name": "{{build_name}}-{{timestamp}}",
      "run_list": [
        "recipe[foo::recipe]"
      ],
      "overlay": {
        "alpha": {
          "run_list": [
            "recipe[bar::recipe]"
          ]
        }
      },
      "type": "chef-client"
    }

Would produce a chef provisioner with a "run_list" of "recipe[foo::recipe],recipe[bar::recipe]".

chef-client provisioner failing on Windows Server 2012 R2: Failed to read the private key

This issue was originally opened by @kbrowns as hashicorp/packer#6366. It was migrated here as a result of the Packer plugin split. The original body of the issue is below.

---

I'm seeing issues with the chef-provisioner starting in build 1.2.0. I"m pretty confident the issue is a bug because downgrading packer to 1.1.3 reliably fixes the issue, but if I upgrade to any version above that (1.2.0+) I reliably see failures with the chef-client being unable to find private key. Full log is listed below, but the consistent failure I see is:

        csg-simple-packer-build: 'skipping chmod 0777 C:/Windows/Temp/packer-chef-client'

        csg-simple-packer-build: Uploading ****...

        csg-simple-packer-build: Creating configuration file 'client.rb'

        csg-simple-packer-build: Creating JSON attribute file

        csg-simple-packer-build: Executing Chef: c:/opscode/chef/bin/chef-client.bat --no-color -c C:/Windows/Temp/packer-chef-client/client.rb -j C:/Windows/Temp/packer-chef-client/first-boot.json

        csg-simple-packer-build: Creating configuration file 'knife.rb'

    ==> csg-simple-packer-build: Cleaning up chef node...

        csg-simple-packer-build: WARN: Failed to read the private key C:/Windows/Temp/packer-chef-client/client.pem: #<Errno::ENOENT: No such file or directory @ rb_sysopen - C:/Windows/Temp/packer-chef-client/client.pem>

        csg-simple-packer-build: ERROR: Your private key could not be loaded from C:/Windows/Temp/packer-chef-client/client.pem

        csg-simple-packer-build: Check your configuration file and ensure that your private key is readable

    ==> csg-simple-packer-build: Terminating the source AWS instance...

==> csg-simple-packer-build: Cleaning up any extra volumes...

    ==> csg-simple-packer-build: No volumes to clean up, skipping

    Build 'csg-simple-packer-build' errored: Error cleaning up chef node: Failed to cleanup node: Non-zero exit status. See output above for more info.

Given that it's complaining there is no client.pem, this seems to suggest that the bootstrap process is somehow short circuited - i.e. the validation key is not uploaded an used maybe?

• Packer version: issues appears to start in 1.2.0 and remains in 1.2.1, 1.2.2, 1.2.3, and 1.2.4. 1.1.3 works
• Host platform: AWS Linux 1 host building Windows Server 2012 R2
• Debug log output from PACKER_LOG=1 packer build template.json: debug output
• Reproduction steps: packer.json

[Chef-solo] roles_path is ignored by chef-solo provisionner

This issue was originally opened by @sogos as hashicorp/packer#3298. It was migrated here as a result of the Packer plugin split. The original body of the issue is below.

---

When i use this snippet

{
    "type": "chef-solo",
    "install_command": "curl -L https://www.chef.io/chef/install.sh | {{if .Sudo}}sudo {{end}}bash -s -- -v 12.6.0",
    "cookbook_paths": ["{{user `cookbook_paths`}}"],
    "environments_path": "{{user `environments_path`}}",
    "roles_path":  "{{user `chef_roles_path`}}",
    "data_bags_path": "{{user `data_bags_path`}}",
    "encrypted_data_bag_secret_path": "{{user `encrypted_data_bag_secret_path`}}",
    "chef_environment": "build",
    "run_list": ["role[webserver]"]
}

The solo.rb is not filled with roles_path and role directory is not uploaded to staging_directory

    virtualbox-iso: Creating directory: /tmp/packer-chef-solo
    virtualbox-iso: Creating directory: /tmp/packer-chef-solo/cookbooks-0
    virtualbox-iso: Creating directory: /tmp/packer-chef-solo/data_bags
    virtualbox-iso: Creating configuration file 'solo.rb'
    virtualbox-iso: Creating JSON attribute file
    virtualbox-iso: Executing Chef: sudo chef-solo --no-color -c /tmp/packer-chef-solo/solo.rb -j /tmp/packer-chef-solo/node.json
    virtualbox-iso: [2016-03-01T16:34:45+01:00] INFO: Forking chef instance to converge...
    virtualbox-iso: [2016-03-01T16:34:45+01:00] INFO: *** Chef 12.6.0 ***
    virtualbox-iso: [2016-03-01T16:34:45+01:00] INFO: Chef-client pid: 1312
    virtualbox-iso: [2016-03-01T16:34:47+01:00] INFO: Setting the run_list to ["role[ugo-vm]"] from CLI options
    virtualbox-iso: [2016-03-01T16:34:47+01:00] ERROR: Role webserver (included by 'top level') is in the runlist but does not exist. Skipping expand.

I use "packer_0.9.0_darwin_amd64"

Thanks