Search code examples
rubyrubygemsversionpuppetrbenv

Puppet: How to reload enviroment when installing gem package - rbenv version is not active

I have a running puppet server and want to do following steps on the puppet agent:

  • download rbenv from git server to /usr/local/rbenv (success)
  • download ruby-build from git server (success)
  • create file rbenv.sh in /etc/profile.d, so that on every login then rbenv-environment ist loaded (success)
  • install a specific ruby version using an exec-resource with rbenv install (success)
  • activate the specific ruby version using an exec-resource with rbenv global (fail for current login)
  • install a specific ruby gem (failed because of ruby version dependency)

The problem is, rbenv started from an exec-resource in puppet switches the ruby version in a subshell, and stores that information somewhere. The ruby version for the current shell, where I startet puppet agent --test is not changed. After logging out and in again, the puppet run is successful, because the environment is successfully loaded again.

So my question is: Is there a possibility to run the package provider in a new subshell? Or do I have to use another exec running gem install?

Solution

  • So my question is: Is there a possibility to run the package provider in a new subshell? Or do I have to use another exec running gem install?

    No. Providers run in the host Ruby instance. They may launch external commands, including shells, but they themselves are not run that way.

    Furthermore, you said,

    After logging out and in again, the puppet run is successful, because the environment is successfully loaded again.

    If it really requires logging out and back in to make the rbenv reconfiguration active (which is unclear), then running the provider in a subshell wouldn't be effective anyway. Neither would running gem install via an Exec, unless that Exec also expressly activated the desired Ruby environment.

    If you are using Puppet to swap out the system's default Ruby, out from under itself, then you need to be prepared for inconsistent behavior. You may be able to work around it by employing an appropriate Exec to perform the gem installation.