can_run() is affected by Rex forcing $PATH

[fff7d1bc]

trafficstars

It seems that Rex does overwrite whatever $PATH is set, making can_run() not really usable in case of setting custom paths. Here I have /opt/prefix/bin in $PATH as well, however can_run() for 'foo' looks like:

[2017-05-28 10:14:25] DEBUG - Executing: export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/pkg/bin:/usr/pkg/sbin ; LC_ALL=C which foo
[2017-05-28 10:14:25] DEBUG - which: no foo in (/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/pkg/bin:/usr/pkg/sbin)

Also, I do not have /usr/pkg/(s)bin in $PATH, but if I had such dir, can_run() would return that it can run something, that in fact,, cannot be executed without full path.

[fff7d1bc]

Friendly bump

[krimdomu]

Hi @slashbeast sorry for the late response.

Rex is using a predefined path if not advised otherwise (https://github.com/RexOps/Rex/blob/development-1.x/lib/Rex/Config.pm#L378).

You can override the path with this (https://www.rexify.org/docs/api/1.3/rex/commands.pm.html#path-path-):

# Rexfile
path "/my/bin", "/bin", "/usr/bin";

Or you can advise rex to read profile (with a feature flag): https://www.rexify.org/docs/other/a_word_on_backward_compatibility.html

# source $HOME/.profile
use Rex -feature => ['source_profile'];

# source /etc/profile
use Rex -feature => ['source_global_profile'];

# leave everything untouched:
use Rex -feature => ['no_path_cleanup'];

HTH, Jan

[ferki]

Thanks for your patience, @slashbeast!

I wished to leave some notes regarding this topic for you and any other readers.

Initial points

It seems that Rex does overwrite whatever $PATH is set, making can_run() not really usable in case of setting custom paths.

I'm more and more leaning towards the opinion that the out-of-the-box experience might be improved if Rex would use any $PATH that may have been set on the managed endpoint. Changing that has a high potential to break backwards compatibility though, so it most probably needs to be an opt-in feature hidden behind a feature flag. Due to this added complexity, would like to work on such change separately from this issue.

Here I have /opt/prefix/bin in $PATH as well

Yeah, since Rex forces a $PATH internally by default, can_run() would not find something outside those paths (for example something /opt/prefix/bin), unless explicitly instructed to either "use PATH is" or "use this specific PATH".

Also, I do not have /usr/pkg/(s)bin in $PATH, but if I had such dir, can_run() would return that it can run something, that in fact,, cannot be executed without full path.

Hmm, staying within Rex context, I don't see that causing much problem :thinking: Given that Rex enforces the same $PATH of every command it executes under the hood, if can_run() finds a command under a path, for example under /usr/pkg/(s)bin, then a subsequent run() call would be able to find it too.

If the command found under /usr/pkg/s(bin) is taken out of Rex context, though (like inserted into a template for on-the-fly generated scripts), it might be a limitation.

What's already possible/done

There's a nice summary of the various related control options above, and since then the feature flags has found their way into core documentation instead of living only on the website.

What's next

I plan to add some extra documentation mentioning relevant settings related to $PATH in the following places before closing this issue:

• [x] can_run()
• [x] run()
• [x] no_path_cleanup feature flag

Apart from that, I'm on the opinion that while being aware of the execution environment of commands is a responsibility of the programmer and there are multiple options to control Rex's behavior in this regard, Rex should also strive to make such common operations as smooth experience as possible (for example by not interfering with any $PATH configuration).

I'm inclined to attempt streamlining this aspect, but I might be missing some of the original context about why exactly Rex is setting its own internal $PATH by default since the very early days. Understanding and changing that would certainly take some more time.

[ferki]

I've ended up adding a CONFIGURATION AND ENVIRONMENT section for Rex::Commands::Run docs, and also cross-references between that and path, set_path and no_path_cleanup.