INN and docker default hostnames

Richard Kettlewell rjk at terraraq.uk
Sat Apr 4 16:24:54 UTC 2020


In a Docker container, the hostname starts off as a random string like this:

   root at e5f1e5a358ac:/# uname -n
   e5f1e5a358ac

This is a perfectly cromulent hostname for the container:

   root at e5f1e5a358ac:/# ping -c1 e5f1e5a358ac
   PING e5f1e5a358ac (172.18.0.2) 56(84) bytes of data.
   64 bytes from e5f1e5a358ac (172.18.0.2): icmp_seq=1 ttl=64 time=0.014 ms

   --- e5f1e5a358ac ping statistics ---
   1 packets transmitted, 1 received, 0% packet loss, time 0ms
   rtt min/avg/max/mdev = 0.014/0.014/0.014/0.000 ms

However, INN hates it, and refuses to even install:

   root at 3bee77b13506:/# apt install inn2
   Reading package lists... Done
   Building dependency tree
   Reading state information... Done
   Suggested packages:
     libgd-perl
   The following NEW packages will be installed:
     inn2
   0 upgraded, 1 newly installed, 0 to remove and 8 not upgraded.
   Need to get 1200 kB of archives.
   After this operation, 3443 kB of additional disk space will be used.
   Get:1 https://mirror.anjou.terraraq.uk/debian buster/main amd64 inn2 
amd64 2.6.3-1+deb10u2 [1200 kB]
   Fetched 1200 kB in 0s (12.4 MB/s)
   debconf: delaying package configuration, since apt-utils is not installed
   Selecting previously unselected package inn2.
   (Reading database ... 10753 files and directories currently installed.)
   Preparing to unpack .../inn2_2.6.3-1+deb10u2_amd64.deb ...
   Unpacking inn2 (2.6.3-1+deb10u2) ...
   Setting up inn2 (2.6.3-1+deb10u2) ...
   innconfval: hostname does not resolve or domain not set in inn.conf
   dpkg: error processing package inn2 (--configure):
    installed inn2 package post-installation script subprocess returned 
error exit status 1
   Errors were encountered while processing:
    inn2
   E: Sub-process /usr/bin/dpkg returned an error code (1)

In many contexts this can be fixed in inn.conf, but not for the specific 
case of package installation, since a suitable inn.conf doesn't exist yet.

I think this is a bug in INN.  The relevant code is inn_getfqdn(), which 
asks getaddrinfo() to canonicalize the hostname but then for some reason 
not only refuses to believe the answer, but also refuses to run even 
basic tools like innconfval.

My suggestion is that INN should believe getaddrinfo(), i.e. remove the 
strchr() check for '.'.

ttfn/rjk


More information about the inn-workers mailing list