Red Hat Bugzilla – Bug 41611
rhn_register doesn't parse the proxy entry correctly
Last modified: 2015-01-07 18:45:48 EST
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...
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.
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.
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...
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
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.
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...