Include `/etc/services` for APT to support mirrors with DNS SRV records

[bbx0]

APT allows to configure a DNS SRV record to serve mirrors. This is useful to route traffic to a mirror (or cache) in the local network.

This works if the used service (http) can be mapped with its port (80) otherwise the mechanism is silently skipped in APT (connect.cc#L490, srvrec.cc#L53). The Docker image ships without /etc/services, which prevents all service/port lookups. The DNS SRV records are therefore not queried (and any DNS SRV based load-balancing does not work).

The feature is used by the official mirror http://deb.debian.org:

 As of July 2022 the SRV record is
_http._tcp.deb.debian.org.    IN      SRV     10 1 80 prod.debian.map.fastly.net.

Please could you consider shipping the netbase package or the file /etc/services in the image? It's a default feature of APT and can help to avoid traffic.

A workaround is to set up /etc/services with http 80/tcp in the Dockerfile before calling apt but this might give trouble with any package pulling in netbase as dependency.

//edit to add test case (with the upstream mirror):

$ echo "http 80/tcp" >> /etc/services
$ apt -oDebug::Acquire::SrvRecs=true update
SrvRecs: got debian.map.fastlydns.net prio: 10 weight: 1

[tianon]

This is https://bugs.debian.org/1092164 👀

[bbx0]

Oh, you are right. I didn't see that report. I thought this as issue with the image removing too many packages from the base. Do you think this should be addressed by APT internally, or would you consider adding netbase to solve the case?

Having netbase sounds reasonable to me as it provides quite basic TCP/IP config files and is very small. (Other distributions like Fedora, Arch Linux, openSUSE or even Googles Distroless variant also come with /etc/services available in their Docker image.)

[tianon]

I think that there are two (maybe two and a half?) reasonable solutions to this problem, and unfortunately adding netbase explicitly at the Docker Image level is neither of them. 😅

If you're curious for more rationale on that part, docker-library/official-images#18514 (comment) is probably the most recent place it was written down (and more clearly than I've ever done, because @paultag is a gem). ❤️

The primary solutions I see are, in no particular order:

1. get netbase explicitly added to minbase in Debian

   • (I believe that's spelled Priority: required, but I might've mixed that up)

2. get netbase implicity added to minbase

   • (most likely by having https://bugs.debian.org/1092164 closed with apt growing a Depends: netbase dep)

3. get apt updated to have sane fallback if netbase isn't available (or to remove the netbase-requiring functionality entirely)

   • reading the APT code that uses /etc/services, I'm not entirely sure why it's reading /etc/services because it appears to be parsing the sources URL, extracting the port, and then using /etc/services to reverse the port to a service name, then using that for the SRV record lookup, which feels weird? maybe it's intentional, but IMO if I'm running an APT repo on port 6667 (http://foo.bar.example.com:6667) it would be kind of surprising for APT to do a lookup for _ircd._tcp.foo.bar.example.com instead of _http._tcp.foo.bar.example.com but I guess this is not a totally unexpected consequence of the way SRV records work 🙈
   • https://github.com/Debian/apt/blob/3e65bcea24f5e77cb27d7eb81f7d92c1b0c3915c/apt-pkg/contrib/srvrec.cc#L36-L59

[bbx0]

Thank you for the details and the background! This helps a lot to understand the situation.

I agree with all your assessment. Unfortunately, that also means there is no "quick" solution to this. :)

1. This is what the other distributions do. Surprising that Debian handles it different.
2. This is spontaneously my preferred option as it makes the (as of today existing) dependency of APT itself obvious and should probably be done either way.
3. I've to admit, I don't understand this look-up dance either. 🙈 Maybe there is some reason for it but to me it sounds odd. The requested service (http) is already explicit part of the URI in the sources list, which makes the port look-up superfluous. The actual port to be used is returned as part of the DNS SRV response and can be different… 😅