Shims aren't loaded for noninteractive shells on ubuntu 12.04

[dmitrym0]

Non interactive

> ssh mymachine 'echo $PATH'                                                                                                                                       
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

Interactive

> ssh mymachine
mymachine$: echo $PATH
/usr/local/rbenv/shims:/usr/local/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

Any tips on fixing this? Basically anything following rbenv role in my playbook that relies on correct ruby version (like the gem role) fails.

[zzet]

ssh dev@domain.com -t "bash -lc 'ruby -v'"
ruby 2.2.2p95

[dmitrym0]

Thanks zzet, if I recall any shell commands are run non-interactively. Any tips?

[zzet]

@dmitrym0 Sorry, can you explain your question?

[dmitrym0]

@zzet, I'm trying to provision an environment from an ansible script. Specifically it requires installing ruby 2.2.2 and Phusion Passenger. I have the following statement:

    - name: install passenger
      shell: gem install passenger

Unfortunately that will run into an issue because it will try to use system ruby (which happens to be 1.9.3 on ubuntu 12.04) because shims aren't loaded for non-interactive shells.

As a work around, I'm specifying that sudo needs to be executed with the -i flag (I found it in another github ansible discussion).

    - name: install passenger
      shell: gem install passenger
      sudo_user: "{{ deployment_user }} -i"

I suppose it works fine, but I do have to add this stanza to every shell invocation. Is this something you're doing as well? How are you using custom ruby versions in your playbooks?

[akostadinov]

I am writing here as the other two issues are closed. I see your point in #9240 but the case is that one could setup user shell and only then use shell with expected profile configuration. Other users have described use cases involving rvm and other tools that can be installed on different places but ultimately are responsible to setup user environment in a way that particular commands are available.

It is in fact more error prone to hardcode things that these tools do as if the tool changes, or some version number changes, then strings would need to be updated on a number of places. And it will be very ugly for example to invoke a rvm installation of ruby without the help of the profile scripts. Also it affects re-usability on different systems where shell is configured to hide the differences for particular plays (e.g. solaris vs linux).

It is totally ok to warn users when doing something but I can't understand why prevent user do something when it makes sense even if that often doesn't make sense. Stupid user will always find a way to do stupid things. But preventing legitimate use cases is more harmful IMO.

P.S. script module as suggested in one of the issues is really an overkill for simple one-line commands. Not only an overkill but also makes playbook harder to understand.

[thom-nic]

came here from ansible/ansible#4854 - to repeat what I said there, I have to wrap my commands in an additional bash -lc like: shell: bash -lc "gem install passenger" which will get the environment initialized correctly. Not pretty, but it works. I suppose you could also change that to command: /bin/bash -lc "gem whatever" if you want to remove one level of "shell inception."

@akostadinov I read your comment a couple times but I'm not sure I understand what you're proposing as a solution. [My comment on 4854] has a more complete example in the context of nodejs/NVM but the issue is exactly the same. I don't actually think this is an issue with rbenv and I think @zzet may be limited as to how much exactly can be solved in this role, vs solving it in either the core shell module or by adding an interactive option to the ansible sudo directive.

[akostadinov]

@thom-nic , good point, I didn't state my proposed solution. In fact I can't think of a common use case where shell profile files are better not loaded. And I can't think of such. If machine was setup by ansible and then maintained by ansible, then shell and profile scripts should be pretty much solid. Is it a common use case to run ansible over some random machine that you are not well aware of it's current setup? I hope not.

So the solution IMO is to enable login shell by default and allow disabling that. I'm ok if at least login shell can be enabled somehow (shell module option or sudo directive).

[thom-nic]

I agree, but don't know of a good solution to enable login profile by default. The discussion in the ansible issue I linked above has a couple proposed solutions but none that song require a change to ansible core.

As I commented on that issue, the best solution I've come up with is to use shell: bash -LC "some command with login env" but that's not exactly pretty.

[iangreenleaf]

Not saying this is necessarily the right solution, but it's the one I came up with messing with rbenv on my own a while ago, and it's been working fine for me:

- name: source rbenv init in non-interactive shells
  lineinfile: dest=/etc/bash.bashrc
              state=present
              regexp='profile.d/rbenv.sh'
              insertbefore=BOF
              line="source /etc/profile.d/rbenv.sh"