Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

5 Common Issues of /etc/hosts in Your Servers

DZone's Guide to

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.

· Web Dev Zone
Free Resource

Start coding today to experience the powerful engine that drives data application’s development, brought to you in partnership with Qlik.

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?

45.33.87.74 www.dennyzhang.com
104.237.153.157 www.dennyzhang.com

The answer is the first match, 45.33.87.74. 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: /etc/hosts.

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.

With the –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.

Image title

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.

Create data driven applications in Qlik’s free and easy to use coding environment, brought to you in partnership with Qlik.

Topics:
performance ,hosts ,file issues ,web dev

Published at DZone with permission of Denny Zhang, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}