Bug 2170013

If I am correct, 

* The issue happened with the non-root user as The PATH env var of the Non-Root user would not have the /opt/puppetlabs/bin and if I am not wrong when satellite SSH to rexuser and sudo to root, It will inherit the PATH var from rexuser 

* So that is why, "puppet: command not found"

* For root user i.e. ( SSH User = root ) it works fine as , The PATH env var of root will have the puppetlabs binary path in it. 


Looking at the code:

https://github.com/theforeman/foreman_remote_execution/blob/master/app/views/templates/script/puppet_run_once.erb


And we export the PATH variable to include the full path of puppet on for Debian only.

<% if @host.operatingsystem.family == 'Debian' -%>
export PATH=/opt/puppetlabs/bin:$PATH
<% end -%>
puppet agent --onetime --no-usecacheonfailure --no-daemonize <%= input("puppet_options") %>


I expect "/etc/profile.d/puppet-agent.sh" to be loaded in OS env when REX stuff happens ( as mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1527627#c7 ). But perhaps that is not happening for non-root users and due to the same , The easiest way to solve this would be to have the "export PATH" applied for redhat based systems  as well, in the job template. 

( we can simply remove the if clause i guess or add a new one for RedHat )

Could be. There is also a quite high chance that it behaves differently depending on which effective user method you use and whether you use ssh or pull. Hardcoding an extension of PATH would be the easy way out.

Also in the meantime, the customer can fix this for themselves by cloning the template, making the changes in the clone and then assigning that template to puppet_run_host feature.

True. The customer had mentioned that the Ansible-based Puppet run works fine ( even via non-root ssh user ). 

I will ask the engineer the verify with 

* SSH 
* Pull
* Ansible 

And then share the observations here ( via non-root user as SSH user )


About,
~~
Also in the meantime, the customer can fix this for themselves by cloning the template, making the changes in the clone and then assigning that template to puppet_run_host feature.
~~

I believe the end-user is aware of it but he would like to have it fixed via Default Templates only.

Hi, 

I have done the below tests using "default templates" while "effective_user_method" is sudo.

=========================================================================================================================
Job Category 	        Job Template	                         User	               Error 	              Success
=========================================================================================================================
Puppet	          Puppet Run Once – Script Default	       rexuser	     puppet: command not found	         No
Puppet	          Puppet Run Once – Script Default	         root	              No Error	                 Yes
-------------------------------------------------------------------------------------------------------------------------				
Ansible Puppet	  Puppet Run Once – Ansible Default	       rexuser	  [Errno 2] No such file or directory	 No
Ansible Puppet	  Puppet Run Once – Ansible Default	          root	              No Error	                 Yes
-------------------------------------------------------------------------------------------------------------------------				
Ansible Commands  Run Comman – Ansible Default                 rexuser	    /bin/sh: puppet: command not found	 No
                  (Command # puppet agent -tv)
	
Ansible Commands  Run Comman – Ansible Default                   root	               No Error	                 Yes
                  (Command # puppet agent -tv)	
-------------------------------------------------------------------------------------------------------------------------

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "SAT-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.