Closed y0zong closed 2 years ago
@y0zong: The label(s) kind/(maybe)
cannot be applied, because the repository doesn't have them.
Thanks for reaching out, @y0zong!
set system proxy (http_proxy)
Where do you set the proxy? Do you set it inside the podman machine
?
Where do you set the proxy? Do you set it inside the
podman machine
?
no, on host (mac os in my case), maybe it's no need to set proxy inside the podman machine
when host is already in proxy?
The proxy is set correctly: proxyconnect tcp: dial tcp 127.0.0.1:7890: connect: connection refused
The problem is that your proxy is listening on 127.0.0.1. Obviously 127.0.0.1 inside the VM is a different address and therefore it cannot connect to the proxy on you actual host.
If you set http_proxy=socks5://host.containers.internal:7890
before you run podman machine init
it should work.
Maybe podman should just s/127.0.0.1/host.containers.internal
and s/localhost/host.containers.internal
automatically when it copies the proxy value from the host.
If you set http_proxy=socks5://host.containers.internal:7890 before you run podman machine init it should work.
thank for point out this @Luap99 , and the problem is should I add 127.0.0.1 host.containers.internal
to my host file on host os? because http_proxy=socks5://host.containers.internal:7890
will break my proxy and before podman machine init
proxy still need to work for podman to pull fedora
I think it's better that podman automatically map host proxy value to machine so it can read it correctly
if you run http_proxy=socks5://host.containers.internal:7890 podman machine init
it will only change the proxy var for this single command not your system.
I just test it and I think you are right, but I don't know why http_proxy=socks5://host.containers.internal:7890 podman machine init
this command still hit the same error but it works as expected when I add 127.0.0.1 host.containers.internal
to my host file
however it works now
add item blow to host file
127.0.0.1 host.containers.internal
and change proxy to
http_proxy=socks5://host.containers.internal:7890
then everything works fine
much thanks @Luap99 for your help and I close this issues for the problem is solved, but I still stay concerned if some day podman can do this itself and no need to change proxy setting
update:
I figured out this issue, it seems podman copy all current shell's env into the machine when I do podman machine init
or podman machine start
? Anyway, I opened a new shell and make sure http_proxy
env is not set then stop & start podman machine, everything works now 💯 .
original post:
I don't have $http_proxy var setting on my host zsh terminal but still got this issue.
$> podman pull alpine
Resolved "alpine" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull docker.io/library/alpine:latest...
Error: initializing source docker://alpine:latest: pinging container registry registry-1.docker.io: Get "https://registry-1.docker.io/v2/": proxyconnect tcp: dial tcp 127.0.0.1:1081: connect: connection refused
After I ssh into the machine:
> podman machine ssh
Connecting to vm podman-machine-default. To close connection, use `~.` or `exit`
Fedora CoreOS 36.20221014.2.0
Tracker: https://github.com/coreos/fedora-coreos-tracker
Discuss: https://discussion.fedoraproject.org/tag/coreos
[core@localhost ~]$ echo $http_proxy
http://127.0.0.1:1081
[core@localhost ~]$
How is this happen, why the machine have http_proxy
set by default ???
update:
I figured out this issue, it seems podman copy all current shell's env into the machine when I do
podman machine init
orpodman machine start
? Anyway, I opened a new shell and make surehttp_proxy
env is not set then stop & start podman machine, everything works now 💯 .original post:
I don't have $http_proxy var setting on my host zsh terminal but still got this issue.
$> podman pull alpine Resolved "alpine" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf) Trying to pull docker.io/library/alpine:latest... Error: initializing source docker://alpine:latest: pinging container registry registry-1.docker.io: Get "https://registry-1.docker.io/v2/": proxyconnect tcp: dial tcp 127.0.0.1:1081: connect: connection refused
After I ssh into the machine:
> podman machine ssh Connecting to vm podman-machine-default. To close connection, use `~.` or `exit` Fedora CoreOS 36.20221014.2.0 Tracker: https://github.com/coreos/fedora-coreos-tracker Discuss: https://discussion.fedoraproject.org/tag/coreos [core@localhost ~]$ echo $http_proxy http://127.0.0.1:1081 [core@localhost ~]$
How is this happen, why the machine have
http_proxy
set by default ???
faced with the same issue, and figured out that it was set in /etc/systemd/system.conf.d/default-env.conf
with the following default value, which seems to override the value I manually set at /etc/systemd/system.conf.d/10-default-env.conf
as suggested here
[Manager]
#Got from QEMU FW_CFG
DefaultEnvironment=http_proxy="http://127.0.0.1:1081" https_proxy="http://127.0.0.1:1081"
Description
In China we have to use proxy to access docker hub to pull image
proxy setting (this works fine in docker)
http_proxy=socks5://127.0.0.1:7890
access test, success to resolve docker.io
or (success when use podman login)
but connection refused when pull image
keypoint in error
pinging container registry registry-1.docker.io: Get "https://registry-1.docker.io/v2/": proxyconnect tcp: dial tcp 127.0.0.1:7890: connect: connection refused
I don't know if podman use ping result to decide connection status, otherwise ping can be failed but connection is still alive when use socks5 proxy (that's why I use curl -vv test instead ping)
pls help
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug (maybe)
Steps to reproduce the issue:
set system proxy (http_proxy)
podman-compose start project
Additional information you deem important (e.g. issue happens only occasionally):
Output of
podman version
:Output of
podman info --debug
:Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)
Yes
Additional environment details (AWS, VirtualBox, physical, etc.):
mac os Monterey