jumper@spf.trw.com (Greg Jumper) (02/07/91)
Summary:
What is the "best" choice for individual "hostnames" and for the format
of the "/etc/hosts" database for a network of Suns using the Internet
and USENET?
(I.e., how do BIND and NIS interact?)
Our network:
A mixture of Sun 3 and Sun 4 systems running SunOS 4.0.3, 4.1, and 4.1.1.
All systems are connected to a class C Ethernet network; one machine is
also connected to the corporate class B backbone, which connects to the
Internet. The gateway machine (between class B and class C) runs the DNS
(BIND) software and serves as the "mailhost"; all machines use NIS (YP),
with the master server one of the machines only on the class C network.
All hosts use "simple" hostnames, which appear as their "true" names in
the "hosts" NIS map -- fully-qualified names do not appear. (See the
"figure" below.)
Questions:
1) "UNIX System Administration" (Nemeth, Snyder, and Seebass) says that,
if you run DNS, the "true" hostname must be the fully qualified name.
However, their example "hosts" files have short hostnames and
fully-qualified aliases; furthermore, with the exception of
"sendmail.mx" on our mailhost, everything seems to work fine the
way we have things set up. Should one really use fully-qualified
hostnames? (Their length is obviously a pain.)
2) I thought the problem with "sendmail.mx" on our system was due to a
problem (previously reported on the net) with name truncation in
Sun's C library. However, "nslookup", "ping", "host", etc. all seem
to use the resolver just fine on our systems. Why wouldn't
"sendmail.mx"? Any ideas?
I greatly appreciate any light people can shed on these configuration issues!
Thanks a lot,
Greg Jumper
TRW Data Systems Center
jumper@spf.trw.com
PS. The figure:
Corporate Class B Backbone (to Internet)
==============================================================================
|
|
|
-----
| | SunOS 4.0.3
| | Runs DNS (BIND)
| | mailhost ("main" sendmail.cf)
-----
|
|
Organizational Class C Ethernet |
------------------------------------------------------------------------------
| | |
| | |
----- ----- -----
| | | | | |
| | | | . . . | |
| | | | | |
----- ----- -----
SunOS 4.0.3
YP master server
all use "subsidiary" sendmail.cf
DNS domain name: "spf.trw.com"
YP domain name: "+spf.trw.com" (so sendmail doesn't strip of "spf")
Hostname format: short name only (not fully qualified)
"/etc/hosts" format: short name only; fully qualified name is NOT included
as an aliasJohn_E_Little@cup.portal.com (02/08/91)
We recently attached to the Internet, and are using a sun as the gateway. We had all sorts of problems, including ypserv going into infinite loops and sendmail bouncing mail as "host unknown" because of nameserver timeouts. After fighting with yp, dns, and sendmail for a while, I learned several things: 1 - yp is not very tolerant of network timeouts, like busy nameservers. While yp returns a timeout error code, the gethostbyname() routine has no way to pass this information to the caller. It either succeeds or it fails. If a program uses gethostbyname() and times out, then it usually assumes that the hostname is invalid. This is bad. 2 - sun engineering does not care about fixing the problems. I was told that unless I provided a more specific reason for the sendmail problems I was seeing, that they would not look at the problem. Since I needed source to provide the level of detail they desired, and I do not have a source licence, they were basically telling me to stuff it. 3 - sun support was somewhat more helpful. Once I convinced them that my problems were real, and pointed out a few unfortunate interactions between yp and gethostbyname(), they started investigating and found some areas of concern in sendmail. However, they said that these fell under the category of rfe's rather than bugs, and that engineering would probably not fix them. Their solution: get the berkeley version of sendmail and use that instead of the sun version. It's pretty sad when sun is advising me to throw away their (allegedly) supported software and run some pd alternative instead. 4 - *Everyone* I have talked to who has attached a sun to the internet has experienced similar problems. For a company who claims "The Network is the Solution," sun has a long way to go. 5 - smail is quite a nice program, it comes with source, the organization makes sense, and it needs very little tweaking to work with the Internet. Our mail reliability is *much* higher since we ditched sun sendmail and took yp off our gateway machine. 6 - you can rebuild the shared C library to use the bind resolver instead of the standard sun yp stuff. The bind sources are effective pd, so you could roll your own combination of bind and yp and perhaps avoid some other the problems. This is not directly applicable to your situation, I suspect, but may give you some clues. John