Dockerfile: Remove /etc/nsswitch.conf workaround

[polarathene]

Preflight checklist

• I could not find a solution in the existing issues, docs, nor discussions.
• I agree to follow this project's Code of Conduct.
• I have read and am following this repository's Contribution Guidelines.

Describe your problem

Some of the Dockerfile files in this repo (and likely other Ory projects) carry an old workaround (introduced in April 2020):

hydra/.docker/Dockerfile-alpine

Lines 9 to 11 in f9cee32

	# set up nsswitch.conf for Go's "netgo" implementation
	# - https://github.com/golang/go/blob/go1.9.1/src/net/conf.go#L194-L275
	RUN echo 'hosts: files dns' > /etc/nsswitch.conf

hydra/.docker/Dockerfile-scratch

Lines 5 to 7 in f9cee32

	# set up nsswitch.conf for Go's "netgo" implementation
	# - https://github.com/golang/go/blob/go1.9.1/src/net/conf.go#L194-L275
	RUN [ ! -e /etc/nsswitch.conf ] && echo 'hosts: files dns' > /etc/nsswitch.conf

This is no longer relevant since Alpine 3.16.3 which now includes /etc/nsswitch.conf, additionally since Go 1.16 the referenced logic has been changed to not prefer dns files, but instead files dns (preferring /etc/hosts before querying DNS).

Describe your ideal solution

Remove the relevant lines from the Dockerfile files across Ory projects.

Workarounds or alternatives

No issue, just communicating that the content is redundant to maintainers.

Version

2.1.2

[polarathene]

Context

When /etc/nsswitch.conf does not exist, previously Go static builds (CGO_ENABLED=0) on Linux would perform a host lookup by first querying DNS with /etc/hosts as a fallback.

• As many expect /etc/hosts to be checked prior to querying DNS, a common workaround was to include /etc/nsswitch.conf in images using a alpine or scratch base where the file would be missing.

• Resolved since Go 1.16 in Feb 2021 (Oct 2020 commit, go-review), /etc/hosts will be used first (even when no /etc/nsswitch.conf exists).

• While not necessary since Go 1.16, Alpine Linux now includes /etc/nsswitch.conf by default (since Alpine 3.16.3, released in Nov 2022):

  $ docker run --rm alpine cat /etc/nsswitch.conf
  
  # musl itself does not support NSS, however some third-party DNS
  # implementations use the nsswitch.conf file to determine what
  # policy to follow.
  # Editing this file is not recommended.
  hosts: files dns

Thus the workaround of adding a /etc/nsswitch.conf file is no longer necessary to carry, so long as you build with Go 1.16 or newer.

Verification

The original golang bug report has a simple reproduction with building a basic Go program.

However to easily reproduce the bug and that demonstrate the fix, I've provided an alternative reproduction that compares past Caddy image releases.

Additional info - References & Timeline (click to expand)

• 2.3.0 is built with Go 1.15.13 on Alpine 3.12 (actual 2.3.0 image, released in Jan 2021, last DockerHub push on June 2021)
• 2.4.0 is built with Go 1.16.4 on Alpine 3.13 (actual 2.4.0 image, released May 2021, last DockerHub push on May 2021)
• Dockerfile workaround adding /etc/nsswitch.conf:
  • Caddy image:
    • Added in June 2020.
    • Removed in Jan 2023.
  • Golang image:
    • /etc/nsswitch.conf workaround added in May 2018 (references original source from Oct 2017 that applies these insights).
    • Adapts for Alpine 3.16.3 in Nov 2022 with full removal in Dec 2022 (due to dropping Alpine 3.15 images).
• NOTE: DockerHub official images can also experience additional delay to publish (via doijanky, a Jenkins build-queue).

Reproduction Config

Using Docker Compose, all we need is a single compose.yaml:

# compose.yaml

services:
  example:
    image: go-dns-bug
    container_name: nsswitch-example
    # Inline Dockerfile build
    # Purpose: Remove `/etc/nsswitch.conf` from the image
    build:
      # CADDY_VERSION below is not a Dockerfile build ARG,
      # Within a compose config, it is interpolated from ENV:
      # https://docs.docker.com/compose/environment-variables/env-file/#interpolation
      dockerfile_inline: |
        FROM caddy:${CADDY_VERSION:-2.3.0}-alpine AS base

        FROM base AS remove-conf
        RUN rm /etc/nsswitch.conf
      # Using an ENV, can change the build target to toggle removing /etc/nsswitch.conf
      target: ${BUILD_TARGET:-remove-conf}
      # Assists with prune filter for cleanup afterwards, as base images are years old:
      labels:
        - "prune-marker=go-dns-bug"
    # Appends to the run-time generated `/etc/hosts`:
    extra_hosts:
      - "example.com:127.0.0.1"
    ports:
      - "80:80"
    configs:
      - source: caddyfile
        target: /etc/caddy/Caddyfile

# Inline config file content requires Docker Compose v2.23.1 (Nov 2023).
# For earlier releases, create a file with the content and
# volume mount it to: /etc/caddy/Caddyfile
configs:
  caddyfile:
    content: |
      {
        admin example.com:1337
      }

      # Optional, can test connection with `curl localhost`
      :80 {
        log
        respond "hello!"
      }

Reproduction Commands

The above compose.yaml file bundles the Caddyfile config and Dockerfile via Docker Compose features (inline content + Dockerfile).

This makes it simple to run a few commands to test the following variants with ENV vars.

# The default will fail (Caddy 2.3.0 with `/etc/nsswitch.conf` removed):
$ docker compose up --force-recreate --build

nsswitch-example  | run: loading initial config: loading new config: starting caddy administration endpoint: listen tcp 93.184.216.34:1337: bind: cannot assign requested address
nsswitch-example exited with code 1

# Caddy 2.3.0 with `/etc/nsswitch.conf` provided from image works (`/etc/hosts` takes priority over DNS lookup):
$ BUILD_TARGET=base docker compose up --force-recreate --build

# Caddy 2.4.0 is consistent with or without `/etc/nsswitch.conf`,
# due to the release being built with Go 1.16 that fixes the logic:
$ CADDY_VERSION=2.4.0 BUILD_TARGET=base docker compose up --force-recreate --build
$ CADDY_VERSION=2.4.0 docker compose up --force-recreate --build

Context for above commands (collapsed for brevity)

• --force-recreate is optional is appended to avoid any confusion that container re-use can cause.
• --build is required to trigger building variants with ENV provided to commands below.
• The default build target removes /etc/nsswitch.conf, BUILD_TARGET ENV is used to test the original image (both images bundle the /etc/nsswitch.conf workaround, they use Alpine before 3.16).
• The default image is Caddy 2.3.0 (built with Go 1.15), thus it is reliant upon /etc/nsswitch.conf.
• The final commands demonstrate that /etc/nsswitch.conf is not relevant for Caddy 2.4.0 (built with Go 1.16).

---

Optionally test the connection is working:

# `-w "\n"` is only to avoid affecting the terminal prompt position
$ curl -w "\n" localhost

hello!

For proper reproduction, it's worth noting that the Caddyfile configured admin address needs to resolve to an IP that's invalid to bind to within the container.

• If the FQDN uses a reserved TLD like .test, typically the DNS query will fail and /etc/hosts will provide the fallback if one is available.
• Changing example.com to example.test will demonstrate that even the failing case can work then, provided it can be resolved by a /etc/hosts entry (eg: added via compose config extra_hosts).

Reproduction Cleanup

$ docker compose down

# Target the images created for pruning via a label filter,
# since the base images (now untagged) are from years ago:
$ docker image prune --all --filter 'label=prune-marker=go-dns-bug'

Additional Info

Related to the topic, but not relevant.

In Nov 2022, Go 1.20 (released Feb 2023) changes DNS for macOS to always defer to the system DNS resolver, regardless of CGO_ENABLED=0. This addresses similar DNS issues for that platform.

[github-actions]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas on how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️