0

I have a recipe that starts a service that can be configured by environment variables. Looking at how to set the variables (adding a bash script to /etc/profile.d didn't do the trick), I came across How to set environment variable using Chef? and so configured a rb file set the variables:

vars.rb:

ENV["foo"] = "bar"

myrecipe.rb:

require "/path/to/vars.rb"

service "someservice" do
  action :restart
end

When I run this, I get the following:

WARN -- : You are setting a key that conflicts with a built-in method Hashie::Mash#default defined in Hash. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method

Is this the best way to set variables for the service? Are the warnings acceptable? How can I get this to run cleanly?

Chef is version 12.04.

Brett
  • 5,690
  • 6
  • 36
  • 63

2 Answers2

1

The error means the key you are trying to set conflicts with a built-in key. Therefore, using the key afterwards would likely have unexpected results. Try using a different key name if possible.

In addition. Setting a variable in /etc/profile.d is for interactive shells. A service isn't running an interactive shell and therefore won't get those variables. In addition any environment variable you set in the Chef run isn't going to persist (if that's a requirement)

Assuming you are running a systemd system. You should set service variables using Environment= or EnvironmentFile= in your unit file. For example this is similar to something I have set up:

someservice.service.erb

[Unit]
Description=Someservice Server
After=network.target

[Service]
User=someservice
Environment="SOMESERVICE_OPTS=-someoption -someotheroption"
ExecStart=/srv/someservice/bin/someservice-server.sh run
ExecStop=/srv/someservice/bin/seomservice-server.sh stop

[Install]
WantedBy=multi-user.target

With Chef, I then copy this file to the correct location and make sure the systemctl daemon reloads systemctl daemon-reload

If this is an init based system you'll need to create an environment file somewhere and source that file in the init script like:

. /etc/default/someservice
<remaining init script>

Then make sure you use Chef to place both that environment file and the new init script on the server.

Brandon Miller
  • 4,695
  • 1
  • 20
  • 27
  • The service is not leveraging any of the standard service systems - the cookbook for the app defines it's own service handler, which basically makes the init command `appname` - so an `action :restart` results in `appname restart` being run. `appname` in /usr/local/bin is hashbanged with `#!/usr/bin/env /usr/local/openresty/bin/resty` and I am not that familiar with it - wanted to use an environment variable preferably.... – Brett May 18 '18 at 12:23
  • 1
    You could potentially work around this by using a `bash` or `execute` resource and defining your variables in a hash with the `environment` property and run the `appname restart` command in that resource. Hard to give a better suggestion when I'm not certain how the service is being set up. – Brandon Miller May 18 '18 at 13:27
0

Something that I overlooked is that the values for the variables are in a file that is only available once a resource has been processed (a bash resource that extracts a tarball). So I wouldn't even be able to access those vars in the first phase.

Instead of using vars.rb which doesn't exist at the start of the chef run, I have changed it to be a vars.sh which exports the variable, and add a notify to another bash resource with the following code:

bash "extract_archive" do
    code "tar zxf archive.tar.gz"
    notifies :run, "bash[restart_with_vars]", :delayed
end

bash "restart_with_vars" do
    code <<EOF
    source vars.sh
    appname restart
EOF
    action :nothing
end

The resolved run list has the service "appname" later on which starts without vars, but the bash gets added to the end of the resource list and restarts with vars.

Brett
  • 5,690
  • 6
  • 36
  • 63