cookbook 'chef_client_updater', '= 3.11.0'
chef_client_updater
(62) Versions
3.11.0
-
-
3.12.3
-
3.12.2
-
3.12.1
-
3.12.0
-
3.11.1
-
3.11.0
-
3.10.1
-
3.10.0
-
3.9.0
-
3.8.6
-
3.8.5
-
3.8.4
-
3.8.3
-
3.8.2
-
3.8.1
-
3.8.0
-
3.7.3
-
3.7.2
-
3.7.1
-
3.7.0
-
3.6.0
-
3.5.3
-
3.5.2
-
3.5.1
-
3.5.0
-
3.4.2
-
3.4.1
-
3.4.0
-
3.3.5
-
3.3.4
-
3.3.3
-
3.3.2
-
3.3.1
-
3.3.0
-
3.2.9
-
3.2.8
-
3.2.7
-
3.2.6
-
3.2.5
-
3.2.4
-
3.2.3
-
3.2.2
-
3.2.1
-
3.2.0
-
3.1.3
-
3.1.2
-
3.1.1
-
3.1.0
-
3.0.4
-
3.0.3
-
3.0.2
-
3.0.1
-
3.0.0
-
2.0.3
-
2.0.2
-
2.0.1
-
2.0.0
-
1.1.1
-
1.1.0
-
1.0.2
-
1.0.1
-
1.0.0
Follow58
- 3.12.3
- 3.12.2
- 3.12.1
- 3.12.0
- 3.11.1
- 3.11.0
- 3.10.1
- 3.10.0
- 3.9.0
- 3.8.6
- 3.8.5
- 3.8.4
- 3.8.3
- 3.8.2
- 3.8.1
- 3.8.0
- 3.7.3
- 3.7.2
- 3.7.1
- 3.7.0
- 3.6.0
- 3.5.3
- 3.5.2
- 3.5.1
- 3.5.0
- 3.4.2
- 3.4.1
- 3.4.0
- 3.3.5
- 3.3.4
- 3.3.3
- 3.3.2
- 3.3.1
- 3.3.0
- 3.2.9
- 3.2.8
- 3.2.7
- 3.2.6
- 3.2.5
- 3.2.4
- 3.2.3
- 3.2.2
- 3.2.1
- 3.2.0
- 3.1.3
- 3.1.2
- 3.1.1
- 3.1.0
- 3.0.4
- 3.0.3
- 3.0.2
- 3.0.1
- 3.0.0
- 2.0.3
- 2.0.2
- 2.0.1
- 2.0.0
- 1.1.1
- 1.1.0
- 1.0.2
- 1.0.1
- 1.0.0
Upgrades chef-client to specified releases
cookbook 'chef_client_updater', '= 3.11.0', :supermarket
knife supermarket install chef_client_updater
knife supermarket download chef_client_updater
chef_client_updater
This cookbook updates the Chef Infra Client
Requirements
Platforms
- All platforms with a Chef Infra Client package on downloads.chef.io
Chef
- Chef 11.6.2+
Usage
This cookbook provides both a custom resource and a default recipe. The default recipe simply uses the custom resource with a set of attributes. You can add chef_client_updater::default to your run list or use the custom resource in a wrapper cookbook.
Init System Caveats
When Chef Infra Client runs as a service under a system init daemon such as Sys-V or systemd each Chef Infra Client run forks off from the main chef-client process being managed by the init system. For a Chef Infra Client upgrade to occur, the running Chef Infra Client as well as the parent process must be killed, and a new Chef Infra Client must start using the updated binaries. This cookbook handles killing the chef-client process, but your init system must properly handle starting the service back up. For systemd this can be handled via configuration, and the chef-client cookbook 8.1.1 or later handles this by default. This functionality is not available in sys-v (RHEL 6, AIX, and older platforms).
For systems where the init system will not properly handle starting the service back up automatically (like Sys-V or SRC) this cookbook will attempt to restart the service via a temporary cron job when either of the following conditions are met:
- node['chef_client']['init_style'] == 'init'
- node['chef_client_updater']['restart_chef_via_cron'] == true
Updating Windows Nodes
On Windows, a one time scheduled task Chef_upgrade
is created in combination with a PowerShell-based upgrade script and the downloaded Handle tool. When the Chef_upgrade scheduled task runs, it executes the PowerShell upgrade script, which first determines whether it can successfully stop any existing Chef Infra Client service and associated Ruby processes, since the MSI Installer will fail if there is a running Chef Infra Client service or ruby.exe process. If it cannot it will sleep for one minute and try again up to five times. If after five tries it still hasn't been successful it modifies the Chef_upgrade
scheduled task to run 10 minutes in the future to try the process again. This eliminates the situation where the scheduled task fails and the Chef Infra Client is no longer configured to run automatically (since the service has been stopped), which in large environments is costly to recover from (requiring reboots of many servers).
The PowerShell upgrade script then moves the current installation to a staging directory and that clears the way for the newer installer to run. Any existing file handles to the old installation folder are forcibly removed and the Eventlog service will be restarted immediately prior to the new installation to release any open file locks. After installation, a log file from the upgrade can be found at c:\opscode\chef_upgrade.log
until the next Chef Infra Client run where it will be cleaned up along with the backup folder. Upon successful installation the Chef_upgrade
scheduled task is deleted.
On Windows, the recommended post_install_action
is exec
instead of kill
if you intend to run Chef Infra Client periodically. In chef_client_updater
versions >= 3.1.0
and <= 3.2.9
, the updater resource by default started a new Chef Infra Client run after upgrading. Newer versions simply run chef-client
only if post_install_action
is set to exec
. To run a custom other PowerShell command after-upgrade, define post_install_action
exec
and define your custom command in exec_command
Running Chef Infra Client as a Scheduled Task
If you run as a scheduled task, then this will work smoothly. The path to the newly installed Chef Infra Client will be the same and the scheduled task will launch it. Part of this resource's job on the next run is to make sure the staging directory with the older client is removed.
Running Chef Infra Client As A Windows Service
If you run Chef Infra Client as a service, things get a tiny bit more complicated. When the new installer runs, the service is removed. This isn't a big deal if you've got the chef-client cookbook set to configure the Windows service. If that is the case, define post_install_action
exec
and the Chef-run triggered after the upgrade will take care of installing the service. Alternatively you can migrate to running Chef Infra Client as a scheduled task as described below.
Migrating from Running Chef Infra Client as a Windows Service to Running as a Scheduled Task During the Upgrade
If you run Chef Infra Client as a service, but want to upgrade to a version of the client with an MSI unstaller that supports running as a scheduled task (any Chef Infra Client >= 12.18) it is now possible with the install_command_options
property (added in version 3.8.0 of the chef_client_updater cookbook). This property accepts a Hash of key/value pairs, with {daemon: 'task'} the necessary pair to notify the MSI Installer to install Chef Infra Client as a scheduled task.
Upgrading from Chef Infra Client 11
Moving from Chef Infra Client 11 has a few challenges when we are dealing with public update sources. Chef Infra Client 11 ships with a very old cacert.pem
. To work through this, we need to get a more current cacert.pem
file and point OpenSSL to it. Unfortunately, for this to work consistently on Windows, we'll need to reboot. Chef Infra Client 11 does not have the reboot resource, so this isn't a graceful process. However, on the next Chef run after the reboot, things will be back on track and the upgrade will perform as on other platforms.
Below is an example of a recipe that can set up Chef Infra Client 11 to work using public update sources.
if platform_family?('windows') && (Chef::VERSION < '12') new_cert_file = File.join(ENV['USERPROFILE'], 'cacert.pem') remote_file new_cert_file do source 'https://curl.haxx.se/ca/cacert.pem' action :create end powershell_script 'restart' do code <<-EOH restart-computer -force EOH action :nothing end env 'SSL_CERT_FILE' do value new_cert_file notifies :run, 'powershell_script[restart]', :immediately end end chef_client_updater 'Install latest Chef' do post_install_action 'kill' end
Chef EULA
Set the node['chef_client']['chef_license']
attribute to accept
or accept-no-persist
to accept the Chef EULA
when upgrading to Chef Infra Client 15 or higher.
Resources
chef_client_updater
Installs the mixlib-install/mixlib-install gems and upgrades the Chef Infra Client.
properties
-
channel
- The chef channel you fetch the Chef Infra Client from.stable
contains all officially released Chef Infra Client builds where ascurrent
contains unreleased builds. Default:stable
-
prevent_downgrade
- Don't allow this cookbook to downgrade the Chef Infra Client version. Default: false -
version
- The version of the Chef Infra Client to install. Default :latest -
post_install_action
- After installing the Chef Infra Client what should we do.exec
to exec the new client orkill
to kill the client and rely on the init system to start up the new version. Default:kill
-
exec_command
- The chef-client command. default: $PROGRAM_NAME.split(' ').first. You can also enter a custom post-action command. -
exec_args
- An array of arguments to exec the Chef Infra Client with. default: ARGV -
download_url_override
- The direct URL for the Chef Infra Client package. -
checksum
- The SHA-256 checksum of the Chef Infra Client package from the direct URL. -
install_timeout
- The install timeout for non-windows systems. The default is 600, slow machines may need to extend this. -
upgrade_delay
- The delay in seconds before the scheduled task to upgrade Chef Infra Client runs on windows. default: 61. Lowering this limit is not recommended. -
product_name
- The name of the product to upgrade. This can bechef
orchefdk
default: chef - 'install_command_options' - A Hash of additional options that will be passed to the Mixlib::Install instance responsible for installing the given product_name. To install Chef Infra Client as a scheduled task on windows, one can pass {daemon: 'task'}. Default: {}
-
rubygems_url
- The location to source rubygems. Replaces the default https://www.rubygems.org. -
handle_zip_download_url
- Url to the Handle zip archive used by Windows. Used to override the default in airgapped environments. default: https://download.sysinternals.com/files/Handle.zip (Note that you can also override thedefault['chef_client_updater']['handle_exe_path']
attribute if you already have that binary somewhere on your system)
examples
chef_client_updater 'Install latest'
chef_client_updater 'Install latest Chef Infra Client 16.x' do version '16' end
chef_client_updater 'Install 12.13.36 and kill' do version '12.13.36' post_install_action 'kill' end
Test Kitchen Testing
In order to test this cookbook it will be necessary to change the post_install_action
to exec
from kill
. While kill
is better in most actual production use cases as it terminates the chef-client run along with cleaning up the parent process, the use of kill
under test kitchen will fail the chef-client run and fail the test-kitchen run. The use of exec
allows test-kitchen to complete and then re-runs the recipe to validate that the cookbook does not attempt to re-update the chef-client and will succeed with the new chef-client. This, however, means that it is not possible to exactly test the config which will be running in production. The best practice advice for this cookbook will be to ignore common best practices and not worry about that. If you change your production config to use exec
in order to run what you test in test-kitchen, then you will find sharp edge cases where your production upgrades will hang and/or fail, which testing will not replicate. In order to test you should most likely test upgrades on your full-scale integration environment (not under test-kitchen) before rolling out to production and not use test-kitchen at all. If you think that there's a rule that you must test absolutely everything you run under test-kitchen, you should probably read this or this.
In order to test that your recipes work under the new chef-client codebase, you should simply test your cookbooks against the new version of chef-client that you wish to deploy in "isolation" from the upgrade process. If your recipes all work on the old client, and all work on the new client, and the upgrader works, then the sum of the parts should work as well (and again, if you really deeply care about the edge conditions where that might not work -- then test on real production-like images and not with test-kitchen).
Use of 'exec' in production
This is highly discouraged since the exec will not clean up the supervising process. You're very likely to see it upgrade successfully and then see the old chef-client process continue to run and fork off copies of the old chef-client to run again. Or for the upgrade process to hang, or for other issues to occur causing failed upgrades.
You can use 'exec' in production if you are running from cron or some other process manager and firing off single-shot --no-fork
chef-client processes without using the --interval
option. This will have the advantage that the new chef-client kicks off immediately after the upgrade giving fast feedback on any failures under the new chef-client. The utility of this approach is most likely is not enough to justify the hassle.
A note about purpose
While this cookbook supports running on Chef Infra Client versions back to 11/12, the supported behavior of the cookbook is to upgrade those versions to 13/14 or newer. It is not intended that users would maintain old Chef-11/12 versions with this cookbook. The latest released version of Chef Infra Client 12 (12.22.1 or later) is still be supported as a target. Older versions of Chef Infra Client will have their embedded rubygems force upgraded by this cookbook to avoid having to regression test against 5+ years of rubygems bugs and establish a stable basis for the cookbook to use.
License
Copyright:: 2016-2020, Chef Software, Inc Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Dependent cookbooks
This cookbook has no specified dependencies.
Contingent cookbooks
chef_client_updater Cookbook CHANGELOG
This file is used to list changes made in each version of the chef_client_updater cookbook.
3.11.0 (2020-08-12)
- #209 Fixed Windows PowerShell task reschedule by using Scheduled Task cmdlets available on PowerShell 3+ on Windows 2012+- @jwdean
- resolved cookstyle error: providers/default.rb:314:3 convention:
Style/RedundantAssignment
3.10.1 (2020-05-27)
- Catch when the windows upgrades fail and make sure we leave the C:\opscode\chef dir - @teknofire
- Improve logging on Windows - @teknofire
- More chef-client / chef -> Chef Infra Client - @tas50
- Improve the exit message so users realize it was a success - @tas50
- Expand testing with new platforms - @tas50
3.10.0 (2020-05-04)
- Disable if_respond to cop for legacy support - @tas50
- Use source parameter for chef_gem if it exists - @ramereth
- Include cinc as an allowed product_name - @ramereth
3.9.0 (2020-04-14)
- Remove #to_s conversion of attributes - @jasonwbarnett
- More robust eventlog and dependent services restarts on Windows - @rabidpitbull
3.8.6 (2020-03-06)
- Fixed restart eventlog and dependent services - @sanga1794
3.8.5 (2020-03-05)
- Fix nil:NilClass error - @dheerajd-msys
3.8.4 (2020-02-20)
-Fix the type for the rubygems_url property
3.8.3 (2020-02-20)
- Updated rubygems_url resource property default and removed attribute - @BrandonTheMandon
3.8.2 (2020-01-14)
- Remove mandatory parameters for WaitForChefClientOrRescheduleUpgradeTask - @bdwyertech
3.8.1 (2020-01-14)
- Necessary changes in PS script to accept the chef-client license while chef client upgrade in Windows. - @Nimesh-Msys
3.8.0 (2019-12-20)
- Add install_command_options to enable installing Chef as a scheduled task on Windows when updating - @gholtiii
- Fix Chef_upgrade scheduled task to reschedule itself when it fails due to running ruby.exe - @gholtiii
3.7.3 (2019-12-09)
- Minor Fixes While detecting chef DK version - @Nimesh-Msys
3.7.2 (2019-11-29)
- fix windows chef install path - @phomein
3.7.1 (2019-11-19)
- Minor fixes while upgrading ChefDK - @Nimesh-Msys
- Replace hardcode value for chef_install_path on Windows with a variable - @dheerajd-msys
3.7.0 (2019-11-18)
- Added noproxy support for airgapped artifact solutions @Romascopa
- Fix for using custom rubygem server - @dheerajd-msys
- Remove opensuse from the list of platforms we support as the correct platform is opensuseleap - @tas50
- Remove the long_description metadata that is unused - @tas50
- Disable some Cookkstyle cops that would break Chef 12 compatibility - @tas50
3.6.0 (2019-10-14)
- Updated provider so that EventLog is properly restarted without error during convergence
- Adding license acceptance support - @tyler-ball
- Fix creation of cron error while licence acceptance - @NAshwini
3.5.3 (2019-06-11)
- Add event_log_service_restart attribute to fix issue of non chef service restart. - @NAshwini
- Use new ChefSpec format - @tas50
- Allow path to handle.exe to be configured - @stefanwb
3.5.2 (2019-01-30)
- Fix rubygems upgrade logic to prevent breaking older chef-client releases such as Chef 12.X
3.5.1 (2018-12-22)
- use --no-document for rubygems 3.0 to prevent upgrade failures - @lamont-granquist
3.5.0 (2018-08-31)
- Only run the cron job on *nix 5 minutes from now
3.4.2 (2018-08-15)
- Fix to retrieve current version for angrychef nodes
3.4.1 (2018-08-02)
- Allow for a configurable package install timeout. (#130)
3.4.0 (2018-07-23)
- Prevent failures on Chef-DK
- rubygems_url: Allow the rubygems source to be specified
- Require mixlib-install 3.11+ for Amazon Linux 2.0 support
- Attempt to move the chef install directory if it still exists before giving up to workaround failures on Windows 2008
3.3.5 (2018-06-20)
- Do not attempt EventLog restart on Windows 7 or Windows Server 2008 editions.
3.3.4 (2018-05-30)
- Improve install success rate on Windows by destroying existing Chef handles prior to upgrade.
3.3.3 (2018-04-26)
- Better support AIX by also restarting the chef-client service via cron on AIX
3.3.2 (2018-04-11)
- Improve how we handle updating rubygems:
- Update RubyGems without shelling out
- Don't upgrade to the very latest version unless we have to (due to old current rubygems)
3.3.1 (2018-04-11)
- Stop push jobs before upgrading Chef on Windows and then start it back up. This prevents failures to update.
3.3.0 (2018-04-10)
- Post action support on Windows
- Prevent failure when the user doesn't use the chef-client cookbook
3.2.9 (2018-04-05)
- Don't run cron on Windows
3.2.8 (2018-04-04)
- Restart chef-client with cron under sysvinit to ensure that chef-client properly restarts
3.2.7 (2018-03-29)
- Update log message to KILL from TERM. We updated the behavior but missed the logging
3.2.6 (2018-03-16)
- Added additional logic to decide if a 'kill' or 'exec' should be done post upgrade. If the chef-client isn't running with the supervsior process then we will no longer try to use kill.
3.2.5 (2018-02-28)
- Use KILL instead of TERM on Windows since TERM isn't always actually killing the process
- Updated the upgrade_delay value on Windows to be 60 seconds since anything less causes issues
3.2.4 (2018-02-05)
- Fix warning '/ST is earlier than current time' on Windows
3.2.3 (2018-01-25)
- Make product_name attribute into a real property on the resource
3.2.2 (2018-01-25)
- Make upgrade_delay a true resource property
3.2.1 (2018-01-25)
- Added new attribute 'upgrade_delay' that defines delay in seconds before upgrading Chef client.
3.2.0 (2018-01-22)
- Require mixlib-install 3.9 which includes initial support for proxies and support for Amazon Linux 2.0
- Add additional debug logging for the installation
- If the user provides an X.Y.Z format version don't contact Chef Inc's servers to validate the version
- error out chef run if shell update fails
3.1.3 (2017-12-20)
- Support custom paths to chef-client
3.1.2 (2017-11-22)
- Windows: Support for downgrading the Chef client
3.1.1 (2017-11-14)
- Windows: Bypass Powershell Execution Policy for upgrade scheduled task
3.1.0 (2017-11-01)
- Raise if download_url_override is set but checksum isn't
- Require a mixin-install that supports proxies
- Improve how we perform the cleanup of the previous install directory on Windows
- Remove a hardcoded path to the chef-client on Windows
- Improve how we perform the Windows upgrade by using a scheduled task to avoid failures during the upgrade
3.0.4 (2017-08-17)
- Fix gem install to actually install mixlib-install 3.3.4
- Fix :latest resulting in chef installing on every run
3.0.3 (2017-08-10)
- Add accurate logging for the rubygems upgrade to reflect that we're actually upgrading to the latest release.
- Require mixlib-install 3.3.4 to prevent failures on Windows nodes due to architecture detection failing within mixlib-install
- Add debug logging for the desired version logic
- Improve logging of the version we're upgrading to in situations where the user provides either :latest or a partial version like '12'. Show the version we're upgrading to instead of what the user passed
3.0.2 (2017-08-08)
- Improve logging to actually log when the upgrade occurs before we kill or exec the current chef-client run
3.0.1 (2017-07-14)
- adding check for gem.cmd on chef-client 13 windows
3.0.0 (2017-07-14)
Breaking Changes
- The default post install action for the resource has been switched from exec to kill. We believe that kill is the most likely default that users would expect as this allows a chef-client daemon running under a modern init system to cleanly upgrade. We highly recommend you check the readme and understand the exec and kill functions to determine which makes the most sense for how you run chef-client and how you execute the upgrade.
- The prevent downgrade attribute for the default recipe has been changes from true to false as this is the default for the resource.
Other Changes
- If chef-client is forked and the user specifies an 'exec' post install action we will now warn and then kill as exec will not worked in a forked run
- Updated the windows task example in the readme to properly set the start time
- Updated the minimum version of mixlib-install to download 3.3.1 which includes many fixes for windows clientsA
- The resource now works around situations where mixlib-install may return an Array of versions
2.0.3 (2017-06-27)
- Fix #31 detect centos platform correctly
2.0.2 (2017-06-22)
- Fix air-gapped installation regression introduced by support for partial versions
2.0.1 (2017-06-16)
- Add information on upgrading Windows nodes and upgrading from Chef 11 to the readme
2.0.0 (2017-06-15)
- The custom resource has been converted to a LWRP so that we can support Chef Client updates from chef-client 11.6.2 to current. This also removes the need for the compat_resource cookbook.
- Support for upgrading Windows clients has been added
- A potential infinite loop in the upgrade process has been fixed
- The existing /opt/chef directory will now be cleaned up before the reinstall so leftover files will not carry over during upgrades
- Full Travis testing of the cookbook has been added
1.1.1 (2017-05-11)
- Fix the initial load of mixlib-install failing
1.1.0 (2017-05-10)
- Add support for download URL overrides via new properties on the resource and attributes for the default recipe. This requires mixlib-install 3.2.1, which we now ensure we install in the updater resource.
- Update the default post_install action in the recipe to match the resource (exec).
- Remove usage of class_eval in the resource since we use compat_resource and class_eval causes issues with some later Chef 12 releases.
- Fix the solaris platform name in the metadata.rb.
- Remove disabling FC016 and FC023 Foodcritic rules as these no longer alert.
- Avoid infinite loops if trying to install the latest chef-client version from any channel.
- Add a true test recipe and remove unused inspec tests
- Add debug logging of the current vs. desired versions to help troubleshooting
- Added a blurb in the readme outlining init system issues surrounding kill and the chef-client starting back up
1.0.2 (2017-04-07)
- Fix Chef 13 compatibility by using Kernel.exec not exec
1.0.1 (2017-04-07)
- point the URLs at the new project repo
- Add ChefSpec matcher
1.0.0
- Initial release of chef_client_updater
Collaborator Number Metric
3.11.0 passed this metric
Contributing File Metric
3.11.0 passed this metric
Foodcritic Metric
3.11.0 passed this metric
No Binaries Metric
3.11.0 passed this metric
Testing File Metric
3.11.0 passed this metric
Version Tag Metric
3.11.0 passed this metric
3.11.0 passed this metric
3.11.0 passed this metric
Foodcritic Metric
3.11.0 passed this metric
No Binaries Metric
3.11.0 passed this metric
Testing File Metric
3.11.0 passed this metric
Version Tag Metric
3.11.0 passed this metric
3.11.0 passed this metric
3.11.0 passed this metric
Testing File Metric
3.11.0 passed this metric
Version Tag Metric
3.11.0 passed this metric
3.11.0 passed this metric
3.11.0 passed this metric