Thanks to all who responded to my query about problems with "talk" on a
To summarize the problem: talk would fail on an NIS and DNS client SparcStation
returning with the message "[Target machine does not recognize us]".
The solution: The administrator had, correctly, removed all extraneous
host names out of the local and NIS /etc/hosts file, assuming that DNS
would handle all host/IP translation. talk could not locate the hostname
of the caller anywhere and would put out the "...does not recognize..."
Ugly solution: put the hostname for the caller back into the NIS server's
/etc/hosts file. This worked fine for just one host, but other hosts still
had the same problem...
Better solution: make sure the reverse DNS maps are in synch with the
regular maps. Many programs like lpd, rsh, and (as it turns out) talk, require
the reverse maps to be running properly. In our case, a central group was
supposed to be providing this machine with reverse maps, but had somehow
failed to do so. They were doing this to avoid the administrator overhead
of having to update the reverse maps manually. My recommendation to them
was to quit being lazy and handle reverse maps at the local DNS server level.
Thanks to those who responded:
firstname.lastname@example.org - word on "ntalk" - I'll look into it.
email@example.com - check for chmod on /etc/utmp.
etsiao@autobahn.ARDFA.CalPoly.EDU - note on OS upgrades
firstname.lastname@example.org - grand prize winner: note on reverse maps.
Thanks again to all...
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:46 CDT