Add myhostname to nsswitch.conf to ensure resolvable hostname

[fullyint]

Fixes #148 and discourse.roots.io/t/deploy-fails-at-ssmtp/6281.

The problem

New servers occasionally have an unresolvable hostname, causing the ssmtp role to fail with the message hostname: Name or service not known. Affected servers will produce this same message in response to a command checking the FQDN.

$ hostname --fqdn
hostname: Name or service not known

An explanation

The Debian hostname resolver consults the hosts parameter of /etc/nsswitch.conf for where to look for hostname information (ref). The parameter value is typically files dns. The files checked are /etc/hostname and /etc/hosts.

/etc/hosts

The hostname is resolvable if /etc/hosts has a line with something fqdn-like, e.g.:

# /etc/hosts
127.0.0.1 {{ fqdn }} {{ shortname }}

Some new servers don't have such a line in/etc/hosts (e.g., DreamCompute servers in the discourse thread mentioned above).

/etc/hostname

New servers typically do have a name in the other file: /etc/hostname. If this name is fqdn-like (name.xyx), the resolver may use this name for hostname --fqdn but not if the name is merely shortname. In this latter case of shortname, the files consulted do not resolve the hostname fqdn and perhaps neither does the dns consulted, resulting in hostname: Name or service not known.

Digital Ocean and DreamCompute put a name in /etc/hostname based on the user-defined server name. For example, if the user assigned the server the the name hostname.domain.com, then /etc/hostname would contain just hostname. This is not fqdn-like, so DreamCompute has the unresolvable hostname problem.

myhostname

Even if /etc/hostname has only shortname, Digital Ocean manages to still resolve the hostname on Ubuntu images by adding myhostname to the hosts parameter in /etc/nsswitch.conf.

# /etc/nsswitch.conf
hosts: files dns myhostname

This myhostname relies on the presence of "nss-myhostname [which] is a plugin for the GNU Name Service Switch (NSS) functionality of the GNU C Library (glibc), primarily providing hostname resolution for the locally configured system hostname" (manpage). Continuing,

Various software relies on an always-resolvable local hostname. When using dynamic hostnames, this is traditionally achieved by patching /etc/hosts at the same time as changing the hostname. This is problematic since it requires a writable /etc file system and is fragile because the file might be edited by the administrator at the same time. With nss-myhostname enabled, changing /etc/hosts is unnecessary, and on many systems, the file becomes entirely optional.

A solution

This PR follows Digital Ocean's lead by ensuring that libnss-myhostname is installed (Debian's nss-myhostname) and that the hosts parameter in /etc/nsswitch.conf contains myhostname.

The proposed lineinfile task checks the hosts: ... line in /etc/nsswitch.conf and appends myhostname to the end of the line if missing. The /etc/nsswitch.conf file itself is unlikely to be missing (would cause the task to fail) because it is part of the base-files.

$ sudo apt-get install apt-file
$ apt-file update
$ apt-file search nsswitch.conf
base-files: /usr/share/base-files/nsswitch.conf

Users running into the hostname: Name or service not known for the ssmtp role will have to apply the changes of this PR then probably either start with a fresh server (recommended) or run sudo apt-get purge ssmtp on the affected server and retry the server.yml playbook.

Some suggest that instead of using nss-myhostname one should just properly set up /etc/hosts and /etc/hostname. Trellis could certainly template the /etc/hosts file and set the hostname in /etc/hostname, but I figured we would prefer not to handle /etc/hosts. Our problem is exactly what nss-myhostname is meant to resolve.

AWS EC2 hostname

#148 reported the unresolvable hostname when launching an EC2 instance to an AWS VPC. I think this problem is more likely to occur when launching an instance to a custom VPC instead of to an account's default VPC.

When creating a custom VPC, there is a yes/no option to "Enable DNS hostname." It currently defaults to "yes", but if set to "no", instances launched to the VPC will have the unresolvable hostname problem. This PR successfully prevents the problem.

DNS resolution

As a debugging note for posterity, when I created a VPC with "Enable DNS hostname" set to "no", an instance launched to the VPC exhibited the confounding Ansible error Timeout (12s) waiting for privilege escalation prompt. I was able to resolve the error by navigating to the AWS VPC console, selecting the affected VPC, choosing the "Action" of "Edit DNS Resolution" and setting "DNS Resolution" to "yes".

DNS hostnames

The unresolvable hostname fqdn problem solved by this PR could also be resolved for the VPC by selecting the VPC and choosing the "Action" of "Edit DNS Hostnames" and setting "DNS Hostnames" to "yes". If set to "no", a fix like this PR will be required for the hostname fqdn to be resolvable.

[swalkinshaw]

Awesome 👍

Changelog +