[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/bin/hostname
On Thu, Jul 25, 2013 at 7:10 AM, Robert Elz <kre%munnari.oz.au@localhost> wrote:
> Date: Thu, 25 Jul 2013 08:23:26 +0100
> From: David Laight <david%l8s.co.uk@localhost>
> Message-ID: <20130725072326.GS24004%snowdrop.l8s.co.uk@localhost>
> | There are many (well some) systems that don't have a FQDN, and where there
> | isn't one that can be assigned.
> Then one should be obtained for it ... these days domain names are cheap,
> if you can afford a computer, you can afford to get it its own private
> registered domain to go along with it - or if you have one already for
> some other computer, you can save a few $s and share the domain... There's
> really no excuse for not doing that, it is quick and easy (and if you don't
> care what the domain is, just that you have one, then trivially easy to
> | A modern example might be some kind of portable system system that
> | only ever connects to the outside world using wifi hotspots.
> | An older example would be a single system using dialup networking.
> What does that have to do with anything? Where the system is connected
> (or how) is totally unrelated to its name. Think of the computer name
> being just like your personal name - think of what life would be like for
> you if all you had was just "David" and no surname to go along with it
> (of course, personal names aren't unique, which does cause problems, but
> making them less unique makes the problems worse.) But given that you
> are David Laight you remain David Laight no matter what house (or flat) you
> live in, or who you work for, or ... The name is independent of the
> connection point. You can of course change your name, as a computer can
> change its hostname, but both you and it should always have a name to use
> anytime you need to use a name.
> | IIRC one of the original uses for FQDN was for email routing
> | (firstname.lastname@example.org).But even then we always published addresses
> | user@mail_domain so that the outside world didn't know which machine
> | users read their mail on 'today' (that involved groging the sendmail
> | masquerade options).
> Well, my e-mail address (munnari.oz.au) is a hostname ...
> user%oz.au@localhost would
> result in mail failing for certain (regardless of what the user part is).
> [Aside: munnari.oz.au isn't in Australia though - it was once, but hasn't
> been for many years now.] But yes, you're right, most hosts don't need
> fqdn's in order to receive incoming e-mail.
> | Since a system can have multiple IP addresses, subsets of which are
> | returned by forwards DNS lookups on many FQDN from different domains
> | it can have nothing to do with IP addresses!
> Absolutely agreed - which is one reason all those dumb options added
> to hostname(1) recently that related to address lookups are inappropriate.
> | For smtp EHLO you really want a name that will forwards lookup to the
> | source IP of the connection, that can only be determined after the
> | connection is established.
> I have no idea what you're thinking of there. The name in the EHLO (or HELO)
> command should be the (or perhaps a) name for the host running the MTA.
> That is, the (or one of the) host's globally unique names. That's all that
> is required of it - the receiving system will use it for logging, and
> things like that (and may - these days probably will - verify that it
> maps to the incoming IP address, but if that fails, it just means extra
> text in the log) - it is certainly never intended to be used as an
> e-mail address (and what's more the originating system isn't required to
> have a smtp server running to receive incoming e-mail, now or ever.)
> But as long as it is a name that belongs to the source host, it is irrelevant
> which name is used if the host happens to have more than one.
> | So it isn't anything to do with mail transfer either.
> | (Yes, I know MTA have a habit of trying to find a FQDN at startup)
> Actually, e-mail is one good example - the hostname is needed for the
> Received headers that all MTAs are required to add (and those then get sent
> on to the next system, so they need to be global names, not just local ones).
> Further, message-id generation, whether done by the MTA, or by an MUA
> (pkgsrc/mail/nmh generates message-ids itself if asked to do so, which is
> the way I run it) - for that we must have a globally unique host name, both
> because the standards require it (yeah, if that was the only reason I wouldn't
> really care) and because it is the only way I can think of to actually be able
> to guarantee generation of unique ids (unique to one message amongst all
> messages ever generated, by anyone, ever.)
> Look at the message ID of this message - it isn't
> because it is being generated by nmh from my laptop. Rather it's in kre.to
> which is a domain that I (big surprise) have registered just for purposes
> like this - I think there are some MX records to allow sending e-mail to
> some of the hostnames that exist in it, but probably not all of them, but
> apart from that, there's little practical use in names in that domain.
> But it does mean that all my hosts (or virtual hosts in this case since
> perseus is just NetBSD in a virtualbox) get unique names as they should.
> | So we now get down to things like the name in the security report emails.
> | Purely local significance.
> | What have I missed??
> Ronald Dowdes gave you a list of other places where hostnames are used.
> And X11 is certainly one of them ... in fact, as I have things configured
> (largely for X11's benefit) illustrates why the
> trick that is supposed to expand nicknames fails ... I put my hostname
> in /etc/hosts (as do many people) and give it 127.0.0.1 (and ::1) as the
> address assigned to the host. Do a lookup on the hostname, you get ::1
> (or 127.0.0.1 if it's a v4 lookup). Do a reverse lookup on that (either of
> them) and you get "localhost." back - as the localhost lines come earlier
> in /etc/hosts, and they're also 127.0.0.1 and ::1.
> The reason for 127.0.0.1 (or ::1) being assigned to the hostname is that it
> makes X11 connections use local domain networking, and that makes them
> (minutely) faster than using true IP.
> But it really is more than just finding examples of places where the
> hostname is used.
> What really matters is what assumptions software can make about the
> hostname - and for that we really should be allowing software to assume
> that the name returned (whether via hostname(2), uname(2), or sysctl(2))
> is a globally unique name. nmh certainly assumes that, configure the
> hostname to be just 'pc1' and you'll get message-id's that are
> unique-local-stuff@pc1 which is non-compliant, and useless.
> This is what's important. If we need any changes to hostname(1), the
> one change I'd be making (to what was there a week ago) would be to verify
> that there's at least one '.' in the hostname supplied when setting the
> hostname, and bitch loudly (and refuse to set it) if there isn't. There's
> no way to actually verify uniqueness, but we can at least weed out the trash.
> Lastly, there are of course many hosts that don't need a name at all.
> I'm sure there's one of those in my microwave oven, and probably a few more
> in my car. That's fine - nothing requires hosts to have a name if they're
> not going to use it. What's more, if you don't use anything that needs it,
> NetBSD runs just fine with no hostname assigned at all. Just if you go to
> the trouble of actually assigning a hostname, make it a useful one.
I've run hundreds of systems which use either a short hostname (no
domain) or which have zero relation to their DNS, forward or reverse
(amazon instances). This included mail servers.
I think it is most common for systems to use a single, short name and
then fully qualify it in /etc/hosts (maybe).
Systems with multiple IP addresses, existing on many vlans, NAT-ing
traffic here and there, running many VirtualHosts (web or email), who
are members of a pool of systems configured similarly, etc, completely
ruin any idea that forward and reverse dns mean anything to a server.
In my opinion, the more options, the better. Networks are complicated
and real life system installs even more so.
If you can hack together a system of naming that works -for you-, then do it.
Main Index |
Thread Index |