buildah: podman-build network fails DNS lookups; podman-run works
Description
When using a VPN (OpenVPN), DNS lookups fail inside of podman build, but work inside of podman run. Routing works (dig outside of the container and use that IP inside), so I think some UDP tables might not be hooked up properly?
Steps to reproduce the issue:
- Set up a VPN in a network namespace (so it is the only available connection)
podman buildfails DNS lookupspodman run -it $previous_image_cacheworks just fine
Describe the results you received:
DNS lookup failure (timeout)
Describe the results you expected:
DNS lookup success.
Output of rpm -q buildah or apt list buildah:
buildah-1.16.2-1.fc33.x86_64
Output of buildah version:
Version: 1.16.2
Go Version: go1.15
Image Spec: 1.0.1-dev
Runtime Spec: 1.0.2-dev
CNI Spec: 0.4.0
libcni Version:
image Version: 5.5.2
Git Commit:
Built: Wed Dec 31 19:00:00 1969
OS/Arch: linux/amd64
Output of podman version if reporting a podman build issue:
Version: 2.1.1
API Version: 2.0.0
Go Version: go1.15.2
Built: Wed Oct 7 12:21:20 2020
OS/Arch: linux/amd64
Output of cat /etc/*release:
Fedora release 33 (Thirty Three)
NAME=Fedora
VERSION="33 (Thirty Three)"
ID=fedora
VERSION_ID=33
VERSION_CODENAME=""
PLATFORM_ID="platform:f33"
PRETTY_NAME="Fedora 33 (Thirty Three)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:33"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f33/system-administrators-guide/"
SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=33
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=33
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
Fedora release 33 (Thirty Three)
Fedora release 33 (Thirty Three)
Output of uname -a:
Linux erythro 5.8.16-300.fc33.x86_64 #1 SMP Mon Oct 19 13:18:33 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Output of cat /etc/containers/storage.conf:
<Fedora default>
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 2
- Comments: 22 (13 by maintainers)
Commits related to this issue
- Fix resolv.conf content whit run --net=private Make sure to use the correct resolv.conf in case of systemd-resolved. Also filter out 127... nameserver when run in private netns. Fixes #2780 Signed-... — committed to Luap99/buildah by Luap99 3 years ago
- Fix resolv.conf content whit run --net=private Make sure to use the correct resolv.conf in case of systemd-resolved. Also filter out 127... nameserver when run in private netns. Fixes #2780 Signed-... — committed to Luap99/buildah by Luap99 3 years ago
- Fix resolv.conf content with run --net=private Make sure to use the correct resolv.conf in case of systemd-resolved. Also filter out 127... nameserver when run in private netns. Fixes #2780 Signed-... — committed to Luap99/buildah by Luap99 3 years ago
- Fix resolv.conf content with run --net=private Make sure to use the correct resolv.conf in case of systemd-resolved. Also filter out 127... nameserver when run in private netns. Fixes #2780 Signed-... — committed to Luap99/buildah by Luap99 3 years ago
@Luap99 @mheon Any update on this?
My podman is experiencing similar symptoms;
podman buildhas a DNS error (on aRUN yum installcommand) but if I build without that and then run the container and execute the command manually it works.I am not using OpenVPN, but this is a corporate environment so I’m not sure if some combination of networking/firewall is causing this. Host is a RHEL8 server.
This affects podman 2.2.1 and 3.0.2-dev
I take a look.
A friendly reminder that this issue had no activity for 30 days.
A friendly reminder that this issue had no activity for 30 days.
That refers to the former. I updated my comment to include the commands to make it clearer.
@rhatdan Just tried that. With that RUN command (using
podman build) I can see something like this:Inside the running container we have:
On the host machine we have:
In all 3 snippets example.com is actually a corporate domain, and in the 3rd snippet the internal IPs are valid internal DNS servers.
I don’t know enough to say that the first snippet is messed up or not.