Unattended upgrades calls my machine "localhost" instead of its hostname

Question

On some of my machines, unattended upgrades sends an email to tell me a reboot is required, and says:

[reboot required] unattended-upgrades result for localhost: SUCCESS

While on others, it specifies the correct hostname instead of localhost. Where can I change this to make it specify the hostname correctly?

Answer 1

As far as I can tell, it uses the 127.0.0.1 or ::1 in /etc/hosts.

Lines like:

127.0.0.1  server.yourdomain.xx server localhost
::1 server.yourdomain.xx server localhost ip6-localhost ip6-loopback

makes it ouput messages with server.yourdomain.xx
Tested on Debian testing

Answer 2

On our systems it would have seemed to be due to differences in how the /usr/bin/unattended-upgrade python3 script tries to figure out its host's name.

On some machines (Ubuntu 18.04) it does:

import os

#...

def host():
    # type: () -> str
    return os.uname()[1]

... whereas on newer machines (Ubuntu 22.04) it does:

import socket

#...

def host():
    # type: () -> str
    return socket.getfqdn()

It is the latter version of host() that simply returns "localhost" because that's what socket.getfqdn() without arguments returns.

This change to the unattended-upgrade script was introduced between versions 1.3 and 1.4.

That pull-request already includes some discussion about it introducing the observed localhost regression, and it also hints at a workaround that does indeed work:

Instead of listing the desired hostname in /etc/hosts as:

127.0.0.1 localhost
127.0.0.1       my-hostname

... list it as:

127.0.0.1 localhost
127.0.1.1       my-hostname

... all I need now, is an understanding of why using 127.0.1.1 instead of 127.0.0.1 makes this work ...

https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_hostname_resolution does serve to provide some extra credibility towards the correctness of the solution but for me it still fails to supply sufficient background as to the mechanisms involved and rationale.

The manpage to hostname(1) has a section on the FQDN that helps getting a grip on the intricacies of name resolving:

The recommended method of setting the FQDN is to make the hostname be an alias for the fully qualified name using /etc/hosts, DNS, or NIS. For example, if the hostname was "ursula", one might have a line in /etc/hosts which reads

127.0.1.1 ursula.example.com ursula

Technically: The FQDN is the name getaddrinfo(3) returns for the host name returned by gethostname(2). The DNS domain name is the part after the first dot.

Therefore it depends on the configuration of the resolver (usually in /etc/host.conf) how you can change it. Usually the hosts file is parsed before DNS or NIS, so it is most common to change the FQDN in /etc/hosts.

Answer 3

Change the content of the relevant file: etc/mailname:

Debian policy says:

If your package needs to know what hostname to use on (for example) outgoing news and mail messages which are generated locally, you should use the file /etc/mailname. It will contain the portion after the username and @ (at) sign for email addresses of users on the machine (followed by a newline).

Usually that's the FQDN name (the long name) of the server as resolved by other systems.

To make things simple, just reconfigure the relevant package. For the Debian 10's default exim4 package it's actually exim4-config:

dpkg-reconfigure -pcritical exim4-config

-pcritical ensures probably no question will be asked. You can omit it or lower it up to -plow to see some or all of these questions.

As OP is not using exim4 but msmtp, for this case, the configuration can be triggered with:

dpkg-reconfigure msmtp

If this was never done before it's important the first question's (Create a system wide configuration file?) answer is Yes, in order to get the followup questions.

It also appears that contrary to exim4, the configuration script (once installed, in /var/lib/dpkg/info/msmtp.config) doesn't check for /etc/mailname, thus not following the recommanded Debian policy.