Re: Bug#579397: STAT_FAIL to debian for SM_MON of 192.168.120.254, No canonical hostname found for 192.168.120.254

Re: Bug#579397: STAT_FAIL to debian for SM_MON of 192.168.120.254, No canonical hostname found for 192.168.120.254

[Ben Hutchings]

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

On Sat, 2010-05-22 at 07:49 +0800, Steven Shiau wrote: 
> Same problem here. However, mine is on the client side.
> On sid system, running kernel is 2.6.32-5-686, nfs-common is 1:1.2.2-1.
> When I mount my NFS server 192.168.120.254, it works. However, if I want 
> to use some tool which need to lock file to save the file on the NFS 
> server, e.g.
> vgcfgbackup -f $NFS_MNT_POINT/vg.cfg
> I get the message "lockd: cannot monitor 192.168.120.254", and the 
> message shown on the /var/log/daemon.log:
> May 21 08:52:44 debian rpc.statd[1298]: STAT_FAIL to debian for SM_MON 
> of 192.168.120.254
> May 21 08:52:44 debian rpc.statd[1298]: No canonical hostname found for 
> 192.168.120.254
[...]

nfs-utils 1.2.2 includes the change:

commit 8ce130c4c828b9d13d429f22160f992b9c1d45cd
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Thu Jan 14 12:24:15 2010 -0500

    statd: Support IPv6 in sm_mon_1_svc()

This appears to have removed support for IPv4 literals.  Was this
intentional?

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Bug#579397: STAT_FAIL to debian for SM_MON of 192.168.120.254, No canonical hostname found for 192.168.120.254

[Chuck Lever]

On 05/21/10 09:38 PM, Ben Hutchings wrote:
> On Sat, 2010-05-22 at 07:49 +0800, Steven Shiau wrote:
>> Same problem here. However, mine is on the client side.
>> On sid system, running kernel is 2.6.32-5-686, nfs-common is 1:1.2.2-1.
>> When I mount my NFS server 192.168.120.254, it works. However, if I want
>> to use some tool which need to lock file to save the file on the NFS
>> server, e.g.
>> vgcfgbackup -f $NFS_MNT_POINT/vg.cfg
>> I get the message "lockd: cannot monitor 192.168.120.254", and the
>> message shown on the /var/log/daemon.log:
>> May 21 08:52:44 debian rpc.statd[1298]: STAT_FAIL to debian for SM_MON
>> of 192.168.120.254
>> May 21 08:52:44 debian rpc.statd[1298]: No canonical hostname found for
>> 192.168.120.254
> [...]
>
> nfs-utils 1.2.2 includes the change:
>
> commit 8ce130c4c828b9d13d429f22160f992b9c1d45cd
> Author: Chuck Lever<chuck.lever@oracle.com>
> Date:   Thu Jan 14 12:24:15 2010 -0500
>
>      statd: Support IPv6 in sm_mon_1_svc()
>
> This appears to have removed support for IPv4 literals.  Was this
> intentional?

statd usually requires a DNS reverse mapping for any host it monitors. 
Does your DNS have a reverse mapping for 192.168.120.254?

It looks like the new logic is more restrictive than the old statd when 
mon_name is a presentation address.  The old code simply allowed 
presentation addresses with no reverse mapping.  The new code requires a 
reverse DNS mapping for presentation addresses.  I think even an entry 
in /etc/hosts would allow a raw address to work in this case.

We can probably remove the reverse mapping constraint for presentation 
addresses.  A simple fix might be to change statd_canonical_name() from:

	freeaddrinfo(ai);
	if (!result)
		return NULL;

to

	freeaddrinfo(ai);
	if (!result)
		return strdup(hostname);

Let me know if this works.

Re: Bug#579397: STAT_FAIL to debian for SM_MON of 192.168.120.254, No canonical hostname found for 192.168.120.254

[Chuck Lever]

On 05/24/10 11:22 AM, Chuck Lever wrote:
> On 05/21/10 09:38 PM, Ben Hutchings wrote:
>> On Sat, 2010-05-22 at 07:49 +0800, Steven Shiau wrote:
>>> Same problem here. However, mine is on the client side.
>>> On sid system, running kernel is 2.6.32-5-686, nfs-common is 1:1.2.2-1.
>>> When I mount my NFS server 192.168.120.254, it works. However, if I want
>>> to use some tool which need to lock file to save the file on the NFS
>>> server, e.g.
>>> vgcfgbackup -f $NFS_MNT_POINT/vg.cfg
>>> I get the message "lockd: cannot monitor 192.168.120.254", and the
>>> message shown on the /var/log/daemon.log:
>>> May 21 08:52:44 debian rpc.statd[1298]: STAT_FAIL to debian for SM_MON
>>> of 192.168.120.254
>>> May 21 08:52:44 debian rpc.statd[1298]: No canonical hostname found for
>>> 192.168.120.254
>> [...]
>>
>> nfs-utils 1.2.2 includes the change:
>>
>> commit 8ce130c4c828b9d13d429f22160f992b9c1d45cd
>> Author: Chuck Lever<chuck.lever@oracle.com>
>> Date: Thu Jan 14 12:24:15 2010 -0500
>>
>> statd: Support IPv6 in sm_mon_1_svc()
>>
>> This appears to have removed support for IPv4 literals. Was this
>> intentional?
>
> statd usually requires a DNS reverse mapping for any host it monitors.
> Does your DNS have a reverse mapping for 192.168.120.254?
>
> It looks like the new logic is more restrictive than the old statd when
> mon_name is a presentation address. The old code simply allowed
> presentation addresses with no reverse mapping. The new code requires a
> reverse DNS mapping for presentation addresses. I think even an entry in
> /etc/hosts would allow a raw address to work in this case.
>
> We can probably remove the reverse mapping constraint for presentation
> addresses. A simple fix might be to change statd_canonical_name() from:
>
> freeaddrinfo(ai);
> if (!result)
> return NULL;
>
> to
>
> freeaddrinfo(ai);
> if (!result)
> return strdup(hostname);
>
> Let me know if this works.

Any update?  I have a patch ready for nfs-utils to fix this regression, 
but I need confirmation that it addresses your problem.

Re: Bug#579397: STAT_FAIL to debian for SM_MON of 192.168.120.254, No canonical hostname found for 192.168.120.254

[Ben Hutchings]

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

On Thu, 2010-06-03 at 17:08 -0400, Chuck Lever wrote:
> On 05/24/10 11:22 AM, Chuck Lever wrote:
[...]
> > We can probably remove the reverse mapping constraint for presentation
> > addresses. A simple fix might be to change statd_canonical_name() from:
> >
> > freeaddrinfo(ai);
> > if (!result)
> > return NULL;
> >
> > to
> >
> > freeaddrinfo(ai);
> > if (!result)
> > return strdup(hostname);
> >
> > Let me know if this works.
> 
> Any update?  I have a patch ready for nfs-utils to fix this regression, 
> but I need confirmation that it addresses your problem.

Steven originally had this problem, not me.  Steven, do you need me to
build a new package with this change?

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Bug#579397: STAT_FAIL to debian for SM_MON of 192.168.120.254, No canonical hostname found for 192.168.120.254

[Steven Shiau]

On 2010=E5=B9=B406=E6=9C=8806=E6=97=A5 04:29, Ben Hutchings wrote:
> On Thu, 2010-06-03 at 17:08 -0400, Chuck Lever wrote:
>   =20
>> On 05/24/10 11:22 AM, Chuck Lever wrote:
>>     =20
> [...]
>   =20
>>> We can probably remove the reverse mapping constraint for presentatio=
n
>>> addresses. A simple fix might be to change statd_canonical_name() fro=
m:
>>>
>>> freeaddrinfo(ai);
>>> if (!result)
>>> return NULL;
>>>
>>> to
>>>
>>> freeaddrinfo(ai);
>>> if (!result)
>>> return strdup(hostname);
>>>
>>> Let me know if this works.
>>>       =20
>> Any update?  I have a patch ready for nfs-utils to fix this regression=
,
>> but I need confirmation that it addresses your problem.
>>     =20
> Steven originally had this problem, not me.  Steven, do you need me to
> build a new package with this change?
>
> Ben.
>
>   =20
Ben,
Yes, please.
Thanks.

Steven.

--=20
Steven Shiau<steven _at_ nchc org tw>  <steven _at_ stevenshiau org>
National Center for High-performance Computing, Taiwan.
http://www.nchc.org.tw
Public Key Server PGP Key ID: 1024D/9762755A
Fingerprint: A2A1 08B7 C22C 3D06 34DB  F4BC 08B3 E3D7 9762 755A

Re: Bug#579397: STAT_FAIL to debian for SM_MON of 192.168.120.254, No canonical hostname found for 192.168.120.254

[Chuck Lever]

On 06/ 9/10 10:41 AM, Steven Shiau wrote:
>
>
> On 2010=E5=B9=B406=E6=9C=8806=E6=97=A5 04:29, Ben Hutchings wrote:
>> On Thu, 2010-06-03 at 17:08 -0400, Chuck Lever wrote:
>>> On 05/24/10 11:22 AM, Chuck Lever wrote:
>> [...]
>>>> We can probably remove the reverse mapping constraint for presenta=
tion
>>>> addresses. A simple fix might be to change statd_canonical_name() =
from:
>>>>
>>>> freeaddrinfo(ai);
>>>> if (!result)
>>>> return NULL;
>>>>
>>>> to
>>>>
>>>> freeaddrinfo(ai);
>>>> if (!result)
>>>> return strdup(hostname);
>>>>
>>>> Let me know if this works.
>>> Any update? I have a patch ready for nfs-utils to fix this regressi=
on,
>>> but I need confirmation that it addresses your problem.
>> Steven originally had this problem, not me. Steven, do you need me t=
o
>> build a new package with this change?
>>
>> Ben.
>>
> Ben,
> Yes, please.
> Thanks.

Any progress on this?

Re: Bug#579397: STAT_FAIL to debian for SM_MON of 192.168.120.254, No canonical hostname found for 192.168.120.254

[Ben Hutchings]

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

On Tue, 2010-07-06 at 13:05 -0400, Chuck Lever wrote:
> On 06/ 9/10 10:41 AM, Steven Shiau wrote:
> >
> >
> > On 2010年06月06日 04:29, Ben Hutchings wrote:
> >> On Thu, 2010-06-03 at 17:08 -0400, Chuck Lever wrote:
> >>> On 05/24/10 11:22 AM, Chuck Lever wrote:
> >> [...]
> >>>> We can probably remove the reverse mapping constraint for presentation
> >>>> addresses. A simple fix might be to change statd_canonical_name() from:
> >>>>
> >>>> freeaddrinfo(ai);
> >>>> if (!result)
> >>>> return NULL;
> >>>>
> >>>> to
> >>>>
> >>>> freeaddrinfo(ai);
> >>>> if (!result)
> >>>> return strdup(hostname);
> >>>>
> >>>> Let me know if this works.
> >>> Any update? I have a patch ready for nfs-utils to fix this regression,
> >>> but I need confirmation that it addresses your problem.
> >> Steven originally had this problem, not me. Steven, do you need me to
> >> build a new package with this change?
> >>
> >> Ben.
> >>
> > Ben,
> > Yes, please.
> > Thanks.
> 
> Any progress on this?

I've heard nothing from Steven but one positive report from another
user.  In any case we'll include this in our package.

We now have a git repository of the nfs-utils package at
<git://git.debian.org/kernel/nfs-utils.git>; currently our changes are
kept in a quilt patch series in debian/patches.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Bug#579397: STAT_FAIL to debian for SM_MON of 192.168.120.254, No canonical hostname found for 192.168.120.254

[Chuck Lever]

On Aug 8, 2010, at 12:59 AM, Ben Hutchings wrote:

> On Tue, 2010-07-06 at 13:05 -0400, Chuck Lever wrote:
>> On 06/ 9/10 10:41 AM, Steven Shiau wrote:
>>>=20
>>>=20
>>> On 2010=E5=B9=B406=E6=9C=8806=E6=97=A5 04:29, Ben Hutchings wrote:
>>>> On Thu, 2010-06-03 at 17:08 -0400, Chuck Lever wrote:
>>>>> On 05/24/10 11:22 AM, Chuck Lever wrote:
>>>> [...]
>>>>>> We can probably remove the reverse mapping constraint for presen=
tation
>>>>>> addresses. A simple fix might be to change statd_canonical_name(=
) from:
>>>>>>=20
>>>>>> freeaddrinfo(ai);
>>>>>> if (!result)
>>>>>> return NULL;
>>>>>>=20
>>>>>> to
>>>>>>=20
>>>>>> freeaddrinfo(ai);
>>>>>> if (!result)
>>>>>> return strdup(hostname);
>>>>>>=20
>>>>>> Let me know if this works.
>>>>> Any update? I have a patch ready for nfs-utils to fix this regres=
sion,
>>>>> but I need confirmation that it addresses your problem.
>>>> Steven originally had this problem, not me. Steven, do you need me=
 to
>>>> build a new package with this change?
>>>>=20
>>>> Ben.
>>>>=20
>>> Ben,
>>> Yes, please.
>>> Thanks.
>>=20
>> Any progress on this?
>=20
> I've heard nothing from Steven but one positive report from another
> user.  In any case we'll include this in our package.
>=20
> We now have a git repository of the nfs-utils package at
> <git://git.debian.org/kernel/nfs-utils.git>; currently our changes ar=
e
> kept in a quilt patch series in debian/patches.

Thanks, I'll submit the latest version of this to the nfs-utils maintai=
ner.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com