Closed rtamalin closed 5 months ago
During a migration I see that the templated repos.sh restore script has been updated to include the etc/products.d:
migration@localhost:~> sudo cat /system-root/var/adm/backup/system-upgrade/repos.sh
#! /bin/sh
# change root to first parameter or use / as default
# it is needed to allow restore in installation
cd ${1:-/}
rm -rf etc/zypp/repos.d
rm -rf etc/zypp/credentials.d
rm -rf etc/zypp/services.d
rm -rf etc/products.d
tar xvf var/adm/backup/system-upgrade/repos.tar.gz --overwrite
# return back to original dir
cd -
Similarly the restore tarball includes the etc/products.d files:
...
drwxr-xr-x root/root 0 2024-04-29 16:51 etc/products.d/
lrwxrwxrwx root/root 0 2024-03-04 14:21 etc/products.d/baseproduct -> SLES_SAP.prod
-rw-r--r-- root/root 2937 2024-04-29 18:28 etc/products.d/SLES_SAP.prod
-rw-r--r-- root/root 2049 2017-11-23 10:28 etc/products.d/sle-module-public-cloud.prod
-rw-r--r-- root/root 2145 2019-10-18 19:21 etc/products.d/sle-module-legacy.prod
-rw-r--r-- root/root 2254 2017-11-23 10:48 etc/products.d/sle-module-web-scripting.prod
-rw-r--r-- root/root 2054 2017-11-23 10:25 etc/products.d/sle-module-adv-systems-management.prod
-rw-r--r-- root/root 1577 2019-08-29 10:03 etc/products.d/sle-module-containers.prod
-rw-r--r-- root/root 1814 2016-12-07 12:35 etc/products.d/sle-module-toolchain.prod
-rw-r--r-- root/root 2029 2017-04-20 23:14 etc/products.d/sle-module-hpc.prod
-rw-r--r-- root/root 2363 2019-10-18 11:58 etc/products.d/sle-sdk.prod
-rw-r--r-- root/root 1920 2019-09-02 10:54 etc/products.d/PackageHub.prod
Can you please provide a test case how to test this change? Should be easy I assume but we have our internal ruling to try to provide at least one test case per pull request :)
Can you please provide a test case how to test this change? Should be easy I assume but we have our internal ruling to try to provide at least one test case per pull request :)
Do you mean a feature test or a unit test? There don't appear to be existing unit or feature tests for backup or restore, though I may not be grokking things in the Ruby testing stuff properly...
The Distribution Migration System (DMS) implements a non-interactive fully automated offline migration of systems by booting into a ISO image that runs through the migration. In some cases, if a migration from one product stream to another product stream fails, the normal rollback handling doesn't always restore the products state correctly.
To address this we should include the /etc/products.d contents in the backup that is created and restored.
Add changelog entry for upcoming v1.9.0 release stream, including the bug tracking id.
Add unit test for the zypper Backup and Restore routines.
Also fixed two bugs found while developing the unit test:
CreateTarball()'s check for potential tar arguments incorrectly checked under the local file system hierarchy, rather than under the specified root hierarchy, meaning it could skip backing up entries that might exist under the root if they didn't exist locally.
The /var/adm/backup/system-upgrade directory created under the specified root hierarchy, and missing intermediary directories, were being created with no access permissions, meaning that only a privileged superuser could access them. In reality migrations are run as root so it didn't impact customer usage, but it did cause problems for the unit tests running as a non-privileged user.
Fixes: #231, #232
Co-authored-by: Felix Schnizlein felixsch@users.noreply.github.com