Chef Client 12.1.0.rc.0 Released


#1

Happy Friday Chefs!

We’ve just released the first release candidate for Chef 12.1.0. A more
detailed blog post will be available with the final release, however for
now, some of the highlights from the release notes
https://github.com/chef/chef/blob/12.1.0.rc.0/RELEASE_NOTES.md are
included below.

  • Experimental Audit Mode
  • OpenBSD package provider has been added
  • Per RFC 027, the file and file-like resources now accept a verify
    attribute. This attribute accepts a string(shell command) or a ruby block
    (similar to only_if) which can be used to verify the contents of a
    rendered template before deploying it to disk.
  • Now that the default for SSL checking is on, no more warning is
    emitted when SSL checking is off.
  • The package provider has been extended to support multiple packages.
    This support is new and and not all subproviders yet support it. Full
    support for apt and yum has been implemented.
  • Compile time installation for chef_gem has been deprecated
  • knife bootstrap command now supports validatorless bootstraps

For more information on these changes, see the release notes
https://github.com/chef/chef/blob/12.1.0.rc.0/RELEASE_NOTES.md. For a
more complete list of changes, see the changelog
https://github.com/chef/chef/blob/12.1.0.rc.0/CHANGELOG.md.

We’d love to get your feedback on this RC. There are many ways to get it:

  • Install the latest release candidate

curl -L https://www.getchef.com/chef/install.sh | sudo bash -s – -p

  • Specify a specific release candidate

curl -L https://www.getchef.com/chef/install.sh | sudo bash -s – -v 12.1.0.rc.0

As always, if you run into any issues, please file it on Github
https://github.com/chef/chef/issues/new.

Thanks!


#2

Hey All,
It’s been brought to my attention that you can’t get the 12.1.0 release
candidate by using:

curl -L https://www.getchef.com/chef/install.sh | sudo bash -s – -p

Instead, please use:

curl -L https://www.getchef.com/chef/install.sh | sudo bash -s – -v 12.1.0.rc.0

Sorry for the confusion and have a delightful weekend!

Jay

On Fri, Feb 20, 2015 at 5:10 PM, Jay Mundrawala jdm@getchef.com wrote:

Happy Friday Chefs!

We’ve just released the first release candidate for Chef 12.1.0. A more
detailed blog post will be available with the final release, however for
now, some of the highlights from the release notes
https://github.com/chef/chef/blob/12.1.0.rc.0/RELEASE_NOTES.md are
included below.

  • Experimental Audit Mode
  • OpenBSD package provider has been added
  • Per RFC 027, the file and file-like resources now accept a verify
    attribute. This attribute accepts a string(shell command) or a ruby block
    (similar to only_if) which can be used to verify the contents of a
    rendered template before deploying it to disk.
  • Now that the default for SSL checking is on, no more warning is
    emitted when SSL checking is off.
  • The package provider has been extended to support multiple packages.
    This support is new and and not all subproviders yet support it. Full
    support for apt and yum has been implemented.
  • Compile time installation for chef_gem has been deprecated
  • knife bootstrap command now supports validatorless bootstraps

For more information on these changes, see the release notes
https://github.com/chef/chef/blob/12.1.0.rc.0/RELEASE_NOTES.md. For a
more complete list of changes, see the changelog
https://github.com/chef/chef/blob/12.1.0.rc.0/CHANGELOG.md.

We’d love to get your feedback on this RC. There are many ways to get it:

  • Install the latest release candidate

curl -L https://www.getchef.com/chef/install.sh | sudo bash -s – -p

  • Specify a specific release candidate

curl -L https://www.getchef.com/chef/install.sh | sudo bash -s – -v 12.1.0.rc.0

As always, if you run into any issues, please file it on Github
https://github.com/chef/chef/issues/new.

Thanks!


#3

Hey,

What’s the idea behind “Experimental Audit Mode”? It seems like all that
info should be provided by monitoring system. Should it supplement current
monitoring or replace it? Any examples?

On Fri, Feb 20, 2015 at 9:46 PM, Jay Mundrawala jdm@getchef.com wrote:

Hey All,
It’s been brought to my attention that you can’t get the 12.1.0 release
candidate by using:

curl -L https://www.getchef.com/chef/install.sh | sudo bash -s – -p

Instead, please use:

curl -L https://www.getchef.com/chef/install.sh | sudo bash -s – -v 12.1.0.rc.0

Sorry for the confusion and have a delightful weekend!

Jay

On Fri, Feb 20, 2015 at 5:10 PM, Jay Mundrawala jdm@getchef.com wrote:

Happy Friday Chefs!

We’ve just released the first release candidate for Chef 12.1.0. A more
detailed blog post will be available with the final release, however for
now, some of the highlights from the release notes
https://github.com/chef/chef/blob/12.1.0.rc.0/RELEASE_NOTES.md are
included below.

  • Experimental Audit Mode
  • OpenBSD package provider has been added
  • Per RFC 027, the file and file-like resources now accept a verify
    attribute. This attribute accepts a string(shell command) or a ruby block
    (similar to only_if) which can be used to verify the contents of a
    rendered template before deploying it to disk.
  • Now that the default for SSL checking is on, no more warning is
    emitted when SSL checking is off.
  • The package provider has been extended to support multiple
    packages. This support is new and and not all subproviders yet support it.
    Full support for apt and yum has been implemented.
  • Compile time installation for chef_gem has been deprecated
  • knife bootstrap command now supports validatorless bootstraps

For more information on these changes, see the release notes
https://github.com/chef/chef/blob/12.1.0.rc.0/RELEASE_NOTES.md. For a
more complete list of changes, see the changelog
https://github.com/chef/chef/blob/12.1.0.rc.0/CHANGELOG.md.

We’d love to get your feedback on this RC. There are many ways to get it:

  • Install the latest release candidate

curl -L https://www.getchef.com/chef/install.sh | sudo bash -s – -p

  • Specify a specific release candidate

curl -L https://www.getchef.com/chef/install.sh | sudo bash -s – -v 12.1.0.rc.0

As always, if you run into any issues, please file it on Github
https://github.com/chef/chef/issues/new.

Thanks!


Best regards,
Koldaev Anton


#4

On Tue, Feb 24, 2015 at 7:49 PM, Anton Koldaev koldaevav@gmail.com wrote:

What’s the idea behind “Experimental Audit Mode”? It seems like all that
info should be provided by monitoring system. Should it supplement current
monitoring or replace it? Any examples?

Sure, I can speak to this. Also some reading of Chef RFC 35 should
shed much light:

The short answer: audit mode == invoke ServerSpec at the end of your
Chef run, but specs sit right inside recipes as part of the DSL using
this control_group/control syntax.

Long answer and justification:

  1. Many folks have brownfield infrastructures, and as these folks get
    started w/ Chef, they are often too afraid to go right to the
    "remediation" (declaring Chef resources in recipes and running them).
    Instead, they’d much rather write a set of expectations around their
    current brownfield, then go off and write recipes that can conform to
    those expectations in a test environment, and then come back to apply
    the recipes to the brownfield.
  2. We heard a lot of people say they loved how minitest-handler works;
    it can, on a live system, assure you that nothing is broken.
    Unfortunately, minitest-handler has a couple of problems, chief among
    them that it’s not true “black box” acceptance testing (because you
    can make assertions about node attributes and whatnot rather than
    inspecting the system state).

There is also a compliance use case here. Chef only runs resources
that you declare. It doesn’t know or do anything about things of
interest that you didn’t declare, so this is a way of having a system
state as a whole accounted for. You could imagine a security team
writing controls that they care about, and the sysadmins writing the
recipes containing resources.

I hope that helps. BTW, the for-pay Chef Analytics product will let
you write rules based on these control failures and do things with
those events (send them by email, webhook, chat, whatnot).

  • Julian

#5

Thanks Julian

On Tue, Feb 24, 2015 at 10:17 PM, Julian C. Dunn jdunn@aquezada.com wrote:

On Tue, Feb 24, 2015 at 7:49 PM, Anton Koldaev koldaevav@gmail.com
wrote:

What’s the idea behind “Experimental Audit Mode”? It seems like all that
info should be provided by monitoring system. Should it supplement
current
monitoring or replace it? Any examples?

Sure, I can speak to this. Also some reading of Chef RFC 35 should
shed much light:
https://github.com/chef/chef-rfc/blob/master/rfc035-audit-mode.md

The short answer: audit mode == invoke ServerSpec at the end of your
Chef run, but specs sit right inside recipes as part of the DSL using
this control_group/control syntax.

Long answer and justification:

  1. Many folks have brownfield infrastructures, and as these folks get
    started w/ Chef, they are often too afraid to go right to the
    "remediation" (declaring Chef resources in recipes and running them).
    Instead, they’d much rather write a set of expectations around their
    current brownfield, then go off and write recipes that can conform to
    those expectations in a test environment, and then come back to apply
    the recipes to the brownfield.
  2. We heard a lot of people say they loved how minitest-handler works;
    it can, on a live system, assure you that nothing is broken.
    Unfortunately, minitest-handler has a couple of problems, chief among
    them that it’s not true “black box” acceptance testing (because you
    can make assertions about node attributes and whatnot rather than
    inspecting the system state).

There is also a compliance use case here. Chef only runs resources
that you declare. It doesn’t know or do anything about things of
interest that you didn’t declare, so this is a way of having a system
state as a whole accounted for. You could imagine a security team
writing controls that they care about, and the sysadmins writing the
recipes containing resources.

I hope that helps. BTW, the for-pay Chef Analytics product will let
you write rules based on these control failures and do things with
those events (send them by email, webhook, chat, whatnot).

  • Julian


Best regards,
Koldaev Anton