Running Sensu on Windows as a specific account

[bodgit]

I have a need to run Sensu on Windows with a different account to the default LocalService/LocalSystem that it uses by default. This would require registering the service with some different Powershell that looks something like this:

$securePassword = convertto-securestring -String "password" -AsPlainText -Force  
$credentialsObject = new-object -typename System.Management.Automation.PSCredential -argumentlist "username", $securePassword
New-Service -Name sensu-client -Credential $credentialsObject -BinaryPathName c:\\opt\\sensu\\bin\\sensu-client.exe -DisplayName 'Sensu Client' -StartupType Automatic

This doesn't strike me as something very idempotent if one were to change the account details after the service has already been registered.

Would it make sense to instead use one of the dsc_service or dsc_xservice types from the DSC module which should a) hide the scary Powershell and b) hopefully be a bit more idempotent w.r.t. the account credentials?

[ghoneycutt]

Hi @bodgit

We do expose the parameters, manage_user along with sensu_user and sensu_group. Would that work for you?

[bodgit]

I notice on Windows that parameter doesn't do anything, there's just a notice(), however I'm not sure it would help anyway as you would still need to register the service with the user you wish to run Sensu as and also I need to run Sensu as a user that already exists in Active Directory. Being able to pass sensu_user at least means I can theoretically make the files owned by that same AD account although I was planning on tackling file ownership outside of this module as technically it can all still be owned by the local account, the AD account just needs permission to read/run the Sensu binaries.

The long story is I have a need to monitor some files/directories that are on SMB/CIFS shares with fairly restrictive permissions, and it's preferable to create a dedicated AD account for Sensu to run with that has read-only access to the shares rather than grant access to the LocalService/LocalSystem account (which I'm not even sure is possible).

What I've done so far is replace the exec with the following (currently untested):

      dsc_service { 'sensu-client':
        dsc_ensure      => present,
        dsc_name        => 'sensu-client',
        dsc_state       => $service_ensure,
        dsc_startuptype => $service_enable ? {
          true    => 'automatic',
          default => 'disabled',
        },
        dsc_credential  => { # This will become a class parameter, or maybe can reuse $sensu_user?
          'user'     => 'DOMAIN\user',
          'password' => 'password',
        },
        dsc_displayname => 'Sensu Client',
        dsc_path        => 'c:\\opt\\sensu\\bin\\sensu-client.exe',
        require         => File['C:/opt/sensu/bin/sensu-client.xml'],
        before          => Service['sensu-client'],
      }

In theory it's functionally equivalent to the exec but I'm not sure if it needs to supplant the regular service resource type or not.

[bodgit]

I've created #823 which contains the changes I've made to get things working.

[ghoneycutt]

Solved by #823

[bodgit]

This hasn't been fixed as #823 was not merged. However there is #907 and #917 which are still open.

[ghoneycutt]

Thanks @bodgit for letting us know! Re-opened and we will continue to work this. Sensu v1 has been on the back burner to get Sensu v2 supported and now we are circling back to get these issues fixed.

[ghoneycutt]

Fixed with PR #917

[ghoneycutt]

Released in v2.61.0