uts: Set default hostname to "localhost", rather than "(none)"

The "hostname" tool falls back to setting the hostname to "localhost" if /etc/hostname does not exist. Distribution init scripts have the same fallback. However, if userspace never calls sethostname, such as when booting with init=/bin/sh, or otherwise booting a minimal system without the usual init scripts, the default hostname of "(none)" remains, unhelpfully appearing in various places such as prompts ("root@(none):~#") and logs. Furthrmore, "(none)" doesn't typically resolve to anything useful, while "localhost" does.

Change the default hostname to "localhost". This removes the need for the standard fallback, provides a useful default for systems that never call sethostname, and makes minimal systems that much more useful with less configuration.

---

Looked at "(none)" one too many times, and figured I ought to do something about it.

Resending, and adding CCs for networking and UTS.

 include/linux/uts.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

index 73eb1ed..610bec2 100644
@@ -9,7 +9,7 @@
 #endif
 
 #ifndef UTS_NODENAME
-#define UTS_NODENAME "(none)"	/* set by sethostname() */
+#define UTS_NODENAME "localhost"	/* set by sethostname() */
 #endif
 
 #ifndef UTS_DOMAINNAME

1.7.4.1

Seems good to me. I'd have no idea if there were valid reasons to object to such a thing so my ack means nothing, but

thanks,
-serge

Yes. Also, quite frankly, I do _not_ think that "localhost" is in any way a more correct hostname.

I'd rather have an obviously invalid hostname for a machine that hasn't been set up correctly than one that might work by random chance.

Linus

I checked fairly thoroughly for evidence of userspace relying on "(none)", and found no instances of that. Userspace typically just says "I haven't set it yet, so nobody has set it yet", and unconditionally sets the hostname. dhclient doesn't rely on "(none)", distro networking scripts don't rely on "(none)", the hostname tool doesn't rely on "(none)", and nothing else I've found looks for "(none)".

That said, I'll certainly acknowledge that some random userspace bits somewhere could have relied on this behavior. Would a transitional period help at all here? Alternatively, see below.

Choosing "localhost" for systems that don't configure a hostname at least makes it fairly likely that you can resolve the system hostname. So, "localhost" will have a tendency to Just Work, but seeing a hostname of "localhost" will still obviously remind a user that they ought to set the hostname to something more sensible on a network-connected box. On a non-networked box, localhost makes perfect sense, and the box need not configure anything else. Similarly, this default would also make sense for various types of virtual systems.

Also, "(none)" doesn't necessarily represent an "invalid" hostname. In general, tools seem to assume the validity of the system hostname, and use it wherever the hostname appears. (For that matter, as some recent security vulnerabilities have demonstrated, "valid hostname" doesn't necessarily mean "alphanumeric"; both DNS and DHCP will happily hand out a hostname with crazy characters in it, including '(' and ')'.)

I wrote this patch with the same motivation as the option to mount devtmpfs on /dev automatically: it makes systems behave more or less sanely in the absence of explicit setup, even though more explicit setup may produce a more optimal configuration (just as devtmpfs makes all devices root:root in the absence of a better configuration). It would often make sense for embedded or virtual systems.

In general, I'd rather see the kernel provide a configuration that will work in at least some cases and do no worse in others (requiring explicit configuration), rather than a configuration which will not work in any cases and *always* requires explicit userspace configuration.

If the above does not provide a sufficiently good argument for changing the default (perhaps with a transition period added), would you consider accepting a patch which added a CONFIG_DEFAULT_UTS_HOSTNAME, defaulting to "(none)"? Then systems could choose to use that configuration option if they know their userspace will work with it.

- Josh Triplett

Seems sane enough to me. Only possible objection I can think of is "if you're running with 'init=/bin/sh' or similar config too crippled to run /bin/hostname, maybe your network config *should* be intentionally toasted so you can't get further surprises".

I personally don't agree - just saying somebody might hold that position.