Possible breakthrough Re: Debian Bug#203918 - statd request on eth interface, not localhost?

Possible breakthrough Re: Debian Bug#203918 - statd request on eth interface, not localhost?

[Chip Salzenberg]

(Jordi, this is an edited msg copied to the NFS list.)

According to Jordi Mallach:
> On Thu, Aug 21, 2003 at 10:40:28AM -0400, Chip Salzenberg wrote:
> > Hm.  I don't suppose if you type
> >    host 127.0.0.1
> >    host localhost
> > it fails?  I know, long shot.  :-)  Looks like a dead end.
> 
> Heh, maybe not...
> 
> I'm assuming you're interested on the server.
> 
> host 127.0.0.1 is ok, but...
> 
> 20740:jordi@natura:~$ host localhost 
> localhost.int.oskuro.net does not exist (Authoritative answer)
> zsh: exit 69    host localhost

That *is* interesting.  It's possible that statd and even portmap will
refuse to accept requests from localhost, since your /etc/hosts.deny
says "ALL: PARANOID", and your loopback interface fails the paranoia
test.

Could you please do what it takes to make "host localhost" and "host
127.0.0.1" work on both client *and* server, and see if your problem
goes away?  Either that or add "ALL: 127.0.0.1" to /etc/hosts.allow.

Hm.  Things could be breaking even sooner than that, depending on
whether any of nfs-utils depends on the name "localhost"....

> both boxes have a
> 
> 127.0.0.1       localhost
> 
> line in /etc/hosts.

Hm again.  I wonder if the tcpwrappers paranoia check uses /etc/hosts.

(Sorry for the resend, Jordi.)
-- 
Chip Salzenberg               - a.k.a. -               <chip@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Possible breakthrough Re: Debian Bug#203918 - statd request on eth interface, not localhost?

[Jordi Mallach]

[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]

On Thu, Aug 21, 2003 at 02:02:14PM -0400, Chip Salzenberg wrote:
> That *is* interesting.  It's possible that statd and even portmap will
> refuse to accept requests from localhost, since your /etc/hosts.deny
> says "ALL: PARANOID", and your loopback interface fails the paranoia
> test.
> 
> Could you please do what it takes to make "host localhost" and "host
> 127.0.0.1" work on both client *and* server, and see if your problem
> goes away?  Either that or add "ALL: 127.0.0.1" to /etc/hosts.allow.

Ok. I added "localhost" to my internal network zone file. I thought this
was bad, but someone on IRC told me it's ok. They also told me it's
really not needed (normal apps should be using nsswitch.conf, but host
doesn't).

20801:jordi@natura:~$ host localhost
localhost.int.oskuro.net        A       127.0.0.1

FWIW, "ALL: 127.0.0.1" didn't help.

Ok. Apparently it doesn't help either... I have restarted the nfs stuff
and nothing happens. I'm seeing the exact same messages on the server's
logs and this on the client's when I try to use apt-get:

Aug 21 20:49:15 nubol rpc.statd[632]: Received erroneous SM_UNMON request from nubol for 192.168.1.1

(nubol = client = 192.168.1.3)

Of course, I haven't remounted or anything after doing these changes,
because I can't umount the share. Should I reboot the client to see?

> (Sorry for the resend, Jordi.)

No problem, after all the help I'm getting from you guys :)

Jordi
-- 
Jordi Mallach Pérez  --  Debian developer     http://www.debian.org/
jordi@sindominio.net     jordi@debian.org     http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/~jordi/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Possible breakthrough Re: Debian Bug#203918 - statd request on eth interface, not localhost?

[Chip Salzenberg]

According to Jordi Mallach:
> Ok. Apparently it doesn't help either.

Darn.

> Of course, I haven't remounted or anything after doing these changes,
> because I can't umount the share. Should I reboot the client to see?

Well, the message is on the server (right?), so if anything, rebooting
the server (or at least stopping and starting nfs-kernel-server and
nfs-common) would be called for as a complete test.
-- 
Chip Salzenberg               - a.k.a. -               <chip@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Possible breakthrough Re: Debian Bug#203918 - statd request on eth interface, not localhost?

[Jordi Mallach]

[-- Attachment #1: Type: text/plain, Size: 525 bytes --]

On Thu, Aug 21, 2003 at 03:31:26PM -0400, Chip Salzenberg wrote:
> Well, the message is on the server (right?), so if anything, rebooting
> the server (or at least stopping and starting nfs-kernel-server and
> nfs-common) would be called for as a complete test.

Yeah. I did restart those, no luck.

-- 
Jordi Mallach Pérez  --  Debian developer     http://www.debian.org/
jordi@sindominio.net     jordi@debian.org     http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/~jordi/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]