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
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
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:
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
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:
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.
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).
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?
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:
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.
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).