Bug 1019992

Summary:	Subscription-manager removes RHUI client certificates under /etc/pki/entitlement during "subscription-manager clean"
Product:	Red Hat Enterprise Linux 7	Reporter:	dgao
Component:	subscription-manager	Assignee:	candlepin-bugs
Status:	CLOSED WONTFIX	QA Contact:	John Sefler <jsefler>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.0	CC:	alikins, bkearney, dgao, dgoodwin, ipanova, tsanders, vkuznets
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	1011082	Environment:
Last Closed:	2013-10-21 14:52:20 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:
Bug Depends On:
Bug Blocks:	863175

Description dgao 2013-10-16 18:13:32 UTC

+++ This bug was initially created as a clone of Bug #1011082 +++

Description of problem:
After installing rhel5.10 with no changes made on it perform 'subscription-manager clean' command. After that, any yum command(yum install, update, repolist, etc.) fails.

Version-Release number of selected component (if applicable):
subscription-manager-1.8.22-1.el5

How reproducible:
always

Steps to Reproduce:

[root@ip-10-245-114-124 ~]# rpm -qa subscription-manager
subscription-manager-1.8.22-1.el5
[root@ip-10-245-114-124 ~]# yum repolist
Loaded plugins: amazon-id, fastestmirror, product-id, rhui-lb, security
Determining fastest mirrors
 * rhui-REGION-client-config-server-5: rhui2-cds01.us-east-1.aws.ce.redhat.com
 * rhui-REGION-rhel-server: rhui2-cds01.us-east-1.aws.ce.redhat.com
rhui-REGION-client-config-server-5                                                                                                                                                          | 2.3 kB     00:00     
rhui-REGION-client-config-server-5/primary_db                                                                                                                                               | 4.5 kB     00:00     
rhui-REGION-rhel-server                                                                                                                                                                     | 3.7 kB     00:00     
rhui-REGION-rhel-server/primary_db                                                                                                                                                          | 7.6 MB     00:00     
Excluding Packages from Red Hat Enterprise Linux Server 5 (RPMs)
Finished
repo id                                                                               repo name                                                                                                           status
rhui-REGION-client-config-server-5                                                    Red Hat Update Infrastructure 2.0 Client Configuration Server 5                                                             3
rhui-REGION-rhel-server                                                               Red Hat Enterprise Linux Server 5 (RPMs)                                                                            15,263+80
repolist: 15,266
[root@ip-10-245-114-124 ~]# subscription-manager list
No installed products to list
[root@ip-10-245-114-124 ~]# yum repolist
Loaded plugins: amazon-id, fastestmirror, product-id, rhui-lb, security
Loading mirror speeds from cached hostfile
 * rhui-REGION-client-config-server-5: rhui2-cds01.us-east-1.aws.ce.redhat.com
 * rhui-REGION-rhel-server: rhui2-cds01.us-east-1.aws.ce.redhat.com
Excluding Packages from Red Hat Enterprise Linux Server 5 (RPMs)
Finished
repo id                                                                               repo name                                                                                                           status
rhui-REGION-client-config-server-5                                                    Red Hat Update Infrastructure 2.0 Client Configuration Server 5                                                             3
rhui-REGION-rhel-server                                                               Red Hat Enterprise Linux Server 5 (RPMs)                                                                            15,263+80
repolist: 15,266
[root@ip-10-245-114-124 ~]# subscription-manager clean
All local data removed
[root@ip-10-245-114-124 ~]# yum repolist
Loaded plugins: amazon-id, fastestmirror, product-id, rhui-lb, security
Loading mirror speeds from cached hostfile
 * rhui-REGION-client-config-server-5: rhui2-cds01.us-east-1.aws.ce.redhat.com
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in ?
    yummain.user_main(sys.argv[1:], exit_code=True)
  File "/usr/share/yum-cli/yummain.py", line 309, in user_main
    errcode = main(args)
  File "/usr/share/yum-cli/yummain.py", line 178, in main
    result, resultmsgs = base.doCommands()
  File "/usr/share/yum-cli/cli.py", line 349, in doCommands
    return self.yum_cli_commands[self.basecmd].doCommand(self, self.basecmd, self.extcmds)
  File "/usr/share/yum-cli/yumcommands.py", line 788, in doCommand
    base.repos.populateSack()
  File "/usr/lib/python2.4/site-packages/yum/repos.py", line 232, in populateSack
    self.doSetup()
  File "/usr/lib/python2.4/site-packages/yum/repos.py", line 79, in doSetup
    self.ayum.plugins.run('postreposetup')
  File "/usr/lib/python2.4/site-packages/yum/plugins.py", line 179, in run
    func(conduitcls(self, self.base, conf, **kwargs))
  File "/usr/lib/yum-plugins/fastestmirror.py", line 205, in postreposetup_hook
    repo.setupGrab()
  File "/usr/lib/python2.4/site-packages/yum/yumRepo.py", line 463, in setupGrab
    self._setupGrab()
  File "/usr/lib/python2.4/site-packages/yum/yumRepo.py", line 474, in _setupGrab
    ugopts = self._default_grabopts()
  File "/usr/lib/python2.4/site-packages/yum/yumRepo.py", line 486, in _default_grabopts
    opts = { 'keepalive': self.keepalive,
  File "/usr/lib/python2.4/site-packages/yum/yumRepo.py", line 656, in _getSslContext
    sslCtx.load_cert(self.sslclientcert, self.sslclientkey)
  File "/usr/lib64/python2.4/site-packages/M2Crypto/SSL/Context.py", line 74, in load_cert
    m2.ssl_ctx_use_cert(self.ctx, certfile)
M2Crypto.SSL.SSLError: No such file or directory


Actual results:
yum command fails 

Expected results:

yum should work normally

Additional info:

--- Additional comment from John Sefler on 2013-09-23 12:26:07 EDT ---

The problem that I found on this system is here...

[root@ip-10-164-16-250 yum.repos.d]# ls /etc/pki/entitlement/
ca.crt  cdn.redhat.com-chain.crt  content-rhel5.key  product  rhui-client-config-server-5.key

Why are these RHUI certificates located in /etc/pki/entitlement/ ?

The /etc/pki/entitlement/ directory is a default configuration used by subscription-manager...
[root@ip-10-164-16-250 ~]# grep entitlement /etc/rhsm/rhsm.conf 
entitlementCertDir = /etc/pki/entitlement

When subscription-manager clean is executed, the contents of /etc/pki/entitlement/ are deleted which screws up all of these redhat-rhui repo files that are pointing to certificates in /etc/pki/entitlement

[root@ip-10-164-16-250 ~]# grep "/etc/pki/entitlement" /etc/yum.repos.d/*.repo
/etc/yum.repos.d/redhat-rhui-client-config.repo:sslcacert=/etc/pki/entitlement/cdn.redhat.com-chain.crt
/etc/yum.repos.d/redhat-rhui-client-config.repo:sslclientcert=/etc/pki/entitlement/product/rhui-client-config-server-5.crt
/etc/yum.repos.d/redhat-rhui-client-config.repo:sslclientkey=/etc/pki/entitlement/rhui-client-config-server-5.key
/etc/yum.repos.d/redhat-rhui.repo:sslclientkey=/etc/pki/entitlement/content-rhel5.key
/etc/yum.repos.d/redhat-rhui.repo:sslclientcert=/etc/pki/entitlement/product/content-rhel5.crt
/etc/yum.repos.d/redhat-rhui.repo:sslcacert=/etc/pki/entitlement/cdn.redhat.com-chain.crt
/etc/yum.repos.d/redhat-rhui.repo:sslclientkey=/etc/pki/entitlement/content-rhel5.key
/etc/yum.repos.d/redhat-rhui.repo:sslclientcert=/etc/pki/entitlement/product/content-rhel5.crt
/etc/yum.repos.d/redhat-rhui.repo:sslcacert=/etc/pki/entitlement/cdn.redhat.com-chain.crt
/etc/yum.repos.d/redhat-rhui.repo:sslclientkey=/etc/pki/entitlement/content-rhel5.key
/etc/yum.repos.d/redhat-rhui.repo:sslclientcert=/etc/pki/entitlement/product/content-rhel5.crt
/etc/yum.repos.d/redhat-rhui.repo:sslcacert=/etc/pki/entitlement/cdn.redhat.com-chain.crt
/etc/yum.repos.d/redhat-rhui.repo:sslclientkey=/etc/pki/entitlement/content-rhel5.key
/etc/yum.repos.d/redhat-rhui.repo:sslclientcert=/etc/pki/entitlement/product/content-rhel5.crt
/etc/yum.repos.d/redhat-rhui.repo:sslcacert=/etc/pki/entitlement/cdn.redhat.com-chain.crt


It seems to me that an arm wrestling match between the RHUI team and the RHSM team over the right to write to /etc/pki/entitlement/ is in order.

--- Additional comment from Vitaly Kuznetsov on 2013-09-24 05:29:08 EDT ---

(In reply to John Sefler from comment #1)
> Why are these RHUI certificates located in /etc/pki/entitlement/ ?
> 
> The /etc/pki/entitlement/ directory is a default configuration used by
> subscription-manager...
> 
> When subscription-manager clean is executed, the contents of
> /etc/pki/entitlement/ are deleted which screws up all of these redhat-rhui
> repo files that are pointing to certificates in /etc/pki/entitlement

Subscription-manager's behavior here doesn't seem correct:
1) If this directory is RHSM-specific - why is has so generalized name? Why not "/etc/pki/rhsm/entitlements"?
2) Why does subscription-manager remove _all_ content from directory no matter who brought it here? Files in "/etc" are usually supposed to be edited/added by humans.
3) If this directory is rhsm-specific data/cache - why it is not under "/var"?

--- Additional comment from Adrian Likins on 2013-10-15 17:50:04 EDT ---

(In reply to Vitaly Kuznetsov from comment #2)
> (In reply to John Sefler from comment #1)
> > Why are these RHUI certificates located in /etc/pki/entitlement/ ?
> > 
> > The /etc/pki/entitlement/ directory is a default configuration used by
> > subscription-manager...
> > 
> > When subscription-manager clean is executed, the contents of
> > /etc/pki/entitlement/ are deleted which screws up all of these redhat-rhui
> > repo files that are pointing to certificates in /etc/pki/entitlement
> 
> Subscription-manager's behavior here doesn't seem correct:
> 1) If this directory is RHSM-specific - why is has so generalized name? Why
> not "/etc/pki/rhsm/entitlements"?

  No idea. "historical reasons". The content is meant to be managed by subscription-manager, and used by yum. 

> 2) Why does subscription-manager remove _all_ content from directory no
> matter who brought it here? Files in "/etc" are usually supposed to be
> edited/added by humans.

  Tend to agree it shouldn't delete stuff it didn't put there. But then again,
manually provisioning rhsm entitlement certs there is more or less supported (for disconnected, or loosely connected scenarios). Not deleting unknown ent certs (or anything unknown) on "clean" seems reasonable.

> 3) If this directory is rhsm-specific data/cache - why it is not under
> "/var"?

   Not really a cache (yum is setup to assume those certs exists, and doesn't do anything to refresh them if not). /etc/pki/ is the normal place for installing certificates.

Comment 2 Devan Goodwin 2013-10-21 14:52:20 UTC

RHUI is now placing their certs in their own location. 

I am extremely hesitant to fix this, ideally yes it would be nice if the directory was named to be rhsm specific, but /etc/pki is probably the correct location for the certificates.

There is no concept of "known" certificates, we support disconnected scenarios where certificates can be manually imported. Trying to track which ones we put there, where they came from, and whether or not someone dropped one in place by themselves is a big increase in complexity and risk for bugs. /etc/pki/entitlement has been subscription-manager certs since day one, nothing else can/should write there. 

Changing this at this point is going to introduce more problems, and there is almost nothing gained by doing so as far as I can tell. I am going to close as a WONTFIX, if anyone feels strongly that this must be done and there is a tangible benefit to doing so then please reopen and state the case but I really do not want to take the upgrade risk and increase in complexity if we don't need to.