Description of problem:
After installing the rhn-org-trusted-ssl-cert-1.0-1.noarch RPM, rhn_register (when run on the ssh command line) opens a curses version of the GUI which bypasses the window that would offer the user the option to specify a satellite server over the default RHN server.
Version-Release number of selected component (if applicable):
rhn_register (Red Hat Network Client Tools) 0.4.20-9.el5
Steps to Reproduce:
1. Create kvm-qemu guest on RHEL5.4 host.
2. Install the rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm on the 5.4 guest
3. ssh to guest
4. run rhn_register
Curses verion of rhn_register GUI prompts with similar screens as the true GUI ... prompts "Are you sure you would like to continue" ... select "Yes, Continue" ... skip "why should I connect to RHN" and select "Next" ... next window prompts for Login/Password for the RHN server and does NOT present a window for opting to use a satellite.
Should be presented with a window for opting to use a satellite.
Workaround was to vnc to the guest desktop and run rhn_register from a command line there. The standard GUI (not curses) then prompts the user with the option to use a satellite. Once configured, "yum update" back on the guest works as expected.
BZ says NEEDINFO but no request for information is present.
Do I understand it correctly you want to add similar functionality GUI have
(possibility to configure target RHN server in the wizard) to the TUI? Am I
Correct, the TUI does not offer the same option (to use a satellite server rather than RHN) that is presented only in the GUI.
*** Bug 580162 has been marked as a duplicate of this bug. ***
Fixing this bug is contingent on fixing bug #580495, which I'm not sure
we can make into RHEL-6.1.
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
While I agree that this would be a nice to have, I don't see this
to be a material for RHEL-5.9, especially since this feature most
likely won't be even implemented for RHEL-6 nor in upstream.
I'm closing this with wontfix.