Description of problem: The installed product stauts remains "Subscribed" when the attached subscription is expired. Version-Release number of selected component (if applicable): subscription-manager-gui-1.8.10-1.el5 subscription-manager-firstboot-1.8.10-1.el5 subscription-manager-1.8.10-1.el5 python-rhsm-1.8.12-1.el5 How reproducible: Always Steps to Reproduce: 1.register the system and attach a subscription #subscription-manager register --username=[] --password=[] --auto-attach 2.Modify the system date to let the subscription expired. #date -s 20150101 3.check the installed products status and the consumed subscriptions #subscription-manager list --installed | grep Status #subscription-manager list --consumed Actual results: The list consumed cmd output is: #subscription-manager list --consumed No consumed subscription pools to list The installed product status is: #subscription-manager list --installed |grep Status Status: Subscribed Status Details: Expected results: The installed product status should be "Expired" Additional info: After I restarted the rhsmcertd service, the result doesn't chage.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
Compliance is calculated on the server, so changing the system time shouldn't really have much effect. Unless you're changing the system time on the server as well, this is working as intended. Please let me know if you need more information.
Hi Carter, You said this is not a bug, but It makes people confused that your product is Subscribed but you can't list what's subscription you attached. The two cmd "list --consumed" "list --installed" 's results are a conflict between each other.
I think there are some bugs in how subman client handles client date, so reopening this. Not a huge priority given the other ssl issues radically off dates incur, but probably worth reviewing if we need those client checks now. A couple things I see: widgets.ContractSubDetailsWidget has a tiny bit of cert expiry calc that uses client time rhsm_d.py also takes client time into consideration for "warning" period. certlib.HealingLib checks cert expiry against local time as well. CertSorter _scan_entitlement_certs filters based on client time as well. mysubstab.on_selection also checks local date for filtering certs
Submitted a patch that stops us from deleting ent certs locally, as that is repetitive. Now this will only happen when they expire server-side. The list --consumed case still displays nothing, but we log a warning "Clock skew detected, please check your system time" This isn't a supported system state, so the results are expected/not a bug. Additionally, this will not happen with "insecure=0", as a time difference will cause ssl errors. commit 831592b911ce3a153a98aab3a378716ad6a8ee96 Author: ckozak <ckozak> Date: Fri Jun 28 09:46:49 2013 -0400 978322: fixed client deleting certs