Bug 1712460

Summary: [microdnf] - UBI containers not "inherit" the subscription automatically from subscribed satellite content host
Product: Red Hat Enterprise Linux 8 Reporter: Omkar Khatavkar <okhatavk>
Component: librhsmAssignee: Packaging Maintenance Team <packaging-team-maint>
Status: CLOSED ERRATA QA Contact: Eva Mrakova <emrakova>
Severity: unspecified Docs Contact:
Priority: high    
Version: 8.0CC: dmach, jhnidek, jpazdziora, packaging-team-maint, sct
Target Milestone: rcKeywords: Triaged
Target Release: 8.0   
Hardware: x86_64   
OS: All   
Whiteboard:
Fixed In Version: librhsm-0.0.3-3.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-11-05 22:22:06 UTC 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 Omkar Khatavkar 2019-05-21 14:43:21 UTC
Description of problem:
UBI containers not "inherit" the subscription automatically from subscribed satellite content host

Version-Release number of selected component (if applicable):
sh-4.4# cat /etc/redhat-release 
Red Hat Enterprise Linux release 8.0 (Ootpa)

How reproducible:
always

Steps to Reproduce:
1. Register Content host to Satellite (having repository https://partha.fedorapeople.org/test-repos/swid-zoo/)

2. Run podman run -it ubi-minimal sh

3. Try to install package from the above mentioned repo 
microdnf install duck => fails to find the package.

Actual results:
UBI containers are not able to "inherit" the subscription automatically from satellite content host if it subscribed.

Expected results:
UBI containers should "inherit" the subscription automatically from satellite content host if it subscribed.  

Additional info:
This is only failing for ubi-minimal, getting passed for ubi.

Comment 1 Stephen Tweedie 2019-05-21 14:51:56 UTC
The necessary host data seems to be mapped correctly in the ubi8/ubi-minimal container:

# find /run/secrets/
/run/secrets/
/run/secrets/rhsm
/run/secrets/rhsm/syspurpose
/run/secrets/rhsm/syspurpose/valid_fields.json
/run/secrets/rhsm/syspurpose/syspurpose.json
/run/secrets/rhsm/rhsm.conf.kat-backup
/run/secrets/rhsm/rhsm.conf
/run/secrets/rhsm/logging.conf
/run/secrets/rhsm/ca
/run/secrets/rhsm/ca/redhat-uep.pem
/run/secrets/rhsm/ca/katello-server-ca.pem
/run/secrets/rhsm/ca/katello-default-ca.pem
/run/secrets/rhel7.repo
/run/secrets/etc-pki-entitlement
/run/secrets/etc-pki-entitlement/3461635950340819004.pem
/run/secrets/etc-pki-entitlement/3461635950340819004-key.pem

and microdnf/librhsm does create /etc/yum.repos.d/redhat.repo, but that file is empty:

# ls -l /etc/yum.repos.d/
total 4
-rw-r--r--. 1 root root    0 May 21 14:50 redhat.repo
-rw-r--r--. 1 root root 1562 Apr 25 16:22 ubi.repo

Comment 2 Omkar Khatavkar 2019-05-22 11:29:10 UTC
I can see the repo is copied here in the location, not sure why the name is rhel7 ? 

sh-4.4# pwd
/run/secrets
sh-4.4# ls
etc-pki-entitlement  rhel7.repo  rhsm
sh-4.4# cat /etc/redhat-release   
Red Hat Enterprise Linux release 8.0 (Ootpa)
sh-4.4#

Comment 3 Daniel Mach 2019-05-27 11:37:50 UTC
Jiri,
could you provide any guidance on how librhsm should behave?
If the rhsm plugin behavior is documented, we could review it and make changes to librhsm accordingly.

Comment 4 Daniel Mach 2019-06-11 12:21:04 UTC
The rhel7.repo is probably oversight in containers-common package:

$ rpm -qf /usr/share/rhel/secrets/rhel7.repo 
containers-common-0.1.32-3.git1715c90.module+el8.0.0+2958+4e823551.x86_64

Comment 5 Daniel Mach 2019-06-11 13:19:48 UTC
I looked into the subscription issue more deeply.

This is what I did:


I installed 2 hosts:
* RHEL 8.0
* RHEL 8.1 (from a development snapshot)

$ dnf install podman
$ subscription-manager register --serverurl=subscription.rhsm.stage.redhat.com


on RHEL 8.0 host:
$ subscription-manager attach --auto
Installed Product Current Status:
Product Name: Red Hat Enterprise Linux for x86_64
Status:       Subscribed


on RHEL 8.1 dev snapshot host:
$ subscription-manager attach --auto
Installed Product Current Status:
Product Name: Red Hat Enterprise Linux for x86_64 Beta
Status:       Subscribed


On both hosts:
$ podman pull --tls-verify=false <url>/ubi8-minimal
$ podman run -it ubi8-minimal sh


In container on RHEL 8.0 host:
$ rm /etc/yum.repos.d/ubi.repo
$ microdnf update
Downloading metadata...
Downloading metadata...
Nothing to do.


In container on RHEL 8.1 host:
$ rm /etc/yum.repos.d/ubi.repo
$ microdnf update
Nothing to do.


The difference is that RHEL 8.1 uses a Beta entitlement and that information is passed to a container with GA productid.
That's why no repos are generated in the container running on RHEL 8.1 host.


Then I tried copying host's productid to /etc/ in the container:
$ setenforce 0
$ podman run --volume /:/opt/rootfs -it ubi8-minimal sh
$ rm /etc/yum.repos.d/ubi.repo
$ microdnf update
Nothing to do.
$ cp /opt/rootfs/etc/pki/product-default/486.pem /etc/pki/product-default/
$ microdnf update
Downloading metadata...
Downloading metadata...
$ cat /etc/yum.repos.d/redhat.repo  | egrep '^(\[|enabled)' | grep enabled=true -B1
[rhel-8-for-x86_64-appstream-beta-rpms]
enabled=true
--
[rhel-8-for-x86_64-baseos-beta-rpms]
enabled=true

--> everything works fine after placing a different productid in the container


I think everything works according to expectations.
I believe I've confirmed that entitlements get inherited to the containers,
there are just some restrictions (or specifics) related to productids.
Please note I tested everything against staging RHSM server, not a Satellite which I don't have.


Omkar,
could you provide a reproducer that anyone could run and reproduce the issue?
Maybe if you could setup a Satellite instance we could register to and test it in the same environment as you do.
Also what happens if you manually place productid for your repository in the container?

Comment 8 Daniel Mach 2019-07-10 08:42:20 UTC
The root cause is that the provided entitlement certificate has arch == "ALL" and that wasn't handled properly.
It's related to bug#1645318
Upstream PR: https://github.com/rpm-software-management/librhsm/pull/4

Comment 20 errata-xmlrpc 2019-11-05 22:22:06 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:3583