SPLUNK_OS_USER is being sets a splunk regardless of $splunk_user value

[tam116]

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: PE 2021.7

• Distribution: Ubuntu 22.04

• Module version: 9.1.1

• Splunk forwarder version 9.0.4

How to reproduce (e.g Puppet code you use)

enable the splunk::forwarder class with all defaults except set the version to 9.0.4, build de405f4a7979

What are you seeing

Splunk service fails to start because it thinks it should run as splunk when all of the files are owner by root. Systemd config thinks it should run as root

What behaviour did you expect instead

Service should start

I believe something changed in at least the Debian installer between forwarder versions 8.x and 9.x and is causing the SPLUNK_OS_USER ini variable to be set =splunk in ${splunk::forwarder::forwarder_homedir}/etc/splunk-launch.conf

My fix is to add the following snippet to manifests/forwarder/config.pp which removes the SPLUNK_OS_USER setting altogether, matching the default config of 8.x

  ini_setting { 'SPLUNK_OS_USER':
    ensure  => absent,
    section => '',
    setting => 'SPLUNK_OS_USER',
    path    => "${splunk::forwarder::forwarder_homedir}/etc/splunk-launch.conf",
  }

I chose not to set the value to $splunk_user because there is a know issue listed on Splunk's site https://docs.splunk.com/Documentation/Splunk/9.0.4/ReleaseNotes/KnownIssues#Admin_and_CLI_issues
I suspect the bug only affects Splunk Enterprise and not the forwarder but figured it was simpler to just omit the value

2019-08-05	SPL-174406, SPL-109254	Root unable to run splunk cli if SPLUNK_OS_USER is set

[siegy22]

I think there's a general mismatch between this module and the RPM installation provided by Splunk.

When I first installed Splunk (Enterprise) and Splunk Forwarder, I chose to set the user by setting splunk::params::splunk_user: splunk which resulted in everything working correctly. Note When upgrading to 9.1.0 there will be a change adding a new user called splunkfwd for the splunk forwarder. We're currently working on handling all of those cases: #350