Hide Forgot
We use a proxy / firewall to access the Internet here, as every other company I have worked at for the last few years. I was very surprised to learn from the support folks that this is not currently a supported feature. My original trouble ticket was #164466. As a supporter and advocate for Linux in the Enterprise I am constantly being bombarded with "Not ready for Primetime" comments. The ability to access RHN and get updates fairly easily was one of the reasons that I purchased the Professional Server product. I am dissapointed that the product cannot negotiate a proxy, nor is there a work around. I hoped to use this as a selling feature to our Enterprise Server folks, but again I am not about to push this out and get "Not ready for Primetime" shoved back at me. Discounting the argument that Microsoft products are _______ "insert comment or bash", the impression in the business community is that Microsoft is "Primetime player #1". Things like this do not help me or Redhat to overcome the image, please upgrade RHN to negotiate a proxy / firewall.
same problem and conclusion. the new up2date package from rawhide don't resolve my problem there is a new support for proxy but it don't work. and the rhn_register from rawhide is the same from redhat 7.0, so proxy support is not ok. appears that Red Hat Network is technicaly a very young project, with functionnality very limited. I don' know why Red Hat don't like apt-get (connectiva ported apt-get to RPM) but it's fully functionnality.
sorry for my poor english, i'm french
Please send details of the problems that you are seeing when attempting to access RHN through a proxy.
I was trying to get rhn_register to work on a RH6.2 Sparc in the office after seeing how well RedHat Network worked on a RH7.0 Celeron.. but even after loading all the recommended updates for rhn_register and up2date, it didn't work. The machine is working well (has been for some time), proxy information is correct but I get messages like 'no contact with server' or 'welcome screen could not be loaded'. I started ethereal and watched what was going out and lo! There was a DNS query for www.rhns.redhat.com which the local DNS server couldn't resolve. Isn't it the case that if an HTTP proxy has been specified then to reach the RHN server, the application should send an HTTP request to the proxy and not try and directly resolve the address? After failing to get a good response, the application sends another DNS request, this time to www.rhns.redhat.com.<my domain appended>.. this fails as well. Regards / Martin
I dug further into this today (had to stay home, waiting for a second line) and found the problem.. httplib.py expects that the proxy url is of the form www-proxy.redhat.com:80 and not http://www-proxy.redhat.com:80 The two ':'s throw off the code.. After removing the leading 'http://', I managed to run up2date -r but rhn_register gave me an error messge ('fatal error retrieving welcome message' or something similar). After running up2date with -r, this went away.. Regards / Martin
From what I can see the xmlrpclib.py doesn't use urllib for more than simply splitting the URL into two different parts. It uses myHTTP to do the actual connectivity. urllib's getproxies actually searches the environment for suitable proxies but its never called because myHTTP does a straight socket connect. On line 428 of cgiwrap.py, in send_http it checks for the existance of a Proxy passed from the request function in class Transport of xmlrpclib. If one doesn't exist, it doesn't pass the host parameter iwhen creating a new myHTTPS object (line 432). A fix is to modify rhnreg.py to add a new global variable 'serverProxy' and setting it to a proxy address in the form of 'some.proxy.com:3128' Whenever a xmlrpclib Server object is created, pass serverProxy to the constructor. Alternatively, myHTTPS could be modified to use getproxies if no proxy is found. But because I didn't want to go messing around with system libraries, I modified the rhnreg.py file. The serverProxy variable should probably be defined through the commandline, and not staticly like this solution. This solution allowed me to successfully register though a proxy. A diff is below. 28a29,30 > serverProxy = "melks-fw.hotkey.net.au:3128" > 197c199 < s = xmlrpclib.Server(serverUrl) --- > s = xmlrpclib.Server(serverUrl, serverProxy) 218c220 < s = xmlrpclib.Server(serverUrl) --- > s = xmlrpclib.Server(serverUrl, serverProxy) 239c241 < s = xmlrpclib.Server(serverUrl) --- > s = xmlrpclib.Server(serverUrl, serverProxy) 273c275 < s = xmlrpclib.Server(serverUrl) --- > s = xmlrpclib.Server(serverUrl, serverProxy) 297c299 < s = xmlrpclib.Server(serverUrl) --- > s = xmlrpclib.Server(serverUrl, serverProxy) 322c324 < s = xmlrpclib.Server(serverUrl) --- > s = xmlrpclib.Server(serverUrl, serverProxy) 357c359 < s = xmlrpclib.Server(serverUrl) --- > s = xmlrpclib.Server(serverUrl, serverProxy) 378c380 < s = xmlrpclib.Server(serverUrl) --- > s = xmlrpclib.Server(serverUrl, serverProxy) 399c401 < s = xmlrpclib.Server(serverUrl) --- > s = xmlrpclib.Server(serverUrl, serverProxy) 419c421 < s = xmlrpclib.Server(serverUrl) --- > s = xmlrpclib.Server(serverUrl, serverProxy) 440c442 < s = xmlrpclib.Server(serverUrl) --- > s = xmlrpclib.Server(serverUrl, serverProxy)
This issue is resolved in the latest rhn_register code which is available in beta and will be available in the next public release.