Bug 1594709

Dev, please check 2.3 branch and 2.4 branch for this issue and reach out to me with the results.

I'm able to reproduce it using master branch of subscription-manager and candlepin, but only in situation, when subscription-manager is running on host (not in VM).

Steps to reproduce (Candlepin server):

1. git clone https://github.com/candlepin/candlepin.git
2. cd candlepin
3. vagrant up dev
4. vagrant ssh dev
5. cd /vagrant
6. ./server/bin/deploy -gta


Steps to reproduce (host running subscription-manager)

1. Get master branch of subman

[root@localhost /tmp]# git clone https://github.com/candlepin/subscription-manager.git

2. Change directory

[root@localhost subscription_manager]# cd subscription-manager

3. Install all required packages; see: https://www.candlepinproject.org/docs/subscription-manager/installation.html

4. Build subscription-manager

[root@localhost subscription_manager]# make

5. Register system

[root@localhost subscription_manager]# PYTHONPATH=./src python -m subscription_manager.scripts.subscription_manager register --username admin --password admin --org admin
Registering to: svice:8443/candlepin
The system has been registered with ID: 1db20c01-caf8-4e01-87b7-d4c407316724
The registered system name is: localhost.localdomain

6. Attach some pool (e.g. using auto attach)

[root@localhost subscription_manager]# ll /etc/pki/product-default/
total 4
-rwxr-xr-x. 1 root root 1289 Jan 23 17:43 32060.pem


[root@localhost subscription_manager]# PYTHONPATH=./src python -m subscription_manager.scripts.rct cc /etc/pki/product-default/32060.pem 

+-------------------------------------------+
	Product Certificate
+-------------------------------------------+

Certificate:
	Path: /etc/pki/product-default/32060.pem
	Version: 1.0
	Serial: 48636971
	Start Date: 2018-01-23 08:43:50+00:00
	End Date: 2028-01-23 08:43:50+00:00

Subject:
	CN: 32060

Issuer:
	C: US
	CN: candle.localdomain
	L: Raleigh

Product:
	ID: 32060
	Name: Awesome OS Instance Server Bits
	Version: 6.1
	Arch: ALL
	Tags: 
	Brand Type: OS
	Brand Name: 


[root@localhost subscription_manager]# PYTHONPATH=./src python -m subscription_manager.scripts.subscription_manager attach --auto
Installed Product Current Status:
Product Name: Awesome OS Instance Server Bits
Status:       Subscribed


7. Get information about consumed subscription

[root@localhost subscription_manager]# PYTHONPATH=./src python -m subscription_manager.scripts.subscription_manager list --consumed
+-------------------------------------------+
   Consumed Subscriptions
+-------------------------------------------+
Subscription Name:   Admin OS Instance Based one socket
Provides:            Awesome OS Instance Server Bits
                     Admin OS Premium Architecture Bits
                     Admin OS Developer Bits
SKU:                 adminos-onesocketib
Contract:            1
Account:             12331131231
Serial:              2209513736220810456
Pool ID:             Not Available    <============ Pool ID is not available
Provides Management: Yes
Active:              True
Quantity Used:       2
Service Level:       Standard
Service Type:        L1-L3
Status Details:      Subscription is current
Subscription Type:   
Starts:              06/26/18
Ends:                06/26/19
System Type:         Physical

Created attachment 1454693 [details]
candlepin.log for 1594709

Created attachment 1454694 [details]
rhsm.log for 1594709

Jiri,

I haven't been able to reproduce this issue at all.  Would you mind doing me a favor and adding 

log4j.logger.org.candlepin.common.filter=DEBUG

to /etc/candlepin/candlepin.conf and then restarting Tomcat?

Also, on the client if you wouldn't mind setting

[logging]
default_logging_level=DEBUG

and then running a subscription-manager clean, re-register, re-attach to the pool, and then run subscription-manager list --consumed.  After all that, if you could bundle up rhsm.log and candlepin.log, hopefully I can track this down.

Alex,
this is interesting. It seems that the entitlement certificate was generated without Pool ID:

[root@localhost subscription-manager]# PYTHONPATH=./src python -m subscription_manager.scripts.subscription_manager attach --pool=ff80808164455a240164455aae5701b4
Successfully attached a subscription for: Admin OS Instance Based one socket
[root@localhost subscription-manager]# PYTHONPATH=./src python -m subscription_manager.scripts.subscription_manager list --consumed
+-------------------------------------------+
   Consumed Subscriptions
+-------------------------------------------+
Subscription Name:   Admin OS Instance Based one socket
Provides:            Awesome OS Instance Server Bits
                     Admin OS Premium Architecture Bits
                     Admin OS Developer Bits
SKU:                 adminos-onesocketib
Contract:            0
Account:             12331131231
Serial:              5554812566954359453
Pool ID:             Not Available
Provides Management: Yes
Active:              True
Quantity Used:       2
Service Level:       Standard
Service Type:        L1-L3
Status Details:      Subscription is current
Subscription Type:   
Starts:              28.6.2018
Ends:                28.6.2019
System Type:         Physical

[root@localhost subscription-manager]# PYTHONPATH=./src python -m subscription_manager.scripts.rct cc /etc/pki/entitlement/5554812566954359453.pem 

+-------------------------------------------+
	Entitlement Certificate
+-------------------------------------------+

Certificate:
	Path: /etc/pki/entitlement/5554812566954359453.pem
	Version: 1.0
	Serial: 5554812566954359453
	Start Date: 2018-06-28 00:00:00+00:00
	End Date: 2019-06-28 00:00:00+00:00
	Pool ID: Not Available   <=============== Pool ID is not available

Subject:
	CN: d74929836b574c329ddd8a626e21d14a
	O: admin

Issuer:
	C: US
	CN: candlepin.example.com
	L: Raleigh

Product:
	ID: 5050
	Name: Admin OS Premium Architecture Bits
	Version: 6.1
	Arch: ppc64
	Tags: 
	Brand Type: 
	Brand Name:


I'm also providing another log files (rhsm.log and candlepin.log) for this case. 

I can also confirm that generated cert sent by candlepin in response doesn't include Pool ID too. The cert is sent twice and the content of cert is same in both responses.

Created attachment 1455233 [details]
candlepin.log for 1594709 (more debug info)

Created attachment 1455234 [details]
rhsm.log for 1594709 (more debug info)

When version of generated certificate is 1.0 and not 3.x, then it generates certificate with missing Pool ID. You can influence it using:

[root@localhost subscription-manager]# PYTHONPATH=./src python -m subscription_manager.scripts.subscription_manager facts | grep certificate
system.certificate_version: 1.0

In following case it generates correct certificate:

[root@localhost subscription-manager]# PYTHONPATH=./src python -m subscription_manager.scripts.subscription_manager facts | grep certificate
system.certificate_version: 3.2

You can test it using fact overrides.

(In reply to Jiri Hnidek from comment #10)
> When version of generated certificate is 1.0 and not 3.x, then it generates
> certificate with missing Pool ID. You can influence it using:

Ah ha!  Would you mind attaching the offending entitlement certificate to the bug?

Jiri,

I'm pretty sure this is working as designed.  If you look at test/certdata.py you'll see the ENTITLEMENT_CERT_V1_0_OUTPUT (the expected output for the test) has Pool ID as "Not Available".  V1 entitlement certificates just didn't have pool ID available.  V3 certificates carry a blob of gzipped json in the "BEGIN ENTITLEMENT DATA" section of the PEM file that does have the pool ID.  There probably aren't very many V1 clients out there but we still support them.