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. :)
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.
Indeed. It does seem like a bad idea to have a single host using loopback, while the rest of the network refers to it by it's real IP address.
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. :)
The reason this came up is because one of our end-users requested such a setup in the /etc/hosts file, and I didn't think it was a good idea. Seems it would be better to fix the application(s) that require the data to use the real network IP address.
Am 03/07/2011 05:49 PM, schrieb Sean Carolan:
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.
Indeed. It does seem like a bad idea to have a single host using loopback, while the rest of the network refers to it by it's real IP address.
Acknowledged. At least it will save you a lot of time next year, when you have forgotten about that and are wondering why every machine on the network can reach a service and only the host itself can't (or vice versa...).
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. :)
The reason this came up is because one of our end-users requested such a setup in the /etc/hosts file, and I didn't think it was a good idea. Seems it would be better to fix the application(s) that require the data to use the real network IP address.
Most of the time it's a good idea to fix applications before ravishing your network setup to make it work. :)
Sean Carolan wrote on Mon, 7 Mar 2011 10:49:18 -0600:
Indeed. It does seem like a bad idea to have a single host using loopback, while the rest of the network refers to it by it's real IP address.
It doesn't matter for the other hosts, the sender ip address will always be the outgoing interface address and not the loopback. It only matters if you connect on the local host and have to troubleshoot a connectivity issue and confuse something ... Usually, it's rather an advantage because in cases where you would just get "localhost" you now get some meaningful name. It really depends. However, I have it set this way on all my hosts for ten years or more and haven't found a single case where this was a problem.
Kai
On Mon, Mar 07, 2011 at 09:31:17PM +0100, Kai Schaetzl wrote:
Usually, it's rather an advantage because in cases where you would just get "localhost" you now get some meaningful name.
You can use the bare hostname as an alias in /etc/hosts, which is probably marginally better than using the FQDN.
In CentOS, I believe that rc.sysinit will try to set the hostname from its FQDN (or whatever you have set in /etc/sysconfig/network) without mucking about with /etc/hosts.
--keith
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
(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...
Sean Carolan wrote:
(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...
I wonder if what they need is another IP being asserted on your NIC....
mark
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 Monday 07 March 2011 15:22, the following was written:
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
You can do this if you want. The host file is only used by the machine it is on. As to bad Idea it would depend on what you are trying to do and if the process you are trying to reach locally is listening on that ip address.
I have only the short name configured on 127.0.0.1
Would the application work with a hosts entry like this?
If the process what configured to listen on that interface, yes.
127.0.0.1 hostname.dummy localhost localhost.localdomain
(Make sure you pick .dummy so as not to interfere with any other DNS.)
Why do you need the '.dummy'? short name should work fine.
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!)
Resolv.conf is not used for the hosts file, it is used for DNS. I have my short name configured to the lo interface and the FQDN to the real ip address. If I ping the short name I get this:
etc $ ping -c 3 bms PING bms (127.0.0.1) 56(84) bytes of data. 64 bytes from bms (127.0.0.1): icmp_seq=1 ttl=64 time=0.038 ms 64 bytes from bms (127.0.0.1): icmp_seq=2 ttl=64 time=0.038 ms 64 bytes from bms (127.0.0.1): icmp_seq=3 ttl=64 time=0.037 ms
If I ping the FQDN I get this:
etc $ ping -c 3 bms.domain.com PING bms.domain.com (x.x.x.x) 56(84) bytes of data. 64 bytes from bms.domain.com (x.x.x.x): icmp_seq=1 ttl=64 time=0.037 ms 64 bytes from bms.domain.com (x.x.x.x): icmp_seq=2 ttl=64 time=0.038 ms 64 bytes from bms.domain.com (x.x.x.x): icmp_seq=3 ttl=64 time=0.093 ms
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.
How do you figure this? The hosts file is ONLY used locally. If someone is looking you up they are using DNS if they don't have you configured in "their" hosts file.
Their "idea" might be flaws but it is not bugs.
On 03/07/2011 02:22 PM, m.roth@5-cent.us wrote:
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.
It is the default way RHEL and CentOS setup up network connections ... and except for a few badly behaving applications, things work fine like that.
(the hostname as 127.0.0.1)
You guys do know that the names in your host file only apply to YOU on that machine right? It does not matter if you connect to 127.0.0.1 or something else UNLESS you specifically listen on a specific IP address on that machine AND you need to connect to that address from the machine itself.
This is also the way to go if you are on DHCP and if the address of the machine might change.
Remember, no machines except that one will refer to it in that way.
Johnny Hughes wrote:
On 03/07/2011 02:22 PM, m.roth@5-cent.us wrote:
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
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.
<snip>
You guys do know that the names in your host file only apply to YOU on that machine right? It does not matter if you connect to 127.0.0.1 or something else UNLESS you specifically listen on a specific IP address on that machine AND you need to connect to that address from the machine itself.
<snip> Let me expand on the above: if anyone on *any* other machine is trying to connect to that, it won't work. If they try to point a browser to it, unless they've done ssh -X to the server, they'll talk to their *own* machine, and it won't be found.
mark
On Tuesday 08 March 2011 12:39, the following was written:
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.
<snip>
You guys do know that the names in your host file only apply to YOU on that machine right? It does not matter if you connect to 127.0.0.1 or something else UNLESS you specifically listen on a specific IP address on that machine AND you need to connect to that address from the machine itself.
<snip> Let me expand on the above: if anyone on *any* other machine is trying to connect to that, it won't work. If they try to point a browser to it, unless they've done ssh -X to the server, they'll talk to their *own* machine, and it won't be found.
Let me try another way to explain this to you.
If you try to get to the site xyz.com and you open your browser and type that in you are using what to get the ip address of that service? Correct, DNS, as you don't have xyz.com listed in your LOCAL host file.
In DNS the site xyz.com resolves to 1.1.1.1
Now you ssh (ssh -x) into the xyz server. The server has the following in its Hosts file;
127.0.0.1 xyz.com
You open a browser the xyz servers X session what is going to resolve for xyz.com? Correct, 127.0.0.1 and if the system is configured correctly to listen on that address you will connect.
Now lets say that the host file has the following;
127.0.0.1 xyz
You are still logged into the server with your x session going. Now in your browser you type "xyz". What address do you get and why? If you type "xyz.com" into the same browser what address do you get and why?
On Mon, Mar 7, 2011 at 11:34 AM, Sean Carolan scarolan@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@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.
On 03/07/2011 08:21 PM, Nico Kadel-Garcia wrote:
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.
When you ping the IP address of your external link, that packet gets short-circuited in the kernel and never goes to the physical port, so you aren't testing your external port for that case either.
On Tue, Mar 8, 2011 at 12:10 AM, Robert Nichols rnicholsNOSPAM@comcast.net wrote:
On 03/07/2011 08:21 PM, Nico Kadel-Garcia wrote:
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.
When you ping the IP address of your external link, that packet gets short-circuited in the kernel and never goes to the physical port, so you aren't testing your external port for that case either.
-- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it.
Not..... completely. Try bringing down the external port with "ifdown" and see what I mean. That short circuiting can't occur for something that isn't enabled, because the kernel won't magically deduce it from the configuration files. This can be helpful for weird debugging situations, such as I encountered last week when cloning a virtual machine under LabManager, and finding that my new network port on eth0 had been replaced with an unconfigured one on eth1, much to my surprise.
You're quite correct that it won't test your external physical portn, though..
-
Alexander Arlt -
Johnny Hughes -
Kai Schaetzl -
Keith Keller -
m.roth＠5-cent.us -
Nico Kadel-Garcia -
Robert Nichols -
Robert Spangler -
Sean Carolan