Bug 41611 - rhn_register doesn't parse the proxy entry correctly
rhn_register doesn't parse the proxy entry correctly
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: rhn_register (Show other bugs)
7.1
All Linux
medium Severity high
: ---
: ---
Assigned To: Adrian Likins
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-05-21 11:18 EDT by Alexander L. Belikoff
Modified: 2015-01-07 18:45 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-07-05 16:05:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Alexander L. Belikoff 2001-05-21 11:18:40 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.19-6.2.1smp i686; Nav)

Description of problem:
In /usr/share/rhn/register/rhnreg.py:49 :

	proxyHost = cfg.readEntry("httpProxy")[7:]

last '[7:]' clause makes it cut the proxy name, it it cannot connect to it.


How reproducible:
Always

Steps to Reproduce:
1. Configure an HTTP proxy
2. edit /etc/sysconfig/rhn/rhn_register to go to the proxy
3. add a print statement after line 49 in /usr/share/rhn/register/rhnreg.py
	

Actual Results:  trashed proxy URL

Expected Results:  good proxy URL

Additional info:

There is more to say about RHN register proxy facility:

1. It is a HUGE pain in the ass to expect users to figure out they have to
edit a text config file in order to just start a registration process, when
those users are behind a firewall.

2. rhn_register itself does nothing to identify a problem - it blocks for
some 5 minutes, than bails out.

Here is what should be done:

1. HTTP proxy setting should be system-global. All programs must grok it:
    - ask during system setup
    - set in /etc/sysconfig/... and suck into shell as a bunch of *_proxy
vars
    - Modify Netscape/Mozilla to grok these env variables
    - modify up2date, rhn_register to do the same

2. Make rhn_register smarter:
    - don't let it block - user should be able to cancel it
    - make it print a friendly message 'Connecting to <proxy URL>'
    - in case of proxy connect error make it print it clearly

3. In fact, rhn_register could probably be implemented as Web-based
registration process... Have to think out all the details though...
Comment 1 Alexander L. Belikoff 2001-05-21 11:23:18 EDT
Just figured it out: this [7:] crap is for 'http://' - so the comment is
wrong!!!
One more complaint - you should be smarter in parsing the proxy specs - should
be able to grok both formats. Other complaints still hold.
Comment 2 Jay Turner 2001-05-22 07:48:23 EDT
Editting of a text file is not necessary, as you can easily run 'rhn_register
--config' and do it from there.  As for there needing to be global proxy
settings, I agree, but I don't think that's a knock on rhn_register/up2date, as
Netscape/Mozilla also require that you configure them for proxy before they will
be very useful to you after installation.
Comment 3 Alexander L. Belikoff 2001-05-22 08:38:52 EDT
Well, to be honest, I had no idea about '--config' option. OTOH, why would
rhn_register be configurable using an option, while up2date would have a special
program for that? Also, when being run on an unregistered machine, why wouldn't
rhn_register go into the configuration mode automagically instead of promptly
trying to access the [unavailable] Internet? Same holds for up2date.

As for Netscape/Mozilla proxy - that's exactly what I suggested:
1. Tweak source code of both to pay attention to *_proxy env. vars. Good way to
do it would be the following logic:

- if personal proxy settings in Netscape/Mozilla configs are explicitly set -
use them
- otherwise, if *_proxy are set - use those and save them in personal configs
- If env vars' values differ from personal configs - warn about it (possibly
once) and offer to save new values in personal configs.

2. Set the aforementioned variables - it is essential, you guys have some
centralized tool to tweak all configs - preferably text-mode, like Yast. This
would set all system config parameters, beginning with proxy settings, to the
firewall config to hard drive parameters tweaking...
Comment 4 Frode Tennebø 2001-06-01 05:36:21 EDT
The comment is not wrong as the attribute should not have a "http://"
according to the comment during configure:

Attribute Name: httpProxy
Comment: HTTP proxy in host:port format, e.g. squid.redhat.com:3128
Comment 5 Alexander L. Belikoff 2001-06-01 11:41:44 EDT
In that case, the '[7:]' part in the aforementioned line of Python code is
wrong. Anyway, this is NOT  relevant for a PROPER fix. The latter should:

1. be able to read proxy in ANY format
2. read proxy from centralized resource rather than from it's own config file
3. inform the user about its current operation in a non-blocked fashion to allow
the user to cancel.
Comment 6 Adrian Likins 2001-07-05 20:20:48 EDT
added more  robust proxy name parsing...
It now understands "foo.bar.com:2341" and  "http://foo.bar.com:23423" 
at least...

btw, there  is already a web based RHN registration system, but it is
somewhat limited (difficult to get the package list, hardware profiles,
etc...). But it does allow you to generate a system id and get the box
registered. 

also, rhn_register and up2date both support the "--config" option. In the
case of up2date, the gui version is implemented as a seperate utility.

work on making the app less blocky has begun as well...

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