Bug 1575975 - [API] Template import from local directory is throwing directory not found error
Summary: [API] Template import from local directory is throwing directory not found error
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Templates Plugin
Version: 6.4
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: 6.4.0
Assignee: Ondřej Pražák
QA Contact: Jitendra Yejare
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-08 13:11 UTC by Jitendra Yejare
Modified: 2019-11-05 23:18 UTC (History)
4 users (show)

Fixed In Version: tfm-rubygem-foreman_templates-6.0.2-1.el7sat
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-16 19:29:23 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 23958 0 Normal Closed [API] Template import from local directory is throwing directory not found error 2020-06-12 09:47:12 UTC

Description Jitendra Yejare 2018-05-08 13:11:58 UTC
Description of problem:
The import from local directory through API calls isnt functinal, its throwing directory not found error as following :
---------------------------------------------------
"message":"Something went wrong during export: Using file-based synchronization, but couldn't find /tmp/now"}
---------------------------------------------------
Here '/tmp/now' folder is created and with right permissions still the issue is misleading.


Version-Release number of selected component (if applicable):
Satellite 6.4.0 snap 2

How reproducible:
Always

Steps to Reproduce:
1. Create a local directory in satellite with foreman owner and correct SELinux policy
2. Create template erb file in that directory
3. Set that directory as 'Repo' in settings
4. Attempt to import above template from API end:
# curl -H "Accept: application/json" -H "Content-Type: application/json" -k -X POST -u admin:passwd https://mysatellite.com/api/v2/templates/export -d '{"verbose": "true", "associate": "new"}'

Actual results:
{"message":"Something went wrong during export: Using file-based synchronization, but couldn't find /tmp/now"}

Expected results:
The template should be imported.

Additional info:

Comment 3 Marek Hulan 2018-05-17 10:52:08 UTC
Jitendra, please try using other directories than /tmp, I have a suspicion that it does not work because of private tmp. See https://www.theforeman.org/plugins/foreman_templates/5.0/index.html#7.3.1Yousettherepoto/tmpbutdon%E2%80%99tseeanythingnewaddedevenafterexportsaysSuccess for more details, I think that should be covered in product documentation (worth of checking though).

If other directories work, I think this should not be blocker and perhaps even go to backlog or be closed as wontfix.

Comment 4 Jitendra Yejare 2018-05-29 11:31:31 UTC
Marek,

I check that by importing from /root/testTemplate/myTemplate directory, I faced same issue:
--------------------
{
  "error": {"message":"Using file-based synchronization, but couldn't find /root/testTemplate/myTemplate"}
}
--------------------

But, interestingly when I tried keeping in /usr/share/jitu/ it just worked,

--------------------
{"message":{"templates":[{"name":"jyejares provisionTemplate fake","id":511,"changed":false,"imported":true,"additional_errors":null,"exception":null,"validation_errors":{},"file":"testProviTable.erb","type":"provisioning_template","diff":null}],"repo":"/usr/share/jitu","branch":""}}

-------------------

So, I think we need to confirm whether it should be /usr/share always or its a bug ?

Comment 5 Ondřej Pražák 2018-05-31 06:57:46 UTC
The fact that you were able to export to /usr/share makes me think this is a permissions issue. You probably cannot export to /root/ because the system user that runs the application is not allowed to write there. It does not have to be /usr/share always, but the directory should be writeable imho.

If it is really a permission issue, we should probably improve the message to let the user know what is going on...

Comment 6 Marek Hulan 2018-05-31 20:14:13 UTC
If that's the case, this shouldn't be a blocker, Jitendra, could you please confirm? Note that the export is running under smart-proxy user and SELinux might also be blocking write access.

Comment 9 Marek Hulan 2018-06-15 15:06:03 UTC
Created redmine issue http://projects.theforeman.org/issues/23958 from this bug

Comment 10 pm-sat@redhat.com 2018-06-21 14:22:43 UTC
Upstream bug assigned to oprazak@redhat.com

Comment 11 pm-sat@redhat.com 2018-06-21 14:22:46 UTC
Upstream bug assigned to oprazak@redhat.com

Comment 12 pm-sat@redhat.com 2018-07-03 08:24:10 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/23958 has been resolved.

Comment 13 Jitendra Yejare 2018-07-09 11:52:33 UTC
Verified !

@ satellite 6.4 snap 11

Steps:

1. Attempt to, Import in or export templates to non /usr/share directory.


Behavior:

The correct error message is diplayed informing user about permissions.

{
  "error": {"message":"Using file-based synchronization, but couldn't access /root/rootDir/impDir to export templates. Please check the access permissions/SELinux and make sure it is writable for the web application user account, typically 'satellite'."}
}

Comment 14 Bryan Kearney 2018-10-16 19:29:23 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-2018:2927


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