Bug 1226007

Summary:	rpm-ostree rebase can cause wrong remote to get used
Product:	Red Hat Enterprise Linux 7	Reporter:	Dusty Mabe <dustymabe>
Component:	subscription-manager	Assignee:	Chris Snyder <csnyder>
Status:	CLOSED NOTABUG	QA Contact:	John Sefler <jsefler>
Severity:	medium	Docs Contact:
Priority:	high
Version:	7.2	CC:	csnyder, dustymabe, ghelleks, gscrivan, hpopal, jkrieger, miabbott, ovasik, redakkan, skallesh, vrjain
Target Milestone:	rc	Keywords:	Extras, Rebase, Triaged
Target Release:	7.4
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Rebase: Bug Fixes and Enhancements
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-10-05 20:42:53 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 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.