Bug 660713
| Summary: | The start/end dates within the product name space of an entitlement cert is getting its time truncated | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | John Sefler <jsefler> | ||||
| Component: | subscription-manager | Assignee: | Jesus M. Rodriguez <jesusr> | ||||
| Status: | CLOSED ERRATA | QA Contact: | John Sefler <jsefler> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 6.1 | CC: | bkearney, jesusr, jomara | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-05-19 13:38:00 UTC | Type: | --- | ||||
| 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: | 639436 | ||||||
| Attachments: |
|
||||||
My comments:
=-=-=-=-=-=-=-
Validity
Not Before: Dec 2 22:41:49 2010 GMT
=> contains the time at which the entitlement certificate was created.
Not After : Dec 2 23:59:59 2011 GMT
=> subscription end date rounded off to midnight.
1.3.6.1.4.1.2312.9.4.6:
..2010-12-02T00:00:00Z => subscription's start date stored in datbase.
1.3.6.1.4.1.2312.9.4.7:
..2011-12-02T00:00:00Z => subs' end date stored in database.
The dates are truncated because, its the way they are stored in the database. (please look at cp_subscription table)
The subs' end date should also be rounded off to midnight. This piece of functionality was missing in candlepin. I have pushed in changes to do this.
Commit sha:
e391c1dc18a98b9928a0ec77ccb8f76e71070e2a refs/heads/master
Fields after commit:
-=-=-==-=-=-=-=-=-=-=
Validity
Not Before: Dec 9 21:04:13 2010 GMT
Not After : Dec 9 23:59:59 2011 GMT
1.3.6.1.4.1.2312.9.4.6:
..2010-12-09T00:00:00Z
1.3.6.1.4.1.2312.9.4.7:
..2011-12-09T23:59:59Z
Clarification: <quote> The dates are truncated because, its the way they are stored in the database. </quote> What I meant was, the dates are truncated because, its the raw data present in the database. Candlepin does not perform any truncating operation to remove time fields. Problem 2 remains: The client tools (subscription-manager cli/gui) still need to include the time when displaying the start/end dates to the user in all the subscription-manager list commands because displaying only the localized date (without the time of day) is in insufficient. The localized expiration will NOT be at midnight in every time zone. In my opinion, the start/end dates as found in the database should be left as-is (not rounded off to midnight GMT). Rounding off to midnight GMT does NOT mean that my subscription (in Raleigh) expires at midnight EST. The confusion with dates would be resolved if 1. the dates in the database are used as-is without rounding to midnight, and 2. the dates presented in the client tools are presented localized with the time of day (hour/min) included. Here is a demonstration of why I suspect rounding the expiration date to midnight causes problems and the issues in Comment#4 still exist.... Here it is 4:40pm in the afternoon EST and the following available pool says it expires on 2011-12-10 201012111640:04.572 - FINE: ssh root.redhat.com subscription-manager list --available (com.redhat.qe.tools.SSHCommandRunner.run) 201012111640:09.329 - FINE: Stdout: +-------------------------------------------+ Available Subscriptions +-------------------------------------------+ ProductName: Basic RHEL Server ProductId: MKT-simple-rhel-server-mkt PoolId: ff8080812cd3ceb8012cd3cf98540162 Quantity: 10 Expires: 2011-12-10 Now we will subscribe to the pool... 201012111640:10.356 - FINE: ssh root.redhat.com subscription-manager subscribe --pool=ff8080812cd3ceb8012cd3cf98540162 (com.redhat.qe.tools.SSHCommandRunner.run) and run list --consumed... 201012111640:18.115 - FINE: ssh root.redhat.com subscription-manager list --consumed (com.redhat.qe.tools.SSHCommandRunner.run) 201012111640:18.416 - FINE: Stdout: +-------------------------------------------+ Consumed Product Subscriptions +-------------------------------------------+ ProductName: RHEL for Physical Servers SVC ContractNumber: 31 AccountNumber: 12331131231 SerialNumber: 11292103611059235 Active: True Begins: 2010-12-10 Expires: 2011-12-11 Notice that the product expired on 2011-12-10 before we subscribed and expires on 2011-12-11 after we subscribed. That's a problem. VERIFYING VERSION: [root@jsefler-betaqa-1 ~]# subscription-manager unsubscribe --all [root@jsefler-betaqa-1 ~]# rpm -qa | grep subscription-manager subscription-manager-gnome-0.93.13-1.git.9.c3d0720.el6.x86_64 subscription-manager-0.93.13-1.git.9.c3d0720.el6.x86_64 subscription-manager-firstboot-0.93.13-1.git.9.c3d0720.el6.x86_64 [root@jsefler-betaqa-1 ~]# rpm -qa | grep python-rhsm python-rhsm-0.94.15-1.git.0.b738ea1.el6.noarch [root@jsefler-betaqa-1 ~]# curl -k -u jsefler-qabetauser-4:redhat https://subscriptions.rhn.webqa.redhat.com:443/subscription/status {"version":"0.1.30","result":true,"release":"1%{?dist}"}[root@jsefler-betaqa-1 ~]# [root@jsefler-betaqa-1 ~]# subscription-manager list --available +-------------------------------------------+ Available Subscriptions +-------------------------------------------+ ProductName: Red Hat Enterprise Linux Server Entitlement Beta for Certified Engineers and System Administrators - NOT FOR SALE ProductId: RH3036913 PoolId: 8a9b90882da9ac9f012da9e5e991000e Quantity: 10 Expires: 2011-07-19 [root@jsefler-betaqa-1 ~]# date Fri Jan 21 14:26:28 EST 2011 [root@jsefler-betaqa-1 ~]# subscription-manager subscribe --pool=8a9b90882da9ac9f012da9e5e991000e [root@jsefler-betaqa-1 ~]# openssl x509 -text -in /etc/pki/entitlement/81295638102955196.pem | grep -A2 Validity Validity Not Before: Jan 21 19:26:47 2011 GMT Not After : Jul 20 03:59:59 2011 GMT [root@jsefler-betaqa-1 ~]# openssl x509 -text -in /etc/pki/entitlement/81295638102955196.pem | grep -A3 1.3.6.1.4.1.2312.9.4.6 1.3.6.1.4.1.2312.9.4.6: ..2011-01-20T05:00:00Z 1.3.6.1.4.1.2312.9.4.7: ..2011-07-20T03:59:59Z [root@jsefler-betaqa-1 ~]# ^^^ VERIFIED The Validity Not Before matches the creation time of the entitlemnt The Validity Not After matches the Expires day (Jul 20 03:59:59 2011 GMT - 5 hours to local EST is 2011-07-19) The EndDate in the order namespace (2011-07-20T03:59:59Z) matches the Validity Not After (Jul 20 03:59:59 2011 GMT) The StartDate in the order namespace (2011-01-20T05:00:00) is the first tick of the subscriptions' start date (20 January 2011 as shown in kingpin - see attachement) Created attachment 474680 [details]
Note the Start Day matches the ordernamespace startDate in the entitlement cert on the system
Will drop the issue in problem 2 of Comment#4 for now. Apparently this issue is accepted by finance who regards Red Hat Standard Time (EST) to be the start and end of every day. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2011-0611.html |
Description of problem: After subscribing to a pool, an entitlement cert is dropped. Inside the entitlement cert are two sets of dates (that currently do not match) they should match... [root@jsefler-onprem01 ~]# openssl x509 -text -in /etc/pki/entitlement11291329709849150.pem | grep -A2 Validity Validity Not Before: Dec 2 22:41:49 2010 GMT Not After : Dec 2 23:59:59 2011 GMT [root@jsefler-onprem01 ~]# openssl x509 -text -in /etc/pki/entitlement11291329709849150.pem | grep -A3 1.3.6.1.4.1.2312.9.4.6 1.3.6.1.4.1.2312.9.4.6: ..2010-12-02T00:00:00Z 1.3.6.1.4.1.2312.9.4.7: ..2011-12-02T00:00:00Z Notice the end date in the product name space is 2011-12-02T00:00:00Z which is 23h:59m:59s earlier in the day than Validity Not After Dec 2 23:59:59 2011 GMT. Moreover, I believe that the name space time is then being localized to render to the user expires dates when calling: subscription-manager list --available --all subscription-manager list --available subscription-manager list --consumed subscription-manager list I believe this because if you localize 2011-12-02T00:00:00Z to my local EST (Raleigh) time, it is actually 2011-12-01 19:00:00 which is then displayed to the user as: [root@jsefler-onprem01 ~]# subscription-manager list --consumed +-------------------------------------------+ Consumed Product Subscriptions +-------------------------------------------+ ProductName: Flexible Hypervisor(Premium Architectures-15-pack) ContractNumber: 19 AccountNumber: 12331131231 SerialNumber: 11291329709849150 Active: True Begins: 2010-12-01 Expires: 2011-12-01 Problem 1: On what minute will the consumed product expire? midnight on 2011-12-01? - wrong. It actually expires the next day on Dec 2 23:59:59 2011 GMT which is 2011-12-02 18:59:59 EST (Raleigh time) Problem 2: You need to include the time when displaying the start/end dates to the user in all the subscription-manager list commands because displaying only the localized date in insufficient. The localized expiration will NOT be at midnight in every time zone.