I fear we can't just leave a previously generated redhat.repo laying around as subscription changes can then alter what the system actually has access too, the file is stale, and yum will then stop functioning entirely until someone addresses the discrepancy, which would not be feasible in the case of RH subscriptions.

The manage_repos feature means "do not generate a redhat.repo", and once enabled we make sure to clear the file out so this breakage does not occur.

What is the use case for requiring subscription-manager to generate a redhat.repo, but then stop keeping it updated?

The man page for rhsm.conf states...
[root@jsefler-7 ~]# man rhsm.conf | grep manage_repos -A6
       manage_repos
           Set this to 1 if subscription manager should manage a
           yum repos file. If set, it will manage the file
           /etc/yum.repos.d/redhat.repo. If set to 0 then the
           subscription is only used for tracking purposes, not
           content.

The header of the redhat.repo explicitly states...
[root@jsefler-7 ~]# cat /etc/yum.repos.d/redhat.repo 
#
# Certificate-Based Repositories
# Managed by (rhsm) subscription-manager
#
# *** This file is auto-generated.  Changes made here will be over-written. ***
# *** Use "subscription-manager repo-override --help" if you wish to make changes. ***
#
# If this file is empty and this system is subscribed consider 
# a "yum repolist" to refresh available repos
#


Based on these descriptions and my understanding of rhsm, setting manage_repos=0 means that all access to "content" from attached entitlements will cease.  The most effective way to make that cease is for the redhat.repo to go blank or go away.  I believe subscription-manager is doing the right thing when manage_repos is set to 0.

Maybe this bug should be used to explicitly state in the rhsm.conf man page that "If set to 0 then attached subscriptions will only used for system tracking purposes, not system access to content.  The /etc/yum.repos.d/redhat.repo will either be purged or deleted."

A man page update sounds fair to me.

(In reply to Devan Goodwin from comment #2)
> What is the use case for requiring subscription-manager to generate a
> redhat.repo, but then stop keeping it updated?

I too am curious why you would need to take a perfectly well managed Red Hat yum repository, freeze it in time and allow it to go stale.  Please realize that if you did that, the certificates referenced in the stale redhat.repo could easily be removed by subscription-manager or revoked at the Customer Portal thereby causing yum to choke on the stale redhat.repo file.

The only use-case I can think of would be to preserve a currently-working repo config against accidental changes from remote overrides. I agree it doesn't make a lot of sense, but in my experience one should anticipate customers will find legitimate reasons to do stuff that doesn't make sense. :)

My main concern was that customers might respond to this behavior by copying out the working `redhat.repo` file to e.g. `our_redhat.repo` and then set `manage_repos` to 0. At the time I filed the bug, this would have broken a tool that I maintain for OpenShift Enterprise - it was using the `repofile` attribute to determine if a `YumRepo` were managed by RHSM, "plain old yum" or RHN.

Since then, I found a different (and more correct) way to do this detection - checking the `RepoActionInvoker` `is_managed` method for systems with newer subscription-manager versions, and falling back to checking the `sslcacert`, `sslclientcert`, etc. and `repofile` on the `YumRepo` for older subscription-manager versions. As far as my needs, this bug is no longer a priority.

That said, I do think this behavior should be documented, so I'm totally on board with the man page update.

Manpage updated in subscription-manager.git d197b9c73fb8e4e8861ed0a1cfb60363cfc776a2

Will appear in: subscription-manager-1.14.3-1

Retested ,

subscription-manager: 1.14.3-1.el6
subscription-manager-gui-1.14.3-1.el6.x86_64
python-rhsm: 1.14.2-1.el6


Man page of rhsm.conf is now updated with,

# man rhsm.conf | grep manage_repos -A6
       manage_repos
           Set this to 1 if subscription manager should manage a yum repos
           file. If set, it will manage the file /etc/yum.repos.d/redhat.repo.
           If set to 0 then the subscription is only used for tracking
           purposes, not content. The /etc/yum.repos.d/redhat.repo file will
           either be purged or deleted.

Moving to Verified.

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://rhn.redhat.com/errata/RHBA-2015-1345.html