Bug 448697

Created attachment 306912 [details]
ks-post.log showing unsatisfied dependencies for yum in ks

My client is also seeing this issue on Satellite 5.0.1 and 5.0.2.  It was first
noticed when building RHEL5 servers.

Adding to Sep Customer backlog tracking bug.

The issue with osad not getting installed appears to be fixed in Satellite 5.2. 

Tested a kickstart profile for both RHEL 5 and RHEL 5u2, each associated with the same activation key that indicated to install osad. In both cases osad was installed after the kickstart.

Interesting to note that with the RHEL 5.2 kickstart, no dependency errors were present in ks-post.log. (osad was still installed)

RHEL 5.0 kickstart, the dependency error *was* in ks-post.log:

error: Failed dependencies:

        python-iniparse is needed by yum-3.2.8-9.el5_2.1.noarch

        yum-metadata-parser >= 1.1.0 is needed by yum-3.2.8-9.el5_2.1.noarch

        yum = 3.0.1-5.el5 is needed by (installed) yum-updatesd-3.0.1-5.el5.noarch


And yet osad was installed, so this does not seem to have been the reason why osad wasn't getting installed.

IIRC we fixed issues with this not long ago, but it looks like it should have been in 5.1: https://bugzilla.redhat.com/show_bug.cgi?id=434943 

In any case this ticket seems to be more so related to the yum upgrade failing, looking into this now.

This is a complicated problem that's only getting worse. The freshen list is there as a rather unpleasant workaround for a situation where we might ship a really busted application in RHEL 5.0 (for example) that prevents proper upgrades or other RHN behavior, so after we kickstart RHEL 5.0 we then try to go install the latest versions of several packages from the latest RHEL, in this case 5.2. This is done with wget and rpm, trying to bypass yum completely which appears to have been involved in whatever nasty scenario cause this.

Already we're seeing new dependencies creeping up and that problem will only get worse and worse as RHEL progresses.

For instance the list just went from:

{"yum",  "pirut", "yum-rhn-plugin"};

to:

{"yum",  "pirut", "yum-rhn-plugin", "python-iniparse", "yum-metadata-parser", "yum-updatesd", "rhn-setup",
 "rhn-check", "rhn-client-tools", "rhnsd", "gamin-python"};


In addition, python-iniparse is a completely new package that isn't installed by default in RHEL 5.0, so the rpm -Fvh (freshen) won't pick it up if it isn't installed. 

We could change this to a -Uvh but this will start installing packages that may not previously have been installed. (pirut for instance!)

In short, this attempt at replicating the behavior of yum from a shell script at the end of a kickstart is bound to fail eventually and is really not something we should be doing. It sounds like this has the unfortunate implication that a RHEL 5 kickstart would have some serious problems post kickstart, possibly not being able to upgrade, or perhaps communicate with Satellite at all.

There are many many ways this could break, for instance if the user added any obscure package to their kickstart profile, but this package then depended on one of our refresh packages, the upgrade will fail.

Discussions underway for what to do.

I have tested removing the RHEL 5 package freshen list entirely and doing a RHEL 5.0 and 5.1 kickstart to see if (a) the system can still communicate with satellite and (b) the system can still yum upgrade.

RHEL 5.0:

- rhn_check functions fine.
- Scheduled a package refresh, picked up fine.
- yum upgrade found a dependency error with xen-libs (ks was for a Xen host) but removing xen allowed the upgrade to proceed fine. This isn't something addressed by the wget hack in any case.
- yum upgrade then proceeds fine, system now up to date.

RHEL 5.1:
- rhn_check works ok.
- yum upgrade works ok.

It looks as if yum-rhn-plugin was the original problem causing package. I think the root ticket is: https://bugzilla.redhat.com/show_bug.cgi?id=378911 (see comment #72 in particular) Essentially if there is some underlying problem talking to the satellite (SSL errors, missing packages, etc) the correct exception is getting masked by one that doesn't identify the problem. (python variable reference exception)

If this is correct and we are upgrading yum-rhn-plugin to properly report errors, then I would argue we can go ahead with removing this manual attempted upgrade functionality. If a user ends up in a situation where they cannot upgrade due to some improper configuration elsewhere (and are not seeing correct error messages), we should rely on the errata infrastructure in place as described in ticket 378911. 

Normal operation seems to be ok, thus I think it best we remove this code.

Thoughts?

Fix applied in spacewalk git repo: 77a369d3709360f27c0c1213c36f1ca9699ad2cc

This will appear in Satellite 5.3.

Looks like jsherrill re-added this code in March in commit f5376cb9 for CentOS kickstarts.

Justin could you review the above discussion on why this code was bad and/or unmaintainable and let us know your preference for best course of action.

IMO we probably need to revert f5376cb9 and instead implement some kind of scheduled package install to get the client packages installed for CentOS.

heh,  sorry about that devan.  Didn't realize I had re-added anything that you removed.   

So I'm not opposed to reverting f5376cb9, but we still need a way to get client packages installed on the machines before registration.  You can't schedule a package install, because the system hasn't registered yet!  (Cent doesn't ship with any of our registration utilities).  

We probably could simply add a "CentOs" distro type that the user could select and only generate those lines in the Kickstart if the distro is of that type.

Lets revert for now and take another stab at getting the client packages installed on Cent OS in a future release of Spacewalk. That is indeed a tricky chicken and egg problem to solve, a check for CentOS or Fedora might do it but we're running the risks of dependency problems as per the above, particularly if you consider what this list of packages might turn into for different versions of Fedora.

Reverted in spacewalk.git: 06b89603b02bc4f2ce0b28f484eb02835dd84c43
reverted in satellite.git: 7558a5f

Release Pending
Satellite: test1182.test.redhat.com
client: fjs-0-13 kickstarted to rhel5u1 yum update works fine after ks.

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-2009-1434.html