apt cant work with disable proxy

I had a similar issue with a Dapper Drake install. In my /etc/apt/apt.conf, the installation process placed 'Acquire::http::Proxy "false";' This meant apt could not connect to anything, since the proxy "false" didn't exist. Removing the entry allowed apt to access all repositories.

The only oddity I can think of during my initial installation was networking. The computer is a laptop with a wireless and wired connections available. The wireless went to a dead end network that needs a VPN to get out of (much more secure than WEP that way). Anyway, when the gnome environment came up, it initially wasn't able to access the net until I had manually removed the wireless from the routing table. Perhaps something assumed that some sort of proxy was needed, but I didn't enter one?

For me, accessing the Internet repos was OK but it doesn't work through apt-proxy.

Removing "http" from the line fixes the problem, allowing APT to work through apt-proxy and direct to the Internet.

I've had the same issue with the apt acquire::http::proxy being set to 'false' preventing it from working with apt-proxy. With the setting as is, apt sends a 'GET http://hostname:portnum/ubuntu/etc' request instead of just 'GET /ubuntu/etc', which causes apt-proxy to (probably wrongfully) barf.

I have repeatedly had trouble with this issue. All new installations of Dapper suffer from this problem. It is very frustrating.

Is this an issue with apt-proxy or apt-get?

should it be put down as a bug for apt-proxy?

This occured on a fresh installation of Ubuntu 6.06.1 server for me too. No fancy setup during install, just let it format a disk, partition the disk, and go.

This doesn't look like a bug in apt. It looks more like apt-setup is creating
a bogus proxy entry, as it was noticed upstream. There it was also reassigned
to apt-setup.

I can confirm that I was also bitten by this bug during installing Dapper 6.06.1 Server
(netboot and CD installation)

This is indeed a bug in apt-setup, but apt still should be able to deal with a bad proxy entry. My lastest (edgy) upload should have fixed the issue.

Could this backported to Dapper? It took me a long time
to figure out why debootstrab in the installer works and installs
the base system, but not the installation of the rest of the packages
inside the chrooted /target.

And this included grub, so I couldn't boot into the new (halfway installed) system.
Which made it really critical for me. Manually chroot into the target and removing
the bogus proxy entry solved it.

Side note:
I used a local ftp mirror of the archive and preseeded the installation to use ftp as download
method and entered the mirror settings manually. Perhaps thats why almost nobody else is
seeing this bug, because everyone else is using http as download method.

Side note++:
I had something like "Acquire:::ftp:Proxy "false";" (ok, this is just from memory, but somewhere
in between these : was ftp; can't remember the exact position; you get the idea) and not the
above mentioned "Acquire::::Proxy "false";"

This was fixed a while back:

apt-setup (1:0.11ubuntu4) edgy; urgency=low

  * Backport from trunk (Joey Hess):
    - Fix broken proxy setting code in 90security. Closes: #378868
      Some systems installed before this fix will have Acquire::http::proxy
      "false" set in apt.conf, which leads to breakage in some situations.
      Also, if a proxy was set, it would not be written to the file.

 -- Colin Watson <email address hidden> Wed, 30 Aug 2006 12:16:36 +0100

I also backported this to Dapper as 1:0.10ubuntu3, although unfortunately too late for Ubuntu 6.06.1. If there's ever an Ubuntu 6.06.2, it will contain this fix.

Subscribed ubuntu-sru.

Please note that this patch fixes a strign corruption problem that is triggered when apt is run under cron. This additioanl fix is trivial and part of edgy and debians apt since several month.

The diff is a PITA to read due to the regeneration of all the *.po files (which should be unnecessary). However, the actual code changes look sane and the .po changes are just comments, so please go ahead and upload to dapper-proposed.

Thanks for reviewing the patch. The new version is uploaded to dapper-proposed. I agree that the apt buildsystem sucks in this regrard and regenerates too much.

Accepted into dapper-proposed, please go ahead with QA testing.

This patch does not appear to do anything with apt 0.6.43.3ubuntu2, which is already in dapper. Is this because the parser is strict enough to throw away the word "false"? I can only reproduce this bug if the proxy is set to "http://false".

Thanks Simon for having a look at this.

The issue is not that it does not work at all (this would have been discovered much earlier). But that it does not work for certain configurations. One is e.g. when apt-proxy is used.

Without the patch and with the above proxy line, apts http module sends full Uri GETs to the server (GET http://foo/bar). Just like as it would talk to a proxy).

With the patch it sends the (correct) relative Uri GETs /foo/bar.

Cheers,
 Micheal

I do not quite understand this bit:

- Args[0] = _config->Find(confvar.c_str(),DecompressProg.c_str()).c_str();
+ string argv0 = _config->Find(confvar.c_str(),DecompressProg.c_str());
+ Args[0] = argv0.c_str();

so the result of _config->Find() is first converted to a c_str(), then converted back to a string, just to be converted once again to a c_str(). Is this meant to do something like strdup()?

This should get into the dapper point release, once the patch is sorted out and verified.

+ string argv0 = _config->Find(confvar.c_str(),DecompressProg.c_str());
Find() returns a string and expects two char*

+ Args[0] = argv0.c_str();
Args[] is a array of char*

- Args[0] = _config->Find(confvar.c_str(),DecompressProg.c_str()).c_str();
The problem with this construct is that _config->Find() returns a string and then the char* of that
string is used in Argv[0]. Because the string from Find() is not assigned it gets out of scope after
that line and the memory is freeded and the Args[0] char* is no longer valid.

Test completed successfully on Dapper Drake installation

With apt version 0.6.43.3ubuntu2 all GET requests start with http://
With apt version 0.6.43.3ubuntu3 all GET requests start with /

Copied to dapper-updates.

I too had this bug, but i fixed it with a simple command:

export http_proxy=

after this all was ok

and here's my /etc/apt/apt.conf

Acquire::::Proxy "false";

Hope this helps :)

*Sigh*

seems like it only fixed terminal apt-get,

if I need plugins for totem or something else, he still gives me an error...

still investigating though..