SCIENTIFIC-LINUX-USERS Archives

July 2004

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Thu, 22 Jul 2004 09:28:34 -0500
Content-Type:
TEXT/PLAIN
Parts/Attachments:
TEXT/PLAIN (56 lines)
I wonder if John's problem is elsewhere, not so much with libwrap.  I find
"from <no address>" suspicious.  It's obvious that xinetd is trying to
verify the host that is connecting to sgi_fam.  And, it cannot do so.
It's as if dmbr063 is not a valid hostname.  Is it in /etc/hosts?  Is
nsswitch.conf messed up so libc cannot verify the hostname?  Is resolv.conf
set up correctly?

I relate one incident that prompts my thinking:  I wrote an ftp-like
server once and found xinetd rejecting connections from client machines.  I
traced it down to my DHCP server which was providing the hostname to the
client machine.  The DHCP entry read 'option host-name somename' which
turned out to be insufficient.  When I changed it to 'option host-name
somename.somedomain', xinetd allowed the connection.

Just wondering.

Ken



On Wed, 21 Jul 2004, csieh wrote:

> John,
>
> Thanks for this info.  We have had problems with this and all we found was
> to add sgi_fam to /etc/hosts.allow which is not a very good solution for
> us.
>
> -Connie Sieh
> [log in to unmask]
>
>  On Tue, 20 Jul 2004, John Franks wrote:
>
> > We have noted with SL 3.0.2 that there are frequently a large number of
> > error messages in /var/log/messages generated by sgi_fam.  They
> > look like
> >
> > Jan 26 16:57:57 dmbr063 xinetd[6342]: libwrap refused connection to
> > sgi_fam (libwrap=fam) from <no address>
> > Jan 26 16:57:58 dmbr063 xinetd[6350]: warning: can't get client
> > address: Transport endpoint is not connected
> >
> > In some cases they are generated fast enough to cause problems like not
> > being able to log in.
> >
> > There is a workaround:  Add the line
> >
> >          flags  =  NOLIBWRAP
> >
> > to /etc/xinetd.d/sgi_fam
> >
> > For more info see
> > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=114316
> >
>

ATOM RSS1 RSS2