Bug 2159839

Summary:	when creating a backup on rhel7 and restoring on rhel8, the restore process will fail with permission issues
Product:	Red Hat Satellite	Reporter:	Waldirio M Pinheiro <wpinheir>
Component:	Foreman Maintain	Assignee:	Evgeni Golov <egolov>
Status:	ON_QA ---	QA Contact:	Satellite QE Team <sat-qe-bz-list>
Severity:	high	Docs Contact:
Priority:	high
Version:	6.11.0	CC:	ahumbe, bhoefer, egolov, ehelms, jpasqual, kurathod, mkalyat, pcreech, pdwyer, pratshar, satellite6-bugs, saydas
Target Milestone:	6.14.0	Keywords:	Triaged
Target Release:	Unused
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:	rubygem-foreman_maintain-1.3.3	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		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 Waldirio M Pinheiro 2023-01-10 22:30:55 UTC

Description of problem:
Currently, there are a lot of customers creating a backup of Satellite 6.11 over rhel7 to restore in a fresh server over rhel8. The issue is, some users have different id's from rhel7 and rhel8, causing permission issues during the restore process.

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

How reproducible:
100%

Steps to Reproduce:
1. Create a satellite on 6.11@rhel7
2. Create a backup using "foreman-maintain backup ..."
3. Install a fresh rhel8
4. Install a fresh 6.11 satellite over rhel8
   Note. Some users will be with a different uid, for example, qpidd and puppet
5. Restore the backup using "foreman-maintain restore ..."

Actual results:
The process will fail because there are some restored files/directories that will keep the original permission from the rhel7 environment

Expected results:
Restore finished correctly with no issues, also, all the permission should be fixed, if necessary.


Additional info:

Comment 10 Eric Helms 2023-02-02 14:00:52 UTC

*** Bug 2158896 has been marked as a duplicate of this bug. ***

Comment 15 Evgeni Golov 2023-07-10 19:29:20 UTC

I was finally able to reproduce this bug.

It only happens:
- for backups that have either Puppet or Katello-Agent/Qpidd features enabled
- when restoring directly with foreman-maintain (and not satellite-clone) (yes, this is absolutely supported, just limits the impact)
- when restoring to a system that does not yet have the same features enabled (this is *technically* unsupported, as we document in [1] that the system to restore to needs to have "the same configuration", but do not elaborate exactly which bits need to be "same")

The issue is when the puppetserver or qpid-cpp-server packages are not installed while we unpack the backup, the files that should be owned by `puppet` or `qpidd` are extracted with their numeric ownership.
Would the packages (and thus the users) be already present, tar would be able to look up the correct UID/GID combination (as the tarball *contains* the names!) and the restore would work.

satellite-clone avoids this issue, as it checks whether the backup has puppet/qpidd and pre-installs the packages [2].

a viable workaround for users who do not wish to use satellite-clone is to install puppetserver/qpid-cpp-server on the system before running the restore, or follow the documentation to enable those features on the target system before doing the restore (but really, installing the packages is enough).

[1] https://access.redhat.com/documentation/en-us/red_hat_satellite/6.11/html/administering_red_hat_satellite/restoring_server_or_smart_proxy_from_a_backup_admin
[2] https://github.com/RedHatSatellite/satellite-clone/commit/8b70ae2b66b7f1cb125cf5868b3b4397618a5990

Comment 16 Evgeni Golov 2023-07-11 08:00:12 UTC

Created redmine issue https://projects.theforeman.org/issues/36578 from this bug

Comment 17 Evgeni Golov 2023-07-11 12:56:18 UTC

I've written how to reproduce this without el7/el8 on a 6.14 in https://github.com/theforeman/foreman_maintain/pull/744#issuecomment-1630638289