# Release Notes: chef-client 12.0 - 12.19¶

[edit on GitHub]

Chef client is released on a monthly schedule with new releases the first Wednesday of every month. Below are the major changes for each release. For a detailed list of changes see the Chef CHANGELOG.md

## What’s New in 12.19¶

The following items are new for chef-client 12.19 and/or are changes from previous versions. The short version:

• Systemd unit files are now verified before being installed.
• Added support for windows alternate user identity in execute resources.
• Added ed25519 key support for for ssh connections.

### Windows alternate user identity execute support¶

The execute resource and similar resources such as script, batch, and powershell_script now support the specification of credentials on Windows so that the resulting process is created with the security identity that corresponds to those credentials.

Note: When Chef is running as a service, this feature requires that the user that Chef runs as has ‘SeAssignPrimaryTokenPrivilege’ (aka ‘SE_ASSIGNPRIMARYTOKEN_NAME’) user right. By default only LocalSystem and NetworkService have this right when running as a service. This is necessary even if the user is an Administrator.

This right can be added and checked in a recipe using this example:

# Add 'SeAssignPrimaryTokenPrivilege' for the user

# Check if the user has 'SeAssignPrimaryTokenPrivilege' rights
Chef::ReservedNames::Win32::Security.get_account_right('<user>').include?('SeAssignPrimaryTokenPrivilege')


### Properties¶

The following properties are new or updated for the execute, script, batch, and powershell_script resources and any resources derived from them:

user
Ruby types: String The user name of the user identity with which to launch the new process. Default value: nil. The user name may optionally be specified with a domain, i.e. domain\user or user@my.dns.domain.com via Universal Principal Name (UPN) format. It can also be specified without a domain simply as user if the domain is instead specified using the domain attribute. On Windows only, if this property is specified, the password property must be specified.
Ruby types String _Windows only:_ The password of the user specified by the user property. Default value: nil. This property is mandatory if user is specified on Windows and may only be specified if user is specified. The sensitive property for this resource will automatically be set to true if password is specified.
domain
Ruby types String _Windows only:_ The domain of the user user specified by the user property. Default value: nil. If not specified, the user name and password specified by the user and password properties will be used to resolve that user against the domain in which the system running Chef client is joined, or if that system is not joined to a domain it will resolve the user as a local account on that system. An alternative way to specify the domain is to leave this property unspecified and specify the domain as part of the user property.

### Usage¶

The following examples explain how alternate user identity properties can be used in the execute resources:

powershell_script 'create powershell-test file' do
code <<-EOH
$stream = [System.IO.StreamWriter] "#{Chef::Config[:file_cache_path]}/powershell-test.txt"$stream.WriteLine("In #{Chef::Config[:file_cache_path]}...word.")


### Ohai Enhancements¶

"languages": {
"stack": {
"version": "1.2.0",
"description": "Version 1.2.0 x86_64 hpack-0.14.0"
}
}
}


LSB Release Detection

The lsb_release command line tool is now preferred to the contents of /etc/lsb-release for release detection. This resolves an issue where a distro can be upgraded, but /etc/lsb-release is not upgraded to reflect the change.

## What’s New in 12.16¶

The following items are new for chef-client 12.16 and/or are changes from previous versions. The short version:

• Added new attribute_changed event hook
• Automatic connection to Chef Automate’s data collector through Chef server
• Added new –field-separator flag to knife show commands

### attribute_changed event hook¶

In a cookbook library file, you can add this in order to print out all attribute changes in cookbooks:

Chef.event_handler do
on :attribute_changed do |precedence, key, value|
puts "setting attribute #{precedence}#{key.map {|n| "[\"#{n}\"]" }.join} = #{value}"
end
end


If you want to setup a policy that override attributes should never be used:

Chef.event_handler do
on :attribute_changed do |precedence, key, value|
raise "override policy violation" if precedence == :override
end
end


### Automatic connection to Chef Automate’s data collector with supported Chef server¶

Chef client will automatically attempt to connect to the Chef server authenticated data collector proxy. If you have a supported version of Chef server with this feature enabled, Chef client run data will automatically be forwarded to Chef Automate without additional Chef client configuration. If you do not have Chef Automate, or the feature is disabled on the Chef server, Chef client will detect this and disable data collection.

Note

Chef Server 12.11.0 or newer is required for this feature.

### RFC018 Partially Implemented: Specify --field-separator for attribute filtering¶

If you have periods (.) in your Chef Node attribute keys, you can now pass the --field-separator (or -S) flag along with your --attribute (or -a) flag to specify a custom nesting character other than ..

In a situation where the webapp node has the following node data:

{
"foo.bar": "baz",
"alpha": {
"beta": "omega"
}
}


Running knife node show with the default field separator (.) won’t show us the data we’re expecting for the foo.bar attribute because of the period:

$knife node show webapp -a foo.bar webapp: foo.bar:$ knife node show webapp -a alpha.beta
webapp:
alpha.beta: omega


However, by specifying a field separator other than . we are now able to show the data.

$knife node show webapp -S: -a foo.bar webapp: foo.bar: baz$ knife node show webapp -S: -a alpha:beta
webapp:
alpha:beta: omega


### Package locking for Apt, Yum, and Zypper¶

To allow for more fine grain control of package installation the apt_package, yum_package, and zypper_package resources now support the :lock and :unlock actions.

package "httpd" do
action :lock
end

package "httpd" do
action :unlock
end


## What’s New in 12.15¶

The following items are new for chef-client 12.15 and/or are changes from previous versions. The short version:

• Omnibus packages are now available for Ubuntu 16.04
• New cab_package resource Supports the installation of cabinet packages on Microsoft Windows.
• Added new Chef client exit code (213) New exit code when Chef client exits during upgrade.
• Default for gpgcheck on yum_repository resource is set to true
• Allow deletion of registry_key without the need for users to pass data key in values hash
• If provided, knife ssh will pass the -P option on the command line as the sudo password and will bypass prompting

### cab_package¶

Supports the installation of cabinet packages on Microsoft Windows. For example:

cab_package 'Install .NET 3.5 sp1 via KB958488' do
source 'C:\Users\xyz\AppData\Local\Temp\Windows6.1-KB958488-x64.cab'
action :install
end

cab_package 'Remove .NET 3.5 sp1 via KB958488' do
source 'C:\Users\xyz\AppData\Local\Temp\Windows6.1-KB958488-x64.cab'
action :remove
end


Note

The cab_package resource does not support URL strings in the source property.

### exit code 213¶

This new exit code signals Chef has exited during a client upgrade. This allows for easier testing of chef client upgrades in Test Kitchen. See Chef Killing in the omnibus_updater cookbook for more information.

## What’s New in 12.14¶

The following items are new for chef-client 12.14 and/or are changes from previous versions. The short version:

• Upgraded Ruby version from 2.1.9 to 2.3.1 Adds several performance and functionality enhancements.
• Now support for Chef client runs on Windows Nano Server A small patch to Ruby 2.3.1 and improvements to the Ohai network plugin now allow you to do chef client runs on Windows Nano Server.
• New yum_repository resource Use the yum_repository resource to manage a yum repository configuration file.
• Added the ability to mark a property of a custom resource as sensitive This will suppress the property’s value when it’s used in other outputs, such as messages used by the data collector.

### yum_repository¶

Use the yum_repository resource to manage a Yum repository configuration file located at /etc/yum.repos.d/repositoryid.repo on the local machine. This configuration file specifies which repositories to reference, how to handle cached data, etc.

For syntax, a list of properties and actions, see yum_repository.

### sensitive: true¶

Some properties in custom resources may include sensitive data, such as a password for a database server. When the resource’s state is built for use by data collector or a similar auditing tool, a hash is built of all state properties for that resource and their values. This leads to sensitive data being transmitted and potentially stored in the clear.

Individual properties can now be marked as sensitive and then have the value of that property suppressed when exporting the resource’s state. To do this, add sensitive: true when definine the property, such as in the following example:

property :db_password, String, sensitive: true


## What’s New in 12.13¶

The following items are new for chef-client 12.13 and/or are changes from previous versions. The short version:

• Ohai 8.18 includes new plugin for gathering available user shells Other additions include a new hardware plugin for OSX that gathers system information and detection of VMWare and VirtualBox installations.
• New Chef client option to override any config key/value pair Use chef-client --config-option to override any config setting from the command line.

### –config-option¶

Use the --config-option option to override a single configuration option when calling a command on chef-client. To override multiple configuration options, simply add additional --config-option options like in the following example:

$chef-client --config-option chef_server_url=http://example --config-option policy_name=web"  ### Updated Dependencies¶ • ruby - 2.1.9 (from 2.1.8) #### Updated Gems¶ • chef-zero - 4.8.0 (from 4.7.0) • cheffish - 2.0.5 (from 2.0.4) • compat_resource - 12.10.7 (from 12.10.6) • ffi - 1.9.14 (from 1.9.10) • ffi-yajl - 2.3.0 (from 2.2.3) • fuzzyurl - 0.9.0 (from 0.8.0) • mixlib-cli - 1.7.0 (from 1.6.0) • mixlib-log - 1.7.0 (from 1.6.0) • ohai - 8.18.0 (from 8.17.1) • pry - 0.10.4 (from 0.10.3) • rspec - 3.5.0 (from 3.4.0) • rspec-core - 3.5.2 (from 3.4.4) • rspec-expectations - 3.5.0 (from 3.4.0) • rspec-mocks - 3.5.0 (from 3.4.1) • rspec-support - 3.5.0 (from 3.4.1) • simplecov - 0.12.0 (from 0.11.2) • specinfra - 2.60.3 (from 2.59.4) • mixlib-archive - 0.2.0 (added to package) ## What’s New in 12.12¶ The following items are new for chef-client 12.12 and/or are changes from previous versions. The short version: • New node attribute APIs Common set of methods to read, write, delete, and check if node attributes exist. • Data collector updates Minor enhancements to data that the data collector reports on. • knife cookbook create has been deprecated You should use chef generate cookbook instead. ### Depreciated node attribute methods¶ The following methods have been deprecated in this release: • node.set • node.set_unless ### data_collector updates¶ • Adds node to the data_collector message. • data_collector reports on all resources and not just those that have been processed. ## What’s New in 12.11¶ The following items are new for chef-client 12.11 and/or are changes from previous versions. The short version: • Support for standard exit codes in Chef client Standard exit codes are now used by Chef client and should be identical across all OS platforms. New configuration setting exit_status has been added to specify how Chef client reports non-standard exit codes. • New data collector functionality for run statistics New feature that provides a unified method for sharing statistics about your Chef runs in webhook-like manner. • Default chef-solo behavior is equivalent to chef-client local mode chef-solo now uses chef-client local mode. To use the previous chef-solo behavior, run in chef-solo --legacy-mode. • New systemd_unit resource Use the systemd_unit to manage systemd units. ### exit_status¶ When set to :enabled, chef-client will use stardardized exit codes for Chef client run status, and any non-standard exit codes will be converted to 1 or GENERIC_FAILURE. This setting can also be set to :disabled which preserves the old behavior of using non-standardized exit codes and skips the deprecation warnings. Default value: nil. Note The behavior with the default value consists of a warning on the use of deprecated and non-standard exit codes. In a future release of Chef client, using standardized exit codes will be the default behavior. ### Data collector¶ The data collector feature is new to Chef 12.11. It provides a unified method for sharing statistics about your Chef runs in a webhook-like manner. The data collector supports Chef in all its modes: Chef client, Chef solo (commonly referred to as “Chef client local mode”), and Chef solo legacy mode. To enable the data collector, specify the following settings in your client configuration file: • data_collector.server_url: Required. The URL to which the Chef client will POST the data collector messages • data_collector.token: Optional. An token which will be sent in a x-data-collector-token HTTP header which can be used to authenticate the message. • data_collector.mode: The Chef mode in which the data collector should run. Chef client mode is chef client configured to use Chef server to provide Chef client its resources and artifacts. Chef solo mode is Chef client configured to use a local Chef zero server (chef-client --local-mode). This setting also allows you to only enable data collector in Chef solo mode but not Chef client mode. Available options are :solo, :client, or :both. Default is :both. • data_collector.raise_on_failure: If enabled, Chef will raise an exception and fail to run if the data collector cannot be reached at the start of the Chef run. Defaults to false. • data_collector.organization: Optional. In Chef solo mode, the organization field in the messages will be set to this value. Default is chef_solo. This field does not apply to Chef client mode. ### Replace previous Chef-solo behavior with Chef client local mode¶ The default operation of chef-solo is now the equivalent to chef-client -z or chef-client --local-mode, but you can use the previous chef-solo behavior by running in chef-solo --legacy-mode. As part of this change, environment and role files written in ruby are now fully supported by knife upload. ### systemd_unit¶ Use the systemd_unit resource to create, manage, and run systemd units. #### Syntax¶ A systemd_unit resource describes the configuration behavior for systemd units. For example: systemd_unit 'sysstat-collect.timer' do enabled true content '[Unit]\nDescription=Run system activity accounting tool every 10 minutes\n\n[Timer]\nOnCalendar=*:00/10\n\n[Install]\nWantedBy=sysstat.service' end  The full syntax for all of the properties that are available to the systemd_unit resource is: systemd_unit 'name' do enabled Boolean active Boolean masked Boolean static Boolean user String content String or Hash triggers_reload Boolean end  where • name is the name of the unit • active specifies if the service unit type should be started • user is the user account that systemd units run under. If not specified, systemd units will run under the system account. • content describes the behavior of the unit #### Actions¶ This resource has the following actions: :create Create a unit file, if it does not already exist. :delete Delete a unit file, if it exists. :enable Ensure the unit will be started after the next system boot. :disable Ensure the unit will not be started after the next system boot. :nothing Default. Do nothing with the unit. :mask Ensure the unit will not start, even to satisfy dependencies. :unmask Stop the unit from being masked and cause it to start as specified. :start Start a unit based in its systemd unit file. :stop Stop a running unit. :restart Restart a unit. :reload Reload the configuration file for a unit. :try_restart Try to restart a unit if the unit is running. :reload_or_restart For units that are services, this action reloads the configuration of the service without restarting, if possible; otherwise, it will restart the service so the new configuration is applied. :reload_or_try_restart For units that are services, this action reloads the configuration of the service without restarting, if possible; otherwise, it will try to restart the service so the new configuration is applied. #### Properties¶ This resource has the following properties: enabled Ruby Types: TrueClass, FalseClass Specifies whether the unit is enabled or disabled. active Ruby Type: TrueClass, FalseClass Specifies whether the unit is started or stopped. masked Ruby Type: TrueClass, FalseClass Specifies whether the unit is masked or not. static Ruby Type: TrueClass, FalseClass Specifies whether the unit is static or not. Static units cannot be enabled or disabled. user Ruby Type: String The user account that the systemd unit process is run under. The path to the unit for that user would be something like /etc/systemd/user/sshd.service. If no user account is specified, the systemd unit will run under a system account, with the path to the unit being something like /etc/systemd/system/sshd.service. content Ruby Type: String, Hash A string or hash that contains a systemd unit file definition that describes the properties of systemd-managed entities, such as services, sockets, devices, and so on. triggers_reload Ruby Type: TrueClass, FalseClass Specifies whether to trigger a daemon reload when creating or deleting a unit. Default is true. ## What’s New in 12.10¶ The following items are new for chef-client 12.10 and/or are changes from previous versions. The short version: • New layout property for mdadm resource Use the layout property to set the RAID5 parity algorithm. Possible values: left-asymmetric (or la), left-symmetric (or ls), right-asymmetric (or ra), or right-symmetric (or rs). • New with_run_context for the Recipe DSL Use with_run_context to run resource blocks as part of the root or parent run context. • New Recipe DSL methods for declaring, deleting, editing, and finding resources Use the declare_resource, delete_resource, edit_resource, and find_resource methods to interact with resources in the resource collection. Use the delete_resource!, edit_resource!, or find_resource! methods to trigger an exception when the resource is not found in the collection. ### with_run_context¶ Use the with_run_context method to define a block that has a pointer to a location in the run_context hierarchy. Resources in recipes always run at the root of the run_context hierarchy, whereas custom resources and notification blocks always build a child run_context which contains their sub-resources. The syntax for the with_run_context method is as follows: with_run_context :type do # some arbitrary pure Ruby stuff goes here end  where :type may be one of the following: • :root runs the block as part of the root run_context hierarchy • :parent runs the block as part of the parent process in the run_context hierarchy For example: action :run do with_run_context :root do edit_resource(:my_thing, "accumulated state") do action :nothing my_array_property << accumulate_some_stuff end end log "kick it off" do notifies :run, "my_thing[accumulated state], :delayed end end  ### declare_resource¶ Use the declare_resource method to instantiate a resource and then add it to the resource collection. The syntax for the declare_resource method is as follows: declare_resource(:resource_type, 'resource_name', resource_attrs_block)  where: • :resource_type is the resource type, such as :file (for the **file** resource), :template (for the template resource), and so on. Any resource available to Chef may be declared. • resource_name the property that is the default name of the resource, typically the string that appears in the resource 'name' do block of a resource (but not always); see the Syntax section for the resource to be declared to verify the default name property. • resource_attrs_block is a block in which properties of the instantiated resource are declared. For example: declare_resource(:file, '/x/y.txy', caller[0]) do action :delete end  is equivalent to: file '/x/y.txt' do action :delete end  New in Chef Client 12.10. ### delete_resource¶ Use the delete_resource method to find a resource in the resource collection, and then delete it. The syntax for the delete_resource method is as follows: delete_resource(:resource_type, 'resource_name')  where: • :resource_type is the resource type, such as :file (for the **file** resource), :template (for the template resource), and so on. Any resource available to Chef may be declared. • resource_name the property that is the default name of the resource, typically the string that appears in the resource 'name' do block of a resource (but not always); see the Syntax section for the resource to be declared to verify the default name property. For example: delete_resource(:template, '/x/y.erb')  New in Chef Client 12.10. ### delete_resource!¶ Use the delete_resource! method to find a resource in the resource collection, and then delete it. If the resource is not found, an exception is returned. The syntax for the delete_resource! method is as follows:   delete_resource!(:resource_type, ‘resource_name’) where: • :resource_type is the resource type, such as :file (for the **file** resource), :template (for the template resource), and so on. Any resource available to Chef may be declared. • resource_name the property that is the default name of the resource, typically the string that appears in the resource 'name' do block of a resource (but not always); see the Syntax section for the resource to be declared to verify the default name property. For example: delete_resource!(:file, '/x/file.txt')  New in Chef Client 12.10. ### edit_resource¶ Use the edit_resource method to: • Find a resource in the resource collection, and then edit it. • Define a resource block. If a resource block with the same name exists in the resource collection, it will be updated with the contents of the resource block defined by the edit_resource method. If a resource block does not exist in the resource collection, it will be created. The syntax for the edit_resource method is as follows: edit_resource(:resource_type, 'resource_name', resource_attrs_block)  where: • :resource_type is the resource type, such as :file (for the **file** resource), :template (for the template resource), and so on. Any resource available to Chef may be declared. • resource_name the property that is the default name of the resource, typically the string that appears in the resource 'name' do block of a resource (but not always); see the Syntax section for the resource to be declared to verify the default name property. • resource_attrs_block is a block in which properties of the instantiated resource are declared. For example: edit_resource(:template, '/x/y.txy') do cookbook_name: cookbook_name end  and a resource block: edit_resource(:template, '/etc/aliases') do source 'aliases.erb' cookbook 'aliases' variables({:aliases => {} }) notifies :run, 'execute[newaliases]' end  New in Chef Client 12.10. ### edit_resource!¶ Use the edit_resource! method to: • Find a resource in the resource collection, and then edit it. • Define a resource block. If a resource with the same name exists in the resource collection, its properties will be updated with the contents of the resource block defined by the edit_resource method. In both cases, if the resource is not found, an exception is returned. The syntax for the edit_resource! method is as follows: edit_resource!(:resource_type, 'resource_name')  where: • :resource_type is the resource type, such as :file (for the **file** resource), :template (for the template resource), and so on. Any resource available to Chef may be declared. • resource_name the property that is the default name of the resource, typically the string that appears in the resource 'name' do block of a resource (but not always); see the Syntax section for the resource to be declared to verify the default name property. • resource_attrs_block is a block in which properties of the instantiated resource are declared. For example: edit_resource!(:file, '/x/y.rst')  New in Chef Client 12.10. ### find_resource¶ Use the find_resource method to: • Find a resource in the resource collection. • Define a resource block. If a resource block with the same name exists in the resource collection, it will be returned. If a resource block does not exist in the resource collection, it will be created. The syntax for the find_resource method is as follows: find_resource(:resource_type, 'resource_name')  where: • :resource_type is the resource type, such as :file (for the **file** resource), :template (for the template resource), and so on. Any resource available to Chef may be declared. • resource_name the property that is the default name of the resource, typically the string that appears in the resource 'name' do block of a resource (but not always); see the Syntax section for the resource to be declared to verify the default name property. For example: find_resource(:template, '/x/y.txy')  and a resource block: find_resource(:template, '/etc/seapower') do source 'seapower.erb' cookbook 'seapower' variables({:seapower => {} }) notifies :run, 'execute[newseapower]' end  New in Chef Client 12.10. ### find_resource!¶ Use the find_resource! method to find a resource in the resource collection. If the resource is not found, an exception is returned. The syntax for the find_resource! method is as follows: find_resource!(:resource_type, 'resource_name')  where: • :resource_type is the resource type, such as :file (for the **file** resource), :template (for the template resource), and so on. Any resource available to Chef may be declared. • resource_name the property that is the default name of the resource, typically the string that appears in the resource 'name' do block of a resource (but not always); see the Syntax section for the resource to be declared to verify the default name property. For example: find_resource!(:template, '/x/y.erb')  New in Chef Client 12.10. ## What’s New in 12.9¶ The following items are new for chef-client 12.9 and/or are changes from previous versions. The short version: • New apt_repository resource • 64-bit chef-client for Microsoft Windows Starting with chef-client 12.9, 64-bit • New property for the mdadm resource Use the mdadm_defaults property to set the default values for chunk and metadata to nil, which allows mdadm to apply its own default values. • File redirection in Windows for 32-bit applications Files on Microsoft Windows that are managed by the file and directory resources are subject to file redirection, depending if the chef-client is 64-bit or 32-bit. • Registry key redirection in Windows for 32-bit applications Registry keys on Microsoft Windows that are managed by the registry_key resource are subject to key redirection, depending if the chef-client is 64-bit or 32-bit. • New values for log_location Use :win_evt to write log output to the (Windows Event Logger and :syslog to write log output to the syslog daemon facility with the originator set as chef-client. • New timeout setting for knife ssh Set the --ssh-timeout setting to an integer (in seconds) as part of a knife ssh command. The ssh_timeout setting may also be configured (as seconds) in the knife.rb file. • New “seconds to wait before first chef-client run” setting The -daemonized option for the chef-client now allows the seconds to wait before starting the chef-client run to be specified. For example, if --daemonize 10 is specified, the chef-client will wait ten seconds. ### apt_repository resource¶ The apt_repository resource, previously available in the apt cookbook, is now included in chef-client. With this change you will no longer need to depend on the apt cookbook to use the apt_repository resource. ### 64-bit chef-client¶ The chef-client now runs on 64-bit Microsoft Windows operating systems. • Support for file redirection • Support for key redirection #### File Redirection¶ 64-bit versions of Microsoft Windows have a 32-bit compatibility layer that redirects attempts by 32-bit application to access the System32 directory to a different location. Starting with chef-client version 12.9, the 32-bit version of the chef-client is subject to the file redirection policy. For example, consider the following script: process_type = ENV['PROCESSOR_ARCHITECTURE'] == 'AMD64' ? '64-bit' : '32-bit' system32_dir = ::File.join(ENV['SYSTEMROOT'], 'system32') test_dir = ::File.join(system32_dir, 'cheftest') test_file = ::File.join(test_dir, 'chef_architecture.txt') directory test_dir do # some directory end file test_file do content "Chef made me, I come from a #{process_type} process." end  When running a 32-bit version of chef-client, the script will write the chef_architecture file to the C:\Windows\SysWow64 directory. However, when running a native 64-bit version of the chef-client, the script will write a file to the C:\Windows\System32 directory, as expected. For more information, see: https://msdn.microsoft.com/en-us/library/windows/desktop/aa384187(v=vs.85).aspx. #### Key Redirection¶ 64-bit versions of Microsoft Windows have a 32-bit compatibility layer in the registry that reflects and redirects certain keys (and their values) into specific locations (or logical views) of the registry hive. The chef-client can access any reflected or redirected registry key. The machine architecture of the system on which the chef-client is running is used as the default (non-redirected) location. Access to the SysWow64 location is redirected must be specified. Typically, this is only necessary to ensure compatibility with 32-bit applications that are running on a 64-bit operating system. 32-bit versions of the chef-client (12.8 and earlier) and 64-bit versions of the chef-client (12.9 and later) generally behave the same in this situation, with one exception: it is only possible to read and write from a redirected registry location using chef-client version 12.9 (and later). For more information, see: http://msdn.microsoft.com/en-us/library/windows/desktop/aa384235(v=vs.85).aspx. ## What’s New in 12.8¶ The following items are new for chef-client 12.8 and/or are changes from previous versions. The short version: • Support for OpenSSL validation of FIPS The chef-client can be configured to allow OpenSSL to enforce FIPS-validated security during a chef-client run. • Support for multiple configuration files The chef-client supports reading multiple configuration files by putting them inside a .d configuration directory. • New launchd resource Use the launchd resource to manage system-wide services (daemons) and per-user services (agents) on the Mac OS X platform. • chef-zero support for Chef Server API endpoints chef-zero now supports using all Chef server API version 12 endpoints, with the exception of /universe. • Updated support for OpenSSL OpenSSL is updated to version 1.0.1. • Ohai auto-detects hosts for Azure instances Ohai will auto-detect hosts for instances that are hosted by Microsoft Azure. • gem attribute added to metadata.rb Specify a gem dependency to be installed via the chef_gem resource after all cookbooks are synchronized, but before any other cookbook loading is done. ### FIPS Mode¶ Federal Information Processing Standards (FIPS) is a United States government computer security standard that specifies security requirements for cryptography. The current version of the standard is FIPS 140-2. The chef-client can be configured to allow OpenSSL to enforce FIPS-validated security during a chef-client run. This will disable cryptography that is explicitly disallowed in FIPS-validated software, including certain ciphers and hashing algorithms. Any attempt to use any disallowed cryptography will cause the chef-client to throw an exception during a chef-client run. Note Chef uses MD5 hashes to uniquely identify files that are stored on the Chef server. MD5 is used only to generate a unique hash identifier and is not used for any cryptographic purpose. Notes about FIPS: • May be enabled for nodes running on Microsoft Windows and Enterprise Linux platforms • Should only be enabled for environments that require FIPS 140-2 compliance • May not be enabled for any version of the chef-client earlier than 12.8 Changed in Chef server 12.13 to expose FIPS runtime flag on RHEL. New in Chef Client 12.8, support for OpenSSL validation of FIPS. #### Enable FIPS Mode¶ Allowing OpenSSL to enforce FIPS-validated security may be enabled by using any of the following ways: • Set the fips configuration setting to true in the client.rb or knife.rb files • Set the --fips command-line option when running any knife command or the chef-client executable • Set the --fips command-line option when bootstrapping a node using the knife bootstrap command #### Command Option¶ The following command-line option may be used to with a knife or chef-client executable command: --[no-]fips Allows OpenSSL to enforce FIPS-validated security during the chef-client run. Bootstrap a node using FIPS $ knife bootstrap 12.34.56.789 -P vanilla -x root -r 'recipe[apt],recipe[xfs],recipe[vim]' --fips


which shows something similar to:

OpenSSL FIPS 140 mode enabled
...
12.34.56.789 Chef Client finished, 12/12 resources updated in 78.942455583 seconds


#### Configuration Setting¶

The following configuration setting may be set in the knife.rb, client.rb, or config.rb files:

fips
Allows OpenSSL to enforce FIPS-validated security during the chef-client run. Set to true to enable FIPS-validated security.

### .d Directories¶

The chef-client supports reading multiple configuration files by putting them inside a .d configuration directory. For example: /etc/chef/client.d. All files that end in .rb in the .d directory are loaded; other non-.rb files are ignored.

.d directories may exist in any location where the client.rb, config.rb, or solo.rb files are present, such as:

• /etc/chef/client.d
• /etc/chef/config.d
• ~/chef/solo.d

(There is no support for a knife.d directory; use config.d instead.)

For example, when using knife, the following configuration files would be loaded:

• ~/.chef/config.rb
• ~/.chef/config.d/company_settings.rb
• ~/.chef/config.d/ec2_configuration.rb
• ~/.chef/config.d/old_settings.rb.bak

The old_settings.rb.bak file is ignored because it’s not a configuration file. The config.rb, company_settings.rb, and ec2_configuration files are merged together as if they are a single configuration file.

Note

If multiple configuration files exists in a .d directory, ensure that the same setting has the same value in all files.

New in Chef Client 12.8.

### launchd¶

Use the launchd resource to manage system-wide services (daemons) and per-user services (agents) on the Mac OS X platform.

#### Syntax¶

A launchd resource manages system-wide services (daemons) and per-user services (agents) on the Mac OS X platform:

launchd 'call.mom.weekly' do
program '/Library/scripts/call_mom.sh'
start_calendar_interval 'Weekday' => 7, 'Hourly' => 10
time_out 300
end


The full syntax for all of the properties that are available to the launchd resource is:

launchd 'name' do
abandon_process_group      TrueClass, FalseClass
backup                     Integer, FalseClass
cookbook                   String
debug                      TrueClass, FalseClass
disabled                   TrueClass, FalseClass
enable_globbing            TrueClass, FalseClass
enable_transactions        TrueClass, FalseClass
environment_variables      Hash
exit_timeout               Integer
group                      String, Integer
hard_resource_limits       Hash
hash                       Hash
ignore_failure             TrueClass, FalseClass
inetd_compatibility        Hash
init_groups                TrueClass, FalseClass
keep_alive                 TrueClass, FalseClass
label                      String
launch_only_once           TrueClass, FalseClass
low_priority_io            TrueClass, FalseClass
mach_services              Hash
mode                       Integer, String
nice                       Integer
notifies                   # see description
on_demand                  TrueClass, FalseClass
owner                      Integer, String
path                       String
process_type               String
program                    String
program_arguments          Array
provider                   Chef::Provider::Launchd
queue_directories          Array
retries                    Integer
retry_delay                Integer
root_directory             String
sockets                    Hash
soft_resource_limits       Array
standard_error_path        String
standard_in_path           String
standard_out_path          String
start_calendar_interval    Hash
start_interval             Integer
start_on_mount             TrueClass, FalseClass
subscribes                 # see description
throttle_interval          Integer
time_out                   Integer
type                       String
wait_for_debugger          TrueClass, FalseClass
watch_paths                Array
working_directory          String
action                     Symbol # defaults to :create if not specified
end


where

• launchd is the resource
• name is the name of the resource block
• action identifies the steps the chef-client will take to bring the node into the desired state
• abandon_process_group, backup, cookbook, debug, disabled, enable_globbing, enable_transactions, environment_variables, exit_timeout, group, hard_resource_limits, hash, inetd_compatibility, init_groups, keep_alive, label, launch_only_once, limit_load_from_hosts, limit_load_to_hosts, limit_load_to_session_type, low_priority_io, mach_services, mode, nice, on_demand, owner, path, process_type, program, program_arguments, queue_directories, retries, retry_delay, root_directory, run_at_load, sockets, soft_resource_limits, standard_error_path, standard_in_path, standard_out_path, start_calendar_interval, start_interval, start_on_mount, throttle_interval, time_out, type, umask, username, wait_for_debugger, watch_paths, and working_directory are properties of this resource, with the Ruby type shown. See “Properties” section below for more information about all of the properties that may be used with this resource.

#### Actions¶

This resource has the following actions:

:create
Default. Create a launchd property list.
:create_if_missing
Create a launchd property list, if it does not already exist.
:delete
Delete a launchd property list. This will unload a daemon or agent, if loaded.
:disable
Disable a launchd property list.
:enable
Create a launchd property list, and then ensure that it is enabled. If a launchd property list already exists, but does not match, updates the property list to match, and then restarts the daemon or agent.

#### Properties¶

This resource has the following properties:

backup

Ruby Types: Integer, FalseClass

The number of backups to be kept in /var/chef/backup. Set to false to prevent backups from being kept.

cookbook

Ruby Type: String

The name of the cookbook in which the source files are located.

group

Ruby Types: String, Integer

When launchd is run as the root user, the group to run the job as. If the username property is specified and this property is not, this value is set to the default group for the user.

hash

Ruby Type: Hash

A Hash of key value pairs used to create the launchd property list.

ignore_failure

Ruby Types: TrueClass, FalseClass

Continue running a recipe if a resource fails for any reason. Default value: false.

label

Ruby Type: String

The unique identifier for the job.

mode

Ruby Types: Integer, String

A quoted 3-5 character string that defines the octal mode. For example: '755', '0755', or 00755. If mode is not specified and if the directory already exists, the existing mode on the directory is used. If mode is not specified, the directory does not exist, and the :create action is specified, the chef-client assumes a mask value of '0777', and then applies the umask for the system on which the directory is to be created to the mask value. For example, if the umask on a system is '022', the chef-client uses the default value of '0755'.

The behavior is different depending on the platform.

UNIX- and Linux-based systems: A quoted 3-5 character string that defines the octal mode that is passed to chmod. For example: '755', '0755', or 00755. If the value is specified as a quoted string, it works exactly as if the chmod command was passed. If the value is specified as an integer, prepend a zero (0) to the value to ensure that it is interpreted as an octal number. For example, to assign read, write, and execute rights for all users, use '0777' or '777'; for the same rights, plus the sticky bit, use 01777 or '1777'.

Microsoft Windows: A quoted 3-5 character string that defines the octal mode that is translated into rights for Microsoft Windows security. For example: '755', '0755', or 00755. Values up to '0777' are allowed (no sticky bits) and mean the same in Microsoft Windows as they do in UNIX, where 4 equals GENERIC_READ, 2 equals GENERIC_WRITE, and 1 equals GENERIC_EXECUTE. This property cannot be used to set :full_control. This property has no effect if not specified, but when it and rights are both specified, the effects are cumulative.

notifies

Ruby Type: Symbol, ‘Chef::Resource[String]’

A resource may notify another resource to take action when its state changes. Specify a 'resource[name]', the :action that resource should take, and then the :timer for that action. A resource may notifiy more than one resource; use a notifies statement for each resource to be notified.

A timer specifies the point during the chef-client run at which a notification is run. The following timers are available:

:before
Specifies that the action on a notified resource should be run before processing the resource block in which the notification is located.
:delayed
Default. Specifies that a notification should be queued up, and then executed at the very end of the chef-client run.
:immediate, :immediately
Specifies that a notification should be run immediately, per resource notified.

The syntax for notifies is:

notifies :action, 'resource[name]', :timer

owner

Ruby Types: Integer, String

A string or ID that identifies the group owner by user name, including fully qualified user names such as domain\user or user@domain. If this value is not specified, existing owners remain unchanged and new owner assignments use the current user (when necessary).

path

Ruby Type: String

The path to the directory. Using a fully qualified path is recommended, but is not always required. Default value: the name of the resource block See “Syntax” section above for more information.

provider

Ruby Type: Chef::Provider::Launchd

Optional. Explicitly specifies a provider. See “Providers” section below for more information.

retries

Ruby Type: Integer

The number of times to catch exceptions and retry the resource. Default value: 0.

retry_delay

Ruby Type: Integer

The retry delay (in seconds). Default value: 2.

session_type

Ruby Type: String

The type of launchd plist to be created. Possible values: system (default) or user.

source

Ruby Type: String

The path to the launchd property list.

subscribes

Ruby Type: Symbol, ‘Chef::Resource[String]’

A resource may listen to another resource, and then take action if the state of the resource being listened to changes. Specify a 'resource[name]', the :action to be taken, and then the :timer for that action.

A timer specifies the point during the chef-client run at which a notification is run. The following timers are available:

:before
Specifies that the action on a notified resource should be run before processing the resource block in which the notification is located.
:delayed
Default. Specifies that a notification should be queued up, and then executed at the very end of the chef-client run.
:immediate, :immediately
Specifies that a notification should be run immediately, per resource notified.

The syntax for subscribes is:

subscribes :action, 'resource[name]', :timer

supports

Ruby Type: Array

An array of options for supported mount features. Default value: { :remount => false }.

type

Ruby Type: String

The type of resource. Possible values: daemon (default), agent.

The following resource properties may be used to define keys in the XML property list for a daemon or agent. Please refer to the Apple man page documentation for launchd for more information about these keys:

abandon_process_group

Ruby Types: TrueClass, FalseClass

If a job dies, all remaining processes with the same process ID may be kept running. Set to true to kill all remaining processes.

debug

Ruby Types: TrueClass, FalseClass

Sets the log mask to LOG_DEBUG for this job.

disabled

Ruby Types: TrueClass, FalseClass

Hints to launchctl to not submit this job to launchd. Default value: false.

enable_globbing

Ruby Types: TrueClass, FalseClass

Update program arguments before invocation.

enable_transactions

Ruby Types: TrueClass, FalseClass

Track in-progress transactions; if none, then send the SIGKILL signal.

environment_variables

Ruby Type: Hash

Additional environment variables to set before running a job.

exit_timeout

Ruby Type: Integer

The amount of time (in seconds) launchd waits before sending a SIGKILL signal. Default value: 20.

hard_resource_limits

Ruby Type: Hash

A Hash of resource limits to be imposed on a job.

inetd_compatibility

Ruby Type: Hash

Specifies if a daemon expects to be run as if it were launched from inetd. Set to wait => true to pass standard input, output, and error file descriptors. Set to wait => false to call the accept system call on behalf of the job, and then pass standard input, output, and error file descriptors.

init_groups

Ruby Types: TrueClass, FalseClass

Specify if initgroups is called before running a job. Default value: true (starting with Mac OS X 10.5).

keep_alive

Ruby Types: TrueClass, FalseClass, Hash

Keep a job running continuously (true) or allow demand and conditions on the node to determine if the job keeps running (false). Default value: false.

Hash type was added in Chef client 12.14.

launch_only_once

Ruby Types: TrueClass, FalseClass

Specify if a job can be run only one time. Set this value to true if a job cannot be restarted without a full machine reboot.

Ruby Type: Array

An array of hosts to which this configuration file does not apply, i.e. “apply this configuration file to all hosts not specified in this array”.

Ruby Type: Array

An array of hosts to which this configuration file applies.

Ruby Type: String

The session type to which this configuration file applies.

low_priority_io

Ruby Types: TrueClass, FalseClass

Specify if the kernel on the node should consider this daemon to be low priority during file system I/O.

mach_services

Ruby Type: Hash

Specify services to be registered with the bootstrap subsystem.

nice

Ruby Type: Integer

The program scheduling priority value in the range -20 to 20.

on_demand

Ruby Types: TrueClass, FalseClass

Keep a job alive. Only applies to Mac OS X version 10.4 (and earlier); use keep_alive instead for newer versions.

process_type

Ruby Type: String

The intended purpose of the job: Adaptive, Background, Interactive, or Standard.

program

Ruby Type: String

The first argument of execvp, typically the file name associated with the file to be executed. This value must be specified if program_arguments is not specified, and vice-versa.

program_arguments

Ruby Type: Array

The second argument of execvp. If program is not specified, this property must be specified and will be handled as if it were the first argument.

queue_directories

Ruby Type: Array

An array of non-empty directories which, if any are modified, will cause a job to be started.

root_directory

Ruby Type: String

chroot to this directory, and then run the job.

Ruby Types: TrueClass, FalseClass

Launch a job once (at the time it is loaded). Default value: false.

sockets

Ruby Type: Hash

A Hash of on-demand sockets that notify launchd when a job should be run.

soft_resource_limits

Ruby Type: Array

A Hash of resource limits to be imposed on a job.

standard_error_path

Ruby Type: String

The file to which standard error (stderr) is sent.

standard_in_path

Ruby Type: String

The file to which standard input (stdin) is sent.

standard_out_path

Ruby Type: String

The file to which standard output (stdout) is sent.

start_calendar_interval

Ruby Type: Hash

A Hash (similar to crontab) that defines the calendar frequency at which a job is started. For example: { Minute => "0", Hour => "20", Day => "*", Weekday => "1-5", Month => "*" } will run a job at 8:00 PM every day, Monday through Friday, every month of the year.

start_interval

Ruby Type: Integer

The frequency (in seconds) at which a job is started.

start_on_mount

Ruby Types: TrueClass, FalseClass

Start a job every time a file system is mounted.

throttle_interval

Ruby Type: Integer

The frequency (in seconds) at which jobs are allowed to spawn. Default value: 10.

time_out

Ruby Type: Integer

The amount of time (in seconds) a job may be idle before it times out. If no value is specified, the default timeout value for launchd will be used.

Ruby Type: Integer

A decimal value to pass to umask before running a job.

Ruby Type: String

When launchd is run as the root user, the user to run the job as.

wait_for_debugger

Ruby Types: TrueClass, FalseClass

Specify if launchd has a job wait for a debugger to attach before executing code.

watch_paths

Ruby Type: Array

An array of paths which, if any are modified, will cause a job to be started.

working_directory

Ruby Type: String

chdir to this directory, and then run the job.

#### Examples¶

Create a Launch Daemon from a cookbook file

launchd 'com.chef.every15' do
source 'com.chef.every15.plist'
end


Create a Launch Daemon using keys

launchd 'call.mom.weekly' do
program '/Library/scripts/call_mom.sh'
start_calendar_interval 'Weekday' => 7, 'Hourly' => 10
time_out 300
end


Remove a Launch Daemon

launchd 'com.chef.every15' do
action :delete
end


Specifies a gem dependency to be installed via the chef_gem resource after all cookbooks are synchronized, but before any other cookbook loading is done. Use this attribute once per gem dependency. For example:

gem "poise"
gem "chef-sugar"
gem "chef-provisioning"


New in Chef Client 12.8.

## What’s New in 12.7¶

The following items are new for chef-client 12.7 and/or are changes from previous versions. The short version:

• Chef::REST => require ‘chef/rest’ Internal API calls are moved from Chef::REST to Chef::ServerAPI. Any code that uses Chef::REST must use require 'chef/rest'.
• New chocolatey_package resource Use the chocolatey_package resource to manage packages using Chocolatey for the Microsoft Windows platform.
• New osx_profile resource Use the osx_profile resource to manage configuration profiles (.mobileconfig files) on the Mac OS X platform.
• New apt_update resource Use the apt_update resource to manage Apt repository updates on Debian and Ubuntu platforms.
• Improved support for UTF-8 The chef-client 12.7 release fixes a UTF-8 handling bug present in chef-client versions 12.4, 12.5, and 12.6.
• New options for the chef-client The chef-client has a new option: --delete-entire-chef-repo.
• Multi-package support for Chocolatey and Zypper A resource may specify multiple packages and/or versions for platforms that use Zypper or Chocolatey package managers (in addition to the edtaxisting support for specifying multiple packages for Yum and Apt packages).

### Chef::REST => require ‘chef/rest’¶

Internal API calls are moved from Chef::REST to Chef::ServerAPI. As a result of this move, Chef::REST is no longer globally required. Any code that uses Chef::REST must be required as follows:

require 'chef/rest'


For code that is run using knife or chef command line interfaces, consider using Chef::ServerAPI instead.

### chocolatey_package¶

Use the chocolatey_package resource to manage packages using Chocolatey for the Microsoft Windows platform.

#### Syntax¶

A chocolatey_package resource block manages packages using Chocolatey for the Microsoft Windows platform. The simplest use of the chocolatey_package resource is:

chocolatey_package 'package_name'


which will install the named package using all of the default options and the default action (:install).

The full syntax for all of the properties that are available to the chocolatey_package resource is:

chocolatey_package 'name' do
notifies                   # see description
options                    String
package_name               String, Array # defaults to 'name' if not specified
provider                   Chef::Provider::Package::Chocolatey
source                     String
subscribes                 # see description
timeout                    String, Integer
version                    String, Array
action                     Symbol # defaults to :install if not specified
end


where

• chocolatey_package tells the chef-client to manage a package
• 'name' is the name of the package
• action identifies which steps the chef-client will take to bring the node into the desired state
• options, package_name, provider, source, timeout, and version are properties of this resource, with the Ruby type shown. See “Properties” section below for more information about all of the properties that may be used with this resource.

#### Actions¶

This resource has the following actions:

:install
Default. Install a package. If a version is specified, install the specified version of the package.
:nothing
Define this resource block to do nothing until notified by another resource to take action. When this resource is notified, this resource block is either run immediately or it is queued up to be run at the end of the chef-client run.
:purge
Purge a package. This action typically removes the configuration files as well as the package.
:reconfig
Reconfigure a package. This action requires a response file.
:remove
Remove a package.
:uninstall
Uninstall a package.
Install a package and/or ensure that a package is the latest version.

#### Properties¶

This resource has the following properties:

ignore_failure

Ruby Types: TrueClass, FalseClass

Continue running a recipe if a resource fails for any reason. Default value: false.

notifies

Ruby Type: Symbol, ‘Chef::Resource[String]’

A resource may notify another resource to take action when its state changes. Specify a 'resource[name]', the :action that resource should take, and then the :timer for that action. A resource may notifiy more than one resource; use a notifies statement for each resource to be notified.

A timer specifies the point during the chef-client run at which a notification is run. The following timers are available:

:before
Specifies that the action on a notified resource should be run before processing the resource block in which the notification is located.
:delayed
Default. Specifies that a notification should be queued up, and then executed at the very end of the chef-client run.
:immediate, :immediately
Specifies that a notification should be run immediately, per resource notified.

The syntax for notifies is:

notifies :action, 'resource[name]', :timer

options

Ruby Type: String

One (or more) additional options that are passed to the command.

package_name

Ruby Types: String, Array

The name of the package. Default value: the name of the resource block See “Syntax” section above for more information.

provider

Ruby Type: Chef Class

Optional. Explicitly specifies a provider. See “Providers” section below for more information.

retries

Ruby Type: Integer

The number of times to catch exceptions and retry the resource. Default value: 0.

retry_delay

Ruby Type: Integer

The retry delay (in seconds). Default value: 2.

source

Ruby Type: String

Optional. The path to a package in the local file system.

subscribes

Ruby Type: Symbol, ‘Chef::Resource[String]’

A resource may listen to another resource, and then take action if the state of the resource being listened to changes. Specify a 'resource[name]', the :action to be taken, and then the :timer for that action.

A timer specifies the point during the chef-client run at which a notification is run. The following timers are available:

:before
Specifies that the action on a notified resource should be run before processing the resource block in which the notification is located.
:delayed
Default. Specifies that a notification should be queued up, and then executed at the very end of the chef-client run.
:immediate, :immediately
Specifies that a notification should be run immediately, per resource notified.

The syntax for subscribes is:

subscribes :action, 'resource[name]', :timer

timeout

Ruby Types: String, Integer

The amount of time (in seconds) to wait before timing out.

version

Ruby Types: String, Array

The version of a package to be installed or upgraded.

#### Examples¶

Install a package

chocolatey_package 'name of package' do
action :install
end


### osx_profile¶

Use the osx_profile resource to manage configuration profiles (.mobileconfig files) on the Mac OS X platform. The osx_profile resource installs profiles by using the uuidgen library to generate a unique ProfileUUID, and then using the profiles command to install the profile on the system.

#### Syntax¶

A osx_profile resource block manages configuration profiles on the Mac OS X platform:

osx_profile 'Install screensaver profile' do
profile 'com.company.screensaver.mobileconfig'
end


The full syntax for all of the properties that are available to the osx_profile resource is:

osx_profile 'name' do
path                       # set automatically
profile                    String, Hash
profile_name               String # defaults to 'name' if not specified
identifier                 String
action                     Symbol # defaults to :install if not specified
end


where

• osx_profile is the resource
• name is the name of the resource block
• action identifies the steps the chef-client will take to bring the node into the desired state
• profile, profile_name, and identifier are properties of this resource, with the Ruby type shown. See “Properties” section below for more information about all of the properties that may be used with this resource.

#### Actions¶

This resource has the following actions:

:install
Default. Install the specified configuration profile.
:nothing

Default. .. tag resources_common_actions_nothing

Define this resource block to do nothing until notified by another resource to take action. When this resource is notified, this resource block is either run immediately or it is queued up to be run at the end of the chef-client run.
:remove
Remove the specified configuration profile.

#### Properties¶

This resource has the following properties:

identifier

Ruby Type: String

Use to specify the identifier for the profile, such as com.company.screensaver.

ignore_failure

Ruby Types: TrueClass, FalseClass

Continue running a recipe if a resource fails for any reason. Default value: false.

notifies

Ruby Type: Symbol, ‘Chef::Resource[String]’

A resource may notify another resource to take action when its state changes. Specify a 'resource[name]', the :action that resource should take, and then the :timer for that action. A resource may notifiy more than one resource; use a notifies statement for each resource to be notified.

A timer specifies the point during the chef-client run at which a notification is run. The following timers are available:

:before
Specifies that the action on a notified resource should be run before processing the resource block in which the notification is located.
:delayed
Default. Specifies that a notification should be queued up, and then executed at the very end of the chef-client run.
:immediate, :immediately
Specifies that a notification should be run immediately, per resource notified.

The syntax for notifies is:

notifies :action, 'resource[name]', :timer

profile

Ruby Types: String, Hash

Use to specify a profile. This may be the name of a profile contained in a cookbook or a Hash that contains the contents of the profile.

profile_name

Ruby Type: String

Use to specify the name of the profile, if different from the name of the resource block.

provider

Ruby Type: Chef Class

Optional. Explicitly specifies a provider.

retries

Ruby Type: Integer

The number of times to catch exceptions and retry the resource. Default value: 0.

retry_delay

Ruby Type: Integer

The retry delay (in seconds). Default value: 2.

subscribes

Ruby Type: Symbol, ‘Chef::Resource[String]’

A resource may listen to another resource, and then take action if the state of the resource being listened to changes. Specify a 'resource[name]', the :action to be taken, and then the :timer for that action.

A timer specifies the point during the chef-client run at which a notification is run. The following timers are available:

:before
Specifies that the action on a notified resource should be run before processing the resource block in which the notification is located.
:delayed
Default. Specifies that a notification should be queued up, and then executed at the very end of the chef-client run.
:immediate, :immediately
Specifies that a notification should be run immediately, per resource notified.

The syntax for subscribes is:

subscribes :action, 'resource[name]', :timer


#### Examples¶

One liner to install profile from cookbook file

The profiles command will be used to install the specified configuration profile.

osx_profile 'com.company.screensaver.mobileconfig'


Install profile from cookbook file

The profiles command will be used to install the specified configuration profile. It can be in sub-directory within a cookbook.

osx_profile 'Install screensaver profile' do
profile 'screensaver/com.company.screensaver.mobileconfig'
end


Install profile from a hash

The profiles command will be used to install the configuration profile, which is provided as a hash.

profile_hash = {
{
'com.apple.screensaver' => {
'Forced' => [
{
'mcx_preference_settings' => {
'idleTime' => 0,
}
}
]
}
}
}
]
}

osx_profile 'Install screensaver profile' do
profile profile_hash
end


Remove profile using identifier in resource name

The profiles command will be used to remove the configuration profile specified by the provided identifier property.

osx_profile 'com.company.screensaver' do
action :remove
end


Remove profile by identifier and user friendly resource name

The profiles command will be used to remove the configuration profile specified by the provided identifier property.

osx_profile 'Remove screensaver profile' do
identifier 'com.company.screensaver'
action :remove
end


### apt_update¶

Use the apt_update resource to manage Apt repository updates on Debian and Ubuntu platforms.

#### Syntax¶

A apt_update resource block defines the update frequency for Apt repositories:

apt_update 'name' do
frequency                  Integer
action                     Symbol # defaults to :periodic if not specified
end


where

• apt_update is the resource
• name is the name of the resource block
• action identifies the steps the chef-client will take to bring the node into the desired state
• frequency is a property of this resource, with the Ruby type shown. See “Properties” section below for more information about all of the properties that may be used with this resource.

#### Actions¶

This resource has the following actions:

:nothing
Define this resource block to do nothing until notified by another resource to take action. When this resource is notified, this resource block is either run immediately or it is queued up to be run at the end of the chef-client run.
:periodic
Update the Apt repository at the interval specified by the frequency property.
:update
Update the Apt repository at the start of the chef-client run.

#### Properties¶

This resource has the following properties:

frequency

Ruby Type: Integer

The frequency at which Apt repository updates are made. Use this property when the :periodic action is specified. Default value: 86400.

ignore_failure

Ruby Types: TrueClass, FalseClass

Continue running a recipe if a resource fails for any reason. Default value: false.

notifies

Ruby Type: Symbol, ‘Chef::Resource[String]’

A resource may notify another resource to take action when its state changes. Specify a 'resource[name]', the :action that resource should take, and then the :timer for that action. A resource may notifiy more than one resource; use a notifies statement for each resource to be notified.

A timer specifies the point during the chef-client run at which a notification is run. The following timers are available:

:before
Specifies that the action on a notified resource should be run before processing the resource block in which the notification is located.
:delayed
Default. Specifies that a notification should be queued up, and then executed at the very end of the chef-client run.
:immediate, :immediately
Specifies that a notification should be run immediately, per resource notified.

The syntax for notifies is:

notifies :action, 'resource[name]', :timer

provider

Ruby Type: Chef Class

Optional. Explicitly specifies a provider.

retries

Ruby Type: Integer

The number of times to catch exceptions and retry the resource. Default value: 0.

retry_delay

Ruby Type: Integer

The retry delay (in seconds). Default value: 2.

subscribes

Ruby Type: Symbol, ‘Chef::Resource[String]’

A resource may listen to another resource, and then take action if the state of the resource being listened to changes. Specify a 'resource[name]', the :action to be taken, and then the :timer for that action.

A timer specifies the point during the chef-client run at which a notification is run. The following timers are available:

:before
Specifies that the action on a notified resource should be run before processing the resource block in which the notification is located.
:delayed
Default. Specifies that a notification should be queued up, and then executed at the very end of the chef-client run.
:immediate, :immediately
Specifies that a notification should be run immediately, per resource notified.

The syntax for subscribes is:

subscribes :action, 'resource[name]', :timer


#### Examples¶

Update the Apt repository at a specified interval

apt_update 'all platforms' do
frequency 86400
action :periodic
end


Update the Apt repository at the start of a chef-client run

apt_update 'update' do
action :update
end


### New chef-client options¶

The chef-client has the following new options:

--delete-entire-chef-repo
Delete the entire chef-repo. This option may only be used when running the chef-client in local mode (--local-mode) mode. This options requires --recipe-url to be specified.

## What’s New in 12.6¶

The following items are new for chef-client 12.6 and/or are changes from previous versions. The short version:

• New timer for resource notifications Use the :before timer with the notifies and subscribes properties to specify that the action on a notified resource should be run before processing the resource block in which the notification is located.
• New ksh resource The ksh resource is added and is based on the script resource.
• New metadata.rb settings The metadata.rb file has settings for chef_version and ohai_version that allow ranges to be specified that declare the supported versions of the chef-client and Ohai.
• dsc_resource supports reboots The dsc_resource resource supports immediate and queued reboots. This uses the reboot resource and its :reboot_now or :request_reboot actions.
• New and changed knife bootstrap options The --identify-file option for the knife bootstrap subcommand is renamed to --ssh-identity-file; the --sudo-preserve-home is new.
• New installer types for the windows_package resource The windows_package resource now supports the following installer types: :custom, Inno Setup (:inno), InstallShield (:installshield), Microsoft Installer Package (MSI) (:msi), Nullsoft Scriptable Install System (NSIS) (:nsis), Wise (:wise). Prior versions of Chef supported only :msi.
• dsc_resource resource may be run in non-disabled refresh mode The latest version of Windows Management Framework (WMF) 5 has relaxed the limitation that prevented the chef-client from running in non-disabled refresh mode. Requires Windows PowerShell 5.0.10586.0 or higher.
• dsc_script and dsc_resource resources may be in the same run-list The latest version of Windows Management Framework (WMF) 5 has relaxed the limitation that prevented the chef-client from running in non-disabled refresh mode, which allows the Local Configuration Manager to be set to Push. Requires Windows PowerShell 5.0.10586.0 or higher.
• New –profile-ruby option Use the --profile-ruby option to dump a (large) profiling graph into /var/chef/cache/graph_profile.out.
• New live_stream property for the execute resource Set the live_stream property to true to send the output of a command run by the execute resource to the chef-client event stream.

A timer specifies the point during the chef-client run at which a notification is run. The following timers are available:

:before
Specifies that the action on a notified resource should be run before processing the resource block in which the notification is located.
:delayed
Default. Specifies that a notification should be queued up, and then executed at the very end of the chef-client run.
:immediate, :immediately
Specifies that a notification should be run immediately, per resource notified.

### ksh¶

Use the ksh resource to execute scripts using the Korn shell (ksh) interpreter. This resource may also use any of the actions and properties that are available to the execute resource. Commands that are executed with this resource are (by their nature) not idempotent, as they are typically unique to the environment in which they are run. Use not_if and only_if to guard this resource for idempotence. New in Chef Client 12.6.

Note

The ksh script resource (which is based on the script resource) is different from the ruby_block resource because Ruby code that is run with this resource is created as a temporary file and executed like other script resources, rather than run inline.

#### Syntax¶

A ksh resource block executes scripts using ksh:

ksh 'hello world' do
code <<-EOH
echo "Hello world!"
echo "Current directory: " $cwd EOH end  where • code specifies the command to run The full syntax for all of the properties that are available to the ksh resource is: ksh 'name' do code String creates String cwd String environment Hash flags String group String, Integer notifies # see description path Array provider Chef::Provider::Script::Ksh returns Integer, Array subscribes # see description timeout Integer, Float user String, Integer umask String, Integer action Symbol # defaults to :run if not specified end  where • ksh is the resource • name is the name of the resource block • action identifies the steps the chef-client will take to bring the node into the desired state • code, creates, cwd, environment, flags, group, path, provider, returns, timeout, user, and umask are properties of this resource, with the Ruby type shown. See “Properties” section below for more information about all of the properties that may be used with this resource. #### Actions¶ This resource has the following actions: :nothing Prevent a command from running. This action is used to specify that a command is run only when another resource notifies it. :run Default. Run a script. #### Properties¶ This resource has the following properties: code Ruby Type: String A quoted (” ”) string of code to be executed. creates Ruby Type: String Prevent a command from creating a file when that file already exists. cwd Ruby Type: String The current working directory. environment Ruby Type: Hash A Hash of environment variables in the form of ({"ENV_VARIABLE" => "VALUE"}). (These variables must exist for a command to be run successfully.) flags Ruby Type: String One or more command line flags that are passed to the interpreter when a command is invoked. group Ruby Types: String, Integer The group name or group ID that must be changed before running a command. ignore_failure Ruby Types: TrueClass, FalseClass Continue running a recipe if a resource fails for any reason. Default value: false. notifies Ruby Type: Symbol, ‘Chef::Resource[String]’ A resource may notify another resource to take action when its state changes. Specify a 'resource[name]', the :action that resource should take, and then the :timer for that action. A resource may notifiy more than one resource; use a notifies statement for each resource to be notified. A timer specifies the point during the chef-client run at which a notification is run. The following timers are available: :before Specifies that the action on a notified resource should be run before processing the resource block in which the notification is located. :delayed Default. Specifies that a notification should be queued up, and then executed at the very end of the chef-client run. :immediate, :immediately Specifies that a notification should be run immediately, per resource notified. The syntax for notifies is: notifies :action, 'resource[name]', :timer  path Ruby Type: Array An array of paths to use when searching for a command. These paths are not added to the command’s environment$PATH. The default value uses the system path.

Warning

For example:

ksh 'mycommand' do
environment 'PATH' => "/my/path/to/bin:#{ENV['PATH']}"
end

provider

Ruby Type: Chef Class

Optional. Explicitly specifies a provider. See “Providers” section below for more information.

retries

Ruby Type: Integer

The number of times to catch exceptions and retry the resource. Default value: 0.

retry_delay

Ruby Type: Integer

The retry delay (in seconds). Default value: 2.

returns

Ruby Types: Integer, Array

The return value for a command. This may be an array of accepted values. An exception is raised when the return value(s) do not match. Default value: 0.

subscribes

Ruby Type: Symbol, ‘Chef::Resource[String]’

A resource may listen to another resource, and then take action if the state of the resource being listened to changes. Specify a 'resource[name]', the :action to be taken, and then the :timer for that action.

A timer specifies the point during the chef-client run at which a notification is run. The following timers are available:

:before
Specifies that the action on a notified resource should be run before processing the resource block in which the notification is located.
:delayed
Default. Specifies that a notification should be queued up, and then executed at the very end of the chef-client run.
:immediate, :immediately
Specifies that a notification should be run immediately, per resource notified.

The syntax for subscribes is:

subscribes :action, 'resource[name]', :timer

timeout

Ruby Types: Integer, Float

The amount of time (in seconds) a command is to wait before timing out. Default value: 3600.

user

Ruby Types: String, Integer

The user name or user ID that should be changed before running a command.

Ruby Types: String, Integer

### Changes for PowerShell 5.0.10586.0¶

Using the dsc_resource has the following requirements:

• Windows Management Framework (WMF) 5.0 February Preview (or higher), which includes Windows PowerShell 5.0.10018.0 (or higher).

• The RefreshMode configuration setting in the Local Configuration Manager must be set to Disabled.

NOTE: Starting with the chef-client 12.6 release, this requirement applies only for versions of Windows PowerShell earlier than 5.0.10586.0. The latest version of Windows Management Framework (WMF) 5 has relaxed the limitation that prevented the chef-client from running in non-disabled refresh mode.

• The dsc_script resource may not be used in the same run-list with the dsc_resource. This is because the dsc_script resource requires that RefreshMode in the Local Configuration Manager be set to Push, whereas the dsc_resource resource requires it to be set to Disabled.

NOTE: Starting with the chef-client 12.6 release, this requirement applies only for versions of Windows PowerShell earlier than 5.0.10586.0. The latest version of Windows Management Framework (WMF) 5 has relaxed the limitation that prevented the chef-client from running in non-disabled refresh mode, which allows the Local Configuration Manager to be set to Push.

• The dsc_resource resource can only use binary- or script-based resources. Composite DSC resources may not be used.

This is because composite resources aren’t “real” resources from the perspective of the the Local Configuration Manager (LCM). Composite resources are used by the “configuration” keyword from the PSDesiredStateConfiguration module, and then evaluated in that context. When using DSC to create the configuration document (the Managed Object Framework (MOF) file) from the configuration command, the composite resource is evaluated. Any individual resources from that composite resource are written into the Managed Object Framework (MOF) document. As far as the Local Configuration Manager (LCM) is concerned, there is no such thing as a composite resource. Unless that changes, the dsc_resource resource and/or Invoke-DscResource command cannot directly use them.

The following settings are new for metadata.rb:

Setting Description
chef_version

A range of chef-client versions that are supported by this cookbook.

For example, to match any 12.x version of the chef-client, but not 11.x or 13.x:

chef_version "~> 12"

ohai_version

A range of chef-client versions that are supported by this cookbook.

For example, to match any 8.x version of Ohai, but not 7.x or 9.x:

ohai_version "~> 8"


Note

These settings are not visible in Chef Supermarket.

### knife bootstrap Options¶

The following option is new for knife bootstrap:

--sudo-preserve-home
Use to preserve the non-root user’s HOME environment.

The --identify-file option is now --ssh-identify-file.

### –profile-ruby Option¶

Use the --profile-ruby option to dump a (large) profiling graph into /var/chef/cache/graph_profile.out. Use the graph output to help identify, and then resolve performance bottlenecks in a chef-client run. This option:

• Generates a large amount of data about the chef-client run.
• Has a dependency on the ruby-prof gem, which is packaged as part of Chef and the Chef development kit.
• Increases the amount of time required to complete the chef-client run.
• Should not be used in a production environment.

New in Chef Client 12.6.

## What’s New in 12.5¶

The following items are new for chef-client 12.5 and/or are changes from previous versions. The short version:

• New way to build custom resources The process for extending the collection of resources that are built into Chef has been simplified. It is defined only in the /resources directory using a simplified syntax that easily leverages the built-in collection of resources. (All of the ways you used to build custom resources still work.)
• “resource attributes” are now known as “resource properties” In previous releases of Chef, resource properties are referred to as attributes, but this is confusing for users because nodes also have attributes. Starting with chef-client 12.5 release—and retroactively updated for all previous releases of the documentation—”resource attributes” are now referred to as “resource properties” and the word “attribute” now refers specifically to “node attributes”.
• ps_credential helper to embed usernames and passwords Use the ps_credential helper on Microsoft Windows to create a PSCredential object—security credentials, such as a user name or password—that can be used in the dsc_script resource.
• New Handler DSL A new DSL exists to make it easier to use events that occur during the chef-client run from recipes. The on method is easily associated with events. The action the chef-client takes as a result of that event (when it occurs) is up to you.
• The -j / –json-attributes supports policy revisions and environments The JSON file used by the --json-attributes option for the chef-client may now contain the policy name and policy group associated with a policy revision or may contain the name of the environment to which the node is associated.
• verify property now uses path, not file The verify property, used by file-based resources such as remote_file and file, runs user-defined correctness checks against the proposed new file before making the change. For versions of the chef-client prior to 12.5, the name of the temporary file was stored as file; starting with chef-client 12.5, use path. This change is documented as a warning across all versions in any topic in which the version attribute is documented.
• depth property added to deploy resource The depth property allows the depth of a git repository to be truncated to the specified number of versions.
• The knife ssl check subcommand supports SNI Support for Server Name Indication (SNI) is added to the knife ssl check subcommand.
• Chef Policy group and name can now be part of the node object Chef policy is a beta feature of the chef-client that will eventually replace roles, environments or manually specifying the run_list. Policy group and name can now be stored as part of the node object rather than in the client.rb file. A recent version of the Chef server, such as 12.2.0 or higher, is needed to fully utilize this feature.

### Custom Resources¶

A custom resource:

• Is a simple extension of Chef that adds your own resources
• Is implemented and shipped as part of a cookbook
• Follows easy, repeatable syntax patterns
• Effectively leverages resources that are built into Chef and/or custom Ruby code
• Is reusable in the same way as resources that are built into Chef

For example, Chef includes built-in resources to manage files, packages, templates, and services, but it does not include a resource that manages websites.

Note

See /custom_resources.html for more information about custom resources, including a scenario that shows how to build a website resource.

#### Syntax¶

A custom resource is defined as a Ruby file and is located in a cookbook’s /resources directory. This file

• Declares the properties of the custom resource
• Defines each action the custom resource may take

The syntax for a custom resource is. For example:

property :name, RubyType, default: 'value'

# some Ruby
end

action :name do
# a mix of built-in Chef resources and Ruby
end

action :name do
# a mix of built-in Chef resources and Ruby
end


where the first action listed is the default action.

For example, the site.rb file in the exampleco cookbook could be similar to:

property :homepage, String, default: '<h1>Hello world!</h1>'

if ::File.exist?('/var/www/html/index.html')
end
end

action :create do
package 'httpd'

service 'httpd' do
action [:enable, :start]
end

file '/var/www/html/index.html' do
content homepage
end
end

action :delete do
package 'httpd' do
action :delete
end
end


where

• homepage is a property that sets the default HTML for the index.html file with a default value of '<h1>Hello world!</h1>'
• the (optional) load_current_value block loads the current values for all specified properties, in this example there is just a single property: homepage
• the if statement checks to see if the index.html file is already present on the node. If that file is already present, its contents are loaded instead of the default value for homepage
• the action block uses the built-in collection of resources to tell the chef-client how to install Apache, start the service, and then create the contents of the file located at /var/www/html/index.html
• action :create is the default resource; action :delete must be called specifically (because it is not the default resource)

Once built, the custom resource may be used in a recipe just like the any of the resources that are built into Chef. The resource gets its name from the cookbook and from the file name in the /resources directory, with an underscore (_) separating them. For example, a cookbook named exampleco with a custom resource named site.rb is used in a recipe like this:

exampleco_site 'httpd' do
homepage '<h1>Welcome to the Example Co. website!</h1>'
action :create
end


and to delete the exampleco website, do the following:

exampleco_site 'httpd' do
action :delete
end


### Custom Resource DSL¶

Use the Custom Resource DSL to define property behaviors within custom resources, such as:

• Comparing the current property value against a desired property value
• Telling the chef-client when and how to make changes

#### action_class¶

Use the action_class block to make methods available to the actions in the custom resource. Modules with helper methods created as files in the cookbook library directory may be included. New action methods may also be defined directly in the action_class block. Code in the action_class block has access to the new_resource properties.

Assume a helper module has been created in the cookbook libraries/helper.rb file.

module Sample
module Helper
def helper_method
# code
end
end
end


Methods may be made available to the custom resource actions by using an action_class block.

property file, String

action :delete do
helper_method
FileUtils.rm(file) if file_ex
end

action_class do

def file_exist
::File.exist?(file)
end

def file_ex
::File.exist?(new_resource.file)
end

require 'fileutils'

include Sample::Helper

end


#### converge_if_changed¶

Use the converge_if_changed method inside an action block in a custom resource to compare the desired property values against the current property values (as loaded by the load_current_value method). Use the converge_if_changed method to ensure that updates only occur when property values on the system are not the desired property values and to otherwise prevent a resource from being converged.

To use the converge_if_changed method, wrap it around the part of a recipe or custom resource that should only be converged when the current state is not the desired state:

action :some_action do

converge_if_changed do
# some property
end

end


For example, a custom resource defines two properties (content and path) and a single action (:create). Use the load_current_value method to load the property value to be compared, and then use the converge_if_changed method to tell the chef-client what to do if that value is not the desired value:

property :content, String
property :path, String, name_property: true

if ::File.exist?(path)
end
end

action :create do
converge_if_changed do
IO.write(path, content)
end
end


When the file does not exist, the IO.write(path, content) code is executed and the chef-client output will print something similar to:

Recipe: recipe_name::block
* resource_name[blah] action create
- update my_file[blah]
-   set content to "hola mundo" (was "hello world")

##### Multiple Properties¶

The converge_if_changed method may be used multiple times. The following example shows how to use the converge_if_changed method to compare the multiple desired property values against the current property values (as loaded by the load_current_value method).

property :path, String, name_property: true
property :content, String
property :mode, String

if ::File.exist?(path)
mode ::File.stat(path).mode
end
end

action :create do
converge_if_changed :content do
IO.write(path, content)
end
converge_if_changed :mode do
::File.chmod(mode, path)
end
end


where

• A converge_if_changed block tests only content
• A converge_if_changed block tests only mode

The chef-client will only update the property values that require updates and will not make changes when the property values are already in the desired state

#### default_action¶

The default action in a custom resource is, by default, the first action listed in the custom resource. For example, action aaaaa is the default resource:

property :name, RubyType, default: 'value'

...

action :aaaaa do
# the first action listed in the custom resource
end

action :bbbbb do
# the second action listed in the custom resource
end


The default_action method may also be used to specify the default action. For example:

property :name, RubyType, default: 'value'

default_action :aaaaa

action :aaaaa do
# the first action listed in the custom resource
end

action :bbbbb do
# the second action listed in the custom resource
end


defines action aaaaa as the default action. If default_action :bbbbb is specified, then action bbbbb is the default action. Use this method for clarity in custom resources, if deliberately stating the default resource is desired, or to specify a default action that is not listed first in the custom resource.

Use the load_current_value method to load the specified property values from the node, and then use those values when the resource is converged. This method may take a block argument.

Use the load_current_value method to guard against property values being replaced. For example:

action :some_action do

if ::File.exist?('/var/www/html/index.html')
end
if ::File.exist?('/var/www/html/404.html')
end
end

end


This ensures the values for homepage and page_not_found are not changed to the default values when the chef-client configures the node.

#### new_resource.property¶

Custom resources are designed to use core resources that are built into Chef. In some cases, it may be necessary to specify a property in the custom resource that is the same as a property in a core resource, for the purpose of overriding that property when used with the custom resource. For example:

resource_name :node_execute

property :command, String, name_property: true
property :version, String

# Useful properties from the execute resource
property :cwd, String
property :environment, Hash, default: {}
property :user, [String, Integer]
property :sensitive, [true, false], default: false

prefix = '/opt/languages/node'

current_value_does_not_exist! if node.run_state['nodejs'].nil?
version node.run_state['nodejs'][:version]
end

action :run do
execute 'execute-node' do
cwd cwd
environment environment
user user
sensitive sensitive
# gsub replaces 10+ spaces at the beginning of the line with nothing
command <<-CODE.gsub(/^ {10}/, '')
#{prefix}/#{version}/#{command}
CODE
end
end


where the property :cwd, property :environment, property :user, and property :sensitive are identical to properties in the execute resource, embedded as part of the action :run action. Because both the custom properties and the execute properties are identical, this will result in an error message similar to:

ArgumentError
-------------
wrong number of arguments (0 for 1)


To prevent this behavior, use new_resource. to tell the chef-client to process the properties from the core resource instead of the properties in the custom resource. For example:

resource_name :node_execute

property :command, String, name_property: true
property :version, String

# Useful properties from the execute resource
property :cwd, String
property :environment, Hash, default: {}
property :user, [String, Integer]
property :sensitive, [true, false], default: false

prefix = '/opt/languages/node'

current_value_does_not_exist! if node.run_state['nodejs'].nil?
version node.run_state['nodejs'][:version]
end

action :run do
execute 'execute-node' do
cwd new_resource.cwd
environment new_resource.environment
user new_resource.user
sensitive new_resource.sensitive
# gsub replaces 10+ spaces at the beginning of the line with nothing
command <<-CODE.gsub(/^ {10}/, '')
#{prefix}/#{new_resource.version}/#{new_resource.command}
CODE
end
end


where cwd new_resource.cwd, environment new_resource.environment, user new_resource.user, and sensitive new_resource.sensitive correctly use the properties of the execute resource and not the identically-named override properties of the custom resource.

#### property¶

Use the property method to define properties for the custom resource. The syntax is:

property :name, ruby_type, default: 'value', parameter: 'value'


where

• :name is the name of the property
• ruby_type is the optional Ruby type or array of types, such as String, Integer, true, or false
• default: 'value' is the optional default value loaded into the resource
• parameter: 'value' optional parameters

For example, the following properties define username and password properties with no default values specified:

property :username, String

##### ruby_type¶

The property ruby_type is a positional parameter. Use to ensure a property value is of a particular ruby class, such as true, false, nil, String, Array, Hash, Integer, Symbol. Use an array of ruby classes to allow a value to be of more than one type. For example:

property :name, String

property :name, Integer

property :name, Hash

property :name, [true, false]

property :name, [String, nil]

property :name, [Class, String, Symbol]

property :name, [Array, Hash]

##### validators¶

A validation parameter is used to add zero (or more) validation parameters to a property.

Parameter Description
:callbacks

Use to define a collection of unique keys and values (a ruby hash) for which the key is the error message and the value is a lambda to validate the parameter. For example:

callbacks: {
'should be a valid non-system port' => lambda {
|p| p > 1024 && p < 65535
}
}

:default

Use to specify the default value for a property. For example:

default: 'a_string_value'

default: 123456789

default: []

default: ()

default: {}

:equal_to

Use to match a value with ==. Use an array of values to match any of those values with ==. For example:

equal_to: [true, false]

equal_to: ['php', 'perl']

:regex

Use to match a value to a regular expression. For example:

regex: [ /^([a-z]|[A-Z]|[0-9]|_|-)+$/, /^\d+$/ ]

:required

Indicates that a property is required. For example:

required: true

:respond_to

Use to ensure that a value has a given method. This can be a single method name or an array of method names. For example:

respond_to: valid_encoding?


Some examples of combining validation parameters:

property :spool_name, String, regex: /$\w+/  property :enabled, equal_to: [true, false, 'true', 'false'], default: true  ##### desired_state¶ Add desired_state: to get or set the list of desired state properties for a resource, which describe the desired state of the node, such as permissions on an existing file. This value may be true or false. • When true, the state of the system will determine the value. • When false, the values defined by the recipe or custom resource will determine the value, i.e. “the desired state of this system includes setting the value defined in this custom resource or recipe” For example, the following properties define the owner, group, and mode properties for a file that already exists on the node, and with desired_state set to false: property :owner, String, default: 'root', desired_state: false property :group, String, default: 'root', desired_state: false property :mode, String, default: '0755', desired_state: false  ##### identity¶ Add identity: to set a resource to a particular set of properties. This value may be true or false. • When true, data for that property is returned as part of the resource data set and may be available to external applications, such as reporting • When false, no data for that property is returned. If no properties are marked true, the property that defaults to the name of the resource is marked true. For example, the following properties define username and password properties with no default values specified, but with identity set to true for the user name: property :username, String, identity: true property :password, String  ##### Block Arguments¶ Any properties that are marked identity: true or desired_state: false will be available from load_current_value. If access to other properties of a resource is needed, use a block argument that contains all of the properties of the requested resource. For example: resource_name :file load_current_value do |desired| puts "The user typed content = #{desired.content} in the resource" end  #### property_is_set?¶ Use the property_is_set? method to check if the value for a property is set. The syntax is: property_is_set?(:property_name)  The property_is_set? method will return true if the property is set. For example, the following custom resource creates and/or updates user properties, but not their password. The property_is_set? method checks if the user has specified a password and then tells the chef-client what to do if the password is not identical: action :create do converge_if_changed do system("rabbitmqctl create_or_update_user #{username} --prop1 #{prop1} ... ") end if property_is_set?(:password) if system("rabbitmqctl authenticate_user #{username} #{password}") != 0 do converge_by "Updating password for user #{username} ..." do system("rabbitmqctl update_user #{username} --password #{password}") end end  #### provides¶ Use the provides method to associate a custom resource with the Recipe DSL on different operating systems. When multiple custom resources use the same DSL, specificity rules are applied to determine the priority, from highest to lowest: 1. provides :resource_name, platform_version: ‘0.1.2’ 2. provides :resource_name, platform: ‘platform_name’ 3. provides :resource_name, platform_family: ‘platform_family’ 4. provides :resource_name, os: ‘operating_system’ 5. provides :resource_name For example: provides :my_custom_resource, platform: 'redhat' do |node| node['platform_version'].to_i >= 7 end provides :my_custom_resource, platform: 'redhat' provides :my_custom_resource, platform_family: 'rhel' provides :my_custom_resource, os: 'linux' provides :my_custom_resource  This allows you to use multiple custom resources files that provide the same resource to the user, but for different operating systems or operation system versions. With this you can eliminate the need for platform or platform version logic within your resources. ##### override¶ Chef will warn you if the Recipe DSL is provided by another custom resource or built-in resource. For example: class X < Chef::Resource provides :file end class Y < Chef::Resource provides :file end  This will emit a warning that Y is overriding X. To disable this warning, use override: true: class X < Chef::Resource provides :file end class Y < Chef::Resource provides :file, override: true end  #### reset_property¶ Use the reset_property method to clear the value for a property as if it had never been set, and then use the default value. For example, to clear the value for a property named password: reset_property(:password)  ### Definition vs. Resource¶ The following examples show: 1. A definition 2. The same definition rewritten as a custom resource 3. The same definition, rewritten again to use a common resource property #### As a Definition¶ The following definition processes unique hostnames and ports, passed on as parameters: define :host_porter, :port => 4000, :hostname => nil do params[:hostname] ||= params[:name] directory '/etc/#{params[:hostname]}' do recursive true end file '/etc/#{params[:hostname]}/#{params[:port]}' do content 'some content' end end  #### As a Resource¶ The definition is improved by rewriting it as a custom resource: property :port, Integer, default: 4000 property :hostname, String, name_property: true action :create do directory "/etc/#{hostname}" do recursive true end file "/etc/#{hostname}/#{port}" do content 'some content' end end  Once built, the custom resource may be used in a recipe just like the any of the resources that are built into Chef. The resource gets its name from the cookbook and from the file name in the /resources directory, with an underscore (_) separating them. For example, a cookbook named host with a custom resource in the /resources directory named porter.rb. Use it in a recipe like this: host_porter node['hostname'] do port 4000 end  or: host_porter 'www1' do port 4001 end  #### Common Properties¶ Unlike definitions, custom resources are able to use common resource properties. For example, only_if: host_porter 'www1' do port 4001 only_if '{ node['hostname'] == 'foo.bar.com' }' end  ### ps_credential Helper¶ Use the ps_credential helper to embed a PSCredential object—a set of security credentials, such as a user name or password—within a script, which allows that script to be run using security credentials. For example, assuming the CertificateID is configured in the local configuration manager, the SeaPower1@3 object is created and embedded within the seapower-user script:  dsc_script 'seapower-user' do code <<-EOH User AlbertAtom { UserName = 'AlbertAtom' Password = #{ps_credential('SeaPower1@3')} } EOH configuration_data <<-EOH @{ AllNodes = @( @{ NodeName = "localhost"; CertificateID = 'A8D1234559F349F7EF19104678908F701D4167' } ) } EOH end  ### Handler DSL¶ Use the Handler DSL to attach a callback to an event. If the event occurs during the chef-client run, the associated callback is executed. For example: • Sending email if a chef-client run fails • Sending a notification to chat application if an audit run fails • Aggregating statistics about resources updated during a chef-client runs to StatsD #### on Method¶ Use the on method to associate an event type with a callback. The callback defines what steps are taken if the event occurs during the chef-client run and is defined using arbitrary Ruby code. The syntax is as follows: Chef.event_handler do on :event_type do # some Ruby end end  where • Chef.event_handler declares a block of code within a recipe that is processed when the named event occurs during a chef-client run • on defines the block of code that will tell the chef-client how to handle the event • :event_type is a valid exception event type, such as :run_start, :run_failed, :converge_failed, :resource_failed, or :recipe_not_found For example: Chef.event_handler do on :converge_start do puts "Ohai! I have started a converge." end end  #### Example: Send Email¶ Use the on method to create an event handler that sends email when the chef-client run fails. This will require: • A way to tell the chef-client how to send email • An event handler that describes what to do when the :run_failed event is triggered • A way to trigger the exception and test the behavior of the event handler Note See /dsl_handler.html for more information about using event handlers in recipes. Define How Email is Sent Use a library to define the code that sends email when a chef-client run fails. Name the file helper.rb and add it to a cookbook’s /libraries directory: require 'net/smtp' module HandlerSendEmail class Helper def send_email_on_run_failure(node_name) message = "From: Chef <chef@chef.io>\n" message << "To: Grant <grantmc@chef.io>\n" message << "Subject: Chef run failed\n" message << "Date: #{Time.now.rfc2822}\n\n" message << "Chef run failed on #{node_name}\n" Net::SMTP.start('localhost', 25) do |smtp| smtp.send_message message, 'chef@chef.io', 'grantmc@chef.io' end end end end  Add the Handler Invoke the library helper in a recipe: Chef.event_handler do on :run_failed do HandlerSendEmail::Helper.new.send_email_on_run_failure( Chef.run_context.node.name ) end end  • Use Chef.event_handler to define the event handler • Use the on method to specify the event type Within the on block, tell the chef-client how to handle the event when it’s triggered. Test the Handler Use the following code block to trigger the exception and have the chef-client send email to the specified email address: ruby_block 'fail the run' do block do fail 'deliberately fail the run' end end  ### New Resource Properties¶ The following property is new for the deploy resource: Property Description depth Ruby Type: Integer The depth of a git repository, truncated to the specified number of revisions. ### Specify Policy Revision¶ Use the following command to specify a policy revision: $ chef client -j JSON


where the JSON file is similar to:

{
"policy_name": "appserver",
"policy_group": "staging"
}


Or use the following settings to specify a policy revision in the client.rb file:

Setting Description
policy_group The name of a policy, as identified by the name setting in a Policyfile.rb file.
policy_name The name of a policy group that exists on the Chef server.

### New Configuration Settings¶

The following settings are new for the client.rb file and enable the use of policy files:

Setting Description
named_run_list The run-list associated with a policy file.
policy_group The name of a policy, as identified by the name setting in a Policyfile.rb file. (See “Specify Policy Revision” in this readme for more information.)
policy_name The name of a policy group that exists on the Chef server. (See “Specify Policy Revision” in this readme for more information.)

### chef-client Options¶

The following options are new or updated for the chef-client executable and enable the use of policy files:

-n NAME, --named-run-list NAME
The run-list associated with a policy file.
-j PATH, --json-attributes PATH

This option now supports using a JSON file to associate a policy revision.

Use this option to use policy files by specifying a JSON file that contains the following settings:

Setting Description
policy_group The name of a policy, as identified by the name setting in a Policyfile.rb file.
policy_name The name of a policy group that exists on the Chef server.

For example:

{
"policy_name": "appserver",
"policy_group": "staging"
}


This option also supports using a JSON file to associate an environment:

Use this option to set the chef_environment value for a node.

Note

Any environment specified for chef_environment by a JSON file will take precedence over an environment specified by the --environment option when both options are part of the same command.

For example, run the following:

$chef-client -j /path/to/file.json  where /path/to/file.json is similar to: { "chef_environment": "pre-production" }  This will set the environment for the node to pre-production. ## What’s New in 12.4¶ The following items are new for chef-client 12.4 and/or are changes from previous versions. The short version: • Validatorless bootstrap now requires the node name Use of the -N node_name option with a validatorless bootstrap is now required. • remote_file resource supports Windows UNC paths for source location A Microsoft Windows UNC path may be used to specify the location of a remote file. • Run PowerShell commands without excessive quoting Use the Import-Module chef module to run Windows PowerShell commands without excessive quotation. • Logging may use the Windows Event Logger Log files may be sent to the Windows Event Logger. Set the log_location setting in the client.rb file to Chef::Log::WinEvt.new. • Logging may be configured to use daemon facility available to the chef-client Log files may be sent to the syslog available to the chef-client. Set the log_location setting in the client.rb file to Chef::Log::Syslog.new("chef-client", ::Syslog::LOG_DAEMON). • Package locations on the Windows platform may be specified using a URL The location of a package may be at URL when using the windows_package resource. • Package locations on the Windows platform may be specified by passing attributes to the remote_file resource Use the remote_file_attributes attribute to pass a Hash of attributes that modifies the remote_file resource. • Public key management for users and clients The knife client and knife user subcommands may now create, delete, edit, list, and show public keys. • knife client create and knife user create options have changed With the new key management subcommands, the options for knife client create and knife user create have changed. • chef-client audit-mode is no longer marked as “experimental” The recommended version of audit-mode is chef-client 12.4, where it is no longer marked as experimental. The chef-client will report audit failures independently of converge failures. ### UNC paths, remote_file¶ When using the remote_file resource, the location of a source file may be specified using a Microsoft Windows UNC. For example: source "\\\\path\\to\\img\\sketch.png"  ### Import-Module chef¶ The chef-client version 12.4 release adds an optional feature to the Microsoft Installer Package (MSI) for Chef. This feature enables the ability to pass quoted strings from the Windows PowerShell command line without the need for triple single quotes (''' '''). This feature installs a Windows PowerShell module (typically in C:\opscode\chef\modules) that is also appended to the PSModulePath environment variable. This feature is not enabled by default. To activate this feature, run the following command from within Windows PowerShell: $ Import-Module chef


or add Import-Module chef to the profile for Windows PowerShell located at:

~\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1


This module exports cmdlets that have the same name as the command-line tools—chef-client, knife, chef-apply—that are built into Chef.

For example:

$knife exec -E 'puts ARGV' """&s0meth1ng"""  is now: $ knife exec -E 'puts ARGV' '&s0meth1ng'


and:

$knife node run_list set test-node '''role[ssssssomething]'''  is now: $ knife node run_list set test-node 'role[ssssssomething]'


To remove this feature, run the following command from within Windows PowerShell:


##### Options¶

This argument has the following options:

-e DATE, --expiration-date DATE
The expiration date for the public key, specified as an ISO 8601 formatted string: YYYY-MM-DDTHH:MM:SSZ. If this option is not specified, the public key will not have an expiration date. For example: 2013-12-24T21:00:00Z.
-f FILE, --file FILE
Save a private key to the specified file name. If the --public-key option is not specified the Chef server will generate a private key.
-k NAME, --key-name NAME
The name of the public key.
-p FILE_NAME, --public-key FILE_NAME
The path to a file that contains the public key. If this option is not specified, and only if --key-name is specified, the Chef server will generate a public/private key pair.

#### key delete¶

Use the key delete argument to delete a public key.

##### Syntax¶

This argument has the following syntax:


##### Options¶

This argument has the following options:

-c, --create-key
Generate a new public/private key pair and replace an existing public key with the newly-generated public key. To replace the public key with an existing public key, use --public-key instead.
-e DATE, --expiration-date DATE
The expiration date for the public key, specified as an ISO 8601 formatted string: YYYY-MM-DDTHH:MM:SSZ. If this option is not specified, the public key will not have an expiration date. For example: 2013-12-24T21:00:00Z.
-f FILE, --file FILE
Save a private key to the specified file name. If the --public-key option is not specified the Chef server will generate a private key.
-k NAME, --key-name NAME
The name of the public key.
-p FILE_NAME, --public-key FILE_NAME
The path to a file that contains the public key. If this option is not specified, and only if --key-name is specified, the Chef server will generate a public/private key pair.

#### key list¶

Use the key list argument to view a list of public keys for the named client.

##### Syntax¶

This argument has the following syntax:



### knife user key¶

The knife user subcommand is used to manage the list of users and their associated RSA public key-pairs.

#### key create¶

Use the key create argument to create a public key.

##### Syntax¶

This argument has the following syntax:



#### key edit¶

Use the key edit argument to modify or rename a public key.

##### Syntax¶

This argument has the following syntax:


##### Options¶

This argument has the following options:

-e, --only-expired
Show a list of public keys that have expired.
-n, --only-non-expired
Show a list of public keys that have not expired.
-w, --with-details
Show a list of public keys, including URIs and expiration status.

#### key show¶

Use the key show argument to view details for a specific public key.

##### Syntax¶

This argument has the following syntax:

Fixnum Integer
Float Double
Hash Hashtable
TrueClass bool($true) These are converted into the corresponding Windows PowerShell type during the chef-client run. resource Ruby Type: String The name of the DSC resource. This value is case-insensitive and must be a symbol that matches the name of the DSC resource. For built-in DSC resources, use the following values: Value Description :archive Use to to unpack archive (.zip) files. :environment Use to to manage system environment variables. :file Use to to manage files and directories. :group Use to to manage local groups. :log Use to to log configuration messages. :package Use to to install and manage packages. :registry Use to to manage registry keys and registry key values. :script Use to to run Powershell script blocks. :service Use to to manage services. :user Use to to manage local user accounts. :windowsfeature Use to to add or remove Windows features and roles. :windowsoptionalfeature Use to configure Microsoft Windows optional features. :windowsprocess Use to to configure Windows processes. Any DSC resource may be used in a Chef recipe. For example, the DSC Resource Kit contains resources for configuring Active Directory components, such as xADDomain, xADDomainController, and xADUser. Assuming that these resources are available to the chef-client, the corresponding values for the resource attribute would be: :xADDomain, :xADDomainController, and xADUser. retries Ruby Type: Integer The number of times to catch exceptions and retry the resource. Default value: 0. retry_delay Ruby Type: Integer The retry delay (in seconds). Default value: 2. subscribes Ruby Type: Symbol, ‘Chef::Resource[String]’ A resource may listen to another resource, and then take action if the state of the resource being listened to changes. Specify a 'resource[name]', the :action to be taken, and then the :timer for that action. A timer specifies the point during the chef-client run at which a notification is run. The following timers are available: :delayed Default. Specifies that a notification should be queued up, and then executed at the very end of the chef-client run. :immediate, :immediately Specifies that a notification should be run immediately, per resource notified. The syntax for subscribes is: subscribes :action, 'resource[name]', :timer  #### Examples¶ Open a Zip file dsc_resource 'example' do resource :archive property :ensure, 'Present' property :path, 'C:\Users\Public\Documents\example.zip' property :destination, 'C:\Users\Public\Documents\ExtractionPath' end  Manage users and groups dsc_resource 'demogroupadd' do resource :group property :groupname, 'demo1' property :ensure, 'present' end dsc_resource 'useradd' do resource :user property :username, 'Foobar1' property :fullname, 'Foobar1' property :password, ps_credential('P@assword!') property :ensure, 'present' end dsc_resource 'AddFoobar1ToUsers' do resource :Group property :GroupName, 'demo1' property :MembersToInclude, ['Foobar1'] end  ## What’s New in 12.1¶ The following items are new for chef-client 12.1 and/or are changes from previous versions. The short version: • chef-client may be run in audit-mode Use audit-mode to run audit tests against a node. • control method added to Recipe DSL Use the control method to define specific tests that match directories, files, packages, ports, and services. A control method must be contained within a control_group block. • control_group method added to Recipe DSL Use the control_group method to group one (or more) control methods into a single audit. • Bootstrap nodes without using the ORGANIZATION-validator.key file A node may now be bootstrapped using the USER.pem file, instead of the ORGANIZATION-validator.pem file. Also known as a “validatorless bootstrap”. • New options for knife-bootstrap Use the --bootstrap-vault-file, --bootstrap-vault-item, and --bootstrap-vault-json options with knife bootstrap to specify items that are stored in chef-vault. • New verify attribute for cookbook_file, file, remote_file, and template resources Use the verify attribute to test a file using a block of code or a string. • New imports attribute for dsc_script resource Use the imports attribute to import DSC resources from modules. • New attribute for chef_gem resource Use the compile_time attribute to disable compile-time installation of gems. • New openbsd_package resource Use the openbsd_package resource to install packages on the OpenBSD platform. • New –proxy-auth option for knife raw subcommand Enable proxy authentication to the Chef server web user interface.. • New watchdog_timeout setting for the Windows platform Use the windows_service.watchdog_timeout setting in the client.rb file to specify the maximum amount of time allowed for a chef-client run on the Microsoft Windows platform. • Support for multiple packages and versions Multiple packages and versions may be specified for platforms that use Yum or Apt. • New attributes for windows_service resource Use the run_as_user and run_as_password attributes to specify the user under which a Microsoft Windows service should run. ### chef-client, audit-mode¶ The chef-client may be run in audit-mode. Use audit-mode to evaluate custom rules—also referred to as audits—that are defined in recipes. audit-mode may be run in the following ways: • By itself (i.e. a chef-client run that does not build the resource collection or converge the node) • As part of the chef-client run, where audit-mode runs after all resources have been converged on the node Each audit is authored within a recipe using the control_group and control methods that are part of the Recipe DSL. Recipes that contain audits are added to the run-list, after which they can be processed by the chef-client. Output will appear in the same location as the regular chef-client run (as specified by the log_location setting in the client.rb file). Finished audits are reported back to the Chef server. From there, audits are sent to the Chef Analytics platform for further analysis, such as rules processing and visibility from the actions web user interface. Use following option to run the chef-client in audit-mode mode: --audit-mode MODE Enable audit-mode. Set to audit-only to skip the converge phase of the chef-client run and only perform audits. Possible values: audit-only, disabled, and enabled. Default value: disabled. #### The Audit Run¶ The following diagram shows the stages of the audit-mode phase of the chef-client run, and then the list below the diagram describes in greater detail each of those stages. When the chef-client is run in audit-mode, the following happens: Stages Description chef-client Run ID The chef-client run identifier is associated with each audit. Configure the Node If audit-mode is run as part of the full chef-client run, audit-mode occurs after the chef-client has finished converging all resources in the resource collection. Audit node based on controls in cookbooks Each control_group and control block found in any recipe that was part of the run-list of for the node is evaluated, with each expression in each control block verified against the state of the node. Upload audit data to the Chef server When audit-mode mode is complete, the data is uploaded to the Chef server. Send to Chef Analytics Most of this data is passed to the Chef Analytics platform for further analysis, such as rules processing (for notification events triggered by expected or unexpected audit outcomes) and visibility from the actions web user interface. ### control¶ A control is an automated test that is built into a cookbook, and then used to test the state of the system for compliance. Compliance can be many things. For example, ensuring that file and directory management meets specific internal IT policies—”Does the file exist?”, “Do the correct users or groups have access to this directory?”. Compliance may also be complex, such as helping to ensure goals defined by large-scale compliance frameworks such as PCI, HIPAA, and Sarbanes-Oxley can be met. Use the control method to define a specific series of tests that comprise an individual audit. A control method MUST be contained within a control_group block. A control_group block may contain multiple control methods. The syntax for the control method is as follows: control_group 'audit name' do control 'name' do it 'should do something' do expect(something).to/.to_not be_something end end end  where: • control_group groups one (or more) control blocks • control 'name' do defines an individual audit • Each control block must define at least one validation • Each it statement defines a single validation. it statements are processed individually when the chef-client is run in audit-mode • An expect(something).to/.to_not be_something is a statement that represents the individual test. In other words, this statement tests if something is expected to be (or not be) something. For example, a test that expects the PostgreSQL pacakge to not be installed would be similar to expect(package('postgresql')).to_not be_installed and a test that ensures a service is enabled would be similar to expect(service('init')).to be_enabled • An it statement may contain multiple expect statements #### directory Matcher¶ Matchers are available for directories. Use this matcher to define audits for directories that test if the directory exists, is mounted, and if it is linked to. This matcher uses the same matching syntax—expect(file('foo'))—as the files. The following matchers are available for directories: Matcher Description, Example be_directory Use to test if directory exists. For example: it 'should be a directory' do expect(file('/var/directory')).to be_directory end  be_linked_to Use to test if a subject is linked to the named directory. For example: it 'should be linked to the named directory' do expect(file('/etc/directory')).to be_linked_to('/etc/some/other/directory') end  be_mounted Use to test if a directory is mounted. For example: it 'should be mounted' do expect(file('/')).to be_mounted end  For directories with a single attribute that requires testing: it 'should be mounted with an ext4 partition' do expect(file('/')).to be_mounted.with( :type => 'ext4' ) end  For directories with multiple attributes that require testing: it 'should be mounted only with certain attributes' do expect(file('/')).to be_mounted.only_with( :attribute => 'value', :attribute => 'value', ) end  #### file Matcher¶ Matchers are available for files and directories. Use this matcher to define audits for files that test if the file exists, its version, if it is is executable, writable, or readable, who owns it, verify checksums (both MD5 and SHA-256) and so on. The following matchers are available for files: Matcher Description, Example be_executable Use to test if a file is executable. For example: it 'should be executable' do expect(file('/etc/file')).to be_executable end  For a file that is executable by its owner: it 'should be executable by owner' do expect(file('/etc/file')).to be_executable.by('owner') end  For a file that is executable by a group: it 'should be executable by group members' do expect(file('/etc/file')).to be_executable.by('group') end  For a file that is executable by a specific user: it 'should be executable by user foo' do expect(file('/etc/file')).to be_executable.by_user('foo') end  be_file Use to test if a file exists. For example: it 'should be a file' do expect(file('/etc/file')).to be_file end  be_grouped_into Use to test if a file is grouped into the named group. For example: it 'should be grouped into foo' do expect(file('/etc/file')).to be_grouped_into('foo') end  be_linked_to Use to test if a subject is linked to the named file. For example: it 'should be linked to the named file' do expect(file('/etc/file')).to be_linked_to('/etc/some/other/file') end  be_mode Use to test if a file is set to the specified mode. For example: it 'should be mode 440' do expect(file('/etc/file')).to be_mode(440) end  be_owned_by Use to test if a file is owned by the named owner. For example: it 'should be owned by the root user' do expect(file('/etc/sudoers')).to be_owned_by('root') end  be_readable Use to test if a file is readable. For example: it 'should be readable' do expect(file('/etc/file')).to be_readable end  For a file that is readable by its owner: it 'should be readable by owner' do expect(file('/etc/file')).to be_readable.by('owner') end  For a file that is readable by a group: it 'should be readable by group members' do expect(file('/etc/file')).to be_readable.by('group') end  For a file that is readable by a specific user: it 'should be readable by user foo' do expect(file('/etc/file')).to be_readable.by_user('foo') end  be_socket Use to test if a file exists as a socket. For example: it 'should be a socket' do expect(file('/var/file.sock')).to be_socket end  be_symlink Use to test if a file exists as a symbolic link. For example: it 'should be a symlink' do expect(file('/etc/file')).to be_symlink end  be_version Microsoft Windows only. Use to test if a file is the specified version. For example: it 'should be version 1.2' do expect(file('C:\\Windows\\path\\to\\file')).to be_version('1.2') end  be_writable Use to test if a file is writable. For example: it 'should be writable' do expect(file('/etc/file')).to be_writable end  For a file that is writable by its owner: it 'should be writable by owner' do expect(file('/etc/file')).to be_writable.by('owner') end  For a file that is writable by a group: it 'should be writable by group members' do expect(file('/etc/file')).to be_writable.by('group') end  For a file that is writable by a specific user: it 'should be writable by user foo' do expect(file('/etc/file')).to be_writable.by_user('foo') end  contain Use to test if a file contains specific contents. For example: it 'should contain docs.chef.io' do expect(file('/etc/file')).to contain('docs.chef.io') end  #### package Matcher¶ Matchers are available for packages and may be used to define audits that test if a package or a package version is installed. The following matchers are available: Matcher Description, Example be_installed Use to test if the named package is installed. For example: it 'should be installed' do expect(package('httpd')).to be_installed end  For a specific package version: it 'should be installed' do expect(package('httpd')).to be_installed.with_version('0.1.2') end  #### port Matcher¶ Matchers are available for ports and may be used to define audits that test if a port is listening. The following matchers are available: Matcher Description, Example be_listening Use to test if the named port is listening. For example: it 'should be listening' do expect(port(23)).to be_listening end  For a named port that is not listening: it 'should not be listening' do expect(port(23)).to_not be_listening end  For a specific port type use .with('port_type'). For example, UDP: it 'should be listening with UDP' do expect(port(23)).to_not be_listening.with('udp') end  For UDP, version 6: it 'should be listening with UDP6' do expect(port(23)).to_not be_listening.with('udp6') end  For TCP/IP: it 'should be listening with TCP' do expect(port(23)).to_not be_listening.with('tcp') end  For TCP/IP, version 6: it 'should be listening with TCP6' do expect(port(23)).to_not be_listening.with('tcp6') end  #### service Matcher¶ Matchers are available for services and may be used to define audits that test for conditions related to services, such as if they are enabled, running, have the correct startup mode, and so on. The following matchers are available: Matcher Description, Example be_enabled Use to test if the named service is enabled (i.e. will start up automatically). For example: it 'should be enabled' do expect(service('ntpd')).to be_enabled end  For a service that is enabled at a given run level: it 'should be enabled at the specified run level' do expect(service('ntpd')).to be_enabled.with_level(3) end  be_installed Microsoft Windows only. Use to test if the named service is installed on the Microsoft Windows platform. For example: it 'should be installed' do expect(service('DNS Client')).to be_installed end  be_running Use to test if the named service is running. For example: it 'should be running' do expect(service('ntpd')).to be_running end  For a service that is running under supervisor: it 'should be running under supervisor' do expect(service('ntpd')).to be_running.under('supervisor') end  or daemontools: it 'should be running under daemontools' do expect(service('ntpd')).to be_running.under('daemontools') end  or Upstart: it 'should be running under upstart' do expect(service('ntpd')).to be_running.under('upstart') end  be_monitored_by Use to test if the named service is being monitored by the named monitoring application. For example: it 'should be monitored by' do expect(service('ntpd')).to be_monitored_by('monit') end  have_start_mode Microsoft Windows only. Use to test if the named service’s startup mode is correct on the Microsoft Windows platform. For example: it 'should start manually' do expect(service('DNS Client')).to have_start_mode.Manual end  #### Examples¶ A package is installed For example, a package is installed: control_group 'audit name' do control 'mysql package' do it 'should be installed' do expect(package('mysql')).to be_installed end end end  The control_group block is processed when the chef-client run is run in audit-mode. If the audit was successful, the chef-client will return output similar to: Audit Mode mysql package should be installed  If an audit was unsuccessful, the chef-client will return output similar to: Starting audit phase Audit Mode mysql package should be installed (FAILED - 1) Failures: 1) Audit Mode mysql package should be installed Failure/Error: expect(package('mysql')).to be_installed.with_version('5.6') expected Package 'mysql' to be installed # /var/chef/cache/cookbooks/grantmc/recipes/default.rb:22:in 'block (3 levels) in from_file' Finished in 0.5745 seconds (files took 0.46481 seconds to load) 1 examples, 1 failures Failed examples: rspec /var/chef/cache/cookbooks/grantmc/recipes/default.rb:21 # Audit Mode mysql package should be installed  A package version is installed A package that is installed with a specific version: control_group 'audit name' do control 'mysql package' do it 'should be installed' do expect(package('mysql')).to be_installed.with_version('5.6') end end end  A package is not installed A package that is not installed: control_group 'audit name' do control 'postgres package' do it 'should not be installed' do expect(package('postgresql')).to_not be_installed end end end  If the audit was successful, the chef-client will return output similar to: Audit Mode postgres audit postgres package is not installed  A service is enabled A service that is enabled and running: control_group 'audit name' do control 'mysql service' do let(:mysql_service) { service('mysql') } it 'should be enabled' do expect(mysql_service).to be_enabled end it 'should be running' do expect(mysql_service).to be_running end end end  If the audit was successful, the chef-client will return output similar to: Audit Mode mysql service audit mysql service is enabled is running  A configuration file contains specific settings The following example shows how to verify sshd configration, including whether it’s installed, what the permissions are, and how it can be accessed: control_group 'check sshd configuration' do control 'sshd package' do it 'should be installed' do expect(package('openssh-server')).to be_installed end end control 'sshd configuration' do let(:config_file) { file('/etc/ssh/sshd_config') } it 'should exist with the right permissions' do expect(config_file).to be_file expect(config_file).to be_mode(644) expect(config_file).to be_owned_by('root') expect(config_file).to be_grouped_into('root') end it 'should not permit RootLogin' do expect(config_file.content).to_not match(/^PermitRootLogin yes/) end it 'should explicitly not permit PasswordAuthentication' do expect(config_file.content).to match(/^PasswordAuthentication no/) end it 'should force privilege separation' do expect(config_file.content).to match(/^UsePrivilegeSeparation sandbox/) end end end  where • let(:config_file) { file('/etc/ssh/sshd_config') } uses the file matcher to test specific settings within the sshd configuration file A file contains desired permissions and contents The following example shows how to verify that a file has the desired permissions and contents: controls 'mysql config' do control 'mysql config file' do let(:config_file) { file('/etc/mysql/my.cnf') } it 'exists with correct permissions' do expect(config_file).to be_file expect(config_file).to be_mode(0400) end it 'contains required configuration' do expect(its('contents')).to match(/default-time-zone='UTC'/) end end end  If the audit was successful, the chef-client will return output similar to: Audit Mode mysql config mysql config file exists with correct permissions contains required configuration  ### control_group¶ Use the control_group method to define a group of control methods that comprise a single audit. The name of each control_group must be unique within the organization. The syntax for the control_group method is as follows: control_group 'name' do control 'name' do it 'should do something' do expect(something).to/.to_not be_something end end control 'name' do ... end ... end  where: • control_group groups one (or more) control blocks • 'name' is the unique name for the control_group; the chef-client will raise an exception if duplicate control_group names are present • control defines each individual audit within the control_group block. There is no limit to the number of control blocks that may defined within a control_group block #### Examples¶ control_group block with multiple control blocks The following control_group ensures that MySQL is installed, that PostgreSQL is not installed, and that the services and configuration files associated with MySQL are configured correctly: control_group 'Audit Mode' do control 'mysql package' do it 'should be installed' do expect(package('mysql')).to be_installed.with_version('5.6') end end control 'postgres package' do it 'should not be installed' do expect(package('postgresql')).to_not be_installed end end control 'mysql service' do let(:mysql_service) { service('mysql') } it 'should be enabled' do expect(mysql_service).to be_enabled end it 'should be running' do expect(mysql_service).to be_running end end control 'mysql config directory' do let(:config_dir) { file('/etc/mysql') } it 'should exist with correct permissions' do expect(config_dir).to be_directory expect(config_dir).to be_mode(0700) end it 'should be owned by the db user' do expect(config_dir).to be_owned_by('db_service_user') end end control 'mysql config file' do let(:config_file) { file('/etc/mysql/my.cnf') } it 'should exist with correct permissions' do expect(config_file).to be_file expect(config_file).to be_mode(0400) end it 'should contain required configuration' do expect(config_file.content).to match(/default-time-zone='UTC'/) end end end  The control_group block is processed when the chef-client is run in audit-mode. If the chef-client run was successful, the chef-client will return output similar to: Audit Mode mysql package should be installed postgres package should not be installed mysql service should be enabled should be running mysql config directory should exist with correct permissions should be owned by the db user mysql config file should exist with correct permissions should contain required configuration  If an audit was unsuccessful, the chef-client will return output similar to: Starting audit phase Audit Mode mysql package should be installed (FAILED - 1) postgres package should not be installed mysql service should be enabled (FAILED - 2) should be running (FAILED - 3) mysql config directory should exist with correct permissions (FAILED - 4) should be owned by the db user (FAILED - 5) mysql config file should exist with correct permissions (FAILED - 6) should contain required configuration (FAILED - 7) Failures: 1) Audit Mode mysql package should be installed Failure/Error: expect(package('mysql')).to be_installed.with_version('5.6') expected Package 'mysql' to be installed # /var/chef/cache/cookbooks/grantmc/recipes/default.rb:22:in 'block (3 levels) in from_file' 2) Audit Mode mysql service should be enabled Failure/Error: expect(mysql_service).to be_enabled expected Service 'mysql' to be enabled # /var/chef/cache/cookbooks/grantmc/recipes/default.rb:35:in 'block (3 levels) in from_file' 3) Audit Mode mysql service should be running Failure/Error: expect(mysql_service).to be_running expected Service 'mysql' to be running # /var/chef/cache/cookbooks/grantmc/recipes/default.rb:38:in 'block (3 levels) in from_file' 4) Audit Mode mysql config directory should exist with correct permissions Failure/Error: expect(config_dir).to be_directory expected File '/etc/mysql'.directory? to return true, got false # /var/chef/cache/cookbooks/grantmc/recipes/default.rb:45:in 'block (3 levels) in from_file' 5) Audit Mode mysql config directory should be owned by the db user Failure/Error: expect(config_dir).to be_owned_by('db_service_user') expected File '/etc/mysql'.owned_by?('db_service_user') to return true, got false # /var/chef/cache/cookbooks/grantmc/recipes/default.rb:49:in 'block (3 levels) in from_file' 6) Audit Mode mysql config file should exist with correct permissions Failure/Error: expect(config_file).to be_file expected File '/etc/mysql/my.cnf'.file? to return true, got false # /var/chef/cache/cookbooks/grantmc/recipes/default.rb:56:in 'block (3 levels) in from_file' 7) Audit Mode mysql config file should contain required configuration Failure/Error: expect(config_file.content).to match(/default-time-zone='UTC'/) expected '-n\n' to match /default-time-zone='UTC'/ Diff: @@ -1,2 +1,2 @@ -/default-time-zone='UTC'/ +-n # /var/chef/cache/cookbooks/grantmc/recipes/default.rb:60:in 'block (3 levels) in from_file' Finished in 0.5745 seconds (files took 0.46481 seconds to load) 8 examples, 7 failures Failed examples: rspec /var/chef/cache/cookbooks/grantmc/recipes/default.rb:21 # Audit Mode mysql package should be installed rspec /var/chef/cache/cookbooks/grantmc/recipes/default.rb:34 # Audit Mode mysql service should be enabled rspec /var/chef/cache/cookbooks/grantmc/recipes/default.rb:37 # Audit Mode mysql service should be running rspec /var/chef/cache/cookbooks/grantmc/recipes/default.rb:44 # Audit Mode mysql config directory should exist with correct permissions rspec /var/chef/cache/cookbooks/grantmc/recipes/default.rb:48 # Audit Mode mysql config directory should be owned by the db user rspec /var/chef/cache/cookbooks/grantmc/recipes/default.rb:55 # Audit Mode mysql config file should exist with correct permissions rspec /var/chef/cache/cookbooks/grantmc/recipes/default.rb:59 # Audit Mode mysql config file should contain required configuration Auditing complete  Duplicate control_group names If two control_group blocks have the same name, the chef-client will raise an exception. For example, the following control_group blocks exist in different cookbooks: control_group 'basic control group' do it 'should pass' do expect(2 - 2).to eq(0) end end  control_group 'basic control group' do it 'should pass' do expect(3 - 2).to eq(1) end end  Because the two control_group block names are identical, the chef-client will return an exception similar to: Synchronizing Cookbooks: - audit_test Compiling Cookbooks... ================================================================================ Recipe Compile Error in /Users/grantmc/.cache/chef/cache/cookbooks /audit_test/recipes/error_duplicate_control_groups.rb ================================================================================ Chef::Exceptions::AuditControlGroupDuplicate -------------------------------------------- Audit control group with name 'basic control group' has already been defined Cookbook Trace: --------------- /Users/grantmc/.cache/chef/cache/cookbooks /audit_test/recipes/error_duplicate_control_groups.rb:13:in 'from_file' Relevant File Content: ---------------------- /Users/grantmc/.cache/chef/cache/cookbooks/audit_test/recipes/error_duplicate_control_groups.rb: control_group 'basic control group' do it 'should pass' do expect(2 - 2).to eq(0) end end control_group 'basic control group' do it 'should pass' do expect(3 - 2).to eq(1) end end Running handlers: [2015-01-15T09:36:14-08:00] ERROR: Running exception handlers Running handlers complete  Verify a package is installed The following control_group verifies that the git package has been installed: package 'git' do action :install end execute 'list packages' do command 'dpkg -l' end execute 'list directory' do command 'ls -R ~' end control_group 'my audits' do control 'check git' do it 'should be installed' do expect(package('git')).to be_installed end end end  ### Validatorless Bootstrap¶ The ORGANIZATION-validator.pem is typically added to the .chef directory on the workstation. When a node is bootstrapped from that workstation, the ORGANIZATION-validator.pem is used to authenticate the newly-created node to the Chef server during the initial chef-client run. Starting with Chef client 12.1, it is possible to bootstrap a node using the USER.pem file instead of the ORGANIZATION-validator.pem file. This is known as a “validatorless bootstrap”. To create a node via the USER.pem file, simply delete the ORGANIZATION-validator.pem file on the workstation. For example: $ rm -f /home/lamont/.chef/myorg-validator.pem


and then make the following changes in the knife.rb file:

• Remove the validation_client_name setting
• Edit the validation_key setting to be something that isn’t a path to an existent ORGANIZATION-validator.pem file. For example: /nonexist.

As long as a USER.pem is also present on the workstation from which the validatorless bootstrap operation will be initiated, the bootstrap operation will run and will use the USER.pem file instead of the ORGANIZATION-validator.pem file.

When running a validatorless knife bootstrap operation, the output is similar to:

desktop% knife bootstrap 10.1.1.1 -N foo01.acme.org \
-E dev -r 'role[base]' -j '{ "foo": "bar" }' \
--ssh-user vagrant --sudo
Node foo01.acme.org exists, overwrite it? (Y/N)
Client foo01.acme.org exists, overwrite it? (Y/N)
Creating new client for foo01.acme.org
Creating new node for foo01.acme.org
Connecting to 10.1.1.1
10.1.1.1 Starting first Chef Client run...
[....etc...]


#### knife bootstrap Options¶

Use the following options to specify items that are stored in chef-vault:

--bootstrap-vault-file VAULT_FILE
The path to a JSON file that contains a list of vaults and items to be updated.
--bootstrap-vault-item VAULT_ITEM
A single vault and item to update as vault:item.
--bootstrap-vault-json VAULT_JSON

A JSON string that contains a list of vaults and items to be updated.

For example:

--bootstrap-vault-json '{ "vault1": ["item1", "item2"], "vault2": "item2" }'


### New Resource Attributes¶

The following attributes are new for chef-client 12.1.

#### verify¶

The verify attribute may be used with the cookbook_file, file, remote_file, and template resources.

verify

A block or a string that returns true or false. A string, when true is executed as a system command.

The following examples show how the verify attribute is used with the template resource. The same approach (but with different resource names) is true for the cookbook_file, file, and remote_file resources:

A block is arbitrary Ruby defined within the resource block by using the verify property. When a block is true, the chef-client will continue to update the file as appropriate.

For example, this should return true:

template '/tmp/baz' do
verify { 1 == 1 }
end


This should return true:

template '/etc/nginx.conf' do
verify 'nginx -t -c %{path}'
end


Warning

For releases of the chef-client prior to 12.5 (chef-client 12.4 and earlier) the correct syntax is:

template '/etc/nginx.conf' do
verify 'nginx -t -c %{file}'
end


This should return true:

template '/tmp/bar' do
verify { 1 == 1}
end


And this should return true:

template '/tmp/foo' do
verify do |path|
true
end
end


Whereas, this should return false:

template '/tmp/turtle' do
verify '/usr/bin/false'
end


If a string or a block return false, the chef-client run will stop and an error is returned.

#### imports¶

The following attribute is new for the dsc_script resource:

imports

Use to import DSC resources from a module. To import all resources from a module, specify only the module name:

imports "module_name"


To import specific resources, specify the module name and then the name for each resource in that module to import:

imports "module_name", "resource_name_a", "resource_name_b", ...


For example, to import all resources from a module named cRDPEnabled:

imports "cRDPEnabled"


And to import only the PSHOrg_cRDPEnabled resource:

imports "cRDPEnabled", "PSHOrg_cRDPEnabled"


#### compile_time¶

The following attribute is new for the chef_gem resource:

compile_time

Controls the phase during which a gem is installed on a node. Set to true to install a gem while the resource collection is being built (the “compile phase”). Set to false to install a gem while the chef-client is configuring the node (the “converge phase”). Possible values: nil (for verbose warnings), true (to warn once per chef-client run), or false (to remove all warnings). Recommended value: false.

To suppress warnings for cookbooks authored prior to chef-client 12.1, use a respond_to? check to ensure backward compatibility. For example:

chef_gem 'aws-sdk' do
compile_time false if respond_to?(:compile_time)
end


#### run_as¶

The following attributes are new for the windows_service resource:

The password for the user specified by run_as_user.
run_as_user
The user under which a Microsoft Windows service runs.

### paludis_package¶

Use the paludis_package resource to manage packages for the Paludis platform.

Note

In many cases, it is better to use the package resource instead of this one. This is because when the package resource is used in a recipe, the chef-client will use details that are collected by Ohai at the start of the chef-client run to determine the correct package application. Using the package resource allows a recipe to be authored in a way that allows it to be used across many platforms.

#### Syntax¶

A paludis_package resource block manages a package on a node, typically by installing it. The simplest use of the paludis_package resource is:

paludis_package 'package_name'


which will install the named package using all of the default options and the default action (:install).

The full syntax for all of the properties that are available to the paludis_package resource is:

paludis_package 'name' do
notifies                   # see description
options                    String
package_name               String, Array # defaults to 'name' if not specified
provider                   Chef::Provider::Package::Paludis
source                     String
subscribes                 # see description
timeout                    String, Integer
version                    String, Array
action                     Symbol # defaults to :install if not specified
end


where

• paludis_package tells the chef-client to manage a package
• 'name' is the name of the package
• action identifies which steps the chef-client will take to bring the node into the desired state
• options, package_name, provider, source, recursive, timeout, and version are properties of this resource, with the Ruby type shown. See “Properties” section below for more information about all of the properties that may be used with this resource.

#### Actions¶

This resource has the following actions:

:install
Default. Install a package. If a version is specified, install the specified version of the package.
:nothing
Define this resource block to do nothing until notified by another resource to take action. When this resource is notified, this resource block is either run immediately or it is queued up to be run at the end of the chef-client run.
:remove
Remove a package.
Install a package and/or ensure that a package is the latest version.

#### Attributes¶

This resource has the following properties:

ignore_failure

Ruby Types: TrueClass, FalseClass

Continue running a recipe if a resource fails for any reason. Default value: false.

notifies

Ruby Type: Symbol, ‘Chef::Resource[String]’

A resource may notify another resource to take action when its state changes. Specify a 'resource[name]', the :action that resource should take, and then the :timer for that action. A resource may notifiy more than one resource; use a notifies statement for each resource to be notified.

A timer specifies the point during the chef-client run at which a notification is run. The following timers are available:

:delayed
Default. Specifies that a notification should be queued up, and then executed at the very end of the chef-client run.
:immediate, :immediately
Specifies that a notification should be run immediately, per resource notified.

The syntax for notifies is:

notifies :action, 'resource[name]', :timer

options

Ruby Type: String

One (or more) additional options that are passed to the command.

package_name

Ruby Types: String, Array

The name of the package. Default value: the name of the resource block See “Syntax” section above for more information.

provider

Ruby Type: Chef Class

Optional. Explicitly specifies a provider. See “Providers” section below for more information.

retries

Ruby Type: Integer

The number of times to catch exceptions and retry the resource. Default value: 0.

retry_delay

Ruby Type: Integer

The retry delay (in seconds). Default value: 2.

source

Ruby Type: String

Optional. The path to a package in the local file system.

subscribes

Ruby Type: Symbol, ‘Chef::Resource[String]’

A resource may listen to another resource, and then take action if the state of the resource being listened to changes. Specify a 'resource[name]', the :action to be taken, and then the :timer for that action.

A timer specifies the point during the chef-client run at which a notification is run. The following timers are available:

:delayed
Default. Specifies that a notification should be queued up, and then executed at the very end of the chef-client run.
:immediate, :immediately
Specifies that a notification should be run immediately, per resource notified.

The syntax for subscribes is:

subscribes :action, 'resource[name]', :timer

timeout

Ruby Types: String, Integer

The amount of time (in seconds) to wait before timing out.

version

Ruby Types: String, Array

The version of a package to be installed or upgraded.

#### Examples¶

Install a package

paludis_package 'name of package' do
action :install
end


### openbsd_package¶

Use the openbsd_package resource to manage packages for the OpenBSD platform.

Note

In many cases, it is better to use the package resource instead of this one. This is because when the package resource is used in a recipe, the chef-client will use details that are collected by Ohai at the start of the chef-client run to determine the correct package application. Using the package resource allows a recipe to be authored in a way that allows it to be used across many platforms.

#### Syntax¶

A openbsd_package resource block manages a package on a node, typically by installing it. The simplest use of the openbsd_package resource is:

openbsd_package 'package_name'


which will install the named package using all of the default options and the default action (:install).

The full syntax for all of the properties that are available to the openbsd_package resource is:

openbsd_package 'name' do
notifies                   # see description
options                    String
package_name               String, Array # defaults to 'name' if not specified
provider                   Chef::Provider::Package::Openbsd
source                     String
subscribes                 # see description
timeout                    String, Integer
version                    String, Array
action                     Symbol # defaults to :install if not specified
end


where

• openbsd_package tells the chef-client to manage a package
• 'name' is the name of the package
• action identifies which steps the chef-client will take to bring the node into the desired state
• options, package_name, provider, source, timeout, and version are properties of this resource, with the Ruby type shown. See “Properties” section below for more information about all of the properties that may be used with this resource.

#### Actions¶

This resource has the following actions:

:install
Default. Install a package. If a version is specified, install the specified version of the package.
:nothing
Define this resource block to do nothing until notified by another resource to take action. When this resource is notified, this resource block is either run immediately or it is queued up to be run at the end of the chef-client run.
:remove
Remove a package.

#### Attributes¶

This resource has the following properties:

ignore_failure

Ruby Types: TrueClass, FalseClass

Continue running a recipe if a resource fails for any reason. Default value: false.

notifies

Ruby Type: Symbol, ‘Chef::Resource[String]’

A resource may notify another resource to take action when its state changes. Specify a 'resource[name]', the :action that resource should take, and then the :timer for that action. A resource may notifiy more than one resource; use a notifies statement for each resource to be notified.

A timer specifies the point during the chef-client run at which a notification is run. The following timers are available:

:delayed
Default. Specifies that a notification should be queued up, and then executed at the very end of the chef-client run.
:immediate, :immediately
Specifies that a notification should be run immediately, per resource notified.

The syntax for notifies is:

notifies :action, 'resource[name]', :timer

options

Ruby Type: String

One (or more) additional options that are passed to the command.

package_name

Ruby Types: String, Array

The name of the package. Default value: the name of the resource block See “Syntax” section above for more information.

provider

Ruby Type: Chef Class

Optional. Explicitly specifies a provider. See “Providers” section below for more information.

retries

Ruby Type: Integer

The number of times to catch exceptions and retry the resource. Default value: 0.

retry_delay

Ruby Type: Integer

The retry delay (in seconds). Default value: 2.

source

Ruby Type: String

Optional. The path to a package in the local file system.

subscribes

Ruby Type: Symbol, ‘Chef::Resource[String]’

A resource may listen to another resource, and then take action if the state of the resource being listened to changes. Specify a 'resource[name]', the :action to be taken, and then the :timer for that action.

A timer specifies the point during the chef-client run at which a notification is run. The following timers are available:

:delayed
Default. Specifies that a notification should be queued up, and then executed at the very end of the chef-client run.
:immediate, :immediately
Specifies that a notification should be run immediately, per resource notified.

The syntax for subscribes is:

subscribes :action, 'resource[name]', :timer

timeout

Ruby Types: String, Integer

The amount of time (in seconds) to wait before timing out.

version

Ruby Types: String, Array

The version of a package to be installed or upgraded.

#### Examples¶

Install a package

openbsd_package 'name of package' do
action :install
end


### New client.rb Settings¶

The following client.rb settings are new:

chef_gem_compile_time

Controls the phase during which a gem is installed on a node. Set to true to install a gem while the resource collection is being built (the “compile phase”). Set to false to install a gem while the chef-client is configuring the node (the “converge phase”). Recommended value: false.

Note

To suppress warnings for cookbooks authored prior to chef-client 12.1, use a respond_to? check to ensure backward compatibility. For example:

chef_gem 'aws-sdk' do
compile_time false if respond_to?(:compile_time)
end

windows_service.watchdog_timeout
The maximum amount of time (in seconds) available to the chef-client run when the chef-client is run as a service on the Microsoft Windows platform. If the chef-client run does not complete within the specified timeframe, the chef-client run is terminated. Default value: 2 * (60 * 60).

### Multiple Packages and Versions¶

A resource may specify multiple packages and/or versions for platforms that use Yum, Apt, Zypper, or Chocolatey package managers. Specifing multiple packages and/or versions allows a single transaction to:

• Download the specified packages and versions via a single HTTP transaction
• Update or install multiple packages with a single resource during the chef-client run

For example, installing multiple packages:

package ['package1', 'package2']


package ['package1', 'package2']  do
end


Removing multiple packages:

package ['package1', 'package2']  do
action :remove
end


Purging multiple packages:

package ['package1', 'package2']  do
action :purge
end


package ['package1', 'package2']  do
action :nothing
end

notifies :install, 'package[package1, package2]', :immediately
end


Note

Notifications and subscriptions do not need to be updated when packages and versions are added or removed from the package_name or version properties.

## What’s New in 12.0¶

The following items are new for chef-client 12.0 and/or are changes from previous versions. The short version:

• Changing attributes Attributes may be modified for named precedence levels, all precedence levels, and be fully assigned. These changes were based on RFC-23.
• Ruby 2.0 (or higher) for Windows; and Ruby 2.1 (or higher) for Unix/Linux Ruby versions 1.8.7, 1.9.1, 1.9.2, and 1.9.3 are no longer supported. See this blog post for more info.
• The number of changes between Ruby 1.9 and 2.0 is small Please review the Ruby 2.0 release notes or Ruby 2.1 release notes for the full list of changes.
• provides method for building custom resources Use the provides method to associate a custom resource with a built-in chef-client resource and to specify platforms on which the custom resource may be used.
• The chef-client supports the AIX platform The chef-client may now be used to configure nodes that are running on the AIX platform, versions 6.1 (TL6 or higher, recommended) and 7.1 (TL0 SP3 or higher, recommended). The service resource supports starting, stopping, and restarting services that are managed by System Resource Controller (SRC), as well as managing all service states with BSD-based init systems.
• New bff_package resource Use the bff_package resource to install packages on the AIX platform.
• New homebrew_package resource Use the homebrew_package resource to install packages on the Mac OS X platform. The homebrew_package resource also replaces the macports_package resource as the default package installer on the Mac OS X platform.
• New reboot resource Use the reboot resource to reboot a node during or at the end of a chef-client run.
• New windows_service resource Use the windows_service resource to manage services on the Microsoft Windows platform.
• New –bootstrap-template option Use the --bootstrap-template option to install the chef-client with a bootstrap template. Specify the name of a template, such as chef-full, or specify the path to a custom bootstrap template. This option deprecates the --distro and --template-file options.
• New SSL options for bootstrap operations The knife bootstrap subcommand has new options that support SSL with bootstrap operations. Use the --[no-]node-verify-api-cert option to to perform SSL validation of the connection to the Chef server. Use the --node-ssl-verify-mode option to validate SSL certificates.
• New format options for knife status Use the --medium and --long options to include attributes in the output and to format that output as JSON.
• New fsck_device property for mount resource The mount resource supports fsck devices for the Solaris platform with the fsck_device property.
• New settings for metadata.rb The metadata.rb file has two new settings: issues_url and source_url. These settings are used to capture the source location and issues tracking location for a cookbook. These settings are also used with Chef Supermarket. In addition, the name setting is now required.
• The http_request GET and HEAD requests drop the hard-coded query string The :get and :head actions appended a hard-coded query string—?message=resource_name—that cannot be overridden. This hard-coded string is deprecated in the chef-client 12.0 release. Cookbooks that rely on this string need to be updated to manually add it to the URL as it is passed to the resource.
• New Recipe DSL methods The Recipe DSL has three new methods: shell_out, shell_out!, and shell_out_with_systems_locale.
• File specificity updates File specificity for the template and cookbook_file resources now supports using the source attribute to define an explicit lookup path as an array.
• Improved user password security for the user resource, Mac OS X platform The user resource now supports salted password hashes for Mac OS X 10.7 (and higher). Use the iterations and salt attributes to calculate SALTED-SHA512 password shadow hashes for Mac OS X version 10.7 and SALTED-SHA512-PBKDF2 password shadow hashes for version 10.8 (and higher).
• data_bag_item method in the Recipe DSL supports encrypted data bag items Use data_bag_item(bag_name, item, secret) to specify the secret to use for an encrypted data bag item. If secret is not specified, the chef-client looks for a secret at the path specified by the encrypted_data_bag_secret setting in the client.rb file.
• value_for_platform method in the Recipe DSL supports version constraints Version constraints—>, <, >=, <=, ~>—may be used when specifying a version. An exception is raised if two version constraints match. An exact match will always take precedence over a match made from a version constraint.
• knife cookbook site share supports –dry-run Use the --dry-run option with the knife cookbook site to take no action and only print out results.
• chef-client configuration setting updates The chef-client now supports running an override run-list (via the --override-runlist option) without clearing the cookbook cache on the node. In addition, the --chef-zero-port option allows specifying a range of ports.
• Unforked interval runs are no longer allowed The --[no-]fork option may no longer be used in the same command with the --daemonize and --interval options.
• Splay and interval values are applied before the chef-client run The --interval and --splay values are applied before the chef-client run when using the chef-client and chef-solo executables.
• All files and templates in a cookbook are synchronized at the start of the chef-client run The no_lazy_load configuration setting in the client.rb file now defaults to true. This avoids issues where time-sensitive URLs in a cookbook manifest timeout before the cookbook_file or template resources converged.
• File staging now defaults to the destination directory by default Staging into a system’s temporary directory—typically /tmp or /var/tmp—as opposed to the destination directory may cause issues with permissions, available space, or cross-device renames. Files are now staged to the destination directory by default.
• Partial search updates Use :filter_result to build search results into a Hash. This replaces the previous functionality that was provided by the partial_search cookbook, albeit with a different API. Use the --filter-result option to return only attributes that match the specified filter. For example: \"ServerName=name, Kernel=kernel.version\".
• Client-side key generation is enabled by default When a new chef-client is created using the validation client account, the Chef server allows the chef-client to generate a key-pair locally, and then send the public key to the Chef server. This behavior is controlled by the local_key_generation attribute in the client.rb file and now defaults to true.
• New guard_interpreter property defaults The guard_interpreter property now defaults to :batch for the batch resource and :powershell_script for the powershell_script resource.
• Events are sent to the Application event log on the Windows platform by default Events are sent to the Microsoft Windows “Application” event log at the start and end of a chef-client run, and also if a chef-client run fails. Set the disable_event_logger configuration setting in the client.rb file to true to disable event logging.
• The installer_type property for the windows_package resource uses a symbol instead of a string Previous versions of the chef-client (starting with version 11.8) used a string.
• The path property is deprecated for the execute resource Use the environment property instead.
• SSL certificate validation improvements The default settings for SSL certificate validation now default in favor of validation. In addition, using the knife ssl fetch subcommand is now an important part of setting up your workstation.
• New property for git resource The git resource has a new property: environment, which takes a Hash of environment variables in the form of {"ENV_VARIABLE" => "VALUE"}.

Please view the notes for more background on the upgrade process from chef-client 11 to chef-client 12.

### Change Attributes¶

Starting with chef-client 12.0, attribute precedence levels may be

• Removed for a specific, named attribute precedence level
• Removed for all attribute precedence levels
• Fully assigned attributes

#### Remove Precedence Level¶

A specific attribute precedence level for default, normal, and override attributes may be removed by using one of the following syntax patterns.

For default attributes:

• node.rm_default('foo', 'bar')

For normal attributes:

• node.rm_normal('foo', 'bar')

For override attributes:

• node.rm_override('foo', 'bar')

These patterns return the computed value of the key being deleted for the specified precedence level.

##### Examples¶

The following examples show how to remove a specific, named attribute precedence level.

Delete a default value when only default values exist

Given the following code structure under 'foo':

node.default['foo'] = {
'bar' => {
'baz' => 52,
'thing' => 'stuff',
},
'bat' => {
'things' => [5, 6],
},
}


And some role attributes:

# Please don't ever do this in real code :)
node.role_default['foo']['bar']['thing'] = 'otherstuff'


And a force attribute:

node.force_default['foo']['bar']['thing'] = 'allthestuff'


When the default attribute precedence node['foo']['bar'] is removed:

node.rm_default('foo', 'bar') #=> {'baz' => 52, 'thing' => 'allthestuff'}


What is left under 'foo' is only 'bat':

node.attributes.combined_default['foo'] #=> {'bat' => { 'things' => [5,6] } }


Delete default without touching higher precedence attributes

Given the following code structure:

node.default['foo'] = {
'bar' => {
'baz' => 52,
'thing' => 'stuff',
},
'bat' => {
'things' => [5, 6],
},
}


And some role attributes:

# Please don't ever do this in real code :)
node.role_default['foo']['bar']['thing'] = 'otherstuff'


And a force attribute:

node.force_default['foo']['bar']['thing'] = 'allthestuff'


And also some override attributes:

node.override['foo']['bar']['baz'] = 99


Same delete as before:

node.rm_default('foo', 'bar') #=> { 'baz' => 52, 'thing' => 'allthestuff' }


The other attribute precedence levels are unaffected:

node.attributes.combined_override['foo'] #=> { 'bar' => {'baz' => 99} }
node['foo'] #=> { 'bar' => {'baz' => 99}, 'bat' => { 'things' => [5,6] }


Delete override without touching lower precedence attributes

Given the following code structure, which has an override attribute:

node.override['foo'] = {
'bar' => {
'baz' => 52,
'thing' => 'stuff',
},
'bat' => {
'things' => [5, 6],
},
}


with a single default value:

node.default['foo']['bar']['baz'] = 11


and a force at each attribute precedence:

node.force_default['foo']['bar']['baz'] = 55
node.force_override['foo']['bar']['baz'] = 99


Delete the override:

node.rm_override('foo', 'bar') #=> { 'baz' => 99, 'thing' => 'stuff' }


The other attribute precedence levels are unaffected:

node.attributes.combined_default['foo'] #=> { 'bar' => {'baz' => 55} }


Non-existent key deletes return nil

node.rm_default("no", "such", "thing") #=> nil


#### Remove All Levels¶

All attribute precedence levels may be removed by using the following syntax pattern:

• node.rm('foo', 'bar')

Note

Using node['foo'].delete('bar') will throw an exception that points to the new API.

##### Examples¶

The following examples show how to remove all attribute precedence levels.

Delete all attribute precedence levels

Given the following code structure:

node.default['foo'] = {
'bar' => {
'baz' => 52,
'thing' => 'stuff',
},
'bat' => {
'things' => [5, 6],
},
}


With override attributes:

node.override['foo']['bar']['baz'] = 999


Removing the 'bar' key returns the computed value:

node.rm('foo', 'bar') #=> {'baz' => 999, 'thing' => 'stuff'}


Looking at 'foo', all that’s left is the 'bat' entry:

node['foo'] #=> {'bat' => { 'things' => [5,6] } }


Non-existent key deletes return nil

node.rm_default("no", "such", "thing") #=> nil


#### Full Assignment¶

Use ! to clear out the key for the named attribute precedence level, and then complete the write by using one of the following syntax patterns:

• node.default!['foo']['bar'] = {...}
• node.force_default!['foo']['bar'] = {...}
• node.normal!['foo']['bar'] = {...}
• node.override!['foo']['bar'] = {...}
• node.force_override!['foo']['bar'] = {...}
##### Examples¶

The following examples show how to remove all attribute precedence levels.

Just one component

Given the following code structure:

node.default['foo']['bar'] = {'a' => 'b'}
node.default!['foo']['bar'] = {'c' => 'd'}


The '!' caused the entire ‘bar’ key to be overwritten: .. code-block:: ruby

node[‘foo’] #=> {‘bar’ => {‘c’ => ‘d’}

Multiple components; one “after”

Given the following code structure:

node.default['foo']['bar'] = {'a' => 'b'}
# Please don't ever do this in real code :)
node.role_default['foo']['bar'] = {'c' => 'd'}
node.default!['foo']['bar'] = {'d' => 'e'}


The '!' write overwrote the “cookbook-default” value of 'bar', but since role data is later in the resolution list, it was unaffected:

node['foo'] #=> {'bar' => {'c' => 'd', 'd' => 'e'}


Multiple components; all “before”

Given the following code structure:

node.default['foo']['bar'] = {'a' => 'b'}
# Please don't ever do this in real code :)
node.role_default['foo']['bar'] = {'c' => 'd'}
node.force_default!['foo']['bar'] = {'d' => 'e'}


With force_default! there is no other data under 'bar':

node['foo'] #=> {'bar' => {'d' => 'e'}


Multiple precedence levels

Given the following code structure:

node.default['foo'] = {
'bar' => {
'baz' => 52,
'thing' => 'stuff',
},
'bat' => {
'things' => [5, 6],
},
}


And some attributes:

# Please don't ever do this in real code :)
node.role_default['foo']['bar']['baz'] = 55
node.force_default['foo']['bar']['baz'] = 66


And other precedence levels:

node.normal['foo']['bar']['baz'] = 88
node.override['foo']['bar']['baz'] = 99


With a full assignment:

node.default!['foo']['bar'] = {}


Role default and force default are left in default, plus other precedence levels:

node.attributes.combined_default['foo'] #=> {'bar' => {'baz' => 66}, 'bat'=>{'things'=>[5, 6]}}
node.attributes.normal['foo'] #=> {'bar' => {'baz' => 88}}
node.attributes.combined_override['foo'] #=> {'bar' => {'baz' => 99}}
node['foo']['bar'] #=> {'baz' => 99}


If force_default! is written:

node.force_default!['foo']['bar'] = {}


the difference is:

node.attributes.combined_default['foo'] #=> {'bat'=>{'things'=>[5, 6]}, 'bar' => {}}
node.attributes.normal['foo'] #=> {'bar' => {'baz' => 88}}
node.attributes.combined_override['foo'] #=> {'bar' => {'baz' => 99}}
node['foo']['bar'] #=> {'baz' => 99}


### provides Method¶

Use the provides method to map a custom resource/provider to an existing resource/provider, and then to also specify the platform(s) on which the behavior of the custom resource/provider will be applied. This method enables scenarios like:

• Building a custom resource that is based on an existing resource
• Defining platform mapping specific to a custom resource
• Handling situations where a resource on a particular platform may have more than one provider, such as the behavior on the Ubuntu platform where both SysVInit and systemd are present
• Allowing the custom resource to declare what platforms are supported, enabling the creator of the custom resource to use arbitrary criteria if desired
• Not using the previous naming convention—#{cookbook_name}_#{provider_filename}

Warning

The provides method must be defined in both the custom resource and custom provider files and both files must have identical provides statement(s).

The syntax for the provides method is as follows:

provides :resource_name, os: [ 'platform', 'platform', ...], platform_family: 'family'


where:

• :resource_name is a chef-client resource: :cookbook_file, :package, :rpm_package, and so on
• 'platform' is a comma-separated list of platforms: 'windows', 'solaris2', 'linux', and so on
• platform_family is optional and may specify the same parameters as the platform_family? method in the Recipe DSL; platform is optional and also supported (and is the same as the platform? method in the Recipe DSL)

A custom resource/provider may be mapped to more than one existing resource/provider. Multiple platform associations may be made. For example, to completely map a custom resource/provider to an existing custom resource/provider, only specificy the resource name:

provides :cookbook_file


The same mapping, but only for the Linux platform:

provides :cookbook_file, os: 'linux'


A similar mapping, but also for packages on the Microsoft Windows platform:

provides :cookbook_file
provides :package, os: 'windows'


Use multiple provides statements to define multiple conditions: Use an array to match any of the platforms within the array:

provides :cookbook_file
provides :package, os: 'windows'
provides :rpm_package, os: [ 'linux', 'aix' ]


Use an array to match any of the platforms within the array:

provides :package, os: 'solaris2', platform_family: 'solaris2' do |node|
node[:platform_version].to_f <= 5.10
end


### AIX Platform Support¶

The chef-client may now be used to configure nodes that are running on the AIX platform, versions 6.1 (TL6 or higher, recommended) and 7.1 (TL0 SP3 or higher, recommended). The service resource supports starting, stopping, and restarting services that are managed by System Resource Controller (SRC), as well as managing all service states with BSD-based init systems.

System Requirements

The chef-client has the same system requirements on the AIX platform as any other platform, with the following notes:

• Expand the file system on the AIX platform using chfs or by passing the -X flag to installp to automatically expand the logical partition (LPAR)
• The EN_US (UTF-8) character set should be installed on the logical partition prior to installing the chef-client

Install the chef-client on the AIX platform

The chef-client is distributed as a Backup File Format (BFF) binary and is installed on the AIX platform using the following command run as a root user:

# installp -aYgd chef-12.0.0-1.powerpc.bff all


Increase system process limits

The out-of-the-box system process limits for maximum process memory size (RSS) and number of open files are typically too low to run the chef-client on a logical partition (LPAR). When the system process limits are too low, the chef-client will not be able to create threads. To increase the system process limits:

1. Validate that the system process limits have not already been increased.

2. If they have not been increased, run the following commands as a root user:

$chsec -f /etc/security/limits -s default -a "rss=-1"  and then: $ chsec -f /etc/security/limits -s default -a "data=-1"


and then:

$chsec -f /etc/security/limits -s default -a "nofiles=50000"  Note The previous commands may be run against the root user, instead of default. For example: $ chsec -f /etc/security/limits -s root_user -a "rss=-1"

3. Reboot the logical partition (LPAR) to apply the updated system process limits.

When the system process limits are too low, an error is returned similar to:

Error Syncing Cookbooks:
==================================================================

Unexpected Error:
-----------------


Install the UTF-8 character set

The chef-client uses the EN_US (UTF-8) character set. By default, the AIX base operating system does not include the EN_US (UTF-8) character set and it must be installed prior to installing the chef-client. The EN_US (UTF-8) character set may be installed from the first disc in the AIX media or may be copied from /installp/ppc/*EN_US* to a location on the logical partition (LPAR). This topic assumes this location to be /tmp/rte.

Use smit to install the EN_US (UTF-8) character set. This ensures that any workload partitions (WPARs) also have UTF-8 applied.

Remember to point INPUT device/directory to /tmp/rte when not installing from CD.

1. From a root shell type:

# smit lang


A screen similar to the following is returned:

                       Manage Language Environment

Move cursor to desired item and press Enter.

Change/Show Primary Language Environment
Remove Language Environments
Change/Show Language Hierarchy
Set User Languages
Change/Show Applications for a Language
Convert System Messages and Flat Files

F1=Help             F2=Refresh          F3=Cancel           F8=Image
F9=Shell            F10=Exit            Enter=Do

2. Select Add Additional Language Environments and press Enter. A screen similar to the following is returned:

                   Add Additional Language Environments

Type or select values in entry fields.
Press Enter AFTER making all desired changes.

[Entry Fields]
CULTURAL convention to install                                             +
LANGUAGE translation to install                                            +
* INPUT device/directory for software                [/dev/cd0]              +
EXTEND file systems if space needed?                yes                    +

WPAR Management
Perform Operation in Global Environment         yes                    +
Perform Operation on Detached WPARs             no                     +
Detached WPAR Names                        [_all_wpars]            +
Remount Installation Device in WPARs            yes                    +
Alternate WPAR Installation Device             []

F1=Help             F2=Refresh          F3=Cancel           F4=List
F5=Reset            F6=Command          F7=Edit             F8=Image
F9=Shell            F10=Exit            Enter=Do

3. Cursor over the first two entries—CULTURAL convention to install and LANGUAGE translation to install—and use F4 to navigate through the list until UTF-8 English (United States) [EN_US] is selected. (EN_US is in capital letters!)

4. Press Enter to apply and install the language set.

New providers

The service resource has the following providers to support the AIX platform:

Long name Short name Notes
Chef::Provider::Service::Aix service The provider that is used with the AIX platforms. Use the service short name to start, stop, and restart services with System Resource Controller (SRC).
Chef::Provider::Service::AixInit service The provider that is used to manage BSD-based init services on AIX.

Enable a service on AIX using the mkitab command

The service resource does not support using the :enable and :disable actions with resources that are managed using System Resource Controller (SRC). This is because System Resource Controller (SRC) does not have a standard mechanism for enabling and disabling services on system boot.

One approach for enabling or disabling services that are managed by System Resource Controller (SRC) is to use the execute resource to invoke mkitab, and then use that command to enable or disable the service.

The following example shows how to install a service:

execute "install #{node['chef_client']['svc_name']} in SRC" do
command "mkssys -s #{node['chef_client']['svc_name']}
-p #{node['chef_client']['bin']}
-u root
-S
-n 15
-f 9
-o #{node['chef_client']['log_dir']}/client.log
-e #{node['chef_client']['log_dir']}/client.log -a '
-i #{node['chef_client']['interval']}
-s #{node['chef_client']['splay']}'"
not_if "lssrc -s #{node['chef_client']['svc_name']}"
action :run
end


and then enable it using the mkitab command:

execute "enable #{node['chef_client']['svc_name']}" do
command "mkitab '#{node['chef_client']['svc_name']}:2:once:/usr/bin/startsrc
-s #{node['chef_client']['svc_name']} > /dev/console 2>&1'"
not_if "lsitab #{node['chef_client']['svc_name']}"
end


### Recipe DSL, Encrypted Data Bags¶

The Recipe DSL provides access to data bags and data bag items (including encrypted data bag items) with the following methods:

• data_bag(bag), where bag is the name of the data bag.
• data_bag_item('bag_name', 'item', 'secret'), where bag is the name of the data bag and item is the name of the data bag item. If 'secret' is not specified, the chef-client will look for a secret at the path specified by the encrypted_data_bag_secret setting in the client.rb file.

The data_bag method returns an array with a key for each of the data bag items that are found in the data bag.

Some examples:

To load the secret from a file:

data_bag_item('bag', 'item', IO.read('secret_file'))


data_bag('admins')


The contents of a data bag item named justin:

data_bag_item('admins', 'justin')


will return something similar to:

# => {'comment'=>'Justin Currie', 'gid'=>1005, 'id'=>'justin', 'uid'=>1005, 'shell'=>'/bin/zsh'}


If item is encrypted, data_bag_item will automatically decrypt it using the key specified above, or (if none is specified) by the Chef::Config[:encrypted_data_bag_secret] method, which defaults to /etc/chef/encrypted_data_bag_secret.

### bff_package¶

Use the bff_package resource to manage packages for the AIX platform using the installp utility. When a package is installed from a local file, it must be added to the node using the remote_file or cookbook_file resources. New in Chef Client 12.0.

Note

A Backup File Format (BFF) package may not have a .bff file extension. The chef-client will still identify the correct provider to use based on the platform, regardless of the file extension.

#### Syntax¶

A bff_package resource block manages a package on a node, typically by installing it. The simplest use of the bff_package resource is:

bff_package 'package_name'


which will install the named package using all of the default options and the default action (:install).

The full syntax for all of the properties that are available to the bff_package resource is:

bff_package 'name' do
notifies                   # see description
options                    String
package_name               String, Array # defaults to 'name' if not specified
provider                   Chef::Provider::Package::Aix
source                     String
subscribes                 # see description
timeout                    String, Integer
version                    String, Array
action                     Symbol # defaults to :install if not specified
end


where

• bff_package tells the chef-client to manage a package
• 'name' is the name of the package
• action identifies which steps the chef-client will take to bring the node into the desired state
• options, package_name, provider, source, timeout, and version are properties of this resource, with the Ruby type shown. See “Properties” section below for more information about all of the properties that may be used with this resource.

#### Actions¶

This resource has the following actions:

:install
Default. Install a package. If a version is specified, install the specified version of the package.
:nothing
Define this resource block to do nothing until notified by another resource to take action. When this resource is notified, this resource block is either run immediately or it is queued up to be run at the end of the chef-client run.
:purge
Purge a package. This action typically removes the configuration files as well as the package.
:remove
Remove a package.

#### Properties¶

This resource has the following properties:

ignore_failure

Ruby Types: TrueClass, FalseClass

Continue running a recipe if a resource fails for any reason. Default value: false.

notifies

Ruby Type: Symbol, ‘Chef::Resource[String]’

A resource may notify another resource to take action when its state changes. Specify a 'resource[name]', the :action that resource should take, and then the :timer for that action. A resource may notifiy more than one resource; use a notifies statement for each resource to be notified.

A timer specifies the point during the chef-client run at which a notification is run. The following timers are available:

:delayed
Default. Specifies that a notification should be queued up, and then executed at the very end of the chef-client run.
:immediate, :immediately
Specifies that a notification should be run immediately, per resource notified.

The syntax for notifies is:

notifies :action, 'resource[name]', :timer

options

Ruby Type: String

One (or more) additional options that are passed to the command.

package_name

Ruby Types: String, Array

The name of the package. Default value: the name of the resource block See “Syntax” section above for more information.

provider

Ruby Type: Chef Class

Optional. Explicitly specifies a provider. See “Providers” section below for more information.

retries

Ruby Type: Integer

The number of times to catch exceptions and retry the resource. Default value: 0.

retry_delay

Ruby Type: Integer

The retry delay (in seconds). Default value: 2.

source

Ruby Type: String

Required. The path to a package in the local file system. The AIX platform requires source to be a local file system path because installp does not retrieve packages using HTTP or FTP.

subscribes

Ruby Type: Symbol, ‘Chef::Resource[String]’

A resource may listen to another resource, and then take action if the state of the resource being listened to changes. Specify a 'resource[name]', the :action to be taken, and then the :timer for that action.

A timer specifies the point during the chef-client run at which a notification is run. The following timers are available:

:delayed
Default. Specifies that a notification should be queued up, and then executed at the very end of the chef-client run.
:immediate, :immediately
Specifies that a notification should be run immediately, per resource notified.

The syntax for subscribes is:

subscribes :action, 'resource[name]', :timer

timeout

Ruby Types: String, Integer

The amount of time (in seconds) to wait before timing out.

version

Ruby Types: String, Array

The version of a package to be installed or upgraded.

#### Providers¶

This resource has the following providers:

Chef::Provider::Package, package
When this short name is used, the chef-client will attempt to determine the correct provider during the chef-client run.
Chef::Provider::Package::Aix, bff_package
The provider for the AIX platform. Can be used with the options attribute.

#### Example¶

Install a package

The bff_package resource is the default package provider on the AIX platform. The base package resource may be used, and then when the platform is AIX, the chef-client will identify the correct package provider. The following examples show how to install part of the IBM XL C/C++ compiler.

Using the base package resource:

package 'xlccmp.13.1.0' do
source '/var/tmp/IBM_XL_C_13.1.0/usr/sys/inst.images/xlccmp.13.1.0'
action :install
end


Using the bff_package resource:

bff_package 'xlccmp.13.1.0' do
source '/var/tmp/IBM_XL_C_13.1.0/usr/sys/inst.images/xlccmp.13.1.0'
action :install
end


### homebrew_package¶

Use the homebrew_package resource to manage packages for the Mac OS X platform.

#### Syntax¶

A homebrew_package resource block manages a package on a node, typically by installing it. The simplest use of the homebrew_package resource is:

homebrew_package 'package_name'


which will install the named package using all of the default options and the default action (:install).

The full syntax for all of the properties that are available to the homebrew_package resource is:

homebrew_package 'name' do
homebrew_user              String, Integer
notifies                   # see description
options                    String
package_name               String, Array # defaults to 'name' if not specified
provider                   Chef::Provider::Package::Homebrew
source                     String
subscribes                 # see description
timeout                    String, Integer
version                    String, Array
action                     Symbol # defaults to :install if not specified
end


where

• homebrew_package tells the chef-client to manage a package
• 'name' is the name of the package
• action identifies which steps the chef-client will take to bring the node into the desired state
• homebrew_user, options, package_name, provider, source, timeout, and version are properties of this resource, with the Ruby type shown. See “Properties” section below for more information about all of the properties that may be used with this resource.

#### Actions¶

This resource has the following actions:

:install
Default. Install a package. If a version is specified, install the specified version of the package.
:nothing
Define this resource block to do nothing until notified by another resource to take action. When this resource is notified, this resource block is either run immediately or it is queued up to be run at the end of the chef-client run.
:purge
Purge a package. This action typically removes the configuration files as well as the package.
:remove
Remove a package.
Install a package and/or ensure that a package is the latest version.

#### Properties¶

This resource has the following properties:

homebrew_user

Ruby Types: String, Integer

The name of the Homebrew owner to be used by the chef-client when executing a command.

The chef-client, by default, will attempt to execute a Homebrew command as the owner of /usr/local/bin/brew. If that executable does not exist, the chef-client will attempt to find the user by executing which brew. If that executable cannot be found, the chef-client will print an error message: Could not find the "brew" executable in /usr/local/bin or anywhere on the path.. Use the homebrew_user attribute to specify the Homebrew owner for situations where the chef-client cannot automatically detect the correct owner.

ignore_failure

Ruby Types: TrueClass, FalseClass

Continue running a recipe if a resource fails for any reason. Default value: false.

notifies

Ruby Type: Symbol, ‘Chef::Resource[String]’

A resource may notify another resource to take action when its state changes. Specify a 'resource[name]', the :action that resource should take, and then the :timer for that action. A resource may notifiy more than one resource; use a notifies statement for each resource to be notified.

A timer specifies the point during the chef-client run at which a notification is run. The following timers are available:

:delayed
Default. Specifies that a notification should be queued up, and then executed at the very end of the chef-client run.
:immediate, :immediately
Specifies that a notification should be run immediately, per resource notified.

The syntax for notifies is:

notifies :action, 'resource[name]', :timer

options

Ruby Type: String

One (or more) additional options that are passed to the command.

package_name

Ruby Types: String, Array

The name of the package. Default value: the name of the resource block See “Syntax” section above for more information.

provider

Ruby Type: Chef Class

Optional. Explicitly specifies a provider. See “Providers” section below for more information.

retries

Ruby Type: Integer

The number of times to catch exceptions and retry the resource. Default value: 0.

retry_delay

Ruby Type: Integer

The retry delay (in seconds). Default value: 2.

source

Ruby Type: String

Optional. The path to a package in the local file system.

subscribes

Ruby Type: Symbol, ‘Chef::Resource[String]’

A resource may listen to another resource, and then take action if the state of the resource being listened to changes. Specify a 'resource[name]', the :action to be taken, and then the :timer for that action.

A timer specifies the point during the chef-client run at which a notification is run. The following timers are available:

:delayed
Default. Specifies that a notification should be queued up, and then executed at the very end of the chef-client run.
:immediate, :immediately
Specifies that a notification should be run immediately, per resource notified.

The syntax for subscribes is:

subscribes :action, 'resource[name]', :timer

timeout

Ruby Types: String, Integer

The amount of time (in seconds) to wait before timing out.

version

Ruby Types: String, Array

The version of a package to be installed or upgraded.

#### Providers¶

This resource has the following providers:

Chef::Provider::Package, package
When this short name is used, the chef-client will attempt to determine the correct provider during the chef-client run.
Chef::Provider::Package::Homebrew, homebrew_package
The provider for the Mac OS X platform.

#### Example¶

Install a package

homebrew_package 'name of package' do
action :install
end


Specify the Homebrew user with a UUID

homebrew_package 'emacs' do
homebrew_user 1001
end


Specify the Homebrew user with a string

homebrew_package 'vim' do
homebrew_user 'user1'
end


### reboot¶

Use the reboot resource to reboot a node, a necessary step with some installations on certain platforms. This resource is supported for use on the Microsoft Windows, Mac OS X, and Linux platforms. New in Chef Client 12.0.

#### Syntax¶

A reboot resource block reboots a node:

reboot 'app_requires_reboot' do
action :request_reboot
reason 'Need to reboot when the run completes successfully.'
delay_mins 5
end


The full syntax for all of the properties that are available to the reboot resource is:

reboot 'name' do
delay_mins                 Fixnum
notifies                   # see description
reason                     String
subscribes                 # see description
action                     Symbol
end


where

• reboot is the resource
• name is the name of the resource block
• action identifies the steps the chef-client will take to bring the node into the desired state
• delay_mins and reason are properties of this resource, with the Ruby type shown. See “Properties” section below for more information about all of the properties that may be used with this resource.

#### Actions¶

This resource has the following actions:

:cancel
Cancel a reboot request.
:nothing
Define this resource block to do nothing until notified by another resource to take action. When this resource is notified, this resource block is either run immediately or it is queued up to be run at the end of the chef-client run.
:reboot_now
Reboot a node so that the chef-client may continue the installation process.
:request_reboot
Reboot a node at the end of a chef-client run.

#### Properties¶

This resource has the following properties:

delay_mins

Ruby Type: Fixnum

The amount of time (in minutes) to delay a reboot request.

ignore_failure

Ruby Types: TrueClass, FalseClass

Continue running a recipe if a resource fails for any reason. Default value: false.

notifies

Ruby Type: Symbol, ‘Chef::Resource[String]’

A resource may notify another resource to take action when its state changes. Specify a 'resource[name]', the :action that resource should take, and then the :timer for that action. A resource may notifiy more than one resource; use a notifies statement for each resource to be notified.

A timer specifies the point during the chef-client run at which a notification is run. The following timer is available:

:immediate, :immediately
Specifies that a notification should be run immediately, per resource notified.
reason

Ruby Type: String

A string that describes the reboot action.

retries

Ruby Type: Integer

The number of times to catch exceptions and retry the resource. Default value: 0.

retry_delay

Ruby Type: Integer

The retry delay (in seconds). Default value: 2.

subscribes

Ruby Type: Symbol, ‘Chef::Resource[String]’

A resource may listen to another resource, and then take action if the state of the resource being listened to changes. Specify a 'resource[name]', the :action to be taken, and then the :timer for that action.

A timer specifies the point during the chef-client run at which a notification is run. The following timer is available:

:immediate, :immediately
Specifies that a notification should be run immediately, per resource notified.

#### Providers¶

This resource has the following providers:

Chef::Provider::Reboot, reboot
The provider that is used to reboot a node.

#### Example¶

Reboot a node immediately

reboot 'now' do
action :nothing
reason 'Cannot continue Chef run without a reboot.'
delay_mins 2
end

execute 'foo' do
command '...'
notifies :reboot_now, 'reboot[now]', :immediately
end


Reboot a node at the end of a chef-client run

reboot 'app_requires_reboot' do
action :request_reboot
reason 'Need to reboot when the run completes successfully.'
delay_mins 5
end


Cancel a reboot

reboot 'cancel_reboot_request' do
action :cancel
reason 'Cancel a previous end-of-run reboot request.'
end


### windows_service¶

Use the windows_service resource to manage a service on the Microsoft Windows platform. New in Chef Client 12.0.

#### Syntax¶

A windows_service resource block manages the state of a service on a machine that is running Microsoft Windows. For example:

windows_service 'BITS' do
action :configure_startup
startup_type :manual
end


The full syntax for all of the properties that are available to the windows_service resource is:

windows_service 'name' do
init_command               String
notifies                   # see description
pattern                    String
provider                   Chef::Provider::Service::Windows
restart_command            String
run_as_user                String
service_name               String # defaults to 'name' if not specified
start_command              String
startup_type               Symbol
status_command             String
stop_command               String
subscribes                 # see description
supports                   Hash
timeout                    Integer
action                     Symbol # defaults to :nothing if not specified
end


where

• windows_service is the resource
• name is the name of the resource block
• action identifies the steps the chef-client will take to bring the node into the desired state
• init_command, pattern, provider, reload_command, restart_command, run_as_password, run_as_user, service_name, start_command, startup_type, status_command, stop_command, supports, and timeout are properties of this resource, with the Ruby type shown. See “Properties” section below for more information about all of the properties that may be used with this resource.

#### Actions¶

This resource has the following actions:

:configure_startup
Configure a service based on the value of the startup_type property.
:disable
Disable a service. This action is equivalent to a Disabled startup type on the Microsoft Windows platform.
:enable
Enable a service at boot. This action is equivalent to an Automatic startup type on the Microsoft Windows platform.
:nothing
Default. Do nothing with a service.
Reload the configuration for this service.
:restart
Restart a service.
:start
Start a service, and keep it running until stopped or disabled.
:stop
Stop a service.

#### Properties¶

This resource has the following properties:

ignore_failure

Ruby Types: TrueClass, FalseClass

Continue running a recipe if a resource fails for any reason. Default value: false.

init_command

Ruby Type: String

The path to the init script that is associated with the service. This is typically /etc/init.d/SERVICE_NAME. The init_command property can be used to prevent the need to specify overrides for the start_command, stop_command, and restart_command attributes. Default value: nil.

notifies

Ruby Type: Symbol, ‘Chef::Resource[String]’

A resource may notify another resource to take action when its state changes. Specify a 'resource[name]', the :action that resource should take, and then the :timer for that action. A resource may notifiy more than one resource; use a notifies statement for each resource to be notified.

A timer specifies the point during the chef-client run at which a notification is run. The following timers are available:

:delayed
Default. Specifies that a notification should be queued up, and then executed at the very end of the chef-client run.
:immediate, :immediately
Specifies that a notification should be run immediately, per resource notified.

The syntax for notifies is:

notifies :action, 'resource[name]', :timer

pattern

Ruby Type: String

The pattern to look for in the process table. Default value: service_name.

provider

Ruby Type: Chef Class

Optional. Explicitly specifies a provider.

Ruby Type: String

The command used to tell a service to reload its configuration.

restart_command

Ruby Type: String

The command used to restart a service.

retries

Ruby Type: Integer

The number of times to catch exceptions and retry the resource. Default value: 0.

retry_delay

Ruby Type: Integer

The retry delay (in seconds). Default value: 2.

Ruby Type: String

The password for the user specified by run_as_user.

run_as_user

Ruby Type: String

The user under which a Microsoft Windows service runs.

service_name

Ruby Type: String

The name of the service. Default value: the name of the resource block See “Syntax” section above for more information.

start_command

Ruby Type: String

The command used to start a service.

startup_type

Ruby Type: Symbol

Use to specify the startup type for a Microsoft Windows service. Possible values: :automatic, :disabled, or :manual. Default value: :automatic.

status_command

Ruby Type: String

The command used to check the run status for a service.

stop_command

Ruby Type: String

The command used to stop a service.

subscribes

Ruby Type: Symbol, ‘Chef::Resource[String]’

A resource may listen to another resource, and then take action if the state of the resource being listened to changes. Specify a 'resource[name]', the :action to be taken, and then the :timer for that action.

A timer specifies the point during the chef-client run at which a notification is run. The following timers are available:

:delayed
Default. Specifies that a notification should be queued up, and then executed at the very end of the chef-client run.
:immediate, :immediately
Specifies that a notification should be run immediately, per resource notified.

The syntax for subscribes is:

subscribes :action, 'resource[name]', :timer

supports

Ruby Type: Hash

A list of properties that controls how the chef-client is to attempt to manage a service: :restart, :reload, :status. For :restart, the init script or other service provider can use a restart command; if :restart is not specified, the chef-client attempts to stop and then start a service. For :reload, the init script or other service provider can use a reload command. For :status, the init script or other service provider can use a status command to determine if the service is running; if :status is not specified, the chef-client attempts to match the service_name against the process table as a regular expression, unless a pattern is specified as a parameter property. Default value: { :restart => false, :reload => false, :status => false } for all platforms (except for the Red Hat platform family, which defaults to { :restart => false, :reload => false, :status => true }.)

timeout

Ruby Type: Integer

The amount of time (in seconds) to wait before timing out. Default value: 60.

#### Providers¶

The windows_service resource does not have service-specific short names. This is because the chef-client identifies the platform at the start of every chef-client run based on data collected by Ohai. The chef-client looks up the platform, and then determines the correct provider for that platform. In certain situations, such as when more than one init system is available on a node, a specific provider may need to be identified by using the provider attribute and the long name for that provider.

This resource has the following providers:

Chef::Provider::Service::Windows, windows_service
The provider that is used with the Microsoft Windows platform.

#### Example¶

Start a service manually

windows_service 'BITS' do
action :configure_startup
startup_type :manual
end


### knife bootstrap Settings¶

The following options are new:

--[no-]node-verify-api-cert
Verify the SSL certificate on the Chef server. When true, the chef-client always verifies the SSL certificate. When false, the chef-client uses the value of ssl_verify_mode to determine if the SSL certificate requires verification. If this option is not specified, the setting for verify_api_cert in the configuration file is applied.
--node-ssl-verify-mode PEER_OR_NONE

Set the verify mode for HTTPS requests.

Use none to do no validation of SSL certificates.

Use peer to do validation of all SSL certificates, including the Chef server connections, S3 connections, and any HTTPS remote_file resource URLs used in the chef-client run. This is the recommended setting.

-t TEMPLATE, --bootstrap-template TEMPLATE

The bootstrap template to use. This may be the name of a bootstrap template—chef-full, for example—or it may be the full path to an Embedded Ruby (ERB) template that defines a custom bootstrap. Default value: chef-full, which installs the chef-client using the omnibus installer on all supported platforms.

Note

The --distro and --template-file options are deprecated.

### knife status Settings¶

The following options are new:

-l, --long
Display all attributes in the output and show the output as JSON.
-m, --medium
Display normal attributes in the output and to show the output as JSON.

### fsck_device Property¶

The following property is new for the mount resource:

Property Description
fsck_device The fsck device on the Solaris platform. Default value: -.

The following settings are new:

Setting Description
issues_url

The URL for the location in which a cookbook’s issue tracking is maintained. This setting is also used by Chef Supermarket. For example:

source_url "https://github.com/chef-cookbooks/chef-client/issues"

source_url

The URL for the location in which a cookbook’s source code is maintained. This setting is also used by Chef Supermarket. For example:

source_url "https://github.com/chef-cookbooks/chef-client"


Warning

The name attribute is now a required setting in the metadata.rb file.

### http_request Actions¶

The :get and :head actions appended a hard-coded query string—?message=resource_name—that cannot be overridden. This hard-coded string is deprecated in the chef-client 12.0 release. Cookbooks that rely on this string need to be updated to manually add it to the URL as it is passed to the resource.

### Recipe DSL¶

The following methods have been added to the Recipe DSL: shell_out, shell_out!, and shell_out_with_systems_locale.

#### shell_out¶

The shell_out method can be used to run a command against the node, and then display the output to the console when the log level is set to debug.

The syntax for the shell_out method is as follows:

shell_out(command_args)


where command_args is the command that is run against the node.

#### shell_out!¶

The shell_out! method can be used to run a command against the node, display the output to the console when the log level is set to debug, and then raise an error when the method returns false.

The syntax for the shell_out! method is as follows:

shell_out!(command_args)


where command_args is the command that is run against the node. This method will return true or false.

#### shell_out_with_systems_locale¶

The shell_out_with_systems_locale method can be used to run a command against the node (via the shell_out method), but using the LC_ALL environment variable.

The syntax for the shell_out_with_systems_locale method is as follows:

shell_out_with_systems_locale(command_args)


where command_args is the command that is run against the node.

#### value_for_platform¶

The value_for_platform helper may use version constraints, such as >= and ~> to help resolve situations where version numbers look like 7.0.<buildnumber>. For example:

value_for_platform(
"redhat" => {
"~> 7.0" => "version 7.x.y"
">= 8.0" => "version 8.0.0 and greater"
}
}


Note

When two version constraints match it is considered ambiguous and will raise an exception. An exact match, however, will always take precedence over a version constraint.

### File Specificity¶

The pattern for file specificity depends on two things: the lookup path and the source attribute. The first pattern that matches is used:

1. /host-$fqdn/$source
2. /$platform-$platform_version/$source 3. /$platform/$source 4. /default/$source
5. /$source Use an array with the source attribute to define an explicit lookup path. For example: file '/conf.py' do source ["#{node.chef_environment}.py", 'conf.py'] end  or: template '/test' do source ["#{node.chef_environment}.erb", 'default.erb'] end  ### Mac OS X, Passwords¶ The following properties are new for the user resource: Property Description iterations The number of iterations for a password with a SALTED-SHA512-PBKDF2 shadow hash. salt The salt value for a password shadow hash. Mac OS X version 10.7 uses SALTED-SHA512 and version 10.8 (and higher) uses SALTED-SHA512-PBKDF2 to calculate password shadow hashes. Use SALTED-SHA512 passwords Mac OS X 10.7 calculates the password shadow hash using SALTED-SHA512. The length of the shadow hash value is 68 bytes, the salt value is the first 4 bytes, with the remaining 64 being the shadow hash itself. The following code will calculate password shadow hashes for Mac OS X 10.7: password = 'my_awesome_password' salt = OpenSSL::Random.random_bytes(4) encoded_password = OpenSSL::Digest::SHA512.hexdigest(salt + password) shadow_hash = salt.unpack('H*').first + encoded_password  Use the calculated password shadow hash with the user resource: user 'my_awesome_user' do password 'c9b3bd....d843' # Length: 136 end  Use SALTED-SHA512-PBKDF2 passwords Mac OS X 10.8 (and higher) calculates the password shadow hash using SALTED-SHA512-PBKDF2. The length of the shadow hash value is 128 bytes, the salt value is 32 bytes, and an integer specifies the number of iterations. The following code will calculate password shadow hashes for Mac OS X 10.8 (and higher): password = 'my_awesome_password' salt = OpenSSL::Random.random_bytes(32) iterations = 25000 # Any value above 20k should be fine. shadow_hash = OpenSSL::PKCS5::pbkdf2_hmac( password, salt, iterations, 128, OpenSSL::Digest::SHA512.new ).unpack('H*').first salt_value = salt.unpack('H*').first  Use the calculated password shadow hash with the user resource: user 'my_awesome_user' do password 'cbd1a....fc843' # Length: 256 salt 'bd1a....fc83' # Length: 64 iterations 25000 end  ### chef-client Options¶ The following options are updated for the chef-client executable: --chef-zero-port PORT The port on which chef-zero listens. If a port is not specified—individually or as range of ports from within the command—the chef-client will scan for ports between 8889-9999 and will pick the first port that is available. This port or port range may also be specified using the chef_zero.port setting in the client.rb file. -o RUN_LIST_ITEM, --override-runlist RUN_LIST_ITEM Replace the current run-list with the specified items. This option will not clear the list of cookbooks (and related files) that is cached on the node. The following configuration settings are updated for the client.rb file and now default to true: Setting Description disable_event_logger Enable or disable sending events to the Microsoft Windows “Application” event log. When false, events are sent to the Microsoft Windows “Application” event log at the start and end of a chef-client run, and also if a chef-client run fails. Set to true to disable event logging. Default value: true. no_lazy_load Download all cookbook files and templates at the beginning of the chef-client run. Default value: true. file_staging_uses_destdir How file staging (via temporary files) is done. When true, temporary files are created in the directory in which files will reside. When false, temporary files are created under ENV['TMP']. Default value: true. local_key_generation Use to specify whether the Chef server or chef-client will generate the private/public key pair. When true, the chef-client will generate the key pair, and then send the public key to the Chef server. Default value: true. ### Filter Search Results¶ Use :filter_result as part of a search query to filter the search output based on the pattern specified by a Hash. Only attributes in the Hash will be returned. Note Prior to chef-client 12.0, this functionality was available from the partial_search cookbook and was referred to as “partial search”. The syntax for the search method that uses :filter_result is as follows: search(:index, 'query', :filter_result => { 'foo' => [ 'abc' ], 'bar' => [ '123' ], 'baz' => [ 'sea', 'power' ] } ).each do |result| puts result['foo'] puts result['bar'] puts result['baz'] end  where: • :index is of name of the index on the Chef server against which the search query will run: :client, :data_bag_name, :environment, :node, and :role • 'query' is a valid search query against an object on the Chef server • :filter_result defines a Hash of values to be returned For example: search(:node, 'role:web', :filter_result => { 'name' => [ 'name' ], 'ip' => [ 'ipaddress' ], 'kernel_version' => [ 'kernel', 'version' ] } ).each do |result| puts result['name'] puts result['ip'] puts result['kernel_version'] end  ### execute Resource, path Property¶ The path property has been deprecated and will throw an exception in Chef Client 13. We recommend you use the environment property instead. ### git Property¶ The following property is new for the git resource: Property Description environment A Hash of environment variables in the form of ({"ENV_VARIABLE" => "VALUE"}). (These variables must exist for a command to be run successfully.) Note The git provider automatically sets the ENV['HOME'] and ENV['GIT_SSH'] environment variables. To override this behavior and provide different values, add ENV['HOME'] and/or ENV['GIT_SSH'] to the environment Hash. ### Chef::Provider, Custom Resources¶ If a custom resource was created in the /libraries directory of a cookbook that also uses a core resource from the chef-client within the custom resource, the base class that is associated with that custom resource must be updated. In previous versions of the chef-client, the Chef::Provider class was all that was necessary because the Recipe DSL was included in the Chef::Provider base class. For example, the lvm_logical_volume custom resource from the lvm cookbook uses the directory and mount resources: class Chef class Provider class LvmLogicalVolume < Chef::Provider include Chef::Mixin::ShellOut ... if new_resource.mount_point if new_resource.mount_point.is_a?(String) mount_spec = { :location => new_resource.mount_point } else mount_spec = new_resource.mount_point end dir_resource = directory mount_spec[:location] do mode '0755' owner 'root' group 'root' recursive true action :nothing not_if { Pathname.new(mount_spec[:location]).mountpoint? } end dir_resource.run_action(:create) updates << dir_resource.updated? mount_resource = mount mount_spec[:location] do options mount_spec[:options] dump mount_spec[:dump] pass mount_spec[:pass] device device_name fstype fs_type action :nothing end mount_resource.run_action(:mount) mount_resource.run_action(:enable) updates << mount_resource.updated? end new_resource.updated_by_last_action(updates.any?) end  Starting with chef-client 12, the Recipe DSL is removed from the Chef::Provider base class and is only available by using LWRPBase. Cookbooks that contain custom resources authored for the chef-client 11 version should be inspected and updated. Cookbooks that contain custom resources in the /libraries directory of a cookbook should: • Be inspected for instances of a) the Chef::Provider base class, and then b) for the presence of any core resources from the chef-client • Be updated to use the LWRPBase base class For example: class Chef class Provider class LvmLogicalVolume < Chef::Provider::LWRPBase include Chef::Mixin::ShellOut ... if new_resource.mount_point if new_resource.mount_point.is_a?(String) mount_spec = { :location => new_resource.mount_point } else mount_spec = new_resource.mount_point end dir_resource = directory mount_spec[:location] do mode 0755 owner 'root' group 'root' recursive true action :nothing not_if { Pathname.new(mount_spec[:location]).mountpoint? } end dir_resource.run_action(:create) updates << dir_resource.updated? mount_resource = mount mount_spec[:location] do options mount_spec[:options] dump mount_spec[:dump] pass mount_spec[:pass] device device_name fstype fs_type action :nothing end mount_resource.run_action(:mount) mount_resource.run_action(:enable) updates << mount_resource.updated? end new_resource.updated_by_last_action(updates.any?) end  ### SSL Certificates¶ Chef server 12 enables SSL verification by default for all requests made to the server, such as those made by knife and the chef-client. The certificate that is generated during the installation of the Chef server is self-signed, which means the certificate is not signed by a trusted certificate authority (CA) that ships with the chef-client. The certificate generated by the Chef server must be downloaded to any machine from which knife and/or the chef-client will make requests to the Chef server. For example, without downloading the SSL certificate, the following knife command: $ knife client list


responds with an error similar to:

ERROR: SSL Validation failure connecting to host: chef-server.example.com ...
ERROR: OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=SSLv3 ...


This is by design and will occur until a verifiable certificate is added to the machine from which the request is sent.

See SSL Certificates for more information about how knife and the chef-client use SSL certificates generated by the Chef server.

## Changelog¶

https://github.com/chef/chef/blob/master/CHANGELOG.md