Description of problem: Version-Release number of selected component (if applicable): # subscription-manager version server type: Red Hat Subscription Management subscription management server: 0.9.45-1 subscription management rules: 5.14 subscription-manager: 1.14.1-1.el6 python-rhsm: 1.14.1-1.el6 How reproducible: always Steps to Reproduce: 1. Enabled auto-heal on the system # subscription-manager auto-attach --enable Auto-attach preference: enabled 2# subscription-manager list --installed +-------------------------------------------+ Installed Product Status +-------------------------------------------+ Product Name: Awesome OS Server Bits Product ID: 37060 Version: 6.1 Arch: ALL Status: Not Subscribed Status Details: Not supported by a valid subscription. Starts: Ends: 3.Wait for the auto-attach process to complete [root@dhcp35-114 entitlement]# tail -f /var/log/rhsm/rhsmcertd.log Fri Mar 6 15:34:22 2015 [INFO] (Cert Check) Certificates updated. Fri Mar 6 15:35:17 2015 [INFO] (Cert Check) Certificates updated. Fri Mar 6 15:36:18 2015 [INFO] (Auto-attach) Certificates updated. Fri Mar 6 15:38:17 2015 [INFO] (Cert Check) Certificates updated. Fri Mar 6 15:38:19 2015 [INFO] (Auto-attach) Certificates updated. Fri Mar 6 15:40:19 2015 [INFO] (Auto-attach) Certificates updated. Fri Mar 6 15:41:17 2015 [INFO] (Cert Check) Certificates updated. Fri Mar 6 15:42:18 2015 [INFO] (Auto-attach) Certificates updated. Fri Mar 6 15:44:17 2015 [INFO] (Cert Check) Certificates updated. Fri Mar 6 15:44:18 2015 [INFO] (Auto-attach) Certificates updated. --------Fri Mar 6 15:46:19 2015 [INFO] (Auto-attach) Certificates updated. [root@dhcp35-114 entitlement]# subscription-manager auto-attach --disable Auto-attach preference: disabled 4.[root@dhcp35-114 entitlement]# subscription-manager list --consumed +-------------------------------------------+ Consumed Subscriptions +-------------------------------------------+ Subscription Name: Awesome OS with up to 4 virtual guests Provides: Awesome OS Server Bits SKU: awesomeos-virt-4 Contract: 2 Account: 12331131231 Serial: 5873392590627193143 Pool ID: ff8080814be9bfc9014be9c058321096 Provides Management: No Active: True Quantity Used: 1 Service Level: Service Type: Status Details: Subscription is current Subscription Type: Multi-Entitleable Starts: 03/05/2015 Ends: 03/06/2015 --> NOTE that the attached subscription is a 24 hour subscription System Type: Virtual [root@dhcp35-114 entitlement]# subscription-manager list --installed +-------------------------------------------+ Installed Product Status +-------------------------------------------+ Product Name: Awesome OS Server Bits Product ID: 37060 Version: 6.1 Arch: ALL Status: Partially Subscribed Status Details: Guest has not been reported on any host and is using a temporary unmapped guest subscription. Starts: 03/05/2015 Ends: 03/04/2016 ---->> Observed that end date of the subscription is displayed as "03/04/2016" Actual results: Expected results: Additional info:
Actual results: Observed a mismatch in "End date" in 'subscription-manager list --installed' Expected results: "End date" in installed product list should match the subscription "End date" from the consumed list
The start and end dates for 'Installed Product Status' reflect the dates on the *product* certificiate, not the entitlement certificate. These two sets of dates are not intended to be identical, it was coincidentally so when all certs had a 1 year life span.
(In reply to William Poteat from comment #2) > The start and end dates for 'Installed Product Status' reflect the dates on > the *product* certificiate, not the entitlement certificate. > > These two sets of dates are not intended to be identical, it was > coincidentally so when all certs had a 1 year life span. hm, looks like we are missing some points here. adding additional details from product and entitlement cert to confirm the observation # rct cc /etc/pki/entitlement/6975432568663614122.pem | more +-------------------------------------------+ Entitlement Certificate +-------------------------------------------+ Certificate: Path: /etc/pki/entitlement/6975432568663614122.pem Version: 3.2 Serial: 6975432568663614122 Start Date: 2015-03-11 00:00:00+00:00 End Date: 2015-03-12 05:23:17+00:00 --> Entitlement Validity Pool ID: ff8080814c074718014c0747bb061ab2 Subject: CN: ff8080814c074718014c074985fd2268 Issuer: C: US CN: 10.70.35.174 L: Raleigh Product: ID: 37060 Name: Awesome OS Server Bits Version: 6.1 Arch: ALL Tags: Brand Type: OS Brand Name: Branded Awesome OS Virtual Datacenter Order: Name: Awesome OS Virtual Datacenter Number: order-8675309 SKU: awesomeos-virt-datacenter [root@dhcp35-114 ~]# rct cc /etc/pki/product/37060.pem +-------------------------------------------+ Product Certificate +-------------------------------------------+ Certificate: Path: /etc/pki/product/37060.pem Version: 1.0 Serial: 48785926 Start Date: 2015-03-02 08:54:46+00:00 End Date: 2025-03-02 08:54:46+00:00 --> product cert Validity Subject: CN: 37060 Issuer: C: US CN: 10.70.35.174 L: Raleigh Product: ID: 37060 Name: Awesome OS Server Bits Version: 6.1 Arch: ALL Tags: Brand Type: OS Brand Name: # subscription-manager list --consumed +-------------------------------------------+ Consumed Subscriptions +-------------------------------------------+ Subscription Name: Awesome OS Virtual Datacenter Provides: Awesome OS Server Bits SKU: awesomeos-virt-datacenter Contract: 1 Account: 12331131231 Serial: 6975432568663614122 Pool ID: ff8080814c074718014c0747bb061ab2 Provides Management: No Active: True Quantity Used: 1 Service Level: Service Type: Status Details: Guest has not been reported on any host and is using a temporary unmapped guest subscription. Subscription Type: Standard Starts: 03/11/2015 Ends: 03/12/2015 System Type: Virtual # subscription-manager list --installed +-------------------------------------------+ Installed Product Status +-------------------------------------------+ Product Name: Awesome OS Server Bits Product ID: 37060 Version: 6.1 Arch: ALL Status: Subscribed Status Details: Starts: 03/11/2015 Ends: 03/10/2016 Note: From the above product and entitlement certificate details its observed that the product cert validity is for 10 yrs [snip] Certificate: Path: /etc/pki/product/37060.pem Version: 1.0 Serial: 48785926 Start Date: 2015-03-02 08:54:46+00:00 End Date: 2025-03-02 08:54:46+00:00 --> product cert Validity [snip] and the entitlement cert validity for one day [snip] Path: /etc/pki/entitlement/6975432568663614122.pem Version: 3.2 Serial: 6975432568663614122 Start Date: 2015-03-11 00:00:00+00:00 End Date: 2015-03-12 05:23:17+00:00 --> Entitlement Validity Pool ID: ff8080814c074718014c0747bb061ab2 [snip] But still the installed product displayed validity for 1 year Starts: 03/11/2015 Ends: 03/10/2016 Moving this bug back to "assigned" for re-checking
I'm going to flip this to a subscription-manager bug since it looks like the problem is not with the actual dates in the certs but in the display of the dates. The dates that are actually baked into both the entitlement certificate and product certificate are correct (as seen in the RCT output in comment #3).
I believe these dates are caclulated server side via rules, it's not for an entitlement, it's the valid range for an installed product, across all possible entitlements and stacks.
commit 00bbb30cfd27713e7ed41f50e71e50c1ce076d02 Author: Devan Goodwin <dgoodwin> Date: Mon Mar 16 12:00:13 2015 -0300 1199443: Add entitlement end date override. In the past both pools and entitlements had a start/end date. This was removed as the data was redundant at the time, however the Entitlement getEndDate() and setEndDate() methods remained for API compatability, and just returned the pool's values. With the addition of 24h unmapped guest entitlements, we actually want to have entitlements with a different end date than the pool. This was implemented by stamping the correct date in the cert, but not available anywhere else in the code causing issues with things like installed product validity date ranges. Fixed by adding an entitlement end date override. getEndDate() will return this value if it's set, otherwise resort to the pools. Compliance code was already properly set up to use the entitlement end date due to the original implementation. (from getEndDate)
Will appear in candlepin-0.9.47.