upgrading to 2.6.1 gives "not a valid sysctl key" error on CentOS

[corporate-gadfly]

After upgrading to 2.6.1 catalog compilation is failing.

For a class as follows:

# @summary Profile for managing common entries in /etc/sysctl.d
class profiles::sysctl::common {

  $target = '/etc/sysctl.d/01-ipv4.conf'

  sysctl { 'net.ipv4.ip_forward':
    ensure => present,
    value  => '1',
    target => $target,
  }
  sysctl { 'net.ipv4.ip_nonlocal_bind':
    ensure => present,
    value  => '1',
    target => $target,
  }
}

I'm getting the following (in debug mode - short snippet):

Debug: Prefetching augeas resources for sysctl
Debug: Facter: resolving fact with user_query: kernel
Debug: Facter: Searching fact: kernel in file: kernel.rb
Debug: Facter: Searching fact: kernel in core facts and external facts
Debug: Facter: Loading all internal facts
Debug: Facter: List of resolvable facts: [#<Facter::SearchedFact:0x0000000004812550 @name="kernel", @fact_class=Facts::Linux::Kernel, @user_query="kernel", @type=:core, @file=nil>]
Debug: Facter: Loading external facts
Debug: Facter: fact "kernel" has resolved to: Linux
Debug: Facter: resolving fact with user_query: kernel
Debug: Facter: Searching fact: kernel in file: kernel.rb
Debug: Facter: Searching fact: kernel in core facts and external facts
Debug: Facter: Loading all internal facts
Debug: Facter: List of resolvable facts: [#<Facter::SearchedFact:0x0000000006950f00 @name="kernel", @fact_class=Facts::Linux::Kernel, @user_query="kernel", @type=:core, @file=nil>]
Debug: Facter: Loading external facts
Debug: Facter: fact "kernel" has resolved to: Linux
Debug: Executing: '/sbin/sysctl -e net.ipv4.ip_forward net.ipv4.ip_nonlocal_bind'
Error: /Stage[main]/Profiles::Sysctl::Common/Sysctl[net.ipv4.ip_forward]: Could not evaluate: Error: `net.ipv4.ip_forward` is not a valid sysctl key
Error: /Stage[main]/Profiles::Sysctl::Common/Sysctl[net.ipv4.ip_nonlocal_bind]: Could not evaluate: Error: `net.ipv4.ip_nonlocal_bind` is not a valid sysctl key
Debug: Class[Profiles::Sysctl::Common]: Resource is being skipped, unscheduling all events

Output of sysctl is:

# /sbin/sysctl -e net.ipv4.ip_forward net.ipv4.ip_nonlocal_bind
net.ipv4.ip_forward = 1
net.ipv4.ip_nonlocal_bind = 1

No issues with 2.6.0.

# puppet --version
7.10.0

# cat /etc/redhat-release 
CentOS Linux release 7.9.2009 (Core)

# uname -a
Linux REDACTED 3.10.0-1160.41.1.el7.x86_64 #1 SMP Tue Aug 31 14:52:47 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

[trevor-vaughan]

That is definitely unexpected! It looks like I missed an edge case during testing.

[corporate-gadfly]

Slightly different behavior on CentOS 8. No catalog failure. Target file was not touched but each run produces the notice:

Notice: /Stage[main]/Profiles::Sysctl::Common/Sysctl[net.ipv4.ip_forward]/value: changed configuration value from '' to '1'

Target file hasn't been touched:

# ls -al /etc/sysctl.d/01-ipv4.conf 
-rw-r--r--. 1 root root 54 Sep 25  2020 /etc/sysctl.d/01-ipv4.conf

[corporate-gadfly]

Similar behavior on Ubuntu 20.04.3 LTS. Notice on every run:

Notice: /Stage[main]/Profiles::Sysctl::Common/Sysctl[net.ipv4.ip_forward]/value: changed configuration value from '' to '1'

[trevor-vaughan]

@corporate-gadfly Definitely a weird edge case. Can you try removing any duplicate entries from /etc/sysctl.conf

[corporate-gadfly]

Good call @trevor-vaughan . There were duplicates in /etc/sysctl.conf. Now, with duplicates removed. on CentOS 7.9, I'm seeing what I was seeing on CentOS 8 and Ubuntu:

Info: Applying configuration version '1630679211'
Notice: /Stage[main]/Profiles::Sysctl::Common/Sysctl[net.ipv4.ip_forward]/value: changed configuration value from '' to '1'

So, a notice for a non-change every time the catalog runs.

Ideally, 2.6.0 behavior would be preferred, i.e.:

• don't fail catalog if there are duplicates
• don't issue notice on every run for a non-change

[trevor-vaughan]

@corporate-gadfly I've identified the edge case and resolved the issue but I'm a bit up in the air about the correct way to implement the solution.

The issues both revolved around having a target set but also having the value specified in a file that would be loaded later (alphabetical and then sysctl.conf).

There are two options:

1. Put the value in the target file regardless of whether or not it will take effect.
   • This is "correct" in that it puts it where you expect but "incorrect" in that it will actually not be correct on reboot (until the next puppet run).
2. Update the value in the latest loaded file that it is found in.
   • This is "correct" in that the system will have the value that you expect but "incorrect" in that it won't actually be placed into the target file.

I don't like the idea of removing it from wherever it was found and then adding it to the file because, technically, it could be specified in multiple files and the last one wins.

I also don't really care for updating both files because, frankly, it's kind of difficult.

CC @op-ct

[corporate-gadfly]

I think I would go for option 1 (I suppose because of element of least surprise??).