Failing to run service as nonroot

[rpattcorner]

Running the default recipe as a root user, but with a nonroot service user attribute (the default 'vault') results in a service start failure:

``systemd[1]: vault.service: control process exited, code=exited status=1
Apr 18 18:43:29 APP systemd[1]: Reload failed for LSB: Init script for vault.
`

Which doesn't tell me much. Deconstructing the command from /etc/rc.d/init.d/vault and running manually like this:

# /opt/vault/0.5.2/vault server -config=/etc/vault/vault.json

works just fine. Anyone know a way to kick up the log level to see just what is dying?

[johnbellone]

It may be the lack of coffee, but I am a little confused with what is wrong. Are you trying to run the vault process as a non-root user other than vault?

[rpattcorner]

Let me try for clarity...

• Default attributes to the vault service user, e.g.

  default['hashicorp-vault']['service_name'] = 'vault'
default['hashicorp-vault']['service_user'] = 'vault'
default['hashicorp-vault']['service_group'] = 'vault'

• Run the recipe using chef local as root user, e.g. chef-client -z -l info -o hashicorp-vault

• Recipe completes with apparent success

• Check the status of the vault service with systemctl status vault -l
  Vault is not in fact running, and the result is:

Apr 19 15:14:26 PPPRS-INFRASTRUCTURE-DEV-2016041817-NG-PPPRS-APP systemd[1]: Stopped LSB: Init script for vault.

Which I found uninformative, hence my wondering if there's a way to get more log information

Then Manually examine the generated file

/etc/rc.d/init.d/vault

and see that the command that is run is:

Kernel.exec(*["/opt/vault/0.5.2/vault", "server", "-config=/etc/vault/vault.json"])

so, in order to see if this is something environmental or systemd related, I run the command by hand, again as root (translated to bash syntax):

# /opt/vault/0.5.2/vault server -config=/etc/vault/vault.json

and vault starts just fine:

==> Vault server configuration:

     Log Level: info
         Mlock: supported: true, enabled: true
       Backend: inmem
    Listener 1: tcp (addr: "127.0.0.1:8200", tls: "disabled")
       Version: Vault v0.5.2

==> Vault server started! Log data will stream in below:

So I'm thinking there's something wrong with the systemd invocation, maybe a missing environment variable or some such, but no way to tell, as the log information is so minimal.

Does that clarify?

[johnbellone]

Yep, thanks!

I am going to bring in @coderanger here since we're using systemd through poise-service library.

[coderanger]

If you are using systemd, the thing to check is /etc/systemd/system/vault.service. That should have the systemd unit file in it. I'm not sure why you would end up with a sysvinit script on a machine using systemd unless you specifically configured it to do that.

[legal90]

I'm not sure why you would end up with a sysvinit script on a machine using systemd unless you specifically configured it to do that.

I suppose, it was fixed by #51

[rpattcorner]

I'm thinking the problem may be related to how I'm invoking the cookbook, probably something thickheaded on my part, and assumed by more experienced chefs, or related to running in a chef-zero (local) environment.

John, could I trouble you for a quick basic usage command-by-command including any berks commands you are issuing? Perhaps a sanitized set of commands the next time you do a run? If it was in chef zero (chef client -z) even better...

[johnbellone]

We are using policyfiles to deploy our cluster using the vault-cluster and the consul-cluster cookbook. Our workflow for deploying policies is:

1. chef update policies/vault-cluster.rb
2. chef push production policies/vault-cluster.rb

If you're going to use Berkshelf and the environment cookbook pattern a similar workflow to lock the cookbook dependencies with environments would be:

1. berks update
2. berks upload
3. berks apply <environment>

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.