Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1463007 - [RFE] Provide a simple way to install Capsules using the same package versions as their Satellite
Summary: [RFE] Provide a simple way to install Capsules using the same package version...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Installation
Version: Unspecified
Hardware: Unspecified
OS: Linux
unspecified
low
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: Katello QA List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-06-19 21:49 UTC by Pablo Hess
Modified: 2021-03-11 15:20 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-27 16:22:26 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Pablo Hess 2017-06-19 21:49:33 UTC
Description of problem:
Suppose I'm running Satellite 6.2.5 while the latest version available is Satellite 6.2.9. I want to add a new Capsule to my setup. If I simply run 'yum install satellite-capsule' my system will end up with all packages matching Satellite(-Capsule) 6.2.9 and will not work correctly with my existing Satellite 6.2.5.

I'd like to be able to tell Capsule to install the exact same package versions as its Satellite so as to avoid version mismatch issues.

The official documentation tells to update Satellite to the latest version, then install the new Capsule. But sometimes updating Satellite is not an option.



Version-Release number of selected component (if applicable):
Any.


How reproducible:
Always.


Steps to Reproduce:
1. Have Satellite running at version older than the latest.
2. Install new Capsule

Actual results:
'yum install satellite-capsule' will pull in the latest version of each capsule package, potentially mismatching the version installed on the Satellite.
In addition, 'satellite-installer --scenario capsule' will also pull in additional packages at the latest version instead of keeping the same ones as the Satellite.


Expected results:
yum should install on the Capsule the same package versions as its Satellite.
satellite-installer would also install on the Capsule the same package versions as its Satellite.



Additional info:
None

Comment 1 Pablo Hess 2017-06-19 22:17:44 UTC
Thinking of approaches: yum-plugin-versionlock is definitely the way to go here.  https://access.redhat.com/solutions/98873


First approach that comes to mind is:

1. Install and enable yum-plugin-versionlock on Capsule

2. Have Satellite run 'rpm -qa > /var/www/html/sat_pkg_versions'

3. Have Capsule download https://satellite.fqdn/sat_pkg_versions and place it under /etc/yum/pluginconf.d/versionlock.list



Alternative:

1. Create new remote execution template named prep-capsule on Satellite to run rpm -qa and output the result to a file, then scp the resulting file to the Capsule, placing it under /etc/yum/pluginconf.d/versionlock.list, then install/enable yum-plugin-versionlock on the Capsule.

2. Have Satellite run the remote execution template against the Capsule system before the Capsule system runs its first yum update.



I'll try both approaches and will be reporting any findings and shortcomings here.

Comment 2 Pablo Hess 2017-06-29 22:25:42 UTC
= Progress report =

1. Installed stock RHEL 7.3. Followed the Satellite install docs without running "yum update" at any point. Ran a minimal satellite-installer command as indicated on the docs.

2. After running satellite-installer, installed yum-plugin-versionlock and added current packages to the list:
   # yum -y install yum-plugin-versionlock
   # rpm -qa |xargs yum versionlock 


3. Provisioned a new RHEL 7.3 VM on libvirt from this Satellite, disabled all repos, enabled only the ones necessary on a capsule (following the docs).

4. Installed yum-plugin-versionlock on the capsule and scp'd the Satellite's /etc/yum/pluginconf.d/versionlock.list over to the capsule.

5. Followed the documentation to install the capsule. satellite-installer --scenario capsule --all --the --usual --options worked perfectly.

6. End result: capsule installed with all satellite-related packages up to the same versions as they are on the Satellite.


I have to check the effects of e.g. yum update on the capsule, and also the maintainability of the versionlock.list file on the satellite and all capsules.

But this is very good news so far.


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