-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DNS and other errors after original network is disconnected #9603
Comments
what is |
Ok, here is the diagnosis. There are two bugs here. When I reproduce this, I think the dns is somewhat expected? but maybe actually a bug. When connecting to the first network, you get a /etc/resolv.conf pointing to the gateway of the first network. when you connect to the second network, that is unchanged. when we remove the first network, /etc/resolv.conf is unchanged. There seems to be a secondary problem where when adding a second network, no route is defined. So when the first network is removed, the container seems to loose it's default route. |
additionally, if you disconnect the first network and then connect the second, a default route is defined. (and again, the resolve is unchanged). @mheon lets talk about this one ... |
@baude |
What are all of the flags you are using for managing the containers with the hzn client? are yall using the network-alias, link and/or dns flags from the docker version? |
@jarcher we are using go-dockerclient to talk to the API endpoint. We definitely use network alias. Not dns or link. Here is an example of our container using
|
Issue opened in cni plugins; containernetworking/plugins#601 |
A friendly reminder that this issue had no activity for 30 days. |
Unsure. It is definitely a target of our current network rewrite efforts, though. |
@umohnani8 I am okay to close it if the scenario described in the issue is working. Namely:
I do not have the env to test it now. |
A friendly reminder that this issue had no activity for 30 days. |
this should be fixed with aardvark and podman 4.0 release |
works with podman 4 |
i want to double check this one |
The `podman network connect` and `podman network disconnect` commands give containers access to different networks than the ones they were created with; these networks can also have DNS servers associated with them. Until now, however, we did not modify resolv.conf as network membership changed. With this PR, `podman network connect` will add any new nameservers supported by the new network to the container's /etc/resolv.conf, and `podman network disconnect` command will do the opposite, removing the network's nameservers from `/etc/resolv.conf`. Fixes containers#9603 Signed-off-by: Matthew Heon <[email protected]>
The `podman network connect` and `podman network disconnect` commands give containers access to different networks than the ones they were created with; these networks can also have DNS servers associated with them. Until now, however, we did not modify resolv.conf as network membership changed. With this PR, `podman network connect` will add any new nameservers supported by the new network to the container's /etc/resolv.conf, and `podman network disconnect` command will do the opposite, removing the network's nameservers from `/etc/resolv.conf`. Fixes containers#9603 Signed-off-by: Matthew Heon <[email protected]>
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
Start a container with a network, connect it to another network and disconnect it from the original network it started with. The DNS is lost for the container and it cannot even ping with an ip.
Steps to reproduce the issue:
podman network create foo-a
podman network create foo-b
podman run --name test --network foo-a -d alpine sleep 10000
podman network connect foo-b test
podman network disconnect foo-a test
podman exec -it test ping google.com
ping: bad address 'google.com'.
podman exec -it test ping 172.217.0.238
PING 172.217.0.238 (172.217.0.238): 56 data bytes
ping: sendto: Network unreachable
WARN[0000] Error resizing exec session 79bb31f01304ce475be90f0eabaf55fbb40c1fafd7bf8822419a5d3b19f3eb33: could not open ctl file for terminal resize for container a5092f2db3f45dde2e785fae5ef2ba4c70843a5e0c220744fe1f64a4e4234503: open /var/lib/containers/storage/overlay-containers/a5092f2db3f45dde2e785fae5ef2ba4c70843a5e0c220744fe1f64a4e4234503/userdata/79bb31f01304ce475be90f0eabaf55fbb40c1fafd7bf8822419a5d3b19f3eb33/ctl: no such device or address
Describe the results you received:
Please see output from step 4 and 5.
Describe the results you expected:
No errors.
Additional information you deem important (e.g. issue happens only occasionally):
Output of
podman version
:Output of
podman info --debug
:Package info (e.g. output of
rpm -q podman
orapt list podman
):Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?
Yes/No
Additional environment details (AWS, VirtualBox, physical, etc.):
The text was updated successfully, but these errors were encountered: