Bug 185309 - yum proxy code section does not seem to be working
yum proxy code section does not seem to be working
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
:
: 185284 186054 188022 188184 188700 189551 (view as bug list)
Depends On:
Blocks: FC5Update 183230
  Show dependency treegraph
 
Reported: 2006-03-13 11:18 EST by Stephen John Smoogen
Modified: 2014-01-21 17:53 EST (History)
11 users (show)

See Also:
Fixed In Version: fc5-updates
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-18 16:26:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Provisionally add proxy support for getMirrorList (1.12 KB, patch)
2006-04-14 06:06 EDT, Peter van Hooft
no flags Details | Diff

  None (edit)
Description Stephen John Smoogen 2006-03-13 11:18:22 EST
Description of problem:

yum mirrorlist section does not work with proxy code.

we sit behind a squid proxy that does FTP, HTTPS, HTTP on port 80.  

http://xxxproxy.foogoo.com:80

We tried adding the line to the /etc/yum.conf 

proxy=http://xxxproxy.foogoo.com:80
Version-Release number of selected component (if applicable):

Doing any yum command will sit at the repository code with a line:
development                                          [1/2]

Setting environment variable to 
HTTP_PROXY=http://xxxproxy.foogoo.com:80 

fixes the problem.
Comment 1 Deon George 2006-03-23 02:06:40 EST
I can confirm that this problem also occurs in FC5.
Comment 2 Peter van Hooft 2006-04-14 06:06:20 EDT
Created attachment 127740 [details]
Provisionally add proxy support for getMirrorList
Comment 3 Jeremy Katz 2006-04-17 18:22:49 EDT
yum-2.6.0-2 in the devel tree helps the case of using yum from the CLI, but it
still doesn't resolve the problems with yum API users (eg, pirut, pup or yumex).
 The patch in comment #2 will work, but I want to try to come up with something
that is a little more elegant.
Comment 4 Jeremy Katz 2006-04-17 18:23:37 EDT
*** Bug 188700 has been marked as a duplicate of this bug. ***
Comment 5 Jeremy Katz 2006-04-17 18:24:25 EDT
*** Bug 185284 has been marked as a duplicate of this bug. ***
Comment 6 Jeremy Katz 2006-04-17 18:25:17 EDT
*** Bug 188184 has been marked as a duplicate of this bug. ***
Comment 7 Jeremy Katz 2006-04-18 11:22:34 EDT
http://people.redhat.com/~katzj/yum-2.6.0-3.noarch.rpm should have a fix for
this -- can you download and see if it fixes things both with yum itself and any
utilities using the yum API such as pup?
Comment 8 stef 2006-04-18 11:37:25 EDT
tested with YUM and PUP

proxy=http://proxy:8080   line added in the /etc/yum.conf

YUM launched with a 'sudo yum -y upgrade', works
PUP launched from the Gnome system tools menu as user (asked for root password),
works

since PUP depends on this proxy setting, should there be a menu or button to
configure the proxy for YUM/PUP ? It doesn't use the proxy setting in the Gnome
menus (makes another redundant setting you must set to have a working system).
Comment 9 stef 2006-04-19 07:33:13 EDT
(In reply to comment #7)
As I pointed in comment #8 the components YUM and PUP are fixed forme, and I can
add too system-config-kickstart.

This YUM update should be pushed ASAP in the updates.
On the other hand, the proxy setting problem I pointed out in comment #8 should
really be addressed, lots of people out there are like me behind a proxy, and to
me a proxy is nowadays a very simple and common network element that shouldn't
be an obstacle.
Comment 10 Jeremy Katz 2006-04-19 10:34:25 EDT
The plan is to push yum-2.6.1 with this fix real soon now (cleaning up a few
other loose ends)

As for visible proxy config within pup/pirut -- on the todo list and once it's
done, I'm intending to push it as an update.  Might see if I can do something to
catch the GNOME proxy settings first as a place to start and get something out
sooner.
Comment 11 Jeremy Katz 2006-04-19 16:42:13 EDT
*** Bug 186054 has been marked as a duplicate of this bug. ***
Comment 12 Jeremy Katz 2006-04-19 17:56:17 EDT
*** Bug 186622 has been marked as a duplicate of this bug. ***
Comment 13 Arch Willingham 2006-04-19 18:24:20 EDT
I originaly marked this as a bug but it turned out to be a problem with our 
proxy server - not with Fedora. 

My problem was caused by some kind of bug in SP2 of ISA2004 that prevents you 
from downloading gz files and you have to:

1. disable "Compression Filter"
2. disable "Caching Compressed Content Filter"

Once I did that, it worked like a charm.
Comment 14 Jeremy Katz 2006-04-20 19:28:08 EDT
*** Bug 189551 has been marked as a duplicate of this bug. ***
Comment 15 Steve Baker 2006-04-24 16:18:16 EDT
Seems to me that the best approach is to centralize proxy provisioning and have
all applications use it - whether or not they are launched from GNOME like pruit
or invoked from the command line.

Actually, if GNOME were to pick up its own proxy settings and place them in the
environment of applications it launches, this would be a non problem for me.
Comment 16 Jeremy Katz 2006-04-26 16:23:37 EDT
*** Bug 188022 has been marked as a duplicate of this bug. ***
Comment 17 Miro Halas 2006-07-20 14:07:02 EDT
From the usability point:
There is a highly visible entry System->Preferences->Network Proxy exactly where
I would expect it to be. I would assume that most users (especially the first
time ones) would assume that this is the entry where the proxy needs to be
configured. User would then expect that these settings would work system-wide
for AT LEAST the applications which are installed by default and therefore
assumed "to be part of Fedora" such as (in general) browser, software updates
and other applications in the Internet folder. I stress the browser and software
updates because without these two working as easy you cannot have stable and
secure system and cannot get help or search how to resolve issues.
Comment 18 Miro Halas 2006-10-12 14:18:12 EDT
I have found workaround to this problem. I have installed on my fedora NTLMAPS
http://ntlmaps.sourceforge.net/ software. Then I have configured any other
application in the system (Gnome, browser, etc.) to use proxy at localhost with
port xxx and with no authorization. I have configured NTLMAPS to use our
corporate proxy with authentication.

This setup had several big advantages for me
1. The password information for our corporate proxy needs to be entered and
managed only at one place. NTLMAPS config file. Since we need to change our
password frequently I do not have to go to all applications and change it. I
change it only at one place.
2. NTLMAPS supports multiple proxies. If one proxy stops responding, it switches
to other proxy server. This is feature which most applications do not support.

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