Description of problem: Importing CV version from exported tar breaks things as below: ``` # hammer -u admin -p passwd content-view version import --export-tar abc/export-5.tar --organization-id 5 [................................................................................................] [100%] No new packages. Error: RPM1004: Error retrieving metadata: [Errno 2] No such file or directory: '//abc/export-5/puppetOrg/content_views/puppetCV/2.0/custom/yumProd/yumRepo/repodata/repomd.xml' Could not import the content view.: bear-4.1-1.noarch.rpm not available in repository yumRepo ``` Version-Release number of selected component (if applicable): Satellite 6.5.0 snap 7 How reproducible: Always Steps to Reproduce: 1. Create Product with yum repository contents. 2. Create CV, add above product to the CV. 3. Publish the CV 4. Export the above CV version. 5. Attempt to import the CV version contents from the exported directory. ``` # hammer -u admin -p passwd content-view version import --export-tar abc/export-5.tar --organization-id 5 ``` Actual results: Import fails with Permission denied error: ``` Error: RPM1004: Error retrieving metadata: [Errno 2] No such file or directory: '//abc/export-5/puppetOrg/content_views/puppetCV/2.0/custom/yumProd/yumRepo/repodata/repomd.xml' Could not import the content view.: bear-4.1-1.noarch.rpm not available in repository yumRepo ``` Expected results: Import of Content View version should be successful. Additional info:
Note: I tried creating export directory in /root and /tmp, same error persists. I also tried changing the owner and group of exported tar and import, same error is seen.
Same was working with Katello 3.9, but looks like 3.10 broke this part.
It looks like Pulp is not able to read from /tmp or other locations due to selinux labels. There are a couple of ways around this: * copy the tar file to /var/lib/pulp/katello-export before importing, since that directory has the correct permissions already, or * run "chcon -R system_u:object_r:httpd_sys_rw_content_t:s0 <directory with tar file>" One of the key parts of the feature is that we allow imports to happen from any directory, for example even from a mounted USB key. We are going to check for file and selinux permissions before starting the import, and will raise a useful error message with info on what to fix if the permissions are incorrect.
The second workaround will work in some cases but not all cases. Please use /var/lib/pulp/katello-export/ for now while we work on this bug.
Last week (dec 17-21) we worked on this bug. There are two issues happening, one is fixable with hammer but the other is not. The first issue is that Pulp needs the import directory to have the correct file permissions. For example, if you are importing from /tmp/my_imports/import-1, the following directories need to have either world-execute permission, or be executable by the apache user or group: * /tmp/my_imports/import-1 * /tmp/my_imports/ * /tmp/ This is something that hammer could check for, and raise an error with user instructions if any directories don't have the correct permission. The second issue is that the SELinux labels on the above three directories need to be correct as well. For example, if a user creates a temp directory with "mktemp -d", it will likely be labelled as "user_tmp_t". Pulp workers do not have permission to work with files in directories with "user_tmp_t" label. Even if you had "/tmp/my_imports/import_1" and the "import_1" directory had the right labels, Pulp would still not be able to access the files unless both "/tmp" and "/tmp/my_imports" had SELinux labels that granted access. If a user chose to read an export from "/mnt/my_usb_key/imports" or "/exports", they would face similar issues. This is compounded by NFS, which requires users to set the SELinux labels via fstab. Unfortunately, given that SELinux issues require different solutions for different directories, we can't raise an error with a single "chcon" command for the user to run. As a solution, we can tell users to put the export files into "/var/lib/pulp/katello-export" before importing. This directory already has the correct permissions and correct SELinux labels, and was created specifically as a landing place for files not created by Pulp that Pulp needs to read or write. We can also provide basic documentation on what to do if users want to use a different directory. We can't anticipate all the different directories they may choose ("/tmp", "/var/tmp", "/srv", "/mnt", etc), but we can provide basic steps and links for further information. (most of the following info is from https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/chap-security-enhanced_linux-troubleshooting) If a user believes they are running into SELinux issues, the first thing to do is check /var/log/audit/audit.log. If nothing is being logged, the user can try doing "semodule -DB" and retrying the import. The user can run "semodule -B" to disable dontaudit rules after debugging is complete. Another option is to *temporarily* set "setenforce 0" and see if the import works. If the user has confirmed that SELinux is blocking Pulp's access to the directory, they can try running "ls -dZ /path/to/dir" and checking the label. If it's different than /var/lib/pulp/katello-export's label, they can run "semanage fcontext -a -e /var/lib/pulp/katello-export /path/to/dir". Note that all parent directories to "/path/to/dir" will need labels that allow Pulp to execute the directory as well. Given that choosing a non-default location for the import is complex, I would recommend fixing this issue via documentation. I would also recommend against checking the non-SELinux file permissions in hammer, since it would only be one half of the solution. If this sounds OK, let me know and we can move the bug to a docs bz.
ACK on Comment 7.
moving category to docs per comment #8 Docs team: comment #7 has more info, but in short, there was a usability concern that is best addressed via feature docs.
Upstream bug assigned to chrobert
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/25715 has been resolved.
Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/25715 has been resolved.
Hello Bryan, I'm Marie, new doc program manager for Satellite docs. I'm still very new to the Satellite docs and Satellite as a product itself, so I may not understand all details yet. Apologies. I see this BZ has been filed against RH Satellite and against the component "Documentation", so I thought it should be assigned to a member of the Satellite docs team, but I see you've reassigned it back to engineering. I'm just wondering why is this. Please could you explain to me? Apologies again that I don't have all the necessary context yet. Thank you so much!
Everything in this BZ was completed a long time ago. Closing CURRENTRELEASE.