Commit 7a1778fb authored by sersut's avatar sersut
Browse files

Merge branch 'master' into 11-stable

Merging mater branch for RC version.
parents 0d097217 cacf2a53
# Chef Client Changelog
## Unreleased
* Including a recipe from a cookbook not in the dependency graph logs
a MissingCookbookDependency warning. Fixes CHEF-4367.
* Improves syntax check speed for Ruby 1.9+, especially when using bundler.
* Send X-Remote-Request-Id header in order to be able to correlate actions during a single run.
* Fix for CHEF-5048.
* Fix for CHEF-5052.
* Fix for CHEF-5018.
* Add --validator option to `knife client create` to be able to create validator clients via knife.
* Add --delete-validators option to `knife client delete` in order to prevent accidental deletion of validator clients.
* Add --delete-validators option to `knife client bulk delete` in order to prevent accidental deletion of validator clients.
* Add -r / --runlist option to chef-client which permanently sets or changes the run_list of a node.
* CHEF-5030: clean up debian ifconfig provider code
* CHEF-5001: spec tests for multiple rollbacks
* Added ohai7 'machinename' attribute as source of `node_name` information
* CHEF-4773: add ruby-shadow support to Mac and FreeBSD distros
* Service Provider for MacOSX now supports `enable` and `disable`
* CHEF-5086: Add reboot_pending? helper to DSL
* Upgrade ohai to 7.0.0.rc.0
* Make the initial bootstrap message more user friendly (CHEF-5102)
* Correctly handle exceptions in formatters when exception.message is nil (CHEF-4743)
* Fix convergence message in deploy provider (CHEF-4929)
* Make group resource idempotent when gid is specified as a string. (CHEF-4927)
* Non-dupable elements are now handled when duping attribute arrays. (CHEF-4799)
* ruby-shadow is not installed on cygwin platform anymore. (CHEF-4946)
* Upgrade chef-zero to 2.0, remove native-compiled puma as chef dependency. (CHEF-4901/CHEF-5005)
* Don't honor splay when sent USR1 signal.
* Don't set log_level in client.rb by default (CHEF-3698)
* Add IBM PowerKVM to Platform map. (CHEF-5135)
* Cookbook metadata now allows boolean and numeric attributes. (CHEF-4075)
* Knife ssh uses cloud port attribute when available. (CHEF-4962)
* Client info and debug logs now contain cookbook versions in addition to cookbook names. (CHEF-4643)
* ShellOut mixin now exposes a method to capture the live stream during command execution. (CHEF-5017)
* Service provider is now aware of maintenance state on Solaris. (CHEF-4990)
* Refactor Chef::Util::FileEdit to indicate the purpose of the former file_edited, now unwritten_changes?. (CHEF-3714)
* Fixed FileEdit#insert_line_if_no_match to match multiple times. (CHEF-4173)
* Hide passwords in error messages from the Subversion resource. (CHEF-4680)
* The dpkg package provider now supports epoch versions. (CHEF-1752)
* Multiple missing dependencies are now listed on knife cookbook upload. (CHEF-4851)
* Add a public file_edited? method to Chef::Util::FileEdit. (CHEF-3714)
* Package provider defaults to IPS provider on Solaris 5.11+ (CHEF-5037)
* Chef::REST works with frozen options. (CHEF-5064)
* Service provider now uses Systemd on ArchLinux. (CHEF-4905)
* Support knife node run_list add --before. (CHEF-3812)
* Don't destructively merge subhashes in hash_only_merge!. (CHEF-4918)
* Display correct host name in knife ssh error message (CHEF-5029)
* Knife::UI#confirm now has a default_choice option. (CHEF-5057)
* Add knife 'ssl check' and 'ssl fetch' commands for debugging SSL errors. (CHEF-4711)
* Usermod group provider is only used on OpenSuse. (OHAI-339)
* Add knife 'ssl check' and 'ssl fetch' commands for debugging SSL errors (CHEF-4711)
* Cron resource accepts a weekday attribute as a symbol. (CHEF-4848)
* Cron resource accepts special strings, e.g. @reboot (CHEF-2816)
* Call WIN32OLE.ole_initialize before using WMI (CHEF-4888)
* Fix TypeError when calling dup on un-dupable objects in DeepMerge
* Add optional client-side generation of client keys during registration (CHEF-4373)
* Restore warning for the overlay feature in `knife cookbook upload`,
which was accidentally removed in 11.0.0.
* Don't save the run_list during `node.save` when running with override run list. (CHEF-4443)
* Enable Content-Length validation for Chef::HTTP::Simple and fix issues around it. (CHEF-5041, CHEF-5100)
* Windows MSI Package Provider (CHEF-5087)
* Fix mount resource when device is a relative symlink (CHEF-4957)
* Increase bootstrap log_level when knife -V -V is set (CHEF-3610)
* Knife cookbook test should honor chefignore (CHEF-4203)
* Fix ImmutableMash and ImmutableArray to_hash and to_a methods (CHEF-5132)
* guard_interpreter attribute: use powershell\_script, other script resources in guards (CHEF-4553)
## Last Release: 11.10.0 (02/06/2014)
http://docs.opscode.com/release/11-10/release_notes.html
### Chef is proud of our community!
Every release of Chef we pick someone from the community to name as the Most Valuable Player for that release. It could be someone who provided a big feature, reported a security vulnerability, or someone doing great things in the community that we want to highlight.
#### Hall of Fame
After receiving three MVP awards, we add someone to the hall of fame. We want to express our gratitude to their continuing participation and give newer community members the opportunity to be reconignized.
* Matthew Kent
* Doug MacEachern
* Tollef Fog Heen
* Thom May
* Bryan Berry
* Bryan McLellan
#### The MVP recipients
| Release | Date | MVP |
|---------|------|-----|
| [Client 11.10.4](http://www.getchef.com/blog/2014/02/20/chef-client-patch-release-11-10-4/) | 2014-02-20 | Jon Cowie |
| [Client 11.10.2](http://www.getchef.com/blog/2014/02/18/chef-client-release-11-10-2-10-30-4/) | 2014-02-18 | Eric Tucker |
| [Client 11.10.0](http://www.getchef.com/blog/2014/02/06/chef-client-11-10-0-release/) | 2014-02-06 | Nikhil Benesch |
| [Client 11.8.2](http://www.getchef.com/blog/2013/12/06/release-chef-client-10-30-2-11-8-2-mixlib-shellout-1-3-0/) | 2013-12-06 | James Ogden |
| [Client 11.8.0](http://www.opscode.com/blog/2013/10/31/release-chef-client-11-8-0-ohai-6-20-0/) | 2013-10-31 | Eric Saxby |
| [Client 11.6.2](http://www.getchef.com/blog/2013/10/08/release-chef-client-11-6-2-10-28-2/) | 2013-10-08 | Jeff Blaine |
| [Client 11.6.0](http://www.opscode.com/blog/2013/07/23/chef-client-11-6-0-ohai-6-18-0-and-more/) | 2013-07-23 | Jesse Campbell |
| [Client 11.4.0](http://www.opscode.com/blog/2013/02/13/chef-client-11-4-0-10-22-0-released/) | 2013-02-13 | Vaidas Jablonskis |
| [Client 11.2.0](http://www.opscode.com/blog/2013/02/07/chef-client-11-2-0-10-20-0-released/) | 2013-02-06 | Mike Javorski |
| [Chef 11.0.0](http://www.opscode.com/blog/2013/02/04/chef-11-released/) | 2013-02-04 | Andrea Campi, Bryan Berry |
| [Chef 10.30.4](http://www.getchef.com/blog/2014/02/18/chef-client-release-11-10-2-10-30-4/) | 2014-02-18 | Christopher Laco |
| [Chef 10.30.2](http://www.getchef.com/blog/2013/12/06/release-chef-client-10-30-2-11-8-2-mixlib-shellout-1-3-0/) | 2013-12-06 | Phil Dibowitz |
| [Chef 10.28.2](http://www.getchef.com/blog/2013/10/08/release-chef-client-11-6-2-10-28-2/) | 2013-10-08 | Jeff Blaine |
| [Chef 10.28.0](http://www.opscode.com/blog/2013/09/03/chef-10-28-0-released/) | 2013-09-03 | Jeff Blaine |
| [Chef 10.26.0](http://www.opscode.com/blog/2013/05/08/chef-10-26-0-released/) | 2013-05-08 | Ranjib Dey |
| [Chef 10.24.0](http://www.opscode.com/blog/2013/02/15/chef-server-11-0-6-and-10-24-0-released/) | 2013-02-15 | Anthony Goddard |
| [Chef 10.22.0](http://www.opscode.com/blog/2013/02/13/chef-client-11-4-0-10-22-0-released/) | 2013-02-13 | Brian Bianco |
| [Chef 10.20.0](http://www.opscode.com/blog/2013/02/07/chef-client-11-2-0-10-20-0-released/) | 2013-02-06 | Chris Roberts |
| [Chef 10.18.2](http://www.opscode.com/blog/2013/01/18/chef-10-18-2-bugfix-release/) | 2013-01-18 | Fletcher Nichol |
| [Chef 10.18.0](http://www.opscode.com/blog/2013/01/16/chef-10-18-0-released/) | 2013-01-16 | Xabier de Zuazo |
| [Chef 10.16.6](http://www.opscode.com/blog/2013/01/11/chef-10-16-6-security-release/) | 2013-01-11 | Dan Kubb |
| [Chef 10.16.4](http://www.opscode.com/blog/2012/12/26/chef-10-16-4-released/) | 2012-12-26 | Avishai Ish-Shalom |
| [Chef 10.16.2](http://www.opscode.com/blog/2012/10/26/chef-10-16-2-released/) | 2012-10-26 | Jamie Winsor |
| [Chef 10.16.0](http://www.opscode.com/blog/2012/10/22/chef-10-16-0-released/) | 2012-10-22 | John Dewey |
| [Chef 10.14.4](http://www.opscode.com/blog/2012/09/28/chef-10-14-4-released/) | 2012-09-27 | Kendrick Martin |
| [Chef 10.14.2](http://www.opscode.com/blog/2012/09/11/chef-10-14-2-released/) | 2012-09-10 | Phil Dibowitz, Tim Smith |
| [Chef 10.14.0](http://www.opscode.com/blog/2012/09/07/chef-10-14-0-released/) | 2012-09-07 | Xabier de Zuazo |
| [Chef 10.12.0](http://www.opscode.com/blog/2012/06/19/chef-10-12-0-released/) | 2012-06-18 | Chris Roberts |
| [Chef 0.10.10](http://www.opscode.com/blog/2012/05/11/chef-0-10-10-released/) | 2012-05-11 | Juanje Ojeda, Igor Afonov |
| [Chef 0.10.8](http://www.opscode.com/blog/2011/12/15/chef-0-10-8-released/) | 2011-12-15 | Bryan Berry |
| [Chef 0.10.6](http://www.opscode.com/blog/2011/12/14/chef-0-10-6-released/) | 2011-12-13 | Andrea Campi |
| [Chef 0.10.4](http://www.opscode.com/blog/2011/08/11/chef-0-10-4-released/) | 2011-08-11 | Matthew Kent |
| [Chef 0.10.2](http://www.opscode.com/blog/2011/06/29/chef-0-10-2-and-0-9-18-released/) | 2011-06-29 | Daniel Oliver |
| [Chef 0.10.0](http://www.opscode.com/blog/2011/05/02/chef-0-10-0-released/) | 2011-05-02 | Grace Mollison, Darrin Eden |
| [Chef 0.9.18](http://www.opscode.com/blog/2011/06/29/chef-0-10-2-and-0-9-18-released/) | 2011-06-29 | Jesai Langenbach |
| [Chef 0.9.16](http://www.opscode.com/blog/2011/04/15/chef-0-9-16-released/) | 2011-04-15 | Michael Leinartas |
| [Chef 0.9.14](http://www.opscode.com/blog/2011/03/04/chef-0-9-14-released/) | 2011-03-04 | Gilles Devaux |
| [Chef 0.9.12](http://www.opscode.com/blog/2010/10/22/chef-0-9-12-released/) | 2010-10-22 | Laurent Désarmes |
| [Chef 0.9.10](http://www.opscode.com/blog/2010/10/19/chef-0-9-10-ohai-0-5-8-and-mixliblog-1-2-0-released/) | 2010-10-19 | Toomas Pelberg, Tommy Bishop |
| [Chef 0.9.8](http://www.opscode.com/blog/2010/08/05/chef-0-9-8-and-mixlib-authentication-1-1-4-released/) | 2010-08-05 | Joe Williams |
| [Chef 0.9.6](http://www.opscode.com/blog/2010/07/03/chef-0-9-6-released/) | 2010-07-03 | Caleb Tennis |
| [Chef 0.9.4](http://www.opscode.com/blog/2010/06/30/chef-0-9-4-released/) | 2010-06-30 | Ian Meyer |
| [Chef 0.9.0](http://www.opscode.com/blog/2010/06/21/chef-0-9-0-and-ohai-0-5-6-released/) | 2010-06-21 | Doug MacEachern |
| [Chef 0.8.16](http://www.opscode.com/blog/2010/05/11/chef-0-8-16-and-ohai-0-5-4-release/) | 2010-05-11 | Akzhan Abdulin |
| [Chef 0.8.14](http://www.opscode.com/blog/2010/05/07/chef-0-8-14-release/) | 2010-05-07 | Renaud Chaput |
| [Chef 0.8.10](http://www.opscode.com/blog/2010/04/02/chef-0-8-10-release/) | 2010-04-02 | Thom May, Tollef Fog Heen |
| [Chef 0.8.8](http://www.opscode.com/blog/2010/03/18/chef-0-8-8-release/) | 2010-03-18 | Eric Hankins |
| [Chef 0.8.6](http://www.opscode.com/blog/2010/03/05/chef-0-8-6-release/) | 2010-03-05 | Ian Meyer |
| [Chef 0.8.4](http://www.opscode.com/blog/2010/03/02/chef-0-8-4-release/) | 2010-03-02 | Tollef Fog Heen |
| [Chef 0.8.2](http://www.opscode.com/blog/2010/03/01/chef-0-8-2-release/) | 2010-03-01 | Scott M. Likens |
| [Chef 0.7.16](http://www.opscode.com/blog/2009/12/22/chef-0-7-16-release/) | 2009-12-22 | Bryan McLellan |
| [Chef 0.7.14](http://www.opscode.com/blog/2009/10/26/chef-0-7-14-ohai-0-3-6-releases/) | 2009-10-16 | Thom May |
| [Chef 0.7.12](http://www.opscode.com/blog/2009/10/06/chef-0-7-12rc0-ohai-0-3-4rc0-releases/) | 2009-10-06 | Diego Algorta |
| [Chef 0.7.10](http://www.opscode.com/blog/2009/09/04/chef-0-7-10-release/) | 2009-09-04 | Dan DeLeo |
| [Chef 0.7.8](http://www.opscode.com/blog/2009/08/13/chef-0-7-8-release/) | 2009-08-13 | Jeppe Nejsum Madsen |
| [Chef 0.7.6](http://www.opscode.com/blog/2009/08/08/chef-0-7-6-release/) | 2009-08-08 | Grant Zanetti |
| [Chef 0.7.4](http://www.opscode.com/blog/2009/06/26/back-to-back-chef-0-7-2-and-chef-0-7-4-released/) | 2009-06-26 | Hongli Lai |
| [Chef 0.7.2](http://www.opscode.com/blog/2009/06/26/back-to-back-chef-0-7-2-and-chef-0-7-4-released/) | 2009-06-26 | Joshua Sierles |
| [Chef 0.7.0](http://www.opscode.com/blog/2009/06/10/chef-0-7-0-release/) | 2009-06-10 | Matthew Kent |
| [Chef 0.6.2](http://www.opscode.com/blog/2009/04/29/chef-0-6-2-release/) | 2009-04-29 | David Balatero |
| [Chef 0.6.0](http://www.opscode.com/blog/2009/04/29/chef-0-6-0-release/) | 2009-04-29 | Matthew Kent |
| [Chef 0.5.6](http://www.opscode.com/blog/2009/03/06/chef-0-5-6/) | 2009-03-06 | Sean Cribbs |
| [Chef 0.5.4](http://www.opscode.com/blog/2009/02/13/chef-0-5-4/) | 2009-02-13 | Arjuna Christensen |
| [Chef 0.5.2](http://www.opscode.com/blog/2009/02/01/chef-0-5-2-and-ohai-0-1-4/) | 2009-02-01 | Bryan McLellan |
......@@ -24,7 +24,7 @@ Chef uses the Apache 2.0 license to strike a balance between open contribution a
The license tells you what rights you have that are provided by the copyright holder. It is important that the contributor fully understands what rights
they are licensing and agrees to them. Sometimes the copyright holder isn't the contributor, most often when the contributor is doing work for a company.
To make a good faith effort to ensure these criteria are met, Opscode requires a Contributor License Agreement (CLA) or a Corporate Contributor License
To make a good faith effort to ensure these criteria are met, Chef requires a Contributor License Agreement (CLA) or a Corporate Contributor License
Agreement (CCLA) for all contributions. This is without exception due to some matters not being related to copyright and to avoid having to continually
check with our lawyers about small patches.
......@@ -74,7 +74,7 @@ helpful to be clear about your use case and change so they can understand it eve
### Github and Pull Requests
All of Opscode's open source projects are available on [Github](http://www.github.com/opscode).
All of Chef's open source projects are available on [Github](http://www.github.com/opscode).
We don't require you to use Github, and we will even take patch diffs attached to tickets on the tracker.
However Github has a lot of convenient features, such as being able to see a diff of changes between a
......@@ -115,7 +115,7 @@ and accounting for it.
## Code Review
Opscode regularly reviews code contributions and provides suggestions for improvement in the code itself or the implementation.
Chef regularly reviews code contributions and provides suggestions for improvement in the code itself or the implementation.
We find contributions by searching the ticket tracker for _resolved_ tickets with a status of _fixed_. If we have feedback we will
reopen the ticket and you should resolve it again when you've made the changes or have a response to our feedback. When we believe
......@@ -134,14 +134,14 @@ The versioning for the Chef project is X.Y.Z.
* Y is a minor release, which adds both new features and bug fixes
* Z is a patch release, which adds just bug fixes
Major releases and have historically been once a year. Minor releases for Chef average every two months and patch releases come as needed.
Major releases have historically been once a year. Minor releases for Chef average every three months and patch releases come as needed.
There are usually beta releases and release candidates (RC) of major and minor releases announced on
the [chef-dev mailing list](http://lists.opscode.com/sympa/info/chef-dev). Once an RC is released, we wait at least three
days to allow for testing for regressions before the final release. If a blocking regression is found then another RC is made containing
the fix and the timer is reset.
Once the official release is made, the release notes are available on the [Opscode blog](http://www.opscode.com/blog).
Once the official release is made, the release notes are available on the [Chef blog](http://www.getchef.com/blog).
## Working with the community
......@@ -151,5 +151,5 @@ These resources will help you learn more about Chef and connect to other members
* #chef and #chef-hacking IRC channels on irc.freenode.net
* [Community Cookbook site](http://community.opscode.com)
* [Chef wiki](http://wiki.opscode.com/display/chef)
* Opscode Chef [product page](http://www.opscode.com/chef)
* Chef [product page](http://www.getchef.com/chef)
<!---
This file is reset every time a new release is done. The contents of this file are for the currently unreleased version.
Example Contribution:
* **kalistec**: Improved file resource greatly.
-->
# Chef Client Contributions:
* **jonlives**: Changed the order of recipe and cookbook name setting. Fixes CHEF-5052.
* **jaymzh**: Added support for `enable` and `disable` to MacOSX service provider.
* **bossmc**: Made formatters more resilient to nil exception messages.
* **valodzka**: Fixed the convergence message in deploy provider.
* **linkfanel**: Made attribute arrays able to handle non-dupable elements while being duped.
* **linkfanel**: Removed ruby-shadow installation on cygwin platform.
* **lbragstad**: Add IBM PowerKVM to platform map.
* **slantview**: Allow boolean and numerics in cookbook metadata.
* **jeffmendoza**: Made knife to use cloud attribute for port when available.
* **ryotarai**: Added a method to capture IO for live stream.
* **sawanoboly**: Fixed service provider to be aware of maintenance state on Solaris.
* **cbandy**: Refactored Chef::Util::FileEdit.
* **cbandy**: Fixed insert_line_if_no_match to run multiple times.
* **pavelbrylov**: Modified subversion resource to hide password from error messages.
* **eherot**: Add support for epoch versions to the dpkg package provider.
* **jdmurphy**: Display all missing dependencies when uploading cookbooks.
* **nkrinner**: Add a public file_edited? method to Chef::Util::FileEdit.
* **ccope**: Made package provider to use IPS provider in Solaris 5.11+
* **josephholsten**: Changed Chef::REST to be able to handle frozen options.
* **andreasrs**: Changed service provider to use Systemd on ArchLinux.
* **eherot**: Add support for epoch versions to the dpkg package provider.
* **jdmurphy**: Display all missing dependencies when uploading cookbooks.
* **nkrinner**: Add a public file_edited? method to Chef::Util::FileEdit.
* **jjasghar**: Output correct host name in knife ssh error message.
* **esigler**: Added default_choice option to Knife::UI#confirm.
* **DracoAter**: Add support to the Cron resource for special strings, e.g. @reboot.
* **ryotarai**: Add support to the Cron resource for weekday passed as a symbol.
* **thommay **: Made sure that `node.save` doesn't save the run_list when chef is running with override-run-list.
* **Maxime Caumartin**: Fix mount resource when device is a relative symlink.
* **jessehu**: Increase bootstrap log_level when knife -V -V is set
* **mveitas**: knife cookbook test honors chefignore
* **zuazo**: Fix ImmutableMash and ImmutableArray to_hash and to_a methods
<!---
This file is reset every time a new release is done. This file describes changes that have not yet been released.
Example Doc Change:
### Headline for the required change
Description of the required change.
-->
# Chef Client Doc Changes:
### --validator option for `knife client create`
Boolean value. If set to true, knife creates a validator client o.w. it creates a user client. Default is false.
### --delete-validators for `knife client delete`
Option that is required to be specified if user is attempting to delete a validator client. No effect while deleting a user client.
### --delete-validators for `knife client bulk delete`
Option that is required to be specified if user is attempting to delete a validator client. If not specified users cannot delete a client if it's validator client. If specified knife asks users for confirmation of deleting clients and validator clients seperately. Some examples for scripting:
To delete all non-validator clients:
`knife client bulk delete regexp --yes`
To delete all clients including validators:
`knife client bulk delete regexp --delete-validators --yes`
### -r / --runlist option for chef-client
Option similar to `-o` which sets or changes the run_list of a node permanently.
### knife bootstrap -V -V
Running ```knife bootstrap -V -V``` will run the initial chef-client with a log level of debug.
### knife cookbook test
```knife cookbook test``` respects chefignore files when selecting which files to test.
### OHAI 7 Upgrade
Unless there are major issues, 11.12.0 will include OHAI 7. We already have ohai 7 docs in place. We probably need to add some notes to ohai 6 notes that one should now use the newer version when possible.
### New knife command: `knife ssl check [URI]`
The `knife ssl check` command is used to check or troubleshoot SSL
configuration. When run without arguments, it tests whether chef/knife
can verify the Chef server's SSL certificate. Otherwise it connects to
the server specified by the given URL.
Examples:
* Check knife's configuration against the chef-server: `knife ssl check`
* Check chef-client's configuration: `knife ssl check -c /etc/chef/client.rb`
* Check whether an external server's SSL certificate can be verified:
`knife ssl check https://www.getchef.com`
### New knife command: `knife ssl fetch [URI]`
The `knife ssl fetch` command is used to copy certificates from an HTTPS
server to the `trusted_certs_dir` of knife or `chef-client`. If the
certificates match the hostname of the remote server, this command is
all that is required for knife or chef-client to verify the remote
server in the future. WARNING: `knife` has no way to determine whether
the certificates were tampered with in transit. If that happens,
knife/chef-client will trust potentially forged/malicious certificates
until they are deleted from the `trusted_certs_dir`. Users are *VERY STRONGLY*
encouraged to verify the authenticity of the certificates downloaded
with `knife fetch` by some trustworthy means.
Examples:
* Fetch the chef server's certificates for use with knife:
`knife ssl fetch`
* Fetch the chef server's certificates for use with chef-client:
`knife ssl fetch -c /etc/chef/client.rb`
* Fetch the certificates from an arbitrary server:
`knife ssl fetch https://www.getchef.com`
### OpenSUSE and SUSE differentiation
With the recent change in OHAI to differentiate between SUSE (or SLES - SUSE Enterprise Linux Server) and OpenSUSE we need to update our docs to reflect following (quoting btm):
* Platform SUSE should be changed to OpenSUSE everywhere that it previously meant OpenSUSE but said SUSE.
* Keeping SLES as platform SUSE is still a bit confusing, but that's the least horrible path we chose.
* It's all still very confusing. :)
This page is an example but we probably want to search for `suse` in our doc repo and see if there is anywhere else.
http://docs.opscode.com/dsl_recipe_method_platform_family.html
### Cron Resource
The weekday attribute now accepts the weekday as a symbol, e.g. :monday or :thursday.
The new time attribute takes special time values specified by cron as a symbol, such as :reboot or :monthly.
### SSL Verification Warnings
Chef 11.12 emits verbose warnings when configured to not verify SSL
certificates. Though not verifying certificates is currently the default
setting, this is unsecure and a future release of Chef will change the
default setting so that SSL certificates are verified.
Users are encouraged to resolve these warnings by adding the following
to their configuration files (client.rb or solo.rb):
`ssl_verify_mode :verify_peer`
This setting will check that the certificate presented by HTTPS servers
is signed by a trusted authority. By default, the on-premises Enterprise
Chef and Open Source Chef server use a self-signed certificate that
chef-client will not be able to verify, which will result in SSL errors
when connecting to the server. To check SSL connectivity with the
server, users can use the `knife ssl check` command. If the server is
configured to use an untrusted self-signed certificate, users can
configure chef-client to trust the remote server by copying the server's
certificate to the `trusted_certs_dir`. The `knife ssl fetch` command
can be used to automate this process; however, `knife` is not able to
determine whether certificates downloaded with `knife ssl fetch` have
been tampered with during the download, so users should verify the
authenticity of any certificates downloaded this way.
If a user absolutely cannot enable certificate verification and wishes
to suppress SSL warnings, they can use HTTP instead of HTTPS as a
workaround. This is highly discouraged. If some behavior of Chef
prevents a user from enabling SSL certificate verification, they are
encouraged to file a bug report.
### New Configuration Option: `local_key_generation`
Chef 11.x servers support client-side generation of keys when creating
new clients. Generating the keys on the client provides two benefits: 1)
the private key never travels over the network, which improves security;
2) the CPU load imposed by key creation is moved to the node and
distributed, which allows the server to handle more concurrent client
registrations.
For compatibility reasons, this feature is opt-in, but will likely be
the default or even only behavior in Chef 12.
To enable it, add this to client.rb before running chef-client on a node
for the first time:
```
local_key_generation true
```
The default value of this setting is `false`
*NOTE:* Chef servers that implement the 10.x API do not support this
feature. Enabling this on a client that connects to a 10.X API server
will cause client registration to silently fail. Don't do it.
### Windows Installer (MSI) Package Provider
The windows_package provider installs and removes Windows Installer (MSI) packages.
This provider utilizies the ProductCode extracted from the MSI package to determine
if the package is currently installed.
You may use the ```package``` resource to use this provider, and you must use the
```package``` resource if you are also using the windows cookbook, which contains
the windows_package LWRP.
#### Example
```
package "7zip" do
action :install
source 'C:\7z920.msi'
end
```
#### Actions
* :install
* :remove
#### Attributes
* source - The location of the package to install. Default value: the ```name``` of the resource.
* options - Additional options that are passed to msiexec.
* installer_type - The type of package being installed. Can be auto-detected. Currently only :msi is supported.
* timeout - The time in seconds allowed for the package to successfully be installed. Defaults to 600 seconds.
* returns - Return codes that signal a successful installation. Defaults to 0.
### New resource attribute: `guard_interpreter`
All resources have a new attribute, `guard_interpreter`, which specifies a
Chef script resource that should be used to evaluate a string command
passed to a guard. Any attributes of the evaluating resource may be specified in
the options that normally follow the guard's command string argument. For example:
# Tell Chef to use bash to interpret the guard string.
# Then we can use a guard command that is valid for bash
# but not for csh for instance
bash 'backupsettings' do
guard_interpreter :bash
code 'cp ~/appsettings.json ~/backup/appsettings.json'
not_if '[[ -e ./appsettings.json ]]', :cwd => '~/backup'
end
The argument for `guard_interpreter` may be set to any of the following values:
* The symbol name for a Chef Resource derived from the Chef `script` resource
such as `:bash`, `:powershell_script`, etc.
* The symbol `:default` which means that a resource is not used to evaluate
the guard command argument, it is simply executed by the default shell as in
previous releases of Chef.
By default, `guard_interpreter` is set to `:default` in this release.
#### Attribute inheritance with `guard_interpreter`
When `guard_interpreter` is not set to `:default`, the resource that evaluates the command will
also inherit certain attribute values from the resource that contains the
guard.
Inherited attributes for all `script` resources are:
* `:cwd`
* `:environment`
* `:group`
* `:path`
* `:user`
* `:umask`
For the `powershell_script` resource, the following attribute is inherited:
* `:architecture`
Inherited attributes may be overridden by specifying the same attribute as an
argument to the guard itself.
#### Guard inheritance example
In the following example, the `:environment` hash only needs to be set once
since the `bash` resource that execute the guard will inherit the same value:
script "javatooling" do
environment {"JAVA_HOME" => '/usr/lib/java/jdk1.7/home'}
code 'java-based-daemon-ctl.sh -start'
not_if 'java-based-daemon-ctl.sh -test-started' # No need to specify environment again
end
### New `powershell_script` resource attribute: `convert_boolean_return`
The `powershell_script` resource has a new attribute, `convert_boolean_return`
that causes the script interpreter to return 0 if the last line of the command
evaluted by PowerShell results in a boolean PowerShell data type that is true, or 1 if
it results in a boolean PowerShell data type that is false. For example, the
following two fragments will run successfully without error:
powershell_script 'false' do
code '$false'
end
powershell_script 'true' do
code '$true'
end
But when `convert_boolean_return` is set to `true`, the "true" case above will
still succeed, but the false case will raise an exception:
# Raises an exception
powershell_script 'false' do
convert_boolean_return true
code '$false'
end
When used at recipe scope, the default value of `convert_boolean_return` is
`false` in this release. However, if `guard_interpreter` is set to
`:powershell_script`, the guard expression will be evaluted with a
`powershell_script` resource that has the `convert_boolean_return` attribute
set to `true`.
#### Guard command example
The behavior of `convert_boolean_return` is similar to the "$?"
expression's value after use of the `test` command in Unix-flavored shells and
its translation to an exit code for the shell. Since this attribute is set to
`true` when `powershell_script` is used via the `guard_interpreter` to
evaluate the guard expression, the behavior of `powershell_script` is very
similar to guards executed with Unix shell interpreters as seen below:
bash 'make_safe_backup' do
code 'cp ~/data/nodes.json ~/data/nodes.bak'
not_if 'test -e ~/data/nodes.bak'
end
# convert_boolean_return is true by default in guards
powershell_script 'make_safe_backup' do
guard_interpreter :powershell_script
code 'cp ~/data/nodes.json ~/data/nodes.bak'
not_if 'test-path ~/data/nodes.bak'
end
......@@ -11,7 +11,7 @@ group(:development, :test) do
gem "simplecov"
gem 'rack', "~> 1.5.1"
gem 'ruby-shadow', :platforms => :ruby unless RUBY_PLATFORM.downcase.match(/(darwin|freebsd|aix)/)
gem 'ruby-shadow', :platforms => :ruby unless RUBY_PLATFORM.downcase.match(/(aix|cygwin)/)
end
# If you want to load debugging tools into the bundle exec sandbox,
......
......@@ -61,7 +61,7 @@ Then get the source and install it:
Before working on the code, if you plan to contribute your changes, you need to
read the
[Opscode Contributing document](http://docs.opscode.com/community_contributions.html).
[Chef Contributions document](http://docs.opscode.com/community_contributions.html).
You will also need to set up the repository with the appropriate branches. We
document the process on the
......
<!---
This file is reset every time a new release is done. The contents of this file are for the currently unreleased version.
Example Note:
## Example Heading
Details about the thing that changed that needs to get included in the Release Notes in markdown.
-->
# Chef Client Release Notes:
#### `knife ssl check` and `knife ssl fetch` Commands
As part of our process to transition to verifying SSL certificates by
default, we've added knife commands to help you test (and fix, if
needed) your SSL configuration.
`knife ssl check` makes an SSL connection to your Chef server or any
other HTTPS server and tells you if the server presents a valid
certificate. If the certificate is not valid, knife will give further
information about the cause and some instructions on how to remedy the
issue. For example, if your Chef server uses an untrusted self-signed
certificate:
```
ERROR: The SSL certificate of chefserver.test could not be
verified
Certificate issuer data:
/C=US/ST=WA/L=Seattle/O=YouCorp/OU=Operations/CN=chefserver.test/emailAddress=you@example.com
Configuration Info:
OpenSSL Configuration:
* Version: OpenSSL 1.0.1e 11 Feb 2013
* Certificate file: /usr/local/etc/openssl/cert.pem
* Certificate directory: /usr/local/etc/openssl/certs
Chef SSL Configuration:
* ssl_ca_path: nil
* ssl_ca_file: nil
* trusted_certs_dir: "/Users/ddeleo/.chef/trusted_certs"
TO FIX THIS ERROR:
If the server you are connecting to uses a self-signed certificate, you
must
configure chef to trust that server's certificate.
By default, the certificate is stored in the following location on the
host
where your chef-server runs:
/var/opt/chef-server/nginx/ca/SERVER_HOSTNAME.crt
Copy that file to you trusted_certs_dir (currently: /home/user/.chef/trusted_certs)
using SSH/SCP or some other secure method, then re-run this command to confirm
that the server's certificate is now trusted.
```
`knife ssl fetch` allows you to automatically fetch a server's
certificates to your trusted certs directory. This provides an easy way
to configure chef to trust your self-signed certificates. Note that
knife cannot verify that the certificates haven't been tampered with, so
you should verify their content after downloading.
#### Unsecure SSL Verification Mode Now Triggers a Warning
When `ssl_verify_mode` is set to `:verify_none`, Chef will print a
warning. Use `knife ssl check` to test SSL connectivity and then add
`ssl_verify_mode :verify_peer` to your configuration file to fix the
warning. Though `:verify_none` is currently the default, this will be
changed in a future release, so users are encouraged to be proactive in
testing and updating their SSL configuration.
#### Chef Solo Missing Dependency Warning ([CHEF-4367](https://tickets.opscode.com/browse/CHEF-4367))
Chef 11.0 introduced ordered evaluation of non-recipe files in
cookbooks, based on the dependencies specified in your cookbooks'
metadata. This was a huge improvement on the previous behavior for all
chef users, but it also introduced a problem for chef-solo users:
because of the way chef-solo works, it was possible to use
`include_recipe` to load a recipe from a cookbook without specifying the
dependency in the metadata. This would load the recipe without having
evaluated the associated attributes, libraries, LWRPs, etc. in that
recipe's cookbook, and the recipe would fail to load with errors that
did not suggest the actual cause of the failure.