Bug 1104498 - Productid not installed after newly installed RHEL5.11 server build
Summary: Productid not installed after newly installed RHEL5.11 server build
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: subscription-manager
Version: 5.11
Hardware: x86_64
OS: Unspecified
Target Milestone: beta
: ---
Assignee: Bryan Kearney
QA Contact: John Sefler
: 1118206 (view as bug list)
Depends On:
Blocks: rhsm-rhel511 1090039
TreeView+ depends on / blocked
Reported: 2014-06-04 07:26 UTC by xingge
Modified: 2016-09-20 02:28 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-09-16 00:23:17 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1225 0 normal SHIPPED_LIVE subscription-manager bug fix and enhancement update 2014-09-16 04:15:23 UTC

Description xingge 2014-06-04 07:26:04 UTC
Description of problem:
In RHEL-6 and RHEL-5 productid file from repodata was copied to /etc/pki/product during installation and this file is used by subscription-manager to determine installed products. And now after install the RHEL5.11 server the product cert is missing.

Version-Release number of selected component (if applicable):


How reproducible:

Steps to Reproduce:

1. Perform minimal installation of RHEL5.11-Server-20140603.0 x86_64 Server
2. In installed system look to /etc/pki/product

Actual results:
empty directory

Expected results:
eg. 69.pem present

Additional info:
I choose install the system from web and the http://download.englab.nay.redhat.com/pub/rhel/rel-eng/RHEL5.11-Server-20140603.0/tree-x86_64/Server/repodata/  do not empty
I download the productid file from this directory and mv it to /etc/pki/product dic as 69.pem, then the subscription-manager works fine.

Comment 1 RHEL Program Management 2014-06-04 07:47:55 UTC
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.

Comment 2 Adrian Likins 2014-06-04 18:58:09 UTC
It look like it's installing to anacondas /etc/pki/product (in the anaconda runtime /) and not to the sysimage /etc/pki/product (/mnt/sysimage).

So, sounds busted. 

May be related to fix for https://bugzilla.redhat.com/show_bug.cgi?id=1038242

Comment 3 Adrian Likins 2014-06-04 19:10:54 UTC
Hmm, likely the fix for  https://bugzilla.redhat.com/show_bug.cgi?id=1038242
(a check for /var/run/anaconda.pid). Which does not appear to exist on RHEL5.

Easiest fix would be just skip that check for 5.

I suspect it could also check for /var/run/init.pid, but I don't know if it's worth changing it just for https://bugzilla.redhat.com/show_bug.cgi?id=1038242

Comment 7 John Sefler 2014-06-05 15:50:50 UTC
I also reproduced this failure with tree:


Comment 8 John Sefler 2014-06-11 14:42:40 UTC
Verifying Nightly Compose...

After installing latest nightly compose and running firstboot with registrtaion, the RHEL product cert was installed by anaconda and corresponding subscription was auto attached.

[root@jsefler-rhel511 ~]# subscription-manager list --installed
    Installed Product Status
Product Name:   Red Hat Enterprise Linux Server
Product ID:     69
Version:        5.11
Arch:           x86_64
Status:         Subscribed
Status Details: 
Starts:         01/05/2014
Ends:           01/04/2015

[root@jsefler-rhel511 ~]# subscription-manager version
server type: Red Hat Subscription Management
subscription management server:
subscription-manager: 1.11.3-6.el5
python-rhsm: 1.11.3-3.el5

Moving to VERIFIED.  Fixed by subscription-manager-1.11.3-6.el5

Comment 9 qianzhan 2014-07-10 08:31:50 UTC
When I finished the installation of RHEL5.11-server-snapshot-1.0 [1] , I found no product cert in /etc/pki/product/ :

[root@dhcp-14-149 ~]# subscription-manager list --installed
No installed products to list
[root@dhcp-14-149 ~]# ls /etc/pki/product/

So, reopen this bug.

[1] http://download.englab.nay.redhat.com/rel-eng/RHEL-5.11-Server-Snapshot-1.0/5/x86_64/os/

Comment 10 Michal Kovarik 2014-07-10 09:21:23 UTC
*** Bug 1118206 has been marked as a duplicate of this bug. ***

Comment 11 Adrian Likins 2014-07-14 18:33:51 UTC
Running a 5.11 snap1 install and checking anaconda.log during anaconda, I
see a 'Warning No module named dateutil.parser' where product install should be happening.

I think commit 4c7fe4009a7902c236ff8f9445a2505bf0eb94e7 in python-rhsm internal
introduced that, and likely the anaconda image doesn't include that dateutil.parser module. 

Doesn't look like anaconda stage2.img has the dateutil module at all. 

Either that needs to get added to stage2, or product-id.py needs to not eventually try to import it.

Comment 12 John Sefler 2014-07-15 19:19:45 UTC
Discussions with the subscription-manager developers suggest that this issue would best be fixed by anaconda (see comment 11).

Moving this bug back to VERIFIED based on comment 8 and comment 5.
Re-opening bug 1118206 to fix the 'Warning No module named dateutil.parser' issue in comment 11 which should fix comment 9.

Comment 14 David Cantrell 2014-07-16 17:18:13 UTC
Looking at bug 1118206 and the log files attached there, I see no anaconda failure.  Anaconda does not directly invoke the subscription-management code.  In fact, I'm not really sure how it's invoked among the various RHELs, I just know it's a combination of yum plugins and firstboot plugins.

At install time, my guess is it is indirectly invoked because we instantiate a yum object in anaconda and that likely fires up all of the available plugins.  Looking at the contents of stage2.img, I see that product-id.py is a yum-plugin on the filesystem and it handles talking with subscription-manager.  So the invocation of this code is through yum.

There's nothing to change for this problem in anaconda.  I'm not sure what's failing as there are no logs indicating where the yum plugin failed, but I advise debugging product-id.py.

The 'import dateutil' warning is simply that, a warning.  python-rhsm invokes dateutil.parser from src/rhsm/connection.py, but it's wrapped in a try/except and in case it fails, it just logs the exception.  It's non-fatal.  Something else is not working.

Comment 15 Adrian Likins 2014-07-16 18:12:37 UTC
yup, anaconda loads a couple yum plugins (kmod and product-id.py). 

anaconda/scripts/upd-instroot has KEEPFILE that includes a hand picked
curated list of files/dirs to include on the stage2.img. 
/usr/lib/python2.4/site-packages/dateutil is not included, so
the dateutil module doesn't exist in /mnt/runtime, causing the import error,
causing the product-id.py plugin to fail.

subman has a rpm dep on python-dateutil, because of a ssl time drift check, that eventually is imported from yum->product-id. 

I'd try/except around the dateutil import.parser import in src/rhsm/connection (and stub drift_check there). But... base subscription-manager code uses dateutil.tz in a few places. Haven't test it yet to see if that code get's
imported in the product-id.py path.

Comment 16 Alexander Todorov 2014-07-17 07:52:55 UTC
Still seeing in snap #2

Comment 19 Carter Kozak 2014-07-17 13:29:52 UTC
*** Bug 1118206 has been marked as a duplicate of this bug. ***

Comment 20 David Cantrell 2014-07-17 17:13:09 UTC
(In reply to Adrian Likins from comment #15)
> yup, anaconda loads a couple yum plugins (kmod and product-id.py). 
> anaconda/scripts/upd-instroot has KEEPFILE that includes a hand picked
> curated list of files/dirs to include on the stage2.img. 
> /usr/lib/python2.4/site-packages/dateutil is not included, so
> the dateutil module doesn't exist in /mnt/runtime, causing the import error,
> causing the product-id.py plugin to fail.

It's worth noting here that any time you have an install-time dependency change, that needs to be filed as a bug against anaconda (for RHEL-5 or RHEL-6) or lorax (RHEL-7).  Over time, the RHEL workflow incorporated checking on installer impacts for new package requests and package rebase requests to catch things like this (this occurred somewhere early in the RHEL-5 cycle).  It's also worth noting that checking on installer impacts in cases where you apply a lot of upstream patches to a package is a good idea too, as there may be unanticipated requirement changes.

Just wanted to make sure everyone was clear on that.  The anaconda image building scripts with variables like KEEPFILE were a huge pain to maintain, which is why we replaced them with the easier to maintain tool called lorax.

Comment 21 xingge 2014-07-18 04:01:42 UTC
This bug happens again in the newest RHEL5.11 build RHEL5.11-20140716.0
All my test is on the virtual machine. 
The real machine which my colleague installed by beaker have it's product cert.

Comment 22 Carter Kozak 2014-07-18 12:48:08 UTC
the fixed packages haven't been pulled into the nightly build yet.

Please wait for:

Comment 23 Sharath Dwaral 2014-07-21 17:25:35 UTC
The latest 5.11-Server build http://download.devel.redhat.com/rel-eng/RHEL-5.11-Server-/5/x86_64/os/Server/  has


Waiting for newer build with 

 subman -       1.11.3-10
 pythin-rhsm -  1.11.3-5

Comment 24 Alexander Todorov 2014-07-25 11:30:55 UTC
I see 69.pem under /etc/pki/product after a fresh snapshot #3 install. Moving to VERIFIED.

Comment 27 errata-xmlrpc 2014-09-16 00:23:17 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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