Avoid http_proxy env from the system host injected to mailcow containers

enriluis commented 1 month ago

Contribution guidelines

[X] I've read the contribution guidelines and wholeheartedly agree

I've found a bug and checked that ...

[X] ... I understand that not following the below instructions will result in immediate closure and/or deletion of my issue.
[X] ... I have understood that this bug report is dedicated for bugs, and not for support-related inquiries.
[X] ... I have understood that answers are voluntary and community-driven, and not commercial support.
[X] ... I have verified that my issue has not been already answered in the past. I also checked previous issues.

Description

I have spent a lot of time investigating an error, the error in question tells me that nginx does not connect to php-fpm, after investigating, reading the forums and checking and redoing everything several times and obtaining the same result, I realized that my problem is caused by the http_proxy env, since my host is behind a proxy server to be able to download the images from the internet, then that http_proxy variable is injected into the containers once deployed, how could I add a variable value to override that value and perhaps empty that variable or maybe someone needs set the http_proxy inside the container to for example download clamav updates, should I be able to establish that variable in the conf or the compose.

On the http proxy server I see many requests from the mailcow vm host that I have not sent:

NONE_NONE/400 | error:invalid-request

After removing http_proxy and restarting the daemon, even the host, everything is running again, but it's hard to keep running and update mailcow.... this never happened to me with docker and http_proxy, all my pulled images are behind http_proxy. So I'm looking for a solution in docker that allows me to pull images behind http_proxy and run the container without http_proxy at the same time.

Logs:

"GET /admin HTTP/2.0", upstream: "fastcgi://172.16.172.7:9002", host: "85687568", referrer: "https://85687568/"
2024/05/30 23:05:02 [error] 19#19: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 85687568, server: myserver, request: "GET /admin HTTP/2.0", upstream: "fastcgi://[::a]:9002", host: "85687568", referrer: "https://85687568/"
435345 - - [30/May/2024:23:05:02 -0400] "GET /admin HTTP/2.0" 502 2015 "https://85687568/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:126.0) Gecko/20100101 Firefox/126.0"
435345 - - [30/May/2024:23:05:02 -0400] "GET /favicon.ico HTTP/2.0" 404 146 "https://85687568/admin" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:126.0) Gecko/20100101 Firefox/126.0"

Steps to reproduce:

mkdir -p ~/.docker/
touch ~/.docker/config.json
cat <<EOF | tee ~/.docker/config.json > /dev/null
{
 "proxies": {
   "default": {
     "httpProxy": "http://myproxy:8080",
     "httpsProxy": "https://myproxy:8080",
     "noProxy": "192.168.0.0/16,172.16.0.0/16,127.0.0.0/8,10.0.0.0/8,172.22.1.0/24"
   }
 }
}
EOF

cat <<EOF | sudo tee /etc/systemd/system/docker.service.d/http-proxy.conf > /dev/null
[Service]
Environment="HTTP_PROXY=http://myproxy:8080"
Environment="HTTPS_PROXY=http://myproxy:8080"
Environment="NO_PROXY=192.168.0.0/16,172.16.0.0/16,127.0.0.0/8,10.0.0.0/8,172.22.1.0/24"
EOF
them restart and reload daemon....
pull all images mailcow
config start  docker compose up -d
goto admin page and get preparing page error... get the logs

Which branch are you using?

master

Which architecture are you using?

x86

Operating System:

ubuntu 24.04

Server/VM specifications:

8 ram, 8 cores

Is Apparmor, SELinux or similar active?

no

Virtualization technology:

vmeare

Docker version:

20.10.21

docker-compose version or docker compose version:

V2.12

mailcow version:

2022-08

Reverse proxy:

Nginx

Logs of git diff:

no relevant

Logs of iptables -L -vn:

no relevant

Logs of ip6tables -L -vn:

no relevant

Logs of iptables -L -vn -t nat:

no relevant

Logs of ip6tables -L -vn -t nat:

no relevant

DNS check:

no relevant

enriluis commented 1 month ago

Maybe is a docker error? https://forums.docker.com/t/prevent-docker-from-passing-proxy-to-container/92718

kovacs-andras commented 3 weeks ago

Seems like some things will never change... For example, the Sun will always rise in the east and set in the west. The Moon will always wax and wane. And Docker doesn't know what to do with proxies. But if we take a closer look you made it pretty sure to use that proxy:

The proxy variables will be passed to the container's env. because of the content of your ~/.docker/config.json There is no need for that if you don't want the running container itself to use that forward proxy.
If you want to use the forward proxy for pulling the container images, the systemd service override should be enough. If I were you I would modify that dirty script somehow like:
```
sudo EDITOR=tee systemctl edit docker.service << 'EOF'
[Service]
Environment="HTTP_PROXY=http://myproxy:8080"
Environment="HTTPS_PROXY=http://myproxy:8080"
Environment="NO_PROXY=192.168.0.0/16,172.16.0.0/16,127.0.0.0/8,10.0.0.0/8,172.22.1.0/24"
EOF
```
This way you don't need to create the drop-in folder and neither reload systemd. (But it's still... not so nice) If you don't believe me, check it by yourself with sg. like docker run --rm -it alpine:latest env with and without your configs. docs: https://docs.docker.com/network/proxy/

IMHO it's not a mailcow related issue and I would close it. But don't give up and I wish good luck to you!

mailcow / mailcow-dockerized