Shared installation about puppet-rbenv

[vjt]

Hi @alup,

the rbenv::client serves a similar purpose, but it uses rbenv installed in the home directory of a sandbox user, that could reside e.g. in /opt or /srv, without polluting the FHS /usr/local location (more info here).

What do you think?

[alup]

Yes, this somehow serves the purpose of a shared installation, I just wonder if this could be used in production where simplicity (e.g. with permissions) is crucial. For now, it is a good solution. I would like to play with it to be sure. Do you think it is the best solution to this problem?

[vjt]

I'll try to summarize the benefits of a sandbox ruby user solution over /usr/local:

• It is manageable by the user itself and not root
• It is self-contained - removing the user and its home directory is enough to wipe it completely
• It does not interfere with system-installed packages / files
• It allows having a system-wide package-installed ruby interpreter for any other purpose
• It does not pollute /usr/local
• It allows for more granular permissioning - if needed (and also think apparmor / selinux)

WRT allowing other users to install rubies, I'd advise against that - better leaving to the single ruby root user that privilege, and letting other users install their gems through bundler. Shared gems across all users (e.g. unicorn, thin, eventmachine, json, ...) can and should instead be installed "globally" in the ruby user home.

Eventually, in a shared hosting setup, this can even be used to grant different sets of users access to different sets of rubies with installed gems, thanks to the isolation provided by the sandbox user.

[alup]

I agree with your arguments, maybe we can rethink the strategy in the future when other problems will occur with this solution.