Bug 1565903 - ansible_provisioning_callback snippet does not set executable permission for '/root/ansible_provisioning_call.sh'
Summary: ansible_provisioning_callback snippet does not set executable permission for ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Ansible
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
high vote
Target Milestone: Released
Assignee: Marek Hulan
QA Contact: Lukas Pramuk
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-11 03:27 UTC by vijsingh
Modified: 2019-10-07 17:19 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-14 12:37:00 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:1222 None None None 2019-05-14 12:37:12 UTC
Foreman Issue Tracker 24981 None None None 2018-09-19 14:00:08 UTC

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 pm-sat@redhat.com 2018-09-19 16:08:50 UTC
Upstream bug assigned to mhulan@redhat.com

Comment 10 pm-sat@redhat.com 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


Note You need to log in before you can comment on or make changes to this bug.