hostname is (still) not added to /etc/hosts

[srcshelton]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

Despite issue #1745, I'm still not seeing the container hostname injected into /etc/hosts - I only realised this recently on trying to launch a Java-based container, and seeing an error regarding not being able to resolve the local hostname (... which is untrue - it resolves just fine, it just doesn't existing in /etc/hosts).

$ cat /etc/hosts | sed 's/#.*$//' | grep -v '^\s*$'
127.0.0.1       localhost
::1             localhost

$ cat /etc/hosts
# /etc/hosts: Local Host Database
#
# This file describes a number of aliases-to-address mappings for the for 
# local hosts that share this file.
#
# The format of lines in this file is:
#
# IP_ADDRESS    canonical_hostname      [aliases...]
#
#The fields can be separated by any number of spaces or tabs.
#
# In the presence of the domain name service or NIS, this file may not be 
# consulted at all; see /etc/host.conf for the resolution order.
#

# IPv4 and IPv6 localhost aliases
127.0.0.1       localhost
::1             localhost

#
# Imaginary network.
#10.0.0.2               myname
#10.0.0.3               myfriend
#
# According to RFC 1918, you can use the following IP networks for private 
# nets which will never be connected to the Internet:
#
#       10.0.0.0        -   10.255.255.255
#       172.16.0.0      -   172.31.255.255
#       192.168.0.0     -   192.168.255.255
#
# In case you want to be able to connect directly to the Internet (i.e. not 
# behind a NAT, ADSL router, etc...), you need real official assigned 
# numbers.  Do not try to invent your own network numbers but instead get one 
# from your network provider (if any) or from your regional registry (ARIN, 
# APNIC, LACNIC, RIPE NCC, or AfriNIC.)
#

This happens both when podman is and isn't executed with a --hostname parameter - but (and this could be key) all of this set of containers are being launched with --network=host (and as root) - is the hostname injection logic only working when container networking is private and/or when run as a non-root user?

(It doesn't appear to make a difference whether the user within the container is root or unprivileged)

Output of podman version:

Version:      2.1.1
API Version:  2.0.0
Go Version:   go1.14.7
Git Commit:   9f6d6ba0b314d86521b66183c9ce48eaa2da1de2
Built:        Sat Oct  3 11:01:42 2020
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.16.1
  cgroupManager: cgroupfs
  cgroupVersion: v2
  conmon:
    package: Unknown
    path: /usr/bin/conmon
    version: 'conmon version 2.0.21, commit: 35a2fa83022e56e18af7e6a865ba5d7165fa2a4a'
  cpus: 8
  distribution:
    distribution: gentoo
    version: unknown
  eventLogger: file
  hostname: dellr330
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.8.9-gentoo
  linkmode: dynamic
  memFree: 1425133568
  memTotal: 8063447040
  ociRuntime:
    name: crun
    package: Unknown
    path: /usr/bin/crun
    version: |-
      crun version 0.15
      commit: 56ca95e61639510c7dbd39ff512f80f626404969
      spec: 1.0.0
      +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    path: /run/podman/podman.sock
  rootless: false
  slirp4netns:
    executable: ""
    package: ""
    version: ""
  swapFree: 23662653440
  swapTotal: 25769787392
  uptime: 469h 28m 41.44s (Approximately 19.54 days)
registries:
  search:
  - docker.io
  - docker.pkg.github.com
  - quay.io
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 23
    paused: 0
    running: 22
    stopped: 1
  graphDriverName: overlay
  graphOptions:
    overlay.ignore_chown_errors: "false"
  graphRoot: /space/podman/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 1765
  runRoot: /space/podman/run
  volumePath: /space/podman/volumes
version:
  APIVersion: 2.0.0
  Built: 1601719302
  BuiltTime: Sat Oct  3 11:01:42 2020
  GitCommit: 9f6d6ba0b314d86521b66183c9ce48eaa2da1de2
  GoVersion: go1.14.7
  OsArch: linux/amd64
  Version: 2.1.1

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

Yes

[mheon]

I remember that this change was deliberate, and relates specifically to the --net=host case (we don't want to set a different hostname than the host if we're sharing network). I think we have two bugs here:

• --hostname is not conflicting with --net=host
• We should be adding the host's hostname to /etc/hosts instead

I need to verify the correct behavior of the second one against Docker on Monday before I can be certain there, though.

[srcshelton]

It's worth noting that in this case the container seems to get a random string of digits and alphabetic characters as hostname by default, and I'm actually trying to give the real system hostname back to the container!

(Is the system hostname a thing which isn't namespaced, similarly to sysctl tunables - or can containers with host-networking legitimately have a separate hostname on the same network (whether this is registered in DNS, or known only to the container itself)?)

Even if there's no safe/catch-all option available, explicitly exposing the option to inject the container hostname into /etc/hosts if the command-line arguments so request feels like a genuinely useful feature...

[mheon]

Hostname is namespaced by the UTS namespace, so I believe it is technically possible to have a different hostname in the container despite sharing the network. This is not exactly a sane thing to do (not only are the two hostnames sharing an IP address, they're sharing the full network stack, so things can get confusing) hence the restriction here.

I think we probably ought to be setting container hostname to the same hostname as the host system in this case, instead of what we seem to be doing (nothing). Will verify what's expected against Docker tomorrow.

[srcshelton]

I think we probably ought to be setting container hostname to the same hostname as the host system in this case, instead of what we seem to be doing (nothing). Will verify what's expected against Docker tomorrow.

That'd be perfect for my use-case!