Ohai Chefs,
We’ve just released Chef Client 12.4.0. This release has a lot of new things:
Better logging options, Windows experience improvements, Resource DSL enhancements, and much more. You can read about some of the changes below. A full list of changes can be found in the changelog.
# What’s New
### Knife Key Management Commands for Users and Clients in Chef Server 12.1
`knife user` and `knife client` now have a suite of subcommands that live under
the `key` subcommand. These subcommands allow you to list, show, create, delete
and edit keys for a given user or client. They can be used to implement
key rotation with multiple expiring keys for a single actor or just
for basic key management. See `knife user key` and `knife client key`
for a full list of subcommands and their usage.
### System Loggers
You can now have all Chef logs sent to a logging system of your choice.
#### Syslog Logger
Syslog can be used by adding the following line to your chef config
file:
[ruby]
log\_location Chef::Log::Syslog.new(“chef-client”, ::Syslog::LOG\_DAEMON)
[/ruby]
This will write to the `daemon` facility with the originator set as
`chef-client`.
#### Windows Event Logger
The logger can be used by adding the following line to your chef config file:
[ruby]
log\_location Chef::Log::WinEvt.new
[/ruby]
This will write to the Application log with the source set as Chef.
### RemoteFile resource supports UNC paths on Windows
You can now use UNC paths with `remote_file` on Windows machines. For
example, you can get `Foo.tar.gz` off of `fooshare` on `foohost` using
the following resource:
[ruby]
remote\_file ‘C:\Foo.tar.gz’ do
source “\\\\foohost\\fooshare\\Foo.tar.gz”
end
[/ruby]
### WindowsPackage resource supports URLs
The `windows_package` resource now allows specifying URLs for the source
attribute. For example, you could install 7zip with the following resource:
[ruby]
windows\_package ‘7zip’ do
source “http://www.7-zip.org/a/7z938-x64.msi”
end
[/ruby]
Internally, this is done by using a `remote_file` resource to download the
contents at the specified url. If needed, you can modify the attributes of
the `remote_file` resource using the `remote_file_attributes` attribute.
The `remote_file_attributes` accepts a hash of attributes that will be set
on the underlying remote_file. For example, the checksum of the contents can
be verified using
[ruby]
windows\_package ‘7zip’ do
source ‘http://www.7-zip.org/a/7z938-x64.msi’
remote\_file\_attributes {
:path => ‘C:\7zip.msi’,
:checksum => ‘7c8e873991c82ad9cfcdbdf45254ea6101e9a645e12977dcd518979e50fdedf3’
}
end
[/ruby]
To make the transition easier from the Windows cookbook, `windows_package` also
accepts the `checksum` attribute, and the previous resource could be rewritten
as:
[ruby]
windows\_package ‘7zip’ do
source ‘http://www.7-zip.org/a/7z938-x64.msi’
checksum ‘7c8e873991c82ad9cfcdbdf45254ea6101e9a645e12977dcd518979e50fdedf3’
end
[/ruby]
### Powershell wrappers for command line tools
There is now an optional feature in the msi that you can enable during the
installation of Chef client that deploys a powershell module alongside the rest
of your installation (usually at `C:\opscode\chef\modules\`). This location
will also be appended to your `PSModulePath` environment variable. Since this
feature is experimental, it is not automatically enabled. You may activate it
by running the following from any powershell session
[powershell]
Import-Module chef
[/powershell]
You can also add the above to your powershell profile at
`~\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1`
The module exports a number of cmdlets that have the same name as the Chef
command line utilities that you already use – such as `chef-client`, `knife`
and `chef-apply`. What they provide is the ability to cleanly pass quoted
argument strings from your powershell command line without the need for excessive
double-quoting. See https://github.com/chef/chef/issues/3026 or
https://github.com/chef/chef/issues/1687 for an examples.
Previously you would have needed
[powershell]
knife exec -E ‘puts ARGV’ “””&s0meth1ng”””
knife node run\_list set test-node ”’role[ssssssomething]”’
[/powershell]
Now you only need
[powershell]
knife exec -E ‘puts ARGV’ ‘&s0meth1ng’
knife node run\_list set test-node ‘role[ssssssomething]’
[/powershell]
If you wish to no longer use the wrappers, run
[powershell]
Remove-Module chef
[/powershell]
### Resource Authoring Changes for LWRP/HWRP Developers
#### Resources may now specify `resource_name` to get DSL
When you declare a resource class, you may call `resource_name` to get recipe DSL for it.
[ruby]
module MyModule
class MyResource < Chef::Resource
resource\_name :my\_resource
# Names the resource “my_resource”
end
end
[/ruby]
When this happens, the resource can be used in a recipe:
[ruby]
my\_resource ‘blah’ do
end
[/ruby]
If you have an abstract class that should *not* have DSL, you may set `resource_name` to `nil` (this is only really important for classes in `Chef::Resource` which get DSL automatically):
[ruby]
class Chef
class Resource
# This will not have DSL
class MyBaseResource < Chef::Resource
resource\_name nil
end
# This will have DSL my\_resource
class MyResource < MyBaseResource
end
end
end
[/ruby]
When you do this, `my_base_resource` will not work in a recipe (but `my_resource` will).
You can still use `provides` to provide other DSL names:
[ruby]
module MyModule
class MyResource < Chef::Resource
provides :super\_resource
end
end
[/ruby]
Which enables this recipe:
[ruby]
super\_resource ‘wowzers’ do
end
[/ruby]
(Note that when you use provides in this manner, `resource_name` will be `my_resource` and `declared_type` will be `super_resource`. This won’t affect most people, but it is worth noting as a matter of explanation.)
Users are encouraged to declare resources in their own namespaces instead of putting them in the `Chef::Resource` namespace.
#### Resources may now use `allowed_actions` and `default_action`
Instead of overriding `Chef::Resource.initialize` and setting `@allowed_actions` and `@action` in the constructor, you may now use the `allowed_actions` and `default_action` DSL to declare them:
[ruby]
class MyResource < Chef::Resource
allowed\_actions :create, :delete
default\_action :create
end
[/ruby]
#### Resource `provides` now has intuitive automatic rules
`provides` is how a Resource or Provider associates itself with the Chef recipe DSL on different OS’s. Now when multiple resources or providers say they provide the same DSL, “specificity rules” are applied to decide the priority of these rules. For example:
[ruby]
class GenericFile < Chef::Resource
provides :file
end
class LinuxFile < Chef::Resource
provides :file, os: ‘linux’
end
class DebianFile < Chef::Resource
provides :file, platform\_family: ‘debian’
end
[/ruby]
This means that if I run this recipe on Ubuntu, it will pick DebianFile:
[ruby]
file ‘x’ do
end
[/ruby]
Now, no matter what order those resources are declared in, the resource lookup system will choose DebianFile on Debian-based platforms since that is the most specific rule. If a platform is Linux but *not* Debian, like Red Hat, it will pick LinuxFile, since that is less specific.
The specificity order (from highest to lowest) is:
1. provides :x, platform\_version: ‘12.4.0’
2. provides :x, platform: ‘ubuntu’
3. provides :x, platform\_family: ‘debian’
4. provides :x, os: ‘linux’
5. provides :x
This means that a class that specifies a platform_version will *always* be picked over any other provides line.
#### Warnings when multiple classes try to provide the same resource DSL
We now warn you when you are replacing DSL provided by another resource or
provider class:
[ruby]
class X < Chef::Resource
provides :file
end
class Y < Chef::Resource
provides :file
end
[/ruby]
This will emit a warning that Y is overriding X. To disable the warning, use `override: true`:
[ruby]
class X < Chef::Resource
provides :file
end
class Y < Chef::Resource
provides :file, override: true
end
[/ruby]
#### LWRPs are no longer automatically placed in the `Chef::Resource` namespace
Starting with Chef 12.4.0, accessing an LWRP class by name from the `Chef::Resource` namespace will trigger a deprecation warning message. This means that if your cookbook includes the LWRP `mycookbook/resources/myresource.rb`, you will no longer be able to extend or reference `Chef::Resource::MycookbookMyresource` in Ruby code. LWRP recipe DSL does not change: the LWRP will still be available to recipes as `mycookbook_myresource`.
You can still get the LWRP class by calling `Chef::ResourceResolver.resolve(:mycookbook_myresource)`.
The primary aim here is clearing out the `Chef::Resource` namespace.
References to these classes is deprecated (and will emit a warning) in Chef 12, and will be removed in Chef 13.
# 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.4.0
For Windows, you can download this version using this link: Chef Client 12.4.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.
