TCP/NFS

mark hilliard mark at gizzmo.UUCP
Fri Nov 23 23:41:50 AEST 1990


In article <50 at mailgzrz.tu-berlin.de> elsn4000 at mailgzrz.tu-berlin.de (Frank Elsner) writes:
>In article <532 at comcon.UUCP> tim at comcon.UUCP (Tim Brown) writes:
>>hostname in /etc/hosts (tho it is there) and the lockd complains about
>>something similiar to do with the hostname being wrong.  Now the
>>really weird part, if I telnet to one of the other hosts (a 6000)
>>using the *internet* address it works but if I try to do it using the
>>hostname, it hangs.  
>I would guess the problem is the Domain Name Service (DNS). Its usage is
>activated by the file /etc/resolv.conf. If this file contains the one and
>only line "nonameserver" you may run into the problems described.

If you are NOT using a name server ANYTHING BUT 'nonameserver' in 
/etc/resolv.conf will cause tcp to look for IP addresses at a remote location
and will blow up.  I have personally had this problem. If you are running
Interactive and use their mail setup program under sysadm, the resolv.conf
is built WRONG!  Go take a look at it and make sure that it says ONLY
nonameserver if you do not have access to one.  If there is a nameserver on
your network, then you must have your systems entered into its databases 
before it will know about you.  Even having a domain line in resolv.conf will
cause tcp to not look in the hosts file.  I know that this is not the way
host lookup is supposed to work, but in the 8 systems I have built in a stand
alone network, this is the only way I could get them talking vi the hosts file.

I also have 2 systems on our main network with nameserver access.  For these
systems, I had to put a domain and nameserver entry in resolv.conf.
-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|  Mark Hilliard, N2HHR                         |    AWK is not just a   |
|  Fax 315-986-5882                             |        LANGUAGE        |
|  mark at gizzmo.kodak.com                        |   It is a way of LIFE! |



More information about the Comp.unix.sysv386 mailing list