I'll admit it now, I have done more research on this than I made it
appear in my first port. I tried to appear more na�ve than I was in
order to foster discussion instead of flames. ;-)

On Wed, 18 May 2005 at 12:12 -0600, Charles Curley wrote:
> > 127.0.0.1 localhost.localdomain localhost foo foo.example.com
> 
> Not good. The first two entries are fine. 
> 
> The foo entries should point to your network interface. The reason for
> this is you may need to resolve your network interface some time when
> DNS is unavailable, e.g. it's down, or you are debugging your network
> setup and can't reach the name server.

As long as you recognize that you are not testing the network interface,
but rather the kernel's abiility to route internally, then I will agree
that this can be useful.

> How often do you ping your own interface? Not very, but almost all the
> time it's when you're toubleshooting your network.

... and then you may be testing the wrong thing.

> > 127.0.0.1 localhost localhost.localdomain
> > 10.0.0.1 foo.example.com foo
> 
> Much better.

I'll mention this here. I didn't notice you mention the order as
important, when in fact it does make a difference. Do you have an
opinion on these?

127.0.0.1 localhost localhost.example.com

vs. 

127.0.0.1 localhost.example.com localhost

(I might also point out the use of the same domain, which I think is
more elegant than localdomain, and which you did in your example below)

> > 127.0.0.1 localhost
> > 10.0.0.1 foo.example.com foo
> 
> Leaves out localhost.localdomain, which you may want to use.

Well, not me personally - I think it's ugly. I think software that
depends on localdomain is probably poorly thought-out too, but I
wouldn't be against putting both localhost.example.com and
localhost.localdomain on that line to appease the bgus.

 
> > 127.0.0.1 localhost
> 
> Ignores your network interface. This means you depend on name
> resolution for your network interface; see above.

I think at least the short hostname should be listed for that reason,
yes.

> > So what is best, and why? Specifically, is it best to put the hostname
> > (foo) on the loopback IP address, or on the real IP address? 
> 
> The real one.
> 
> > If the latter, what if your box has several IP addresses?
> 
> Then it's pretty much dependent on your network. If a machine is
> multihomed and a router, I'd point it to my upstream connection. If I
> have several upstream connections, I'd pick the one most likely to
> cause me problems.

Unless of course those problems are problems that you're trying to
avoid. :-) As an example, many daemons will by default, or can be
configured to behave differently depending on which address was used to
connect. In the admittedly depressing case where you want the behavior
of address 1 in daemon A, and address 2 in daemon B, you are pretty much
out of luck if you assign either address 1 or address 2 to your
hostname, for applications that connect locally. 

> # Do not remove the following line, or various programs
> # that require network functionality will fail.
> 127.0.0.1     localhost.localdomain localhost
> 192.168.1.3   charlesc charlesc.localdomain

From what I've read, I get the impression that you might want that
second line to be 

192.168.1.3  charlesc.localdomain charlesc

but it probably only matters if the output of hostname -d and 
hostname -f don't output what you'd expect.

Thanks, it's an enlightening discussion so far, and I feel myself
beginning to come to an opinion.

-- 
 .O.  Hans Fugal            | De gustibus non disputandum est.
 ..O  http://hans.fugal.net | Debian, vim, mutt, ruby, text, gpg
 OOO                        | WindowMaker, gaim, UTF-8, RISC, JS Bach
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95  CB5E FC98 E8CD E0AA D460

Attachment: signature.asc
Description: Digital signature

.===================================.
| This has been a P.L.U.G. mailing. |
|      Don't Fear the Penguin.      |
|  IRC: #utah at irc.freenode.net   |
`==================================='

Reply via email to