Bug 450531 - Upgrade of proxy on rhel5 do not work
Summary: Upgrade of proxy on rhel5 do not work
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Network
Classification: Retired
Component: RHN/Other
Version: rhn505
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Bryan Kearney
QA Contact: Stephen Herr
URL:
Whiteboard: US= 29981
Depends On: 424901
Blocks: 455600
TreeView+ depends on / blocked
 
Reported: 2008-06-09 12:35 UTC by Miroslav Suchý
Modified: 2013-01-10 09:20 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-09-25 13:03:31 UTC
Embargoed:


Attachments (Terms of Use)

Description Miroslav Suchý 2008-06-09 12:35:10 UTC
This change in Proxy 5.2 installer need to be done in hosted too (see svn
revision on the bottom):

+++ This bug was initially created as a clone of Bug #450299 +++

Description of problem:
When you have some conflicting packages on machine RHEL5, the installer will
fail, becouse of unresolvable dependencies. 

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

Steps to Reproduce:
1. install proxy on rhel5
2. deactivate (do not remove packages)
3. install again using webui
  
Actual results:
error: Failed dependencies:
 httpd is needed by (installed) rhns-proxy-html-5.2.0-5.el5.noarch
 libidn.so.11 is needed by (installed) jwhois-3.2.3-8.el5.i386
 libidn.so.11 is needed by (installed) curl-7.15.5-2.el5.i386
 libidn.so.11 is needed by (installed) gnupg-1.4.5-12.i386
 perl(Apache2::Const) is needed by (installed) perl-Frontier-RPC-0.07-7.noarch
 perl(Apache2::ServerUtil) is needed by (installed) perl-Frontier-RPC-0.07-7.noarch
 mod_python is needed by (installed) rhns-proxy-common-5.2.0-4.el5.noarch
 mod_ssl is needed by (installed) rhns-proxy-common-5.2.0-4.el5.noarch
 rhns-proxy-broker >= 5.2.0 is needed by (installed)
rhns-proxy-common-5.2.0-4.el5.noarch

Expected results:
no error

-- Additional comment from msuchy on 2008-06-06 11:13 EST --
commited to trunk rev. 173634

Comment 1 James Bowes 2008-06-11 17:44:06 UTC
So the change set from satellite does not apply (via patch, not conceptually) at
all to hosted. The installer XML file in our code base doesn't have any of the
checks for conflicting packages. Am I missing something?

Comment 2 Miroslav Suchý 2008-06-12 08:05:49 UTC
Yes, we are missing fix of this bug: 424901. I swear I think you already copy
this commits, but apparently not.

Comment 3 Stephen Herr 2008-07-24 20:57:02 UTC
Okay, so the long and the short of this is that this bug is untestable right now.

This is dependent on Proxy 5.2, which has not yet reached GA. Without having the
proxy 5.2 rpms in our environment (which we don't) it's impossible to test.
Furthermore, the bug this was cloned from is still only modified; so the patch
that jbowes applied has not yet been tested by the satellite team. The
combination of those two factors make me very uneasy about releasing this patch.
We can discuss this at our next meeting, but we should consider what options we
have.

Comment 4 Miroslav Suchý 2008-07-25 07:42:51 UTC
The satellite part (BZ 235504, 235506) are verified and furthermore verified in
stage. Proxy 5.2 are available in webqa. Yeah it is not available on stage. 

Comment 5 Stephen Herr 2008-07-28 15:30:15 UTC
To get around the "RPM not signed" error:
edit /etc/yum/pluginconf.d/rhnplugin.conf; set gpgcheck = 0

Note: at this time the associated tools in rhn-tools have *not* been pushed into
webqa. Install from BREW instead:
http://porkchop.devel.redhat.com/brewroot/packages/rhns-certs-tools/5.2.0/3.el5/noarch/rhns-certs-tools-5.2.0-3.el5.noarch.rpm

Comment 6 Stephen Herr 2008-07-28 15:38:23 UTC
Miroslav, I have not been able to recreate this bug in webqa. The proxy
installer seems to know that the packages have already been installed and it
does not schedule that step. Can you provide more guidance on how to re-create
this? Thanks.

Comment 7 Miroslav Suchý 2008-07-29 08:15:33 UTC
I'm not sure, I just followed Steps to Reproduce and I got the given error.
Which step do you mean by "that step"?

Comment 8 Stephen Herr 2008-07-29 13:22:45 UTC
By "that step" I mean the Event that installs the proxy packages. When I try to
reactivate the proxy the installer recognizes (I assume) that the machine
already has the packages installed and does not schedule that event. As a
result, I do not get the conflicting packages error and the proxy reactivates
successfully. And you say you can reproduce this error in RHN Hosted in webqa?
Strange...

Comment 9 Miroslav Suchý 2008-07-31 14:31:36 UTC
you can not reproduce this bug on webqa since on webqa is evidently not
presented patch from BZ 424901, and this bug appear only if you have this feature.

Comment 10 Stephen Herr 2008-07-31 15:27:59 UTC
verified in webdev

As msuchy notes it's not possible to test this in an environment where 424901
has not been applied, and the fix that that bug was added to webdev at the same
time as this one was. So I have not been able to reproduce the bug, but at least
we know that the process is working properly with this fix in place. 

Comment 11 Stephen Herr 2008-09-05 20:19:19 UTC
verified in qa


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