Doesn't honor gnome proxy settings

Bug #24250 reported by Sven Herzberg on 2005-10-19
This bug affects 3 people
Affects Status Importance Assigned to Milestone
update-manager (Ubuntu)
Michael Vogt

Bug Description

I have a machine at work that uses a web proxy. I configured the proxy in my
GNOME settings and in the apt settings, despite that u-m still says:

"Failed to download changes. Please check if there is an active internet connection"

u-m should use apt's proxy settings.

(This is from Hoary, cannot check Breezy until I've got in installation CD for it)

Michael Vogt (mvo) wrote :

Thanks for your bugreport.

A possible fix would be to run update-manageras normal user and only become root to actually install the updates. This would solve this problem.


Changed in update-manager:
status: Unconfirmed → Confirmed
John Cooper (choffee) wrote :

But it shows up in the status bar as updates available which I then click on and it says that it can't even get the info about updates because it has no proxy setup.

Perhaps the wrapper could check my proxy settings before it lauches and set them in the app on the command line?


Sven Herzberg (herzi) wrote :

I'd still prefer if it took the apt-settings because the apt-settings are the ones used for getting packages.

Florian Boucault (fboucault) wrote :

What about the state of this bug in Dapper ? in Edgy ? :)

Have a nice day.

Sven Herzberg (herzi) wrote :

I can't tell as I don't need the proxy settings anymore.

Florian Boucault (fboucault) wrote :

Old bug with no remaining testers. Sorry... Feel free to re-open.

Changed in update-manager:
status: Confirmed → Rejected
Sebastian Heinlein (glatzor) wrote :

This bug/feature request doesn't depend on Sven.

Changed in update-manager:
status: Rejected → Confirmed
Sven Herzberg (herzi) wrote :

I also think that the target audience is anyone in the world and not only people who already use Ubuntu and know how to use Launchpad.

Sitsofe Wheeler (sitsofe) wrote :

This looks similar to Bug #19372

Sven Herzberg (herzi) wrote :

> This looks similar to Bug #19372

Actually not. Bug #19372 is about offline support while this bug is about using the right proxy settings.

Dmitriy Kropivnitskiy (nigde) wrote :

The problem still persists in Feisty. I have set Acquire::http::Proxy in /etc/apt/apt.conf.d/99proxy and I have configured proxy settings in both gnome preferences and synaptic preferences. The update manager still doesn't work.

I still don't think that the gnome proxy settings should be what update-manager should look at for several reasons:

1. I might run update-manager with root permissions (remember: I might even do this without a proper intention, because all the update tools need superuser priviliges) - then there's no way to access the gnome proxy settings of the user anymore
2. The technical reason: update-manager serves (in a rough view) as a front-end to apt. Listening to the gnome proxy settings is nice, but as long as the apt-settings are not correct (or - by mistake or intention - apt and gnome have different proxy settings), update-manager should still use exactly the same mechanism as apt does.

Use case: set up a local apt proxy for Ubuntu and use an http proxy to forward all apt-requests to is, but the default web access is provided by the plain router setup.

I think I know what is going on here. When you set the proxy settings in your Gnome Preferences, it does two different things:

      - Sets the /system/http_proxy gconf keys
      - Sets the $http_proxy environment variable.

It appears to be the second of these that is causing the problem (at least for me). If you do an "unset http_proxy" from the command line, and then do a "sudo update-manager" things work fine. There doesn't appear to be anything wrong with the content of the $http_proxy variable (i.e. http://<user>:<pass>@<proxy-server>:<port>/ ), so I can only assume that update manager isn't parsing it correctly.

Christophe Olinger (olingerc) wrote :

Unsetting http_proxy solved the problem in gutsy also. This problem persits since edgy. Why is it not solved yet?

Richard (rd1) wrote :

I have had a similar problem during a Feisty to Gutsy upgrade using apt-cacher as proxy (see ), but it's a generic proxy problem. If Canonical are serious about the corporate market, where proxy servers are very common, they need to fix this sort of bug... Having to hack around on the command line is fine for me since I've used Linux for ages, but users new to Linux will probably just give up or have to use the apt-get upgrade method, which of course can lead to breakage that requires *more* expertise to fix.

Please fix this bug and the 113658 bug. Your corporate users will thank you!

Claudio Satriano (claudiodsf) wrote :

I agree with Richard: bug #113658 is related to this.

Also people here at my university lab (where we use apt-cacher to save bandwith) would benefit a lot!

(p.s. Richard: put # before the bug number, in order to have automatic linking ;) )

Please set the importance of this bug much higher than it currently is. This bug is preventing me from upgrading from Gutsy to Hardy, because for bandwidth reasons I have to use apt-cacher.

Note, though, that update-manager should follow APT's proxy settings, not GNOME's settings.

I am Matt Jones (iammattjones) wrote :

This still exists in Hardy.
Proxy is set in both Gnome and APT. FFx works perfectly, command line apt or Synaptic Package Manager and Update-Manager fail to connect to the proxy.

W: Failed to fetch
  Could not resolve '!1@hrmc'

Michael Vogt (mvo) wrote :

I checked the way the proxy initialization works and I changed it so that it now goes in the order of:
- apt proxy setting
- synaptic proxy setting
- gconf proxy setting
- http environemnt

(in bzr for jaunty). If there are still issues left, please file them as seperate bugs because the original report (gnome settings not honored) should be fixed with that.

Changed in update-manager:
importance: Low → Medium
status: Confirmed → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package update-manager - 1:0.97

update-manager (1:0.97) jaunty; urgency=low

  * UpdateManager/Core/
    - remove debug message (LP: #310046)
  * UpdateManager/Common/
    - when initializing the proxy configuration, do in this
      * check apt setting
      * check synaptic setting
      * check users gconf
      * check http_proxy environment
    (LP: #24250)
  * UpdateManager/Core/
    - ensure correct error message if downloading failed
      (LP: #113658)
    - when fetching from mirrors, add fallback if the mirror
      is too loaded to cope
    - improve logic that detects what mirror is in use by
      sources.list inspection (LP: #107983)
  * DistUpgrade/,
    - re-factor and make code more modular
    - do not overwrite existing log files on upgrade
      (LP: #111819)
  * reorganize the imports and get rid of "Common" submodule
    and merge that all into "Core"
  * improve the debug output via the "DEBUG_UPDATE_MANAGER"

 -- Michael Vogt <email address hidden> Mon, 26 Jan 2009 17:26:40 +0100

Changed in update-manager:
status: Fix Committed → Fix Released

Clarification question: Given that this is fixed in Jaunty (much thanks, by the way), will it first apply to Intrepid => Jaunty upgrades, or Jaunty => Jaunty+1 upgrades?

Sverre J Bjørke (sjbjorke) wrote :

I still got this problem in Jaunty. Any help appreciated.

pimlists (pimlists) wrote :

I just downloaded and installed Jaunty, the problem is still present. Apparently it is possible to set the proxy, but never to change it back. "Apply system wide" in the network proxy menu seems to not change a thing for the update manager. Very annoying!

pimlists (pimlists) wrote :

Actually there seem to be more issues. If the proxy is set once, it will never be set back for the update manager, apt, synaptic, but ALSO for totem, rythmbox, etc. Firefox does change itself along with the proxy setting. It's like there is still a hidden setting active.

pimlists (pimlists) wrote :

ok, as Matt Mossholder wrote in 2007! (#13) the problem is that the network proxy manager from gnome can set, but cannot unset the http_proxy environmental variable. Only manual unset overrides it, and firefox seems to not care?

Interestingly, if you use "reset" in the gnome network proxy manager, it will always return to the state with proxy, not sure why it assumes that to be the default. Please fix this by now! Essential bug that has been around way too long.

John Hardin (jhardin-impsec) wrote :

The problem is that Synaptic caches the proxy settings in its config file, and the "Apply system wide" option doesn't know how to replace that (naturally).

Take a look in /root/.synaptic/synaptic.conf - I wager you will see the old proxy settings. Either correct them there, or delete them so that the global settings are used.

I'd suggest this is a bug in synaptic - it shouldn't cache proxy settings that are obtained from the systemwide config.

JohnCollaros (timefantom) wrote :

I am trying to do a release upgrade to karmic from jaunty and have noticed it does not honor proxy settings.
Currently, regular upgrades work, but the dist-upgrade is failing.
I am running from a non-privileged user prompt

  sudo update-manager -d

In another terminal i have a tcpdump running.
When update-manager launches I can see it connecting to my apt-cacher on port 3142.
But when I click the new distribution upgrade button, I can see it making direct requests to the internet, bypassing the proxy server.
I have proxy unset in the environment variables, but set in apt.conf, in synaptics, and in gnome all to the same thing. (my apt-cacher)
Even when I use the http_proxy= environment variable I get the same result.

It seems update-manager's dist-upgrade process ignores any proxy setting.

Is anyone else having this problem?

Serge van Ginderachter (svg) wrote :

See info in #440229


edit /usr/lib/python2.5/site-packages/UpdateManager/Core/

and add a line " return True" atthe beginning of the downloadable function:

def url_downloadable(uri, debug_func=None):
  helper that checks if the given uri exists and is downloadable
  (supports optional debug_func function handler to support
   e.g. logging)

  Supports http (via HEAD) and ftp (via size request)
  return True
  if debug_func:
    debug_func("url_downloadable: %s" % uri)
  import urlparse

Distribution upgrade, as noted above, ignores proxy settings from any source I've tried (apt, env, gnome). This means normal package upgrades work fine, but you are unable to use the 'Upgrade' button on Update Manager.

jhaig (josephhaig) wrote :

I have seen this as well. It seems only to be a problem when you click on the 'Upgrade' button, when it does some checks before displaying the Release Notes. I can verify this by starting update-manager with ports 80 and 443 blocked on the proxy server (ie, http and https forced through the proxy), clicking 'Upgrade' (at which point update-manager freezes) and then going on to the proxy and unblocking those two ports. When the firewall is restarted with ports 80 and 443 open, update-manager continues to the Release Notes page. I can then block the ports on the proxy again and the upgrade continues as normal, using the proxy. I am guessing that there is just one point in the code where the proxy is being ignored.

Neil Mayhew (neil.mayhew) wrote : (the Python code that does the check) uses urllib2 directly, and doesn't use the apt/synaptic settings. Although urllib2 looks at the environment variables for proxy settings, sudo zaps these for security reasons. I was able to make it work by using sudo -s to get a root shell, setting the environment variables, and then running update-manager. My squid access log shows that it fetched

I believe this is a bug in, which should be changed to use the proxy settings from apt/synaptic.

Captain (stephen-morgans) wrote :

I did the following and now I hav resolved my synaptic system using proxy,

Take a look in /root/.synaptic/synaptic.conf - I wager you will see the old proxy settings. Either correct them there, or delete them so that the global settings are used.

BUT I still can't seem to get updates via synaptic, now getting a different error message, as follows. (PLEASE HELP)

W: Failed to fetch Could not resolve ''

univ (universe) wrote :

That bug is really annoying. And it appears to have been there for a long time. But not affecting everyone for some strange reason. I tried to upgrade from Jaunty to Karmic today and all proxy settings were ignored, I had them in apt, update-manager and in the enrivonment just fine, nothing worked. In the end I edited as suggested by Serge van Ginderachter and this made it finally working! The strange thing is, when I did the last upgrade from Intrepid to Jaunty the whole update process worked just fine without messing with any settings. So probably something changed (again?) with Jaunty?

How many people noticed that according to this bug's status, it has already been fixed. If that's incorrect, then please change the status accordingly. Otherwise, please search for / file an appropriate bug report. Commenting on an already-fixed bug seems to me to be a waste of time.

JohnCollaros (timefantom) wrote :

Ok, I have changed to incomplete.

Changed in update-manager (Ubuntu):
status: Fix Released → Incomplete
JohnCollaros (timefantom) wrote :

Thanks Serge
I tried return True as described in comment 28

He is right, that this routine url_downloadable() is the cause of the issue.
By skipping straight over it, all is well.

Until there is a patch, I believe this is a solution to getting your boxes upgraded behind a proxy or apt-cacher.


JohnCollaros (timefantom) wrote :

Ok, if u look at #361554 someone has proposed a fix.
Marking as duplicate

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.