RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 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 "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". 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 "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-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 1226007 - rpm-ostree rebase can cause wrong remote to get used
Summary: rpm-ostree rebase can cause wrong remote to get used
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: subscription-manager
Version: 7.2
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: rc
: 7.4
Assignee: Chris Snyder
QA Contact: John Sefler
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-05-28 18:00 UTC by Dusty Mabe
Modified: 2016-10-05 20:42 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Rebase: Bug Fixes and Enhancements
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-05 20:42:53 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Dusty Mabe 2015-05-28 18:00:38 UTC 
Description of problem:


I have a situation where rpm-ostree gets confused on which remote it should be
using. If I register a system using subscription manager and then rebase it onto 
some other tree, then perform an upgrade the system is totally confused about 
what remote it should be using. The version of rpm-ostree I was using was 
rpm-ostree-client-2015.5-3.atomic.el7.x86_64 which was composed into my test 
tree. Here is the worked out example:



*Initial Setup*
===============
-bash-4.2# rpm-ostree status
  TIMESTAMP (UTC)         VERSION     ID             OSNAME               REFSPEC                                                 
* 2015-04-02 20:14:06     7.1.1-1     21bd99f9f3     rhel-atomic-host     rhel-atomic-host:rhel-atomic-host/7/x86_64/standard     
-bash-4.2# 
-bash-4.2# 
-bash-4.2# ls /etc/ostree/remotes.d/
-bash-4.2# subscription-manager register --auto-attach
Username: XXXXX
Password: 
The system has been registered with ID: 8e26062d-c1e7-42d1-b0a7-10da70f88a6c 

Installed Product Current Status:
Product Name: Red Hat Enterprise Linux Atomic Host
Status:       Subscribed

Product Name: Red Hat Enterprise Linux Server
Status:       Subscribed

-bash-4.2# ls /etc/ostree/remotes.d/                                                                                                                                           
redhat.conf


*Rebasing*
==========

-bash-4.2# ostree remote add lab --set=gpg-verify=false http://192.168.122.121:8000/repo
-bash-4.2# rpm-ostree rebase lab:goodtree

568 metadata, 2724 content objects fetched; 173996 KiB transferred in 82 secondsCopying /etc changes: 25 modified, 4 removed, 58 added
Transaction complete; bootconfig swap: yes deployment count change: 1
Deleting ref 'rhel-atomic-host-ostree:rhel-atomic-host/7/x86_64/standard'
Changed:
...
...
-bash-4.2# reboot


*Upgrading*
==============

-bash-4.2# rpm-ostree status
  TIMESTAMP (UTC)         VERSION     ID             OSNAME               REFSPEC                                                        
* 2015-05-25 02:27:05                 7e4135eeb5     rhel-atomic-host     lab:goodtree                                                   
  2015-04-02 20:14:06     7.1.1-1     21bd99f9f3     rhel-atomic-host     rhel-atomic-host-ostree:rhel-atomic-host/7/x86_64/standard

-bash-4.2# rpm-ostree upgrade
Updating from: lab:goodtree

51 metadata, 60 content objects fetched; 112700 KiB transferred in 9 seconds
Copying /etc changes: 25 modified, 4 removed, 60 added
Transaction complete; bootconfig swap: yes deployment count change: 0
Changed:
...
...
Upgrade prepared for next boot; run "systemctl reboot" to start a reboot
-bash-4.2#
-bash-4.2# rpm-ostree status
  TIMESTAMP (UTC)         ID             OSNAME               REFSPEC                              
  2015-05-27 01:42:42     559d5f3d7b     rhel-atomic-host     lab:goodtree                         
* 2015-05-25 02:27:05     7e4135eeb5     rhel-atomic-host     rhel-atomic-host-ostree:goodtree
-bash-4.2# reboot


*After Reboot*
==============

-bash-4.2# rpm-ostree status
  TIMESTAMP (UTC)         ID             OSNAME               REFSPEC                              
* 2015-05-27 01:42:42     559d5f3d7b     rhel-atomic-host     rhel-atomic-host-ostree:goodtree     
  2015-05-25 02:27:05     7e4135eeb5     rhel-atomic-host     rhel-atomic-host-ostree:goodtree
-bash-4.2# rpm-ostree upgrade
Updating from: rhel-atomic-host-ostree:goodtree


error: Server returned status 404: Not Found



Version-Release number of selected component (if applicable):
rpm-ostree-client-2015.5-3.atomic.el7.x86_64

How reproducible:
Always


Steps to Reproduce:
See description.
Comment 2 Colin Walters 2015-05-28 18:30:22 UTC 
My best guess here is the subscription manager daemon `rhsmcertd` is coming in and overwriting things.

Try:
systemctl stop rhsmcertd
systemctl mask rhsmcertd

?
Comment 3 Dusty Mabe 2015-05-28 18:40:19 UTC 
(In reply to Colin Walters from comment #2)
> My best guess here is the subscription manager daemon `rhsmcertd` is coming
> in and overwriting things.
> 
> Try:
> systemctl stop rhsmcertd
> systemctl mask rhsmcertd
> 
> ?

At what point in the process (the one described in the description) do you want those two commands to be run?
Comment 4 Dusty Mabe 2015-05-31 16:10:24 UTC 
(In reply to Colin Walters from comment #2)
> My best guess here is the subscription manager daemon `rhsmcertd` is coming
> in and overwriting things.
> 
> Try:
> systemctl stop rhsmcertd
> systemctl mask rhsmcertd
> 
> ?


That seems to work if I disable/mask rhsmcertd right after I run *subscription-manager register --auto-attach*. 

One thing that might be of interest is that I see these denials when I run *subscription-manager register --auto-attach*: 




[  125.083645] type=1400 audit(1433086915.767:5): avc:  denied  { write } for  pid=9505 comm="rhsmcertd-worke" name=".dbenv.lock" dev="dm-0" ino=4199789 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
[  219.084882] type=1400 audit(1433087009.767:6): avc:  denied  { write } for  pid=9505 comm="rhsmcertd-worke" name="21bd99f9f37727358454866bf4f0d51fe53c2f03fc74f2e69c75cbef0383a3f1.0.origin" dev="dm-0" ino=4199523 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
[  220.419414] type=1400 audit(1433087011.102:7): avc:  denied  { write } for  pid=9513 comm="rhsmcertd-worke" name=".dbenv.lock" dev="dm-0" ino=4199789 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
[  225.179294] type=1400 audit(1433087015.863:8): avc:  denied  { write } for  pid=9513 comm="rhsmcertd-worke" name="21bd99f9f37727358454866bf4f0d51fe53c2f03fc74f2e69c75cbef0383a3f1.0.origin" dev="dm-0" ino=4199523 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
Comment 9 Chris Snyder 2016-10-05 15:43:19 UTC 
I need a bit of clarification on the use case here. This comment might be more appropriate for the RFE bz above but nevertheless I will place it here.

What use case is being tested here? It seems the subscription manager ostree plugin assumes the only valid configurations for remotes will be in '/etc/ostree/remotes.d/redhat.conf'. Is there a valid use case in this bug that is not covered by the RFE?

Is it expected and valid to add a remote not included in an entitlement cert and rebase off said remote?

If the answer to the above is 'no' I will close this bug in favor of the RFG bug 1378495

Thank you in advance for your response.
Comment 10 Dusty Mabe 2016-10-05 16:11:49 UTC 
Hey Chris,

I don't know the answers to your questions. Is rebasing something that needs to be supported? Maybe? I guess that depends on if we ever offer different trees to our customers.

I think what I was trying to report here is a situation where the software is behaving in a way it shouldn't. Upstream rpm-ostree has a feature that allows you to rebase to another tree, and in the case I outlined above I rebased to a different tree, did an upgrade, and then it no longer knows how to contact the remote. 

I was just trying to report the issue, as there is some bug here (or was at the time I was trying this out).
Comment 11 Chris Snyder 2016-10-05 20:42:53 UTC 
This works as designed. Switching from a tree that was provided by a subscription to a tree that was added through some other means is unsupported. For any parties interested in that functionality please refer to bug 1378495 as the work to support that functionality will be completed there.
Note You need to log in before you can comment on or make changes to this bug.