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:
*** Bug 2158896 has been marked as a duplicate of this bug. ***
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
Created redmine issue https://projects.theforeman.org/issues/36578 from this bug
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