Podman: Build fails if slirp4netns is installed

Created on 7 Mar 2019 · 14Comments · Source: containers/podman

/kind bug

Description
Build fails if slirp4netns is installed (it builds without slirp4netns)

Steps to reproduce the issue:

install slirp4netns (v0.3.0-alpha.2)
use rootless podman to build an image
3.

RUN apt update
Err:1 http://deb.debian.org/debian stretch InRelease
  Temporary failure resolving 'deb.debian.org'
Err:2 http://security.debian.org/debian-security stretch/updates InRelease
  Temporary failure resolving 'security.debian.org'
Err:3 http://deb.debian.org/debian stretch-updates InRelease
  Temporary failure resolving 'deb.debian.org'
Err:4 http://security.debian.org/debian-security buster/updates InRelease
  Temporary failure resolving 'security.debian.org'
Err:5 http://deb.debian.org/debian buster InRelease
  Temporary failure resolving 'deb.debian.org'
Err:6 http://deb.debian.org/debian buster-updates InRelease
  Temporary failure resolving 'deb.debian.org'

Describe the results you received:
The domain name deb.debian.org can not be resolved in build.

Describe the results you expected:
It should resolve the domain...

Output of podman version:

podman version
Version:            1.0.1-dev
RemoteAPI Version:  1
Go Version:         go1.10.4
OS/Arch:            linux/amd64

Output of podman info --debug:

podman info --debug
debug:
  compiler: gc
  git commit: ""
  go version: go1.10.4
  podman version: 1.0.1-dev
host:
  BuildahVersion: 1.7-dev
  Conmon:
    package: 'cri-o-1.12: /usr/lib/crio/bin/conmon'
    path: /usr/lib/crio/bin/conmon
    version: 'conmon version 1.12.4-dev, commit: '
  Distribution:
    distribution: ubuntu
    version: "18.04"
  MemFree: 2979913728
  MemTotal: 16418299904
  OCIRuntime:
    package: 'cri-o-runc: /usr/sbin/runc'
    path: /usr/sbin/runc
    version: 'runc version spec: 1.0.1-dev'
  SwapFree: 19999485952
  SwapTotal: 19999485952
  arch: amd64
  cpus: 8
  hostname: thomas-laptop
  kernel: 5.0.0-050000-generic
  os: linux
  rootless: true
  uptime: 54m 17.82s
insecure registries:
  registries: []
registries:
  registries:
  - docker.io
store:
  ConfigFile: /home/thomas/.config/containers/storage.conf
  ContainerStore:
    number: 12
  GraphDriverName: vfs
  GraphOptions: null
  GraphRoot: /home/thomas/.local/share/containers/storage
  GraphStatus: {}
  ImageStore:
    number: 16
  RunRoot: /run/user/1000

Additional environment details (AWS, VirtualBox, physical, etc.):

Ubuntu 18.4

kinbug

Source

chpio

All 14 comments

@giuseppe PTAL

rhatdan on 7 Mar 2019

it looks like a duplicate of the Buildah issue, how does the /etc/resolv.conf file look like inside of the container?

giuseppe on 8 Mar 2019

RUN cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "systemd-resolve --status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0
search <snip; it's the domain of my network>

chpio on 8 Mar 2019

thanks, so the issue is that it is using a local DNS server that is not accessible from the rootless container.

Do you get anything different if you run as root user?

giuseppe on 8 Mar 2019

hmmm... the /etc/resolv.conf file looks just the same, but now it's resolving the dns names.

chpio on 8 Mar 2019

I am surprised that it works as root, how does the network inside of the container look like ip addr?

I am trying to reproduce locally using a similar resolv.conf as yours but it fails for root as well

giuseppe on 8 Mar 2019

Bind-mounting /etc/resolv.conf is known to be unmounted when the host file is removed and recreated (by systemd-resolved or NetworkManager).

AkihiroSuda on 8 Mar 2019

rootless:

STEP 2: RUN ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: tap0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 86:b0:76:f3:a8:e8 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.100/24 brd 10.0.2.255 scope global tap0
       valid_lft forever preferred_lft forever
    inet6 fe80::84b0:76ff:fef3:a8e8/64 scope link tentative 
       valid_lft forever preferred_lft forever

run as root: it's just my local network context

FROM debian
RUN ip addr
RUN cat /etc/resolv.conf
RUN ping google.com

run as: $ podman build . or $ sudo podman build .

chpio on 8 Mar 2019

ah ok, so as root it is running the equivalent of --net host. That should work for rootless as well, you can run the container in the host network namespace with:

podman build --net host ...

giuseppe on 8 Mar 2019

$ podman build --net host .
STEP 1: FROM debian
STEP 2: RUN ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: tap0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 06:9c:f0:f6:90:1b brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.100/24 brd 10.0.2.255 scope global tap0
       valid_lft forever preferred_lft forever
    inet6 fe80::49c:f0ff:fef6:901b/64 scope link tentative 
       valid_lft forever preferred_lft forever
<snip>
STEP 6: RUN ping google.com
ping: google.com: Temporary failure in name resolution
Error: error building at step {Env:[PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin] Command:run Args:[ping google.com] Flags:[] Attrs:map[] Message:RUN ping google.com Original:RUN ping google.com}: error while running runtime: exit status 2

chpio on 8 Mar 2019

I've opened a PR to honor --net host: https://github.com/containers/libpod/pull/2585

That is the solution, I believe, when the resolv.conf contains addresses that are not accessible from the container

giuseppe on 8 Mar 2019

👍1

@giuseppe Why not just write slirp4netns built-in DNS 10.0.2.3 to resolv.conf?

AkihiroSuda on 8 Mar 2019

👍1

@giuseppe Why not just write slirp4netns built-in DNS 10.0.2.3 to resolv.conf?

great idea. I've added a patch to do it

giuseppe on 11 Mar 2019

👍1

@giuseppe Why not just write slirp4netns built-in DNS 10.0.2.3 to resolv.conf?

great idea. I've added a patch to do it

IMHO - in this situation will be better to change order of nameservers into guest's resolv.conf - please add 10.0.2.3 as first one and then all others because default number of nameservers used by system is only 3 (MAXNS in resolv.h).