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):
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
eg. 69.pem present
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.
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
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
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
I also reproduced this failure with tree:
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
[root@jsefler-rhel511 ~]# subscription-manager version
server type: Red Hat Subscription Management
subscription management server: 0.9.15.3-1
Moving to VERIFIED. Fixed by subscription-manager-1.11.3-6.el5
When I finished the installation of RHEL5.11-server-snapshot-1.0  , 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.
*** Bug 1118206 has been marked as a duplicate of this bug. ***
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.
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.
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.
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.
Still seeing in snap #2
(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.
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.
the fixed packages haven't been pulled into the nightly build yet.
Please wait for:
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
I see 69.pem under /etc/pki/product after a fresh snapshot #3 install. Moving to VERIFIED.
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.