Rudder

Taking care of this.

I tested on five different machines ranging from 2.10 (the version where this change was introduced) to 2.12 (bleeding edge) and on every machine, /etc/profile.d/rudder-agent.sh contains the right value and alters the PATH to have cf-* binaries in it.

The best I can come with would be a machine ignoring profile.d or altering PATH in a local .profile / .bashrc / .xxxrc, breaking this.

I am unable to reproduce this :( Can you tell me in which conditions (OS, ...) you encoutered this problem ?

Well, that is WEIRD.

I saw this at a customer's just a few weeks ago. He was using Rudder 2.11 on CentOS 6. I just installed a new CentOS 6 box with Rudder 2.11 (via vagrant) and it works...

I'll reject this. Thanks for looking into it Matthieu.

Ha, i've been trying this, on 5 different debian 7.4 generated by vagrant
They all have the file /etc/profile.d/rudder-agent.sh, but none of them have a proper PATH setup

Thanks for the update Nico. Matthieu, could you look into this please?

• When you run as a normal user, no problem: cf-agent is in the PATH
• When you run a root shell using either sudo -i (simulate initial login) or sudo bash/sh, it works too. Same goes for direct root logins via console or SSH.
• The problems happens when you use sudo -s (run the target user shell directly) or sudo su, in this case you bypass the call to /etc/profile (or for the first case, sudo cleans up the environment to only expose variables he deems safe, cleaning PATH in the process) and the PATH is not updated: no direct cf-agent call possible.

For me, it is to be expected, and changing this would mean altering the system far beyond what we are supposed to do for a simple tool calling helper (modifying sudoers, possibly global bashrc's / shellrc's, and so on) and is not adviseable.

What do you think jon ?

Matthieu CERDA wrote:

We tried together to reproduce this, the problem is simple:

• When you run as a normal user, no problem: cf-agent is in the PATH
• When you run a root shell using either sudo -i (simulate initial login) or sudo bash/sh, it works too. Same goes for direct root logins via console or SSH.
• The problems happens when you use sudo -s (run the target user shell directly) or sudo su, in this case you bypass the call to /etc/profile (or for the first case, sudo cleans up the environment to only expose variables he deems safe, cleaning PATH in the process) and the PATH is not updated: no direct cf-agent call possible.

For me, it is to be expected, and changing this would mean altering the system far beyond what we are supposed to do for a simple tool calling helper (modifying sudoers, possibly global bashrc's / shellrc's, and so on) and is not adviseable.

What do you think jon ?

Thank you for this detailed analysis. This now makes sense.

I think the best solution is to publish a blog post titled "10 reasons why sudo -s is considered harmful (#7 will blow your mind)" and not do anything else.

Er, sorry, just kidding, serious mode back on...

Since we are about to implement a "rudder" CLI for 3.0, that should wrap all necessary commands around cf-* binaries, I actually think it now makes sense to not have them in the path. However, it may make sense to have the rudder command installed under /usr/bin or /usr/sbin to make it available everywhere and avoid this problem.

Thoughts?

Would that be an appropriate approach ?

Mathieu is right in hi analysis of the sudo -s, this is expected.
As for the rudder command line, it is now in the path.
Closing this bug unless someone complains about PATH again.