Bug 660713 - The start/end dates within the product name space of an entitlement cert is getting its time truncated
Summary: The start/end dates within the product name space of an entitlement cert is g...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: subscription-manager
Version: 6.1
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: rc
: ---
Assignee: Jesus M. Rodriguez
QA Contact: John Sefler
URL:
Whiteboard:
Depends On:
Blocks: Entitlement-Beta
TreeView+ depends on / blocked
 
Reported: 2010-12-07 16:43 UTC by John Sefler
Modified: 2011-05-19 13:38 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-19 13:38:00 UTC
Target Upstream Version:


Attachments (Terms of Use)
Note the Start Day matches the ordernamespace startDate in the entitlement cert on the system (126.85 KB, image/png)
2011-01-21 20:19 UTC, John Sefler
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2011:0611 normal SHIPPED_LIVE new package: subscription-manager 2011-05-18 17:56:21 UTC

Description John Sefler 2010-12-07 16:43:42 UTC
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.

Comment 2 Ajay Kumar Nadathur Sreenivasan 2010-12-09 21:03:42 UTC
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

Comment 3 Ajay Kumar Nadathur Sreenivasan 2010-12-09 21:11:59 UTC
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.

Comment 4 John Sefler 2010-12-12 19:43:51 UTC
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.

Comment 5 John Sefler 2010-12-13 04:24:20 UTC
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@jsefler-onprem01.usersys.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@jsefler-onprem01.usersys.redhat.com subscription-manager subscribe --pool=ff8080812cd3ceb8012cd3cf98540162 (com.redhat.qe.tools.SSHCommandRunner.run)

and run list --consumed...

201012111640:18.115 - FINE: ssh root@jsefler-onprem01.usersys.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.

Comment 11 John Sefler 2011-01-21 20:17:11 UTC
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)

Comment 12 John Sefler 2011-01-21 20:19:27 UTC
Created attachment 474680 [details]
Note the Start Day matches the ordernamespace startDate in the entitlement cert on the system

Comment 13 John Sefler 2011-01-21 20:24:36 UTC
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.

Comment 14 errata-xmlrpc 2011-05-19 13:38:00 UTC
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


Note You need to log in before you can comment on or make changes to this bug.