Re: hosts.allow does not resolve names

On Wed, 28 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <slrnfkpn2v.4d9.BitTwister@xxxxxxxxxxxxxxx>, Bit Twister wrote:

Moe Trin wrote:

Very simple solution. Two lines - one with the old range, one with the
new.

Yes, but I really wanted the names to work.

Well, they should. Your syntax appears (to me) to be correct.

It's kinda like doing the math problems which have the answers in the
back of the book. I could work the ones with answers and could not
work out the answer of the ones without the answers. :(

By the time I got to that stage, the problems were quite complex, and
there's the answer, but how the heck did they get that? ;-)

Have you got any other daemon that is running out of xinetd?

Nope.
xinetd based services:
cups-lpd: off
cvs: off
proftpd-xinetd: off
rexec: off
rlogin: off
rsh: off

You wonder why they even include the Berkeley 'r' commands any more. If
you are on an isolated network that is fully trusted, they're OK, (and
exceptionally convenient), but they are _so_ easy to abuse.

that's portmap bitching, not tcpd or xinetd.

Yes, but hosts.allow changes is what is keeping portmap from allowing
the nfs request. :(

The thought was to try another xinetd service to see if the reactions
were the same. I could be wrong, but just enabling the service in
xinetd EVEN IF THE SERVER ISN'T INSTALLED should allow testing of tcpd.
This would show up in the server xinetd logs.

Only other thing I thought of was:
Three different versions of the NFS protocol are supported by the
Linux NFS client:

I don't _think_ so.

That is why I went with
[bittwister@wb ~]$ grep m2008 /etc/fstab
m2008:/local /mlocal nfs rsize=32768,wsize=32768,timeo=14,intr 0 0

Not sure about the timeo option, but that's not the problem we're seeing.

Did not want to get buried in Kerberos and whatnot.

I don't know why ;-)

Old guy
.