Bug 19336 - xinetd-2.1.8.9pre11-1 has name resolution problems
xinetd-2.1.8.9pre11-1 has name resolution problems
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: xinetd (Show other bugs)
7.3
alpha Linux
medium Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-10-18 16:45 EDT by Michal Jaegermann
Modified: 2007-04-18 12:29 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-10-18 19:14:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2000-10-18 16:45:38 EDT
This new xinetd-2.1.8.9pre11-1 looks to me in an absence of a name
server on a subnetwork quite thoroughly broken.

My test machine is now 'kinga.home.front' and in /etc/hosts has, among
other things a line

192.168.23.4    thebox.home.front       thebox

in /etc/hosts.allow one can find things like that:

ALL: 127.0.0.1, \
        LOCAL, \
        192.168.23. : \
        allow

and in /etc/nsswitch.conf

hosts:      files nisplus nis dns

Despite of all this trying on 'thebox' the following

$ ssh -v -l michal kinga

results in this:

thebox.home.front: Connecting to kinga [192.168.23.6] port 22.
thebox.home.front: Allocated local port 1022.
thebox.home.front: connect: Connection refused
thebox.home.front: Trying again...
thebox.home.front: Connecting to kinga [192.168.23.6] port 22.
thebox.home.front: Allocated local port 1022.
thebox.home.front: connect: Connection refused
thebox.home.front: Trying again...
thebox.home.front: Connecting to kinga [192.168.23.6] port 22.
thebox.home.front: Allocated local port 1022.
thebox.home.front: connect: Connection refused
thebox.home.front: Trying again...
thebox.home.front: Connecting to kinga [192.168.23.6] port 22.
thebox.home.front: Allocated local port 1022.
thebox.home.front: connect: Connection refused
Secure connection to kinga refused; reverting to insecure method.
Using rsh.  WARNING: Connection will not be encrypted.
/usr/bin/rsh kinga -l michal

and on 'kinga' I get in /var/log/messages this:

Oct 18 14:24:26 kinga xinetd[7283]: warning: /etc/hosts.allow, line
18: can't verify hostname: gethostbyname(thebox.home.front) failed
Oct 18 14:24:26 kinga pam_rhosts_auth[7859]: denied to
michal@thebox.home.front as michal: access not allowed
Oct 18 14:24:26 kinga PAM_unix[7860]: (system-auth) session opened for
user michal by (uid=0)

Nothing of that sort happens when trying to connect on the same
network to x86 machine with RH 7 but which still is using
xinetd-2.1.8.9pre9-6.  Doing 'ssh -v' from 'thebox' produces

thebox.home.front: Allocated local port 1020.
thebox.home.front: Connection established.

To add insult to injury 'tcpdcheck' and 'tcpdmatch' were dumped
instead of fixing a parser to read xinetd.conf as well.

  Michal
  michal@harddata.com
Comment 1 Trond Eivind Glomsrxd 2000-10-18 16:50:06 EDT
ssh doesn't use xinetd?
Comment 2 Nalin Dahyabhai 2000-10-18 18:43:12 EDT
The sshd server doesn't use xinetd, but it does use tcp-wrappers internally. 
Kinga doesn't appear to be listening on port 22... is it actually running sshd? 
Does shutting sshd down using the init script, running "sshd -d" on kinga, and
attempting to connect from thebox using ssh give any other information?
Comment 3 Michal Jaegermann 2000-10-18 19:14:16 EDT
Oops.  Scratch that report.  I am an idiot!

I failed to notice that an upgrade from an existing 6.2 installation
dropped in on my disk

openssh-askpass-2.1.1p4-1
openssh-2.1.1p4-1
openssh-clients-2.1.1p4-1
openssh-askpass-gnome-2.1.1p4-1

but not openssh-server-2.1.1p4-1.  And in installation from scratch
on another Alpha (not here in the moment) got openssh-server on it.
It should be like that?

Got confused by complaints from xinetd, which still should be able
to resolve the name in question using /etc/hosts.  Sigh!
(I should take a break for a few days, apparently).

Note You need to log in before you can comment on or make changes to this bug.