Careers

Chef Client 12.2.0 Released

Update Sat Mar 28 00:28:04 UTC 2015: Chef 12.2.0 has a regression that will prevent you from running chef-client in situations where the HOME environment variable is unset.This will likely break anybody running chef-client as a service. We are currently working on getting a release out.
For now, if you are running chef-client as a service, it’s probably best to wait for 12.2.1 before upgrading.

We’ve just released Chef Client 12.2.0. This release includes bug fixes as well couple of new goodies… we hope you enjoy them. You can check out the CHANGELOG for a full set of the changes.

# What’s New
## Policyfile Chef Server 12.0.7 Compatibility

Chef Server 12.0.7 will contain the minimum necessary functioning
implementation of Policyfiles to converge a node. Policyfile “native
mode” is updated to work with the APIs in Chef Server 12.0.7. Note that
Chef Server 12.0.7 will likely not ship with the necessary code to
upgrade existing organizations, so you will need to set some special
configuration to opt-in to enabling the Policyfile APIs in Chef Server.
That process will be described in the release notes for Chef Server.

## Desired State Configuration (DSC) Resource

If you are using `Windows Management Framework(WMF) 5`, you can now take advantage of the new `dsc_resource`.
This new functionality takes advantage of WMF 5’s `Invoke-DscResource` cmdlet to
directly invoke resources.

### Prerequisites

To use this new resource, you must have the February preview of WMF 5.
This can be installed using the Powershell cookbook. It is also required that
the Local Configuration Manager(LCM) be configured with a `RefreshMode` of `Disabled`.
Doing this will preclude you from using `dsc_script`. Below we provide an example
DSC configuration:

# Run the configuration command and generate the meta.mof to configure
# a local configuration manager
LCMSettings

# Apply the local configuration manager settings found in the LCMSettings
# folder (by default configurations are generated to a folder in the current
# working directory named for the configuration command name
Set-DscLocalConfigurationManager -path ./LCMSettings

[/powershell]

Running this script tells the LCM not to do document management, allowing Chef to
take over that role. While you may be able to switch this to other values mid-run,
you should not be doing this to run both `dsc_script` and `dsc_resource` resources.

### Usage

Once the LCM is correctly configured, you can begin using `dsc_resource` in your recipes.
You can get a list of available by running the `Get-DscResource` command. You will be
able to use any resource that does not have an `ImplementedAs` property with value
`Composite`.

As an example, let’s consider the `User` dsc resource. Start by taking a look
at what a DSC `User` resource would look like

From above, the `User` resource has a require property `UserName`, however we’re probably
also going to want to prover at the very least a `Password`. From above, we can see the `UserName`
property must be of type string, and `Password` needs to be of type `PSCredential`. Since there
is no native Ruby type that maps to a Powershell PSCredential, a dsl method `ps_credential` is
provided that makes creating this simple. `ps_credential` can be called as `ps_credential(password)`
or `ps_credential(username, password)`. Under the hood, this creates a
`Chef::Util::Powershell::PSCredential` which gets serialized into a Powershell PSCredential.

The following type translations are supported:

Ruby Type

Powershell Type

Fixnum

Integer

Float

Doule

FalseClass

$false

TrueClass

$true

Chef::Util::Powershell:PSCredential

PSCredential

Hash

Hashtable

Array

Object[]

With this information in hand, we can now construct a Chef `dsc_resource` resource that creates
a user.

#### Third Party Resources
`dsc_resource` also supports the use of 3rd party DSC resources, for example the DSC Resource Kit. These
resources can be used just like you would use any `PSDesiredStateConfiguration` resource like `User`. Since
the implementation of `dsc_resource` knows how to talk to DSC resources that are visible through the
`Get-DscResource` cmdlet, it should just work. For example, if we wanted to use `xSmbShare`, we could
construct the powershell resource as

to look up the module name, and in this case use `xSmbShare`. However, this lookup process can slow down
the process. It is also possible that there are multiple DSC resources with that name. To address these
cases, `dsc_resource` provides an aditional attribute `module_name`. You can pass the name of the module
that the resource comes from, and `dsc_resource` will make sure that it uses that module. This will
short-circuit any logic to lookup the module name, shortening the time it takes to execute the resource.

### Notes

– The implementation of `dsc_resource` is base on the experimental `Invoke-DscResource` cmdlet

# How do I get it?
You can visit our [download page](https://www.chef.io/download-chef-client/).

Additionally you can use this command to download the latest version of the Chef Client on platforms other than windows:

For Windows, you can download this version using this link: [Chef Client 12.2.0](https://opscode-omnibus-packages.s3.amazonaws.com/windows/2008r2/x86_64/chef-client-12.2.0-1.msi)

# Get Help
If you run into any issues with this release, please file an [issue on Github](https://github.com/chef/chef/issues/new) or drop an email on our [chef](http://lists.opscode.com/sympa/info/chef) and [chef-dev](http://lists.opscode.com/sympa/info/chef-dev) mailing lists.