Don’t make manual changes to the hosts file in your servers.
It would be hard to maintain. If you have to, here are 5 common issues I’d like you to know. And also some tips and free tools included in this post.
Check it out! And share it with your friends, if you find it useful.
Normally people don’t need to hack /etc/hosts. Occasionally they may have to. For example, simulate some tests without touching the official DNS; enable nodes talking by hostnames with the absence of an internal DNS, etc.
Find yourself in the same situations, my friend? Here are 5 common issues I’d like you to know.
Issue1: Duplicate binding
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.
Issue2: Conflict binding
It makes sense that one ip address points to multiple different hostnames.
But what if one hostname points to multiple ip addresses? Having difficulty understanding that, right? I’m with you!
Question. With below bindings in /etc/hosts, which ip the requests will hit if we open https://www.dennyzhang.com?
184.108.40.206 www.dennyzhang.com 220.127.116.11 www.dennyzhang.com
The answer is the first match, 18.104.22.168. 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. Super easy for you, right? But can you automate the check with minimum effort? Just keep reading, my friend.
Issue3: Obsoleted binding
You have hacked hosts file previously. But as time goes, you just forget about the changes.
The impact? With the obsoleted 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! Feel embarrassing to update the details with your boss and colleagues? You’re not alone.
We need to find out a why to detect the obsoleted changes. Any thoughts, DevOps Ninjas?
Issue4: Missing binding
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 would you do? Hack hosts file in each node.
While you keep adding or removing nodes in your cluster, how you can guarantee hosts files in all nodes are up-to-date with all necessary bindings? Surely you will have standard procedure, guides or tools. But mistakes happen.
It’s better we find a way to detect the issues of missing bindings.
Issue5: Design Flaw of /etc/hosts
Evaluating issue#3(obsoleted bindings) and issue#4(missing bindings), it’s all about customization for the hosts file. Isn’t it?
The problem is that OS only read one file to load the bindings. /etc/hosts.
So our customization has to be in the same file as default section. Naturally it’s easy to mix up.
I strongly insist: Instead of one single hosts file, it’s better to be / etc/hosts.d/.
Think about /etc/profile.d/*.sh.
Would it be wonderful, if we can divide the changes of hosts file into different files? Like below.
root@dennyzhang$ tree /etc/hosts.d/ etc/hosts.d/ |---- change1.conf |---- change2.conf 0 directories, 2 files
Well, back to the earth. In the near future, we will still have one hostsfile only.
With –extra_host_file option, we can specify all the customization. If anything unexpected is captured in your hosts file, this script will fail.
I usually create a Jenkins job to enforce daily check of /etc/hosts, if necessary. Maybe you can give it a try as well.
Now we can easily automate the examing process. How about the fix process? Yeah, we can automate it as well.
Here is one example: update_hosts_file.py.