On Sat, 8 Jan 2000, Chad Glendenin wrote:
> I just finished installing my brand-new Redhat 6.1 on one of my Intel
> boxes yesterday. Today I noticed that whenever I tried to connect to that
> machine from another Unix machine on my network, it took several minutes
> before it asked for my login information. Just out of curiosity, I tried
> running tcpdmatch, but it locked up after warning about hostname aliases.
I'm not sure what's going on... yet. :)
First, are you sure of "several minutes"? I'd have guessed you're running
into the default 30-second resolver delay if anything, but maybe that's
not right. From what you write, it looks like you're making the same
guess I am: *tcpd* is what's timing out in one case but working
immediately in the other.
So... second, are you are sure the behavior your describe is replicable?
I'm not sure what the substantial difference between your "working" syntax
for /etc/hosts and the slow one is, except for which canonical name the
addresses will resolve to when you do an address-to-name lookup (as tcpd
does). What are 'abcd' and 10.0.0.10 in this context? (That is, are the
lines just garbage, or are they real machines on your network?)
My best guess is that something's resolving in one case to a hostname
that, when used, causes a timeout but which, when it resolves to the
'truncated' name, works fine (maybe because your search order implies that
'abcd' isn't 'abcd.mydomain.com'?). But I can't figure out why tcpd would
actually *use* (as opposed to just verify) a hostname that's the result of
an address-to-name resolution.
But there are clear steps to help figure out what's going on, if you want:
first, isolate it to tcpd by connecting to a service that doesn't use it.
Then, figure out the minimal change in /etc/hosts that produces the error.
Shawn
This archive was generated by hypermail 2b29 : Wed Apr 27 2005 - 03:30:03 EDT