sous-chefs-boneyard/sysctl

Development repository for the sysctl cookbook

sysctl's Issues

Integer values are rendered as floats

I've noticed that when I have

"file-max": "5000000"

in node attributes, it is rendered as 300000.0 and ignored by sysctl.

Changing it to

"file-max": "5000000"

makes things work as expected. Needless to say, this is confusing and violates the principle of least surprise ;)

v1.0.0: Params that have not been changed do not get written out to disk

Prior to version 1.0.0 of the sysctl cookbook, when setting a sysctl param with the sysctl_param resource, the current value was verified against both sysctl -n and the contents of /etc/sysctl.d. However, with 1.0.0, the check against /etc/sysctl.d was dropped and the current value is only verified with sysctl -n. This means that sysctl params that are "accidentally" correct (including params that haven't changed from their default values) will not get persisted.

To give an example: if I the default value of the sysctl param "foo" is "0", then I set foo to "1" using sysctl foo=1, and then I run a cookbook that contains the resource sysctl_param('foo') { value(1) }, then the sysctl_param resources assumes that the foo param has not changed, no file /etc/sysctl.d/99-chef-foo will get written out, so the next time the system reboots, foo will reset to its default value of "0".

As a user of the sysctl cookbook, I expect the sysctl_param resource to guarantee that the value given for the param is persisted, so that the system will always boot up with the correct value applied for the given sysctl param.

Sysctl cookbook fails on Amazon Linux

Cookbook version

0.10.0

Chef-client version

12.21.3

Platform Details

Amazon Linux 2017.03 on Amazon us-east-1

Scenario:

I was looking to apply sysctl parameters via attributes fs.suid_dumpable

Steps to Reproduce:

I upgraded the cookbook from 0.9.0 to 0.10.0

Expected Result:

I was expecting the sysctl parameters to be applied

Actual Result:

Recipe: sysctl::default

• sysctl_param[fs.suid_dumpable] action apply

    Error executing action `apply` on resource 'sysctl_param[fs.suid_dumpable]'
    ================================================================================

    RuntimeError
    ------------
    Unknown sysctl file location. Unsupported platform.

    Cookbook Trace:
    ---------------
    /var/chef/cache/cookbooks/sysctl/libraries/helpers_param.rb:32:in `config_sysctl'
    /var/chef/cache/cookbooks/sysctl/libraries/sysctl_param.rb:57:in `block in create_sysctld'
    /var/chef/cache/cookbooks/sysctl/libraries/sysctl_param.rb:56:in `create_sysctld'
    /var/chef/cache/cookbooks/sysctl/libraries/sysctl_param.rb:67:in `block (2 levels) in <class:SysctlParam>'
    /var/chef/cache/cookbooks/sysctl/libraries/sysctl_param.rb:64:in `block in <class:SysctlParam>'

    Resource Declaration:
    ---------------------
    # In /var/chef/cache/cookbooks/sysctl/recipes/default.rb

     26:   sysctl_param k do
     27:     value v
     28:   end
     29: end if node.attribute?('sysctl') && node['sysctl'].attribute?('params')

    Compiled Resource:
    ------------------
    # Declared in /var/chef/cache/cookbooks/sysctl/recipes/default.rb:26:in `block in from_file'

    sysctl_param("fs.suid_dumpable") do
      action [:apply]
      retries 0
      retry_delay 2
      default_guard_interpreter :default
      declared_type :sysctl_param
      cookbook_name "sysctl"
      recipe_name "default"
      value "0"
      key "fs.suid_dumpable"
    end

    System Info:
    ------------
    chef_version=12.21.3
    platform=amazon
    platform_version=2017.03
    ruby=ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-linux]
    program_name=chef-client worker: ppid=30745;start=14:14:50;
    executable=/opt/chef/bin/chef-client

sysctl::default should be in run_list when using resource[sysctl_param]

In #9 you asked about cases, where I don't care about persist sysctl params. So, what about nodes without persistent store? For example, nodes with boot over PXE.

Also, i wanna use only resource, but i should add sysctl::default in run list, or use include_recipe.

Maybe resource should invoke recipe[default] by itself in a code?

ruby_block[save-sysctl-params] not found

As of 0.7.4 the following message now occurs when using the cookbook:

resource execute[sysctl[net.core.somaxconn]] is configured to notify resource ruby_block[save-sysctl-params] with action run, but ruby_block[save-sysctl-params] cannot be found in the resource collection. execute[sysctl[net.core.somaxconn]] is defined in /tmp/kitchen/cookbooks/sysctl/providers/param.rb:23:inblock in class_from_file'
`

cookbook dependancies in the metadata

cookbook dependencies should specify minimum version instead of approximate version(>= instead of ~>). This allows dependencies to be upgraded to latest version, with bug fixes and enhancements, even if major version changes without update of this cookbook. If breaking change is found then pinning to specifc version makes more sense and should be noted in changelog and or readme.

sysctl matcher: undefined method `define_matcher' for ChefSpec:Module

Greetings.

What is the significance/purpose of https://github.com/svanzoest-cookbooks/sysctl/blob/master/libraries/matchers.rb#L6 ? I have looked at several other cookbook community cookbook matchers and they do not have this line. Looking at the Chefspec docs, the example for packaged matchers does not have a line like that either.

The reason I am inquiring about this line is that with the existence of that line, I get the following error with my spec that tests the sysctl lwrp.

     NoMethodError:
       undefined method `define_matcher' for ChefSpec:Module

Take that line away and everything is golden.

Using sysctl cookbook v0.6.2
Using chefspec v4.0.1

Thanks,

Matt

Undefined method `new_resource` for Custom resource sysctl_param from cookbook sysctl

Cookbook version

1.0.1

Chef-client version

12.6.0

Platform Details

Ubuntu 14.04

Scenario:

Disable swapiness

Steps to Reproduce:

Set the following inside a recipe:
sysctl_param 'vm.swappiness' do
value 0
end

Expected Result:

Swapiness set to 0, no errors

Actual Result:

       ================================================================================
       Error executing action `apply` on resource 'sysctl_param[vm.swappiness]'
       ================================================================================
       
       NoMethodError
       -------------
       undefined method `new_resource' for Custom resource sysctl_param from cookbook sysctl
       
       Cookbook Trace:
       ---------------
       /tmp/kitchen/cache/cookbooks/sysctl/libraries/helpers.rb:5:in `set_sysctl_param'
       /tmp/kitchen/cache/cookbooks/sysctl/resources/param.rb:56:in `block (2 levels) in class_from_file'
       /tmp/kitchen/cache/cookbooks/sysctl/resources/param.rb:46:in `block in class_from_file'
       /tmp/kitchen/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:78:in `run_action'
       /tmp/kitchen/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:106:in `block (2 levels) in converge'
       /tmp/kitchen/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:106:in `each'
       /tmp/kitchen/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:106:in `block in converge'
       /tmp/kitchen/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:105:in `converge'
       
       Resource Declaration:
       ---------------------
       # In /tmp/kitchen/cache/cookbooks/verifi_mysql/recipes/files.rb
       
        58: sysctl_param 'vm.swappiness' do
        59:   value 20
        60: end
       
       Compiled Resource:
       ------------------
       # Declared in /tmp/kitchen/cache/cookbooks/verifi_mysql/recipes/files.rb:58:in `from_file'
       
       sysctl_param("vm.swappiness") do
         action [:apply]
         retries 0
         retry_delay 2
         default_guard_interpreter :default
         declared_type :sysctl_param
         cookbook_name "verifi_mysql"
         recipe_name "files"
         value "20"
         key "vm.swappiness"
         conf_dir "/etc/sysctl.d"
       end

Option to immediately persist to file

We're currently facing an issue where we update the value of net.core.somaxconn and then try to run an application (3rd party) that checks that value is greater than 1024.

Because the values aren't persisted until the end of the chef run, the application sees the old value as it starts up and errors out and causes the entire chef run to fail.

sysctl_param('net.core.somaxconn') do
  value 4096
end

Chef::Log.warn `sysctl net.core.somaxconn` #=>  default system value

I suggest having the values persisted in two cases;

1. When all values set via the params attribute have been updated
2. During an LWRP call when a new resource variable is set immediate true for example

chef 10 NameError: Cannot find a resource for action_run

It fails when trying to use sysctl cookbook.

[Wed, 16 Jul 2014 13:14:29 +0200] INFO: Processing template[/etc/rc.d/init.d/procps] action create (sysctl::service line 20)
[Wed, 16 Jul 2014 13:14:29 +0200] INFO: Processing service[procps] action enable (sysctl::service line 26)
[Wed, 16 Jul 2014 13:14:29 +0200] INFO: Processing directory[/etc/sysctl.d] action create (sysctl::default line 25)
[Wed, 16 Jul 2014 13:14:29 +0200] INFO: Processing ruby_block[save-sysctl-params] action nothing (sysctl::default line 35)
[Wed, 16 Jul 2014 13:14:29 +0200] INFO: Processing ruby_block[apply-sysctl-params] action nothing (sysctl::default line 43)
[Wed, 16 Jul 2014 13:14:29 +0200] INFO: Processing template[/etc/sysctl.d/99-chef-attributes.conf] action nothing (sysctl::default line 53)
[Wed, 16 Jul 2014 13:14:29 +0200] INFO: Processing ruby_block[notify-apply-sysctl-params] action create (sysctl::apply line 22)
[Wed, 16 Jul 2014 13:14:29 +0200] INFO: ruby_block[notify-apply-sysctl-params] called
[Wed, 16 Jul 2014 13:14:29 +0200] INFO: ruby_block[notify-apply-sysctl-params] sending run action to ruby_block[apply-sysctl-params] (immediate)
[Wed, 16 Jul 2014 13:14:29 +0200] INFO: Processing ruby_block[apply-sysctl-params] action run (sysctl::default line 43)

================================================================================
Error executing action `run` on resource 'ruby_block[apply-sysctl-params]'
================================================================================


NameError
---------
Cannot find a resource for action_run on ubuntu version 12.04


Resource Declaration:
---------------------
# In /var/cache/chef/cookbooks/sysctl/recipes/default.rb

 43:   ruby_block 'apply-sysctl-params' do
 44:     action :nothing
 45:     block do
 46:     end
 47:     notifies :create, "template[#{Sysctl.config_file(node)}]", :immediately
 48:   end
 49:



Compiled Resource:
------------------
# Declared in /var/cache/chef/cookbooks/sysctl/recipes/default.rb:43:in `from_file'

ruby_block("apply-sysctl-params") do
  block #<Proc:0x0000000000000000@/var/cache/chef/cookbooks/sysctl/recipes/default.rb:45>
  cookbook_name "sysctl"
  block_name "apply-sysctl-params"
  action [:nothing]
  retry_delay 2
  recipe_name "default"
  retries 0
end



[Wed, 16 Jul 2014 13:14:29 +0200] ERROR: Running exception handlers
[Wed, 16 Jul 2014 13:14:33 +0200] FATAL: Saving node information to /var/cache/chef/failed-run-data.json
[Wed, 16 Jul 2014 13:14:33 +0200] ERROR: Exception handlers complete
[Wed, 16 Jul 2014 13:14:33 +0200] FATAL: Stacktrace dumped to /var/cache/chef/chef-stacktrace.out
[Wed, 16 Jul 2014 13:14:33 +0200] FATAL: NameError: ruby_block[apply-sysctl-params] (sysctl::default line 43) had an error: NameError: Cannot find a resource for action_run on ubuntu version 12.04

Attempt to apply a sysctl attribute that does not exist on the system returns an error. Used to not.

Cookbook version

0.10.1

Chef-client version

12.21.4

Platform Details

CentOS 6 in AWS

Scenario:

Attempting to apply a sysctl attribute that does not exist on the system and hitting an error

Steps to Reproduce:

Add a sysctl attibute ` 'sysctl' : { 'params' : { 'random.attribute=1' }}

Expected Result:

If attribute does not exist within sysctl, do not attempt to apply it or attempt to apply it without erring out (send a warning to the logs)

Actual Result:

In my case...

* sysctl_param[net.ipv6.conf.all.accept_ra] action apply

    ================================================================================
    Error executing action `apply` on resource 'sysctl_param[net.ipv6.conf.all.accept_ra]'
    ================================================================================

    Mixlib::ShellOut::ShellCommandFailed
    ------------------------------------
    Expected process to exit with [0], but received '255'
    ---- Begin output of sysctl -w "net.ipv6.conf.all.accept_ra=0" ----
    STDOUT:
    STDERR: error: "net.ipv6.conf.all.accept_ra" is an unknown key
    ---- End output of sysctl -w "net.ipv6.conf.all.accept_ra=0" ----
    Ran sysctl -w "net.ipv6.conf.all.accept_ra=0" returned 255

    Cookbook Trace:
    ---------------
    /var/chef/cache/cookbooks/sysctl/libraries/helpers_param.rb:62:in `set_sysctl_param'
    /var/chef/cache/cookbooks/sysctl/libraries/sysctl_param.rb:68:in `block (2 levels) in <class:SysctlParam>'
    /var/chef/cache/cookbooks/sysctl/libraries/sysctl_param.rb:64:in `block in <class:SysctlParam>'

    Resource Declaration:
    ---------------------
    # In /var/chef/cache/cookbooks/sysctl/recipes/default.rb

     26:   sysctl_param k do
     27:     value v
     28:   end
     29: end if node.attribute?('sysctl') && node['sysctl'].attribute?('params')

    Compiled Resource:
    ------------------
    # Declared in /var/chef/cache/cookbooks/sysctl/recipes/default.rb:26:in `block in from_file'

    sysctl_param("net.ipv6.conf.all.accept_ra") do
      action [:apply]
      retries 0
      retry_delay 2
      default_guard_interpreter :default
      declared_type :sysctl_param
      cookbook_name "sysctl"
      recipe_name "default"
      value "0"
      key "net.ipv6.conf.all.accept_ra"
    end

    System Info:
    ------------
    chef_version=12.21.4
    platform=centos
    platform_version=6.9
    ruby=ruby 2.3.4p301 (2017-03-30 revision 58214) [x86_64-linux]
    program_name=chef-client worker: ppid=4884;start=16:23:13;
    executable=/opt/chef/bin/chef-client


Running handlers:
  - SyslogReporting
  - Chef::Handler::JsonFile
Running handlers complete

I recognize that net.ipv6.conf.all.accept_ra is valid, but I do not have it on my system and the attribute is coming in from an upstream cookbook that I am unable to remove via env/role attributes. Using version 0.9.0 of this cookbook seems to work fine in this regard.

Feature Request: Specify conf file

Was thinking that it would be nice to be able to specify the conf file name to be used, that way you can leverage multiple files say if you wanted to separate your hardening parameters vs your application tuning parameters. I will try to submit a pull request for this feature if I have time, but if someone gets to it first, be my guest.

procps doesn't work with CentOS 5

The apply_sysctl function isn't defined in /etc/rc.d/init.d/functions for CentOS 5

remove_sysctl_param fails with ImmutableAttributeModification error

Cookbook version

0.8.1

Chef-client version

Chef: 12.15.19

Platform Details

RHEL 6.2 and RHEL 7.2

Scenario:

Attempting to remove sysctl.conf settings.

Steps to Reproduce:

Try and remove any of the settings from the sysctl conf.

For example,

sysctl_param("remove_net.bridge.bridge-nf-call-ip6tables") do
  action [:remove]
  retries 0
  retry_delay 2
  default_guard_interpreter :default
  declared_type :sysctl_param
  cookbook_name "my_sysctl"
  recipe_name "default"
  key "net.bridge.bridge-nf-call-ip6tables"
end

Expected Result:

Successful chef-client and test-kitchen run with success output:
* sysctl_param[remove_net.bridge.bridge-nf-call-ip6tables] action remove

Actual Result:

chef-client and test-kitchen are both failing with following error.

ERROR: sysctl_param[remove_net.bridge.bridge-nf-call-ip6tables] (my_sysctl::default line 47) had an error: Chef::Exceptions::ImmutableAttributeModification: Node attributes are read-only when you do not specify which precedence level to set. To set an attribute use code like 'node.default["key"] = "value"'

Proposed Solution:

The following line in provider param.rb, should be updated to use sys_attrs and not node['sysctl']['params]. https://github.com/sous-chefs/sysctl/blob/v0.8.1/providers/param.rb#L40

Feature: Ignore errors when keys do not exist on system.

Cookbook version

1.0.0

Chef-client version

14.0.59

Platform Details

Amazon Linux 2017.09

Scenario:

Feature request for a way to define in the resource to ignore errors when a given key does not exist on a platform, this will make wrapper cookbooks easier to implement as there won't be a need to introduce complex guards in each resource.

Steps to Reproduce:

Declare a sysctl paramter that does not exist on the system. For example net.ipv4.tcp_syncookies. See travis output at https://travis-ci.org/sous-chefs/sysctl/jobs/342817880

Expected Result:

Previous versions of the cookbook would silently fail if the key does not exist on a target system.

Actual Result:

The cookbook throws an exception because the sysctl -p command returns an error 255. Full details below

Mixlib::ShellOut::ShellCommandFailed
------------------------------------
execute[sysctl -p] (/opt/kitchen/cache/cookbooks/sysctl/resources/param.rb line 62) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '255'

Support for amazon platform.

Cookbook version

0.9.0

Chef-client version

13.0.118

Platform Details

platform=amazon
platform_version=2017.03
ruby=ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-linux]

Scenario:

Trying to run a recipe that contains

include_recipe 'sysctl::default'
in order to use sysctl_param resource

Steps to Reproduce:

Run a recipe that includes sysctl cookbook on the amazon platform

Expected Result:

Expecting a successful converge.

Actual Result:

`
Recipe: sysctl::service
* template[/etc/rc.d/init.d/procps] action create (skipped due to only_if)
* service[procps] action enable
* service[procps]: Service is not known to chkconfig.
================================================================================
Error executing action 'enable' on resource 'service[procps]'
================================================================================

       Chef::Exceptions::Service
       -------------------------
       service[procps]: Service is not known to chkconfig.

       Resource Declaration:
       ---------------------
       # In /tmp/kitchen/cache/cookbooks/sysctl/recipes/service.rb

        26: service 'procps' do
        27:   supports :restart => true, :reload => true, :status => false
        28:   action :enable
        29: end

       Compiled Resource:
       ------------------
       # Declared in /tmp/kitchen/cache/cookbooks/sysctl/recipes/service.rb:26:in 'from_file'

       service("procps") do
         action [:enable]
         default_guard_interpreter :default
         service_name "procps"
         enabled nil
         running nil
         masked nil
         pattern "procps"
         declared_type :service
         cookbook_name "sysctl"
         recipe_name "service"
         supports {:restart=>true, :reload=>true, :status=>false}
       end

`

only_if guard for sysctl conf dir doesn't properly handle nil value

In the following resource declaration:

directory node['sysctl']['conf_dir'] do
  owner 'root'
  group 'root'
  mode 0755
  action :create
  only_if { node['sysctl']['conf_dir'] }
end

the only_if is supposed to guard against node['sysctl']['conf_dir'] evaluating to nil. This may be the case if the node's platform_family isn't set to one of a few values:

if platform_family?('arch', 'debian', 'rhel', 'fedora')
  default['sysctl']['conf_dir'] = '/etc/sysctl.d'
  default['sysctl']['conf_file'] = File.join(node['sysctl']['conf_dir'], '/99-chef-attributes.conf')
else
  default['sysctl']['conf_dir'] = nil
end

However, if during converge, the platform_family? check falls through to the else clase and node['sysctl']['conf_dir'] is set to nil, the following error occurs (example is from a ChefSpec converge):

     ArgumentError:
       You must supply a name when declaring a directory resource
     # /tmp/d20160209-10997-q2x337/cookbooks/sysctl/recipes/default.rb:24:in `from_file'

Recently (presumably due to Foodcritic complaining), the old-style guard clause was removed. It looked like this:

if node['sysctl']['conf_dir']
  directory node['sysctl']['conf_dir'] do
    owner 'root'
    group 'root'
    mode 0755
    action :create
  end
end

The old-style guard clause works and does not result in an error if node['sysctl']['conf_dir'] is nil.

I suggest restoring the old-style guard clause and telling Foodcritic to ignore/whitelist this guard clause.

Support to Ubuntu 16.06

This cookbook then support to ubuntu 16.04?
In my test falied when I include in my cookbook.

Provider for procps should be systemd for Ubuntu >= 15.04

Currently Upstart is chosen for Ubuntu >= 9.10, this will fail for Vivid.

Config managed by attribute won't restart procps if value is modified with sysctl -w manually

Cookbook version

latest

Chef-client version

12.5+

Platform Details

centos

Scenario:

say I have node['sysctl']['params']['vm']['swappiness'] = 20
and someone on the host changes it sysctl -w vm.swappiness=19 (but sysctl.conf and 99-chef-attributes.conf) is not altered
in case of lwrp sysctl_param 'vm.swappines' it works fine because it runs systl -w everytime https://github.com/sous-chefs/sysctl/blob/master/providers/param.rb#L22

Steps to Reproduce:

see above

Expected Result:

sysctl value should be set to what is mentioned in node attribute

Actual Result:

nothing happens, just skips thinking its already upto date.

Missing cleanup of old configuration files

Cookbook version

0.10.0

Scenario:

There was a refactoring in 0.10.0. After this refactoring sysctl cookbook starts to store the sysctl flags to the dedicated files instead of managing a big file.
In the same time there is no cleanup of sysctl files created before. E.g. on RHEL systems you would still have the `99-chef-attributes.conf' together with new files. This can lead to unpredicted results, as the old files are not removed and are not managed anymore.

It would be nice to have a cleanup code in default.rb, which would remove the old files.

Ubuntu 16.04 Support

I'm currently in the process of upgrading my Ubuntu servers to the latest LTS version. For some reason this recipe keeps trying to compile using Upstart instead of Systemd? Platform version is 16.04 on the remote server. Here's the chef-solo output;

================================================================================
    Error executing action `enable` on resource 'service[procps]'
    ================================================================================

    Errno::ENOENT
    -------------
    No such file or directory - /sbin/status

    Resource Declaration:
    ---------------------
    # In /home/robot/chef-solo/cookbooks-2/sysctl/recipes/service.rb

     26: service 'procps' do
     27:   supports :restart => true, :reload => true, :status => false
     28:   case node['platform']
     29:   when 'freebsd'
     30:     service_name 'sysctl'
     31:   when 'arch', 'exherbo'
     32:     service_name 'systemd-sysctl'
     33:     provider Chef::Provider::Service::Systemd
     34:   when 'ubuntu'
     35:     if node['platform_version'].to_f >= 9.10
     36:       provider Chef::Provider::Service::Upstart
     37:     end
     38:   end

    Compiled Resource:
    ------------------
    # Declared in /home/robot/chef-solo/cookbooks-2/sysctl/recipes/service.rb:26:in `from_file'

    service("procps") do
      provider Chef::Provider::Service::Upstart
      action [:enable]
      supports {:restart=>true, :reload=>true, :status=>false}
      retries 0
      retry_delay 2
      default_guard_interpreter :default
      service_name "procps"
      pattern "procps"
      declared_type :service
      cookbook_name :sysctl
      recipe_name "service"
    end

/etc/init.d/procps: line 22: apply_sysctl: command not found

On a RHEL 6.1 test node (Test Kitchen), I get the following error:

 Recipe: sysctl::service


           ================================================================================
           Error executing action `restart` on resource 'service[procps]'
           ================================================================================

           Mixlib::ShellOut::ShellCommandFailed
           ------------------------------------
           Expected process to exit with [0], but received '127'
           ---- Begin output of /sbin/service procps restart ----
           STDOUT: 
           STDERR: /etc/init.d/procps: line 22: apply_sysctl: command not found
           ---- End output of /sbin/service procps restart ----
           Ran /sbin/service procps restart returned 127

           Resource Declaration:
           ---------------------
           # In /tmp/kitchen/cache/cookbooks/sysctl/recipes/service.rb

            26: service 'procps' do
            27:   supports :restart => true, :reload => true, :status => false
            28:   case node['platform']
            29:   when 'freebsd'
            30:     service_name 'sysctl'
            31:   when 'arch', 'exherbo'
            32:     service_name 'systemd-sysctl'
            33:     provider Chef::Provider::Service::Systemd
            34:   when 'centos', 'redhat', 'scientific'
            35:     if node['platform_version'].to_f >= 7.0
            36:       service_name 'systemd-sysctl'
            37:       provider Chef::Provider::Service::Systemd
            38:     end
            39:   when 'fedora'

           Compiled Resource:
           ------------------
           # Declared in /tmp/kitchen/cache/cookbooks/sysctl/recipes/service.rb:26:in `from_file'

           service("procps") do
             action [:enable]
             updated true
             supports {:restart=>true, :reload=>true, :status=>true}
             retries 0
             retry_delay 2
             default_guard_interpreter :default
             service_name "procps"
             enabled true
             pattern "procps"
             declared_type :service
             cookbook_name "sysctl"
             recipe_name "service"
           end

Could it be due to this line, https://github.com/svanzoest-cookbooks/sysctl/blob/master/templates/default/procps.init-rhel.erb#L14, being flawed?

update crack to avoid CVE-OSVDB-90742

We just forked this repo and our organization-audit found this:

Name: crack
Version: 0.1.8
Advisory: CVE-OSVDB-90742
Criticality: High
URL: http://osvdb.org/show/osvdb/90742
Title: crack Gem for Ruby Type Casting Parameter Parsing Remote Code Execution
Solution: upgrade to >= 0.3.2

@svanzoest

FC059: declare use_inline_resources

Use use_inline_resources as per FC059 or resolve the issue some other way. We ended up reverting this for v0.7.4 and created this ticket to address it later as it is currently breaking folks.

See #51 for more details.

sysctl::apply doesn't apply the sysctl params changes after provisioning

Hi there

Yesterday I was using the sysctl cookbook for the first time to manage some ipv6 related kernel params. I noticed though that after a chef-client run, the params were not being taken into account, meaning that the changes were being set correctly but were not being applied by sysctl.

I'm not sure whether the following is expected behaviour, is by design, or neither of both so probably you can clarify it to me (and future comers).

What I was trying to do was to basically disable ipv6 capabilities so to have the web server handle only IPv4.

Following the interested files.

The attributes:

# attributes/sysctl.rb

default['sysctl']['allow_sysctl_conf'] = true
default['sysctl']['params']['net']['ipv6']['conf']['all']['forwarding'] = 0
default['sysctl']['params']['net']['ipv6']['conf']['all']['accept_source_route'] = 0
default['sysctl']['params']['net']['ipv6']['conf']['all']['accept_redirects'] = 0
default['sysctl']['params']['net']['ipv6']['conf']['all']['disable_ipv6'] = 1

default['sysctl']['params']['net']['ipv6']['conf']['default']['forwarding'] = 0
default['sysctl']['params']['net']['ipv6']['conf']['default']['accept_source_route'] = 0
default['sysctl']['params']['net']['ipv6']['conf']['default']['accept_redirects'] = 0
default['sysctl']['params']['net']['ipv6']['conf']['default']['disable_ipv6'] = 1

default['sysctl']['params']['net']['ipv6']['conf']['enp0s3']['disable_ipv6'] = 1
default['sysctl']['params']['net']['ipv6']['conf']['lo']['disable_ipv6'] = 1

The recipe:

# recipes/default.rb

include_recipe 'sysctl::apply'
# other "include_recipe" lines

I always needed to run sysctl -p /path/to/chef-sysctl-params-file to have the changes applied.
Is this behaviour expected?

I was applying this against the CentOS 7 box provided by OpsCode.

Thanks!

Error executing action `apply` on resource 'sysctl_param[kernel.mm.transparent_hugepage.defrag]'

The trace:

    Mixlib::ShellOut::ShellCommandFailed
    ------------------------------------
    Expected process to exit with [0], but received '255'
    ---- Begin output of sysctl -w "kernel.mm.transparent_hugepage.defrag=never" ----
    STDOUT:
    STDERR: sysctl: cannot stat /proc/sys/kernel/mm/transparent_hugepage/defrag: No such file or directory
    ---- End output of sysctl -w "kernel.mm.transparent_hugepage.defrag=never" ----
    Ran sysctl -w "kernel.mm.transparent_hugepage.defrag=never" returned 255

    Cookbook Trace:
    ---------------
    /var/chef/cache/cookbooks/sysctl/libraries/helpers_param.rb:62:in `set_sysctl_param'
    /var/chef/cache/cookbooks/sysctl/libraries/sysctl_param.rb:68:in `block (2 levels) in <class:SysctlParam>'
    /var/chef/cache/cookbooks/sysctl/libraries/sysctl_param.rb:64:in `block in <class:SysctlParam>'

    Resource Declaration:
    ---------------------
    # In /var/chef/cache/cookbooks/sysctl/recipes/default.rb

     26:   sysctl_param k do
     27:     value v
     28:   end
     29: end if node.attribute?('sysctl') && node['sysctl'].attribute?('params')

    Compiled Resource:
    ------------------
    # Declared in /var/chef/cache/cookbooks/sysctl/recipes/default.rb:26:in `block in from_file'

    sysctl_param("kernel.mm.transparent_hugepage.defrag") do
      action [:apply]
      retries 0
      retry_delay 2
      default_guard_interpreter :default
      declared_type :sysctl_param
      cookbook_name "sysctl"
      recipe_name "default"
      value "never"
      key "kernel.mm.transparent_hugepage.defrag"
    end

    System Info:
    ------------
    chef_version=12.21.26
    platform=ubuntu
    platform_version=16.04
    ruby=ruby 2.3.5p376 (2017-09-14 revision 59905) [x86_64-linux]
    program_name=chef-client worker: ppid=6907;start=13:34:53;
    executable=/opt/chef/bin/chef-client

I found that it tries to modify
/proc/sys/kernel/mm/transparent_hugepage/defrag
while the correct path is
/sys/kernel/mm/transparent_hugepage/defrag

sysctl_param LWRP tries to notify non-existing resource

In a cookbook of mine, I use the sysctl_param LWRP standalone without including any recipes:

sysctl_param 'vm.swappiness' do
  value 0
end

With version 0.6.0 of the cookbook, however, I get the following error when running chef:

FATAL: Chef::Exceptions::ResourceNotFound: resource execute[sysctl[vm.swappiness]] is configured to notify resource ruby_block[save-sysctl-params] with action run, but ruby_block[save-sysctl-params] cannot be found in the resource collection. execute[sysctl[vm.swappiness]] is defined in /tmp/vagrant-chef-1/chef-solo-1/cookbooks/sysctl/providers/param.rb:20:in `block in class_from_file'

Looks like this bug was introduced with the addition of this line: https://github.com/onehealth-cookbooks/sysctl/blob/master/providers/param.rb#L22 at the following commit: onehealth-cookbooks/sysctl@deadf43#diff-2.

If writing to the sysctl config file is the intended behavior, it should at least be documented that in order to use the sysctl_param LWRP, you must include the sysctl::default recipe (cannot be used standalone).

Otherwise, the LWRP should be fixed to notify the resource conditionally.

Thanks!

sysctl attributes in version 1.0.1

Cookbook version

[1.0.1]

Chef-client version

[12.19.36]

Platform Details

[physical Ubuntu 14.04.4 LTS kernel version 4.2.0-27-generic]

Scenario:

We are trying to update from sysctl cookbook 0.10.2 to 1.0.1 but sysctl attributes seem to be ignored.

Steps to Reproduce:

Attributes file used to work with the following example:
default['sysctl']['params']['vm']['swappiness'] = 20 default['sysctl']['params']['net']['core']['netdev_max_backlog'] = 50000 default['sysctl']['params']['net']['ipv4']['tcp_fin_timeout'] = 30

Expected Result:

and files were populated like:
/etc/sysctl.d/99-chef-vm.swappiness.conf
with
vm.swappiness = 20

Actual Result:

No new files are created in /etc/sysctl.d/ unless I use the following
sysctl_param 'vm.swappiness' do
value 20 <- there should be 2 spaces on this line
end

in a recipe. Have the attributes changed? Or am I missing something obvious?
The following is in the README
There are two main ways to interact with the cookbook. This is via chef attributes or via the resource.
so I assume I can still use attributes to populate /etc/sysctl.d/ - correct?

Using sysctl::apply with attributes can't find ruby_block[apply-sysctl-params]

chef-stacktrace.out:

Generated at 2014-08-22 08:40:03 +0200
Chef::Exceptions::ResourceNotFound: resource ruby_block[notify-apply-sysctl-params] is configured to notify resource ruby_block[apply-sysctl-params] with action run, but ruby_block[apply-sysctl-params] cannot be found in the resource collection. ruby_block[notify-apply-sysctl-params] is defined in /Users/simlu/.chef/local-mode-cache/cache/cookbooks/sysctl/recipes/apply.rb:22:in `from_file'

/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/resource_collection.rb:123:in `lookup'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/resource_collection.rb:241:in `find_resource_by_string'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/resource_collection.rb:147:in `block in find'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/resource_collection.rb:142:in `each'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/resource_collection.rb:142:in `find'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/resource.rb:65:in `fix_resource_reference'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/resource.rb:54:in `resolve_resource_reference'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/resource.rb:441:in `block in resolve_notification_references'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/resource.rb:441:in `each'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/resource.rb:441:in `resolve_notification_references'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/runner.rb:76:in `block in converge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/resource_collection.rb:90:in `block in each'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/resource_collection.rb:89:in `each'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/resource_collection.rb:89:in `each'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/runner.rb:75:in `converge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/client.rb:345:in `converge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/client.rb:431:in `do_run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/client.rb:213:in `block in run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/client.rb:207:in `fork'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/client.rb:207:in `run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/application.rb:217:in `run_chef_client'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/application/client.rb:328:in `block in run_application'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/application/client.rb:317:in `loop'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/application/client.rb:317:in `run_application'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/lib/chef/application.rb:67:in `run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.12.8/bin/chef-client:26:in `<top (required)>'
/usr/bin/chef-client:23:in `load'
/usr/bin/chef-client:23:in `<main>'

$ knife cookbook list | grep sysctl sysctl 0.6.0

$ knife role edit generic { "name": "generic", "description": "Generic OS X role", "json_class": "Chef::Role", "default_attributes": { "sysctl": { "params": { "net": { "inet6": { "ip6": { "use_tempaddr": 0 } } } } } } }

I use chef-client --local-mode on OS X 10.9.4 and I'm probably doing something wrong since I'm pretty new to chef = )

The cookbook works on archlinux, too, if you include it in the platform_family check

As the title says. If you add 'arch_linux' to the platform_family check, the rest of the cookbook will work.

In the mean time, a work around is to specify the attributes in your own cookbook:

if node['platform'] == 'arch'
  node.default['sysctl']['conf_dir'] = '/etc/sysctl.d'
  node.default['sysctl']['conf_file'] = File.join(node['sysctl']['conf_dir'], '/99-chef-attributes.conf')
end

procps failure on rhel 6.5

Restarting procps service triggered by sysctl:apply defined within this cookbook is generating the below error on my Red Hat 6.5 box.

Output:

Recipe: sysctl::service
service[procps] action start

Error executing action `start` on resource 'service[procps]'

Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '1'
---- Begin output of /sbin/service procps start ----
STDOUT:
STDERR:
---- End output of /sbin/service procps start ----
Ran /sbin/service procps start returned 1

Resource Declaration:

---

In /var/chef/cache/cookbooks/sysctl/recipes/service.rb
 26: service 'procps' do
 27:   supports :restart => true, :reload => true, :status => false
 28:   case node['platform']
 29:   when 'freebsd'
 30:     service_name 'sysctl'
 31:   when 'arch', 'exherbo'
 32:     service_name 'systemd-sysctl'
 33:     provider Chef::Provider::Service::Systemd
 34:   when 'ubuntu'
 35:     if node['platform_version'].to_f >= 9.10
 36:       service_name 'procps-instance' if node['platform_version'].to_f >= 14.10
 37:       provider Chef::Provider::Service::Upstart
 38:     end
 39:   end

Compiled Resource:

---

Declared in /var/chef/cache/cookbooks/sysctl/recipes/service.rb:26:in `from_file'

service("procps") do
  action [:enable]
  updated true
  supports {:restart=>true, :reload=>true, :status=>true}
  retries 0
  retry_delay 2
  default_guard_interpreter :default
  service_name "procps"
  enabled true
  pattern "procps"
  declared_type :service
  cookbook_name "sysctl"
  recipe_name "service"
end

Contents of /etc/rc.d/init.d/functions:

---

Apply sysctl settings, including files in /etc/sysctl.d 
apply_sysctl() {
sysctl -e -p /etc/sysctl.conf >/dev/null 2>&1
for file in /etc/sysctl.d/* ; do
    is_ignored_file "$file" && continue
    test -f "$file" && sysctl -e -p "$file" >/dev/null 2>&1
 done
 }

Should be able to specify config file

Currently it isn't possible to set a preferred config file. Each value gets it own file 👎

started getting failure to notify

With the upgrade from 0.7.2 - 0.7.4 our build/test system started dying on the following error. Doing a role back to 0.7.2 fixes it.

    ================================================================================
    Error executing action `apply` on resource 'sysctl_param[vm.swappiness]'
    ================================================================================

    Chef::Exceptions::ResourceNotFound
    ----------------------------------
    resource execute[sysctl[vm.swappiness]] is configured to notify resource ruby_block[save-sysctl-params] with action run, but ruby_block[save-sysctl-params] cannot be found in the resource collection. execute[sysctl[vm.swappiness]] is defined in /var/chef/cache/cookbooks/sysctl/providers/param.rb:23:in `block in class_from_file'

    Resource Declaration:
    ---------------------
    # In /var/chef/cache/cookbooks/hadoop/recipes/_system_tuning.rb

     25: sysctl_param 'vm.swappiness' do
     26:   value 0
     27: end
     28:

    Compiled Resource:
    ------------------
    # Declared in /var/chef/cache/cookbooks/hadoop/recipes/_system_tuning.rb:25:in `from_file'

    sysctl_param("vm.swappiness") do
      action [:apply]
      updated true
      updated_by_last_action true
      retries 0
      retry_delay 2
      default_guard_interpreter :default
      declared_type :sysctl_param
      cookbook_name "hadoop"
      recipe_name "_system_tuning"
      value 0
      key "vm.swappiness"
    end

sysctl Chef-13

FreeBSD support?

Hi there, excellent cookbook. But why don't you announce it is compatible with FreeBSD? You have implemented the code, I checked on version 10.2, values are changed and persisted after reboot, for me no problems. Do you know any issues with that?

Mention 'service sysctl reload' in README.md

Many guidelines on sysctl changes suggest changing sysctl.conf directly. I see that this cookboks is handling it well, but I'd like to add notes about using 'service sysctl reload' as a guideline for others who become confused and try to run the bare 'sysctl -p' command.

node['sysctl']['allow_sysctl_conf'] and pre-existing conf files

I have a situation where our base Centos 7 image (which is outside of my control) has a pre-existing /etc/sysctl.conf

I'm attempting to use this cookbook, and I'm using the default value for node['sysctl']['allow_sysctl_conf'] of false.

When I run the cookbook, a new file (/etc/sysctl.d/99-chef-attributes.conf) is created with the value I set.

The problem is that in that pre-existing file, the key I am setting already exists with a different value, and it appears that systemd-sysctl.service prefers that file over the /etc/sysctl.d/ one. Based on man sysctl.conf it seems the load order is:

       /run/sysctl.d/*.conf
       /etc/sysctl.d/*.conf
       /usr/local/lib/sysctl.d/*.conf
       /usr/lib/sysctl.d/*.conf
       /lib/sysctl.d/*.conf
       /etc/sysctl.conf

This lines up with what I am seeing getting set.

I understand that in a wrapper I could wipe out that pre-existing configuration file, but I'm raising the question here on if node['sysctl']['allow_sysctl_conf'] set to false should blow that pre-existing file away. As-is it is a little confusing to tell the system not to allow that file, yet its present and preferred over custom files.

Ability to change notify for service[procps]

Sometimes notifying service[procps] to start doesn't apply sysctl params, because when service[procps] started, some modules can be not loaded still.
It would be nice to see something like attribute to change behavior here: https://github.com/svanzoest-cookbooks/sysctl/blob/master/recipes/default.rb#L57

Release new version (v0.6.3)

It would be much appreciated if a new version of this cookbook was released (i.e. v0.6.3) to facilitate using the newest features.

ubuntu 16.04 problem?

Cookbook version

master

Chef-client version

12.12.15, chef-solo

Platform Details

ubuntu 16.04, virtualbox/vagrant

Scenario:

I am using the LWRP
sysctl::apply_params
and it suddenly stopped working for ubuntu and centos.

Steps to Reproduce:

node.default['sysctl']['allow_sysctl_conf'] = true
node.default['sysctl']['params']['vm']['swappiness'] = 1
node.default['sysctl']['params']['vm']['overcommit_memory'] = 1
node.default['sysctl']['params']['vm']['overcommit_ratio'] = 100
node.default['sysctl']['params']['net']['core']['somaxconn'] = 1024
include_recipe 'sysctl::apply'

Expected Result:

This worked until the recent big merge to master.

I think the problem is here:
libraries/sysctl_param.rb:57
The execute block is run during the compile phase, before the template creates the /etc/sysctl.d/99-chef-#{key}.conf file.
I checked and the conf file hasn't been created when the execute block is run:

vagrant@hopsworks0:~/.karamel/install$ ls -artlh /etc/sysctl.d/
total 44K
-rw-r--r-- 1 root root 519 Jan 13 2016 README
-rw-r--r-- 1 root root 506 Jan 13 2016 10-zeropage.conf
-rw-r--r-- 1 root root 1.3K Jan 13 2016 10-ptrace.conf
-rw-r--r-- 1 root root 509 Jan 13 2016 10-network-security.conf
-rw-r--r-- 1 root root 1.2K Jan 13 2016 10-magic-sysrq.conf
-rw-r--r-- 1 root root 257 Jan 13 2016 10-link-restrictions.conf
-rw-r--r-- 1 root root 726 Jan 13 2016 10-kernel-hardening.conf
-rw-r--r-- 1 root root 490 Jan 13 2016 10-ipv6-privacy.conf
-rw-r--r-- 1 root root 77 Jan 13 2016 10-console-messages.conf
lrwxrwxrwx 1 root root 14 Jan 18 2017 99-sysctl.conf -> ../sysctl.conf
drwxr-xr-x 2 root root 4.0K Apr 27 18:03 .
drwxr-xr-x 96 root root 4.0K Aug 7 12:47 ..

Actual Result:

RuntimeError

Unknown sysctl file location. Unsupported platform.

Cookbook Trace:

/tmp/chef-solo/cookbooks/sysctl/libraries/helpers_param.rb:32:in config_sysctl' /tmp/chef-solo/cookbooks/sysctl/libraries/sysctl_param.rb:57:in block in create_sysctld'
/tmp/chef-solo/cookbooks/sysctl/libraries/sysctl_param.rb:56:in create_sysctld' /tmp/chef-solo/cookbooks/sysctl/libraries/sysctl_param.rb:67:in block (2 levels) in class:SysctlParam'
/tmp/chef-solo/cookbooks/sysctl/libraries/sysctl_param.rb:64:in `block in class:SysctlParam'

Resource Declaration:

In /tmp/chef-solo/cookbooks/sysctl/recipes/default.rb

26: sysctl_param k do
27: value v
28: end
29: end if node.attribute?('sysctl') && node['sysctl'].attribute?('params')

Compiled Resource:

Declared in /tmp/chef-solo/cookbooks/sysctl/recipes/default.rb:26:in `block in from_file'

sysctl_param("net.core.somaxconn") do
action [:apply]
retries 0
retry_delay 2
default_guard_interpreter :default
declared_type :sysctl_param
cookbook_name "sysctl"
recipe_name "default"
value "1024"
key "net.core.somaxconn"
end

Platform:

x86_64-linux

Old 99-chef-attributes.conf is replaced when setting a new config param

The apply action of the param when called for the second run with a new param, is replacing the already created 99-chef-attributes.conf file. Thus resulting in the loss of the already configured params.
Shouldn't it be appending the new params to the old file instead of replacing it?

Provider fails when default recipe hasnt been run.

As of this commit, using the provider without first including the default recipe causes exceptions, since that conditional hasn't run and the ruby block doesn't exist yet to notify.

This wasn't the case before 0.4.0, and seems kinda unintentional.

have the command invoked be sysctl -e -w instead of sysctl -w.

Address and close https://github.com/onehealth-cookbooks/sysctl.orig/issues/17

Suse 11 & 12 Support

I'm working through all of the tests to make sure nothing is broken on the other platforms, and while that's going on I realized that I can't check in the kitchen.yml pointing to our Suse images. Do you have any preference on how to handle supporting a platform that doesn't have publicly available images?

1.0.0 unnecessarily(?) breaks existing users

Cookbook version

1.0.0

Chef-client version

12.x

Platform Details

Amazon Linux

Scenario:

Several cookbooks in my environment depend on the sysctl cookbook, each of these contains include_recipe "sysctl" before the first use of sysctl_param.

The changelog for 1.0.0 notes that "recipes:default no longer needs to be added to persist parameters" - awesome! However, the default recipe was deleted entirely. This causes include_recipe to fail, which means that all consumers of this cookbook need to update simultaneously.

I propose adding an empty default recipe to this cookbook to preserve backward compatibility. Or, if the break was intended, could this be more clearly called out as a breaking change in the release notes?

I'm happy to submit a PR either way, but I'm not sure what the intent was.

rename repo sysctl-cookbook

To match our other cookbooks we should rename this repo

does not combine sysctl files for version higher than 0.9.0

Cookbook version

0.10.1

Scenario:

attributes/default.rb file is missing since version 0.10.0, which exists on previous versions

Scenario:

using version higher than 0.9.0 does not combine sysctl files

Expected Result:

to combine sysctl files into a single file

Actual Result:

does not combine sysctl files into a single file

Compatibility with Ohai 4.x

Can you please allow the Ohai 4.x cookbook series to be used with this cookbook?

sysctl::apply always updates 2 resources

is there a way to prevent this from updating 2 resources, on every chef run, from the notifies that happen with the apply recipe? we expect chef runs to always have 0 resources updated, until an actual change has happened.