[Bug 1906970] Re: dpkg hook hostname error

[Paride Legovini]

Sergio (~sergiodj) did some digging on `search .` and found out that it
should be supported after all. I'm copy/pasting here his email to
ubuntu-server at lists.u.c for future reference:

=== Message-ID: <87k0msqlzy.fsf at ubuntu.com> ===

I think the reporter from #1906970 is right: it seems that "search ." is
indeed supported.

Interestingly, I could not find any documentation to truly back this up;
even though the manpage for resolv.conf(5) is well written (kudos to
Michael Kerrisk and the man-pages project, btw!), it is not
authoritative when it comes to defining what "search ." means.  So I had
to resort to the real source of knowledge here: glibc and its resolver.

Long story short, the resolver code lives under the "resolv/" directory
on glibc.  If you look at the res_search function (which performs DNS
queries taking "search" into account), you will find this excerpt here:

https://sourceware.org/git/?p=glibc.git;a=blob;f=resolv/res_query.c;h=ebbe5a6a4ed86abe3fccd4a134bfcf6f613c9bbb;hb=HEAD#l385

When RES_DNSRCH is set, it means that the resolver will search for
hostnames in the current domain and in parent domains.  Particularly,
this excerpt is interesting:

	/* __res_context_querydoman concatenates name
	   with dname with a "." in between.  If we
	   pass it in dname the "." we got from the
	   configured default search path, we'll end
	   up with "name..", which won't resolve.
	   OTOH, passing it "" will result in "name.",
	   which has the intended effect for both
	   possible representations of the root
	   domain.  */
	if (dname[0] == '.')
		dname++;
	if (dname[0] == '\0')
		root_on_list++;

So you see that the code takes into account the case when "search ." is
used, and interprets it as representing the root domain indeed.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to sbuild in Ubuntu.
https://bugs.launchpad.net/bugs/1906970

Title:
  dpkg hook hostname error

Status in postfix package in Ubuntu:
  Confirmed
Status in sbuild package in Ubuntu:
  Confirmed

Bug description:
  I tried to install postfix (3.4.13-0ubuntu1) within a Dockerfile
  (Ubuntu 20.04.01 LTS) and it failed because there is an error in the
  dpkg info file.

  I'm attaching the log of the 2nd time "apt install -y postfix" is
  executed, as it is way shorter and still shows the error message.

  ```
  root at cc1a572af0dc:/etc# apt install -y postfix
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  postfix is already the newest version (3.4.13-0ubuntu1).
  0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
  1 not fully installed or removed.
  After this operation, 0 B of additional disk space will be used.
  Setting up postfix (3.4.13-0ubuntu1) ...

  Postfix (main.cf) configuration was untouched.  If you need to make changes,
  edit /etc/postfix/main.cf (and others) as needed.  To view Postfix
  configuration values, see postconf(1).

  After modifying main.cf, be sure to run 'systemctl reload postfix'.

  Running newaliases
  newaliases: warning: valid_hostname: misplaced delimiter: cc1a572af0dc..
  newaliases: fatal: file /etc/postfix/main.cf: parameter myhostname: bad parameter value: cc1a572af0dc..
  dpkg: error processing package postfix (--configure):
   installed postfix package post-installation script subprocess returned error exit status 75
  Processing triggers for libc-bin (2.31-0ubuntu9.1) ...
  Errors were encountered while processing:
   postfix
  E: Sub-process /usr/bin/dpkg returned an error code (1)
  ```

  I then looked into the /etc/postfix/main.cf file and tried to manually
  change the hostname, but it automatically gets overwritten by dpkg
  when apt install is ran.

  After that I was able to track the issue into the script
  "/var/lib/dpkg/info/postfix.postinst" more exactly the sed command in
  line 52. It reads the content of the search parameter from
  /etc/resolv.conf, and concatenates it with a "." as delimiter with the
  hostname, but it doesn't honor the special case of "search ." and
  therefore constructs an incorrect myhostname parameter for postfix of
  "cc1a572af0dc..".

  I'd propose to remove this resolve.conf lookup entirely so that the package installation doesn't fail within docker containers...
  It is a bad practice in my opinion to overwrite existing config files upon package installation.
  Also I'd suggest not executing postfix after the configuration is written, so that in case of unforeseen circumstances (like this one) a user can just simply run a sed against the config file after installing the package.

  And the Dockerfile for reference:
  ```
  FROM ubuntu:latest

  ENV DEBIAN_FRONTEND=noninteractive
  #ENV DEBIAN_PRIORITY=low

  RUN apt update \
      && echo "postfix postfix/main_mailer_type select Internet Site" | debconf-set-selections \
      && echo "postfix postfix/mailname string mysubdomain.mydomain.com" | debconf-set-selections \
      && apt install -y postfix
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1906970/+subscriptions