CentOS - Mar 2011 - /etc/hosts - hostname alias for 127.0.0.1

Can anyone point out reasons why it might be a bad idea to put this
sort of line in your /etc/hosts file, eg, pointing the FQDN at the
loopback address?

127.0.0.1    hostname.domain.com hostname   localhost localhost.localdomain

Am 03/07/2011 05:34 PM, schrieb Sean Carolan:
> Can anyone point out reasons why it might be a bad idea to put this
> sort of line in your /etc/hosts file, eg, pointing the FQDN at the
> loopback address?
>
> 127.0.0.1    hostname.domain.com hostname   localhost localhost.localdomain
First, if your host is actually communicating with any kind of ip-based 
network, it is quite certain, that 127.0.0.1 simply isn't his IP 
address. And, at least for me, that's a fairly good reason.

Second, sendmail had the habit of breaking if your hostname was mapped 
to 127.0.0.1, but I stopped using sendmail a decade ago, so I can't 
verify this. :)

On Mon, Mar 07, 2011 at 10:34:24AM -0600, Sean Carolan
wrote:
> Can anyone point out reasons why it might be a bad idea to put this
> sort of line in your /etc/hosts file, eg, pointing the FQDN at the
> loopback address?
> 
> 127.0.0.1    hostname.domain.com hostname   localhost localhost.localdomain
Would the application work with a hosts entry like this?

127.0.0.1    hostname.dummy   localhost localhost.localdomain

(Make sure you pick .dummy so as not to interfere with any other DNS.)

In theory you could leave off .dummy, but then you risk hostname being
completed with the search domain in resolv.conf, which creates the
problems already mentioned with putting hostname.domain.com in
/etc/hosts.  (I have not tested this at all!)

--keith

-- 
kkeller at wombat.san-francisco.ca.us

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.centos.org/pipermail/centos/attachments/20110307/5c254bcf/attachment-0002.sig>

> (Make sure you pick .dummy so as not to interfere with any other DNS.)
>
> In theory you could leave off .dummy, but then you risk hostname being
> completed with the search domain in resolv.conf, which creates the
> problems already mentioned with putting hostname.domain.com in
> /etc/hosts. ?(I have not tested this at all!)
I will probably just leave this decision to the application
architects, with the recommendation that we should simply use DNS as
intended...

Keith Keller wrote:
> On Mon, Mar 07, 2011 at 10:34:24AM -0600, Sean Carolan wrote:
>> Can anyone point out reasons why it might be a bad idea to put this
>> sort of line in your /etc/hosts file, eg, pointing the FQDN at the
>> loopback address?
>>
>> 127.0.0.1    hostname.domain.com hostname   localhost
>> localhost.localdomain
>
> Would the application work with a hosts entry like this?
>
> 127.0.0.1    hostname.dummy   localhost localhost.localdomain
>
> (Make sure you pick .dummy so as not to interfere with any other DNS.)
>
> In theory you could leave off .dummy, but then you risk hostname being
> completed with the search domain in resolv.conf, which creates the
> problems already mentioned with putting hostname.domain.com in
> /etc/hosts.  (I have not tested this at all!)
And giving it 127.0.0.1 would tell it others to ignore it, I think. Where
did your user come up with this idea - clearly, they have *no* clue what
they're doing, and need at least a brown bag lunch about TCP/IP, and they
should not be allowed to dictate this. Their "idea" is a bug, and
needs to
be fixed.

          mark

On Mon, Mar 7, 2011 at 11:34 AM, Sean Carolan <scarolan at gmail.com>
wrote:
> Can anyone point out reasons why it might be a bad idea to put this
> sort of line in your /etc/hosts file, eg, pointing the FQDN at the
> loopback address?
>
> 127.0.0.1 ? ?hostname.domain.com hostname ? localhost localhost.localdomain
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
It's common to do so, so that the network lookups for "hostname"
still
operate, even if the rest of the network is dead. This is particularly
important for self-monitoring, sendmail (which relies on the FQHN
beinf first, mind you!!!) and X Windows.

If you have an intermittent network connection, such as one for a DSL
connected device or a roving wireless connection, keeping the hostname
in the 127.0.0.1 line helps assure that the X sessions work, even when
other connections are interrupted. It also helps improve performance
for local network access and keeps your external ports uncluttered by
local CIFS and NFS access.

That said, it can be problematic when you "ping $HOSTNAME" and get a
valid 127.0.0.1 response, and haven't actually tested your external
port. It also requires thought for configuring SSH and SNMP and NFS to
allow localhost access.