Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755534Ab1DKSxW (ORCPT ); Mon, 11 Apr 2011 14:53:22 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:50291 "EHLO relay3-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751370Ab1DKSxV (ORCPT ); Mon, 11 Apr 2011 14:53:21 -0400 X-Originating-IP: 217.70.178.45 X-Originating-IP: 50.43.15.19 Date: Mon, 11 Apr 2011 11:53:10 -0700 From: Josh Triplett To: Linus Torvalds Cc: Stephen Hemminger , David Miller , netdev@vger.kernel.org, "Serge E. Hallyn" , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [PATCH RESEND] uts: Set default hostname to "localhost", rather than "(none)" Message-ID: <20110411185309.GA13391@feather> References: <20110411050155.GA2507@feather> <20110411080254.403d3166@nehalam> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3362 Lines: 64 On Mon, Apr 11, 2011 at 08:12:40AM -0700, Linus Torvalds wrote: > On Mon, Apr 11, 2011 at 8:02 AM, Stephen Hemminger > wrote: > > It makes sense but this behavior has existed so long in Linux > > that some distro might actually be depending on it. 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. > 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. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/