Add a login(true) option to the bash resource to invoke a shell with the target users environment

I've finding this makes running RVM system wide very difficult, as a lot of the standard cookbooks need to be modified to add a login shell wrapper to certain commands. Perhaps it could be the default option: is there any reason why not?

That would be great improvement. Many times I needed to do sth related to user's HOME dir but setting "user foo" did not change HOME.

The workaround for me was to use bash resource with code invoking "su -l -c 'stuff' someuser". But that is not obvious for everyone and requires additional layer of escaping strings (very error prone).

+1

Just as Marcin mentioned above, I'd like to get the user's HOME more easily. Just to simply set an alias or PATH for the user (via $HOME/.bash*) etc.

+1

We've solved the problem by using the Etc module, sample code bellow:

require 'etc'

login = Etc.getlogin
home = Etc.getpwnam(login).dir
open(home + '/.bash_profile', 'a') do |f|
  f << "JAVA_HOME = ..."
end

So one could close this ticket IMHO - "know thy libraries" was the key here.

+1

Also would have expected that the script/execute/bash resources would be invoked with the full environment of the given user.

Related:
CHEF-1523 and https://github.com/wijet/chef-sudo

This also affects the execute resource. Wonder if the enhancement actually needs to be made down in mixlib-shellout.

I've run into the same issue executing npm install as a specific user.

This prevents us from installing cloudfoundry vcap with chef-hosted: it works fine with chef-solo executed by the ubuntu user. When the run is driven by chef-client with the root user the bash resources don't execute as intended.
I'll be re-factoring them on my branch to explicitly set the HOME and USER environment and then source the bash_profile.

As far as implementing this for execute resources, I'm not sure there's a way to do that correctly, since environment initialization is handled by a shell, and shell out executes commands directly without a shell[0]. I suppose we could implement a compromise where we attempt to lookup HOME and USER and set those; from the comments above, it seems like this would cover a decent number of use cases, but cases where people rely on (e.g.) JAVA_HOME being set in a bash initialization script wouldn't work.

0. This isn't strictly true, when a command is given as a single string, ruby itself will invoke /bin/sh when exec is called to split arguments into the argv array passed to the command (and deal with booleans, pipes, and the like). This is implementation and doesn't change the semantics, though.

Could we use Chef::Provider::Script and then call shellout to pipe it to a shell with '-l'?

$ cat /tmp/foo
/bin/ls
$ cat /tmp/foo | bash -l
CHANGELOG  chef  chef-expander	chef-server  chef-server-api  chef-server-webui  chef-solr  CONTRIBUTING  cucumber.yml	features  LICENSE  NEWS  NOTICE  Rakefile  README.rdoc	scripts
$ cat /tmp/foo | zsh -l
CHANGELOG  chef  chef-expander	chef-server  chef-server-api  chef-server-webui  chef-solr  CONTRIBUTING  cucumber.yml	features  LICENSE  NEWS  NOTICE  Rakefile  README.rdoc	scripts
$ cat /tmp/foo | tcsh -l
CHANGELOG  chef  chef-expander	chef-server  chef-server-api  chef-server-webui  chef-solr  CONTRIBUTING  cucumber.yml	features  LICENSE  NEWS  NOTICE  Rakefile  README.rdoc	scripts

Here is what I am doing for now:

• extend bash to prefix a small script; it sets the HOME and USER variables then sources .bashrc
• gem installs on behalf of the 'deployment' user with this gem_binary value:
  gem_binary "sudo -u #{node[:deployment][:user]} #{File.join(node[:ruby][:path], "bin", "gem")}"

Still a newbie so I can't say if this is really specific to cloudfoundry's recipes or something useful to all that could be made more robust.

Thanks for attention.

What is the status on this?

I would like to be able to use the user's environment when executing a script.