Bug 1565903

Summary: ansible_provisioning_callback snippet does not set executable permission for '/root/ansible_provisioning_call.sh'
Product: Red Hat Satellite Reporter: vijsingh
Component: Ansible - Configuration ManagementAssignee: Marek Hulan <mhulan>
Status: CLOSED ERRATA QA Contact: Lukas Pramuk <lpramuk>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.3.0CC: mhulan, oprazak, pcreech, vijsingh
Target Milestone: 6.5.0Keywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-05-14 12:37:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description vijsingh 2018-04-11 03:27:21 UTC
Description of problem:
[Satellite 6.3] 'ansible_provisioning_callback snippet' does not set executable permission for '/root/ansible_provisioning_call.sh'

Version-Release number of selected component (if applicable):

Red Hat Satellite 6.3

How reproducible:

Always

Steps to Reproduce:
1. on GUI see the below in snippet "ansible_provisioning_callback":

---------------
 <% else -%>
# Assume systemd is not available
<%= save_to_file('/root/ansible_provisioning_call.sh', snippet('ansible_tower_callback_script')) %>
(crontab -u root -l 2>/dev/null; echo "@reboot /root/ansible_provisioning_call.sh" ) | crontab -u root -
<% end -%>
<% end -%>
---------------

 In above creating the "/root/ansible_provisioning_call.sh" but without executable permission due to which after reboot cron get run but without success.
 

Actual results:

 File create without executable permission.

Expected results:

 File should create with executable permission:

e.g. snippet

-----------------
<% else -%>
# Assume systemd is not available
<%= save_to_file('/root/ansible_provisioning_call.sh', snippet('ansible_tower_callback_script')) %>
(chmod +x /root/ansible_provisioning_call.sh;crontab -u root -l 2>/dev/null; echo "@reboot /root/ansible_provisioning_call.sh" ) | crontab -u root -                  <====
-----------------

Additional info:

Comment 2 Marek Hulan 2018-04-11 08:59:19 UTC
Quickly looking at that, it seems the chmod is there but can fail for some reason. My guess is that the ansible_tower_callback_script does not render \n at the end, could you please ask customer to "Preview" the template for some host, so we get rendered version on his environment? Thanks

Comment 7 Marek Hulan 2018-09-19 14:00:06 UTC
Created redmine issue https://projects.theforeman.org/issues/24981 from this bug

Comment 8 Marek Hulan 2018-09-19 14:02:59 UTC
Sent a fix upstream for review, the chmod needs to be added explicitly.

Comment 9 Satellite Program 2018-09-19 16:08:50 UTC
Upstream bug assigned to mhulan

Comment 10 Satellite Program 2018-09-19 16:08:52 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/24981 has been resolved.

Comment 12 Lukas Pramuk 2018-12-11 15:45:24 UTC
This issue is not Satellite 6.3 specific therefore omitting "[Satellite 6.3]" from BZ title

One can expect this BZ to be cloned for other Satellite versions as well (depends on triage team)

Comment 13 Lukas Pramuk 2018-12-11 18:29:59 UTC
VERIFIED.

@satellite-6.5.0-5.beta.el7sat.noarch
foreman-1.20.1-1.el7sat.noarch

by following manual reproducer:

1) Provision RHEL6 host with Host Parameter "ansible_tower_provisioning = true"

2) At provisioned RHEL6 host check /root/ansible_provisioning_call.sh file perms

# ls -l /root/ansible_provisioning_call.sh 
-rwxr-xr-x. 1 root root 171 Dec 11 17:57 /root/ansible_provisioning_call.sh

>>> ansible provisioning callback script has executable permission set

Comment 16 errata-xmlrpc 2019-05-14 12:37:00 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:1222