5 Common Issues of /etc/hosts in Your Servers
5 Common Issues of /etc/hosts in Your Servers
Normally, people don’t need to hack /etc/hosts, but occasionally, they may have to. If you're in this situation, here are five common issues that you should know about.
Join the DZone community and get the full member experience.Join For Free
Jumpstart your Angular applications with Indigo.Design, a unified platform for visual design, UX prototyping, code generation, and app development.
You shouldn’t make manual changes to the host files on your servers. The changes would be hard to maintain. But if you have to, here are five common issues that you should know, as well as some tips and free tools.
Check it out! And share it with your friends if you find it useful.
Normally, people don’t need to hack
/etc/hosts, but occasionally, they may have to; for example, to simulate some tests without touching the official DNS, to enable nodes talking by hostnames with the absence of an internal DNS, etc.
Have you found yourself in any of this situations? Here are five common issues I’d like you to know.
Issue 1: Duplicate Bindings
This has to do with multiple entries with the same IP/hostname binding. This would be the most harmless case. Still, it’s better we avoid it just to prevent confusion.
Issue 2: Conflict Bindings
It makes sense that one IP address points to multiple different hostnames. But what if one hostname points to multiple IP addresses? You're probably having some difficulty understanding that, right? I’m with you!
With the below bindings in
/etc/hosts, which IP will the requests hit if we open http://www.dennyzhang.com?
220.127.116.11 www.dennyzhang.com 18.104.22.168 www.dennyzhang.com
The answer is the first match, 22.214.171.124. Order matters in name resolving.
Yes, the conflict binding will work, but it introduces potential misunderstandings and surprises.
We need to detect this issue and fix it. That's probably super easy for you, right? But can you automate the check with minimum effort? Just keep reading, my friend.
Issue 3: Obsolete Bindings
You have hacked host files previously. But as time has gone on, you've just forgotten about the changes.
The impact? With obsolete bindings, something may not be working in the way it’s supposed to be. With lots of frustration, you finally find out the root cause. How stupid it is! Does it feel embarrassing to update the details with your boss and colleagues? You’re not alone.
We need to find out a way to detect obsolete changes. Any thoughts, DevOps ninjas?
Issue 4: Missing Bindings
You may want nodes to talk by hostnames. For humans, hostnames are more meaningful than IP addresses. If applications/servers communicate with hostnames, we may have fewer issues when we have to replace some servers.
But you just don’t have the luxury to host an internal DNS in your cluster. So what do you do? Hack host files in each node.
While you keep adding or removing nodes in your cluster, how you can guarantee that host files in all nodes are up-to-date with all necessary bindings? Surely, you have a standard procedure, guides, or tools. But mistakes happen.
It’s better we find a way to detect the issues of missing bindings.
Issue 5: Design Flaw of /etc/hosts
Evaluating issue #3 (obsolete bindings) and issue #4 (missing bindings), it’s all about customization for the host file. Isn’t it?
The problem is that OS only reads one file to load the bindings:
So our customization has to be in the same file as the default section. Naturally, it’s easy to mix up.
I strongly insist: Instead of one single host file, it’s better to be
/etc/hosts.d/. Think about
/etc/profile.d/*.sh. Wouldn't it be wonderful if we could divide the changes of host file into different files? For example, like this:
root@dennyzhang$ tree /etc/hosts.d/ etc/hosts.d/ |---- change1.conf |---- change2.conf 0 directories, 2 files
Well, back to earth. In the near future, we will still have only one host file.
To examine the quality of the host file, check out
examine_hosts_file.py oin GitHub.
–extra_host_file option, we can specify all the customizations. If anything unexpected is captured in your host file, this script will fail. I usually create a Jenkins job to enforce a daily check of
/etc/hosts, if necessary. Maybe you can give this a try, as well.
Now, we can easily automate the examination process. How about the fixing process? Yeah, we can automate it, as well. Here is one example: update_hosts_file.py.
Published at DZone with permission of Denny Zhang , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.