Acquire::http::proxy ignored / used inconsistently?

[Benjamin Portner]

Problem description

I have a client (A) and a freight server (B) serving apt packages on the same network. I also have a proxy server (C), which the client uses to talk to "the internet". When I run `sudo apt update`, my client talks to the freight server directly, without contacting the proxy. However, when `apt.daily` runs, the client contacts the proxy, which then connects to the freight server.

Expected behavior

Although updates work in both cases, the current behavior is inconsistent. The proxy should be used in both cases or in neither case.

Setup details

I use Ubuntu 22.04.4 with apt 2.4.11 (amd64). /etc/apt/sources.list.d/freight.list contains the local freight server. /etc/apt/sources.list lists the official Ubuntu repositories. /etc/apt/apt.config.d/95proxy contains one line `Acquire::http::proxy "http://my.proxy:8080/"`. Omitting the proxy config (`Acquire::http::proxy "false"`) lets the client contact the freight server directly during `apt.daily`, but updating the official repositories fails. Having the proxy properly configured,`apt.daily` succeeds but with the described inconsistent behavior.

Note: I am aware that proxy exceptions can be configured using the "DIRECT" keyword.

[Julian Andres Klode (juliank)]

Hi there,

the bug tracker is not the right place for user support. APT does not suddenly pick different proxies when running as a service. It does respect your http_proxy and no_proxy variables. Please note that while http_proxy does not override Acquire::http::proxy, no_proxy does. It sounds likely that when you run update manually, you have your freight server in the no_proxy variable.

You have plenty of options to configure this more reliably, such as

1) configure Acquire::http::proxy::archive.ubuntu.com to only proxy for archive.ubuntu.com (repeat for all hosts you want proxy)
2) configure Acquire::http::proxy to your proxy and configuring Acquire::http::proxy::freightserverhostname "DIRECT"
3) configure Acquire::http::proxy (or http_proxy) and set no_proxy in /etc/environment(.d)

[Benjamin Portner (benportner)]

@juliank

Respectfully disagree. Calling `no_proxy="" sudo apt update` still by-passes the proxy. This is not the cause of the problem.

> Please note that while http_proxy does not override Acquire::http::proxy, no_proxy does.

This too, seems rather inconsistent to me. Is this behavior documented somewhere? I read through the bug reports and found many tickets relating to apt dealing with http_proxy and no_proxy. It seems the behavior changed over time and I am not the only one who lost track of what apt does with these settings.

[Benjamin Portner (benportner)]

Okay, I realized that `no_proxy="" sudo ...` does not overwrite no_proxy because it gets loaded again from /etc/environment when switching to the su context. If I do `sudo su` and then call `no_proxy="" apt update` then indeed the proxy is no longer by-passed.

> 3) configure Acquire::http::proxy (or http_proxy) and set no_proxy in /etc/environment(.d)

This is exactly what I did and it leads to the described inconsistent behavior. Apparently, /etc/environment is not read when apt.daily runs. This means, no_proxy is *not* defined when apt runs as a service - but it *is* defined when running apt from the terminal. So effectively, apt does "suddenly pick different proxies when running as a service".

Note that this is not a support request as I did not ask for help or pose any questions.

[Julian Andres Klode (juliank)]

I mean that's good to know that systemd does not load system-wide environment variables but it's their design choice and not a bug in apt (or systemd).

[Benjamin Portner (benportner)]

Okay, I agree that this is not an apt bug. However, the fact that you and me got this part wrong shows that the documentation can be improved. I propose updating the apt-transport-http manpage "Proxy Configuration" section as follows:

- From the current description, it does not become clear that http_proxy does *not* override Acquire::http::proxy. This should be explicitly stated.

- There should be an explicit note that apt, when run as a systemd service, does not read /etc/environment. It should be followed by a specific recommendation to use the Acquire::http::proxy::freightserverhostname "DIRECT" mechanism in addition to "no_proxy" environment variables to ensure consistent behavior.