Ohai Chefs,
Today, we’re excited to announce that Chef Client 12.1.0 is now available. This release brings with it many new features and bug fixes. Below are some of the highlights. For more information, check out the changelog, release notes, and doc changes.
## What’s New
### chef_gem deprecation of installation at compile time
A `compile_time` flag has been added to the chef_gem resource to control if it is installed at `compile_time` or not. The prior behavior has been that this
resource forces itself to install at `compile_time` which is problematic since if the gem is native it `forces build_essentials` and other dependent libraries
to have to be installed at `compile_time` in an escalating war of forcing compile time execution. This default was engineered before it was understood that a better
approach was to lazily require gems inside of provider code which only ran at converge time and that requiring gems in recipe code was bad practice.
The default behavior has not changed, but every `chef_gem` resource will now emit out a warning:
[2015-02-06T13:13:48-08:00] WARN: chef_gem[aws-sdk] chef_gem compile_time installation is deprecated
[2015-02-06T13:13:48-08:00] WARN: chef_gem[aws-sdk] Please set `compile_time false` on the resource to use the new behavior.
[2015-02-06T13:13:48-08:00] WARN: chef_gem[aws-sdk] or set `compile_time true` on the resource if compile_time behavior is required.
The preferred way to fix this is to make every `chef_gem` resource explicit about compile_time installation (keeping in mind the best-practice to default to false
unless there is a reason):
chef_gem ‘aws-sdk’ do
compile_time false
end
[/ruby]
There is also a `Chef::Config[:chef_gem_compile_time]` flag which has been added. If this is set to true (not recommended) then chef will only emit a single
warning at the top of the chef-client run:
[2015-02-06T13:27:35-08:00] WARN: setting chef_gem_compile_time to true is deprecated
It will behave like Chef 10 and Chef 11 and will default `chef_gem` to `compile_time` installations and will suppress
subsequent warnings in the chef-client run.
If this setting is changed to ‘false’ then it will adopt Chef-13 style behavior and will default all `chef_gem` installs to not run at compile_time by default. This
may break existing cookbooks.
* All existing cookbooks which require `compile_time true` MUST be updated to be explicit about this setting.
* To be considered high quality, cookbooks which require `compile_time true` MUST be rewritten to avoid this setting.
* All existing cookbooks which do not require `compile_time true` SHOULD be updated to be explicit about this setting.
For cookbooks that need to maintain backwards compatibility a `respond_to?` check should be used:
chef_gem ‘aws-sdk’ do
compile_time false if respond_to?(:compile_time)
end
[/ruby]
### Experimental Audit Mode Feature
This is a new feature intended to provide _infrastructure audits_. Chef already allows you to configure your infrastructure
with code, but there are some use cases that are not covered by resource convergence. What if you want to check that
the application Chef just installed is functioning correctly? If it provides a status page an audit can check this
and validate that the application has database connectivity.
Audits are performed by leveraging Serverspec and RSpec on the
node. As such the syntax is very similar to a normal RSpec spec.
#### Syntax
control_group “Database Audit” do
control “postgres package” do
it “should not be installed” do
expect(package(“postgresql”)).to_not be_installed
end
end
let(:p) { port(111) }
control p do
it “has nothing listening” do
expect(p).to_not be_listening
end
end
end
[/ruby]
Using the example above I will break down the components of an Audit:
* `control_group` – This named block contains all the audits to be performed during the audit phase. During Chef convergence
the audits will be collected and ran in a separate phase at the end of the Chef run. Any `control_group` block defined in
a recipe that is ran on the node will be performed.
* `control` – This keyword describes a section of audits to perform. The name here should either be a string describing
the system under test, or a Serverspec resource.
* `it` – Inside this block you can use RSpec expectations to
write the audits. You can use the Serverspec resources here or regular ruby code. Any raised errors will fail the
audit.
#### Output and error handling
Output from the audit run will appear in your `Chef::Config[:log_location]`. If an audit fails then Chef will raise
an error and exit with a non-zero status.
#### Further reading
More information about the audit mode can be found in its RFC
### OpenBSD Package provider was added
The package resource on OpenBSD is wired up to use the new OpenBSD package provider to install via `pkg_add` on OpenBSD systems.
### Case Insensitive URI Handling
Previously, when a URI scheme contained all uppercase letters, Chef
would reject the URI as invalid. In compliance with RFC3986, Chef now
treats URI schemes in a case insensitive manner.
### File Content Verification (RFC 027)
Per RFC 027, the file and file-like resources now accept a `verify`
attribute. This attribute accepts a string(shell command) or a ruby
block (similar to `only_if`) which can be used to verify the contents
of a rendered template before deploying it to disk.
### Drop SSL Warnings
Now that the default for SSL checking is on, no more warning is emitted when SSL
checking is off.
### Multi-package Support
The `package` provider has been extended to support multiple packages. This
support is new and and not all subproviders yet support it. Full support for
`apt` and `yum` has been implemented.
As an example, you can now do something like this:
“`apt_package [“xml2-dev”, “xslt-dev”]“`
### Knife Bootstrap Validatorless Bootstraps and Chef Vault integration
The knife bootstrap command now supports validatorless bootstraps. This can be enabled via deleting the validation key.
When the validation key is not present, knife bootstrap will use the user key in order to create a client for the node
being bootstrapped. It will also then create a node object and set the environment, run\_list, initial attributes, etc (avoiding
the problem of the first chef-client failing and not saving the node’s run\_list correctly).
Also knife vault integration has been added so that knife bootstrap can use the client key to add chef vault items to
the node, reducing the number of steps necessary to bootstrap a node with chef vault.
There is no support for validatorless bootstraps when the node object has been precreated by the user beforehand, as part
of the process any old node or client will be deleted when doing validatorless bootstraps. The old process with the validation
key still works for this use case. The setting of the run_list, environment and json attributes first via knife bootstrap
should mitigate some of the need to precreate the node object by hand first.
### Windows service now has a configurable timeout
You can now set the amount of time a chef-client run is allowed when running the provided windows service. This can be configured by
setting `windows_service.watchdog_timeout` in your `client.rb` to the number of seconds desired. The default value is 2 hours.
## How do I get it?
You can visit our download page.
Additionally you can use this command to download the latest version of the Chef Client on platforms other than windows:
curl -L https://www.chef.io/chef/install.sh | sudo bash -s -\- -v 12.1.0
For Windows, you can download this version using this link: Chef Client 12.1.0
## Get Help
If you run into any issues with this release, please file an issue on Github or drop an email on our chef and chef-dev mailing lists.
