/etc/hosts question ..

[someone_4]

we have several boxes with differnt /etc/hosts files. What is the best way to get all the hosts files to be the same. And any specific details that I need to watch out for.And ways to work around them.

Thanks

Richard

[linuxfan · Accepted solution]

Hi Richard,

Why don't you use NIS, easy to manage, but if that is not an option then hmm..

get all the host files onto one host and lets say you have them at /tmp/host1, /tmp/host2,
where host1 is the host file from host1 and so on.

One way of generating a host file is

cd /tmp
cat host* |grep -v "\#" | sort |uniq > final_hosts_file

This will create a unique sorted list of all the hosts.

-HTH
I am RU

[Andrew_4]

Not sure if you've considered using NIS (Networking Information Service).. but that will allow you to have 'syncronised' /etc/hosts...

For details, see the NIS manual... :

http://www.docs.hp.com/hpux/onlinedocs/B1031-90048/B1031-90048.html

Hope this helps !

Andrew

[linuxfan]

Hi Richard,

If you are only concerned about synchronizing hosts then ofcourse setting up DNS is another option.

-Regards
I am RU

[Sridhar Bhaskarla]

If you are too particular about security at your site, you may think twice to use NIS. NIS+ is tedious to configure but supports encryption. Going for LDAP with ssl encryption is too much to think.

DNS is the best way.

Sri

[Thierry Poels_1]

hey,
how about using DNS ??
this results in an extremely small hosts file, and all your IP definitions will be centralized.
regards,
Thierry.

[James R. Ferguson]

Hi Richard:

I'd use DNS. Make sure, however, that each server's hosts file has a 'localhost' (127.0.0.1) entry and its own hostname at a minimum.

...JRF...

[melvyn burnard]

If you do not want to use thing slike NIS or DNS, you could look at the rdist facility.
man rdist

[A. Clay Stephenson]

Hi Richard,

Actually you need to think beyond the hosts files, you have the same problem with the /etc/services file, passwd, group, ... .

It's probably time to bite the bullet and implement BOTH DNS and NIS (or NIS+). It's very nice to be able to change an IP address or a passwd in one place and have the changes propogate thoughout your domain.

My personal preference it to resolve hostnames with DNS and everything else with NIS(+).
If you don't have them already, two of your first O'Reilly Books should be 'DNS and BIND' and 'Managing NFS and NIS'.

Get these systems up and running and life becomes much easier.

Regards, Clay

[John Bolene]

DNS is the obvious solution.

Otherwise you can create the master hosts file and rcp it to all machines assuming you can use rcp.

[Victor BERRIDGE]

Hi Richard,
I would suggest like Melvyn the use of rdist (thats what do...) even with DNS( because I dont add printers in the DNS...)
You would have to choose a box where you update /etc/hosts (and other files why not...) and rdist would synchronize all the boxes
so man rdist!

All the best
Victor

[Victor BERRIDGE]

Hi Richard,
I just remembered about rdist:
http://docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B2355-90147/B2355-90147_top.html&con=/hpux/onlinedocs/B2355-90147/00/00/85-con.html&toc=/hpux/onlinedocs/B2355-90147/00/00/85-toc.html&searchterms=rdist&queryid=20010608-065927


All the best

Victor

[someone_4]

wow .. The web site is working today whoo hooo!
First of all Ramesh congrats on your hat there buddy. And what got to me is that you did it in a short time. You have been with the forum for a while but you didnt start to answer soo much till this last month.

Now about my issue here. NIS and DNS sound great as a matter of fact I found out that we already have an internal DNS server set up. Why did I just find out (thats another post).
But the reason behind the etc hosts is that we have some 3rd party software running. That I was told would only work with the etc hosts. Im not too sure why but that is what I was told. So that I why I was wanting to fix the etc hosts files.

Richard

[Joseph C. Denman]

Hi Richard,

I don't think I have ever seen a third party program rely on /etc/hosts. I would think as long as the system is resolving, you would be ok. At least it would be worth a try, instead of attempting maintain like hosts files. If worst comes to worst, you could write a script to do it, but I would at least attempt DNS or NIS before............#$%^&*

My thoughts.

...jcd...

[A. Clay Stephenson]

Hi again Richard,

Before I took someone's word that software can only use /etc/hosts, I would try it. It's very easy to test if your already have a DNS server.
Simply create an /etc/resolv.conf file and modify your /etc/nsswitch.conf file to look at DNS. You actually have to work in C to not use
DNS,NIS, or the hosts file. The library routines hide the task of deciding how to resolve the hostnames from the programmer. My guess is that it will work. I certainly keep all hostnames in DNS including printers.

Clay

[Jim Turner]

Hi Richard,

It looks like your question has been well-answered, but I just wanted to throw in one more option. I worked at a site many years ago that used a network copy of /etc/hosts. Unfortunately, I only heard of it second-hand and never saw it in operation. I think they made /etc/hosts on all "client" machines a sym link to an nfs-mounted copy of /etc/hosts from the "master" machine.

Probably ill-advised for more than one reason, but it's an option just the same.

Cheers,
Jim

[James R. Ferguson]

Hi Richard:

Your third-party vendor is blowing smoke! The biggest problem you may encounter with DNS is a timing one with 'reverse-name-lookups'. You will usually see this with telnet sessions. It stems from the fact that DNS is trying to make sure your are not spoofing.

Reverse lookup is the process by which a server receiving a request for service from a remote machine ascertains whether the identity claimed by the machine is in fact its true one. The process goes like this:

1. The request arrives in a packet with an IP address indicating the point of origin.

2. The server queries name service on the net to find out what hostname is associated with that IP address.

3. The server then queries name service to find out what IP address is associated with that hostname.

4. If this last request fails to find an IP address, or finds one that doesn't match the original, the request for service is rejected.

When you setup your DNS (a.k.a. BIND) environment correctly, this is not a problem. If worse comes to worse, you can put bogus hostnames in your /etc/hosts to accomodate telnet devices more easily.

The resolution of hostnames to IPaddresses is transparent to your vendor. The appropriate mechanism (hosts file or DNS) is done through the library call 'gethostbyname' in all cases.

Regards!

...JRF...

[linuxfan]

Hi Richard,

First of all thanks, I have been following this forum much before my present account was created, just decided one fine day to start sharing/learning more. The more one shares, the more one learns. And i know if i say something wrong, others will be there to point my mistake.

Now coming to your problem, whoever your vendor is, they are just trying to pull a fast one. Even if you have updated the hosts file and modified the /etc/nsswitch.conf file not to look at hosts, there goes your hosts file lookup, because name resolution will not consult the hosts file anymore.

Like I and so many others have suggested the way to go is with DNS/NIS/NIS+

-Regards
I am RU

[Bill Hassell]

Actually, there is a good reason to use nsswitch.conf setup as: hosts then dns (and perhaps then nis). As mentioned, some DNS servers aren't maintained as a critical network tool and things go down hard when DNS goes out. And while nsswitch.conf can specify the next alternative, each request can take 15-20 seconds per request for a timeout.

These long delays are often confused with overloaded networking or permission issues, but they are simple timeouts that create a lot of problems. So a workaround is to create a small /etc/hosts file on each server. Most servers use a small number of unique hosts regularly.

And most important, many network backup tools (including Omniback) will perform a DNS lookup for EVERY file it stores on tape (commercial backup tools can backup multiple hosts at the same time so each file must also have the source's name and IP stored too). This means that the DNS server (and network) can get slammed with dozens of requests per second during a backup. If /etc/hosts provides the IP/name service for selected systems, no network traffic and much faster lookup times.

But the most important is to survive a DNS failure. By coding the most important IP/name entries in /etc/hosts, the server can continue without DNS.

As far as the vendor's requirement, this is quite possible. IP address lookup is not a kernel function at all--it is user-space code and if anyone remembers the old days of HP-UX when there was no nsswitch.conf support, the number of pieces of code that had to be patched to support this file was lengthy. Xwindows did it one, telnet another, DCE still another way, NFS, remsh, and the list goes on.

So for reliability, I would recommend /etc/hosts be populated with important IP/names and setup nsswitch.conf to use hosts, then DNS and if available, nis.

[someone_4]

What a day what a day.
Tommrow I have a meeting with my IT director about this and other issues that I have uncoverd. Even though my title at my company is still "customer support" I have taken all the dutited of the system admin that was let go. And now I find my self cleaning up a mess that I didnt make. Go figure but anyways that is another post. I will find out about the etc/hosts and dns. I will find out what the vendor says and come armed with the details I have gathered from this post. I will update this post tommrow and let everyone know what happened.

richard

[Jim Hendrick]

Hi,
Hope your meeting went well.

One other suggestion that I have seen help with
the DNS timing issue.

Make the host doing all the lookups (Omniback, etc.) a caching-only DNS server and have it point to itself.

Then you can reverse the order in nsswitch.conf
to be dns *then* files so that you get the most current info by default and only fall back on files if DNS goes away (which it shouldn't since you are running the caching server locally)

Hope this helps.

By the way, if other more-experienced HP folks have reasons why this is not a good idea, I would like to hear them!

Thanks,

Jim