Bug 763941 - (GLUSTER-2209) [3.1.1-GA] gNFS goes into an unusable state if dns-lookups fail
[3.1.1-GA] gNFS goes into an unusable state if dns-lookups fail
Status: CLOSED WONTFIX
Product: GlusterFS
Classification: Community
Component: nfs (Show other bugs)
3.1.1
All Linux
low Severity medium
: ---
: ---
Assigned To: Shehjar Tikoo
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-10 14:46 EST by Harshavardhana
Modified: 2015-12-01 11:45 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: RTP
Mount Type: nfs
Documentation: DP
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Harshavardhana 2010-12-10 14:46:23 EST
Even if we have used ips to create the volume, "gNFS" still tries to do reverse name resolution on incoming mount requests. 

If those ips are not listed in DNS it provides a permission denied error to the user, where as user would think there is a problem with the server but "showmount -e" says the volume is shared by everyone with "*"

When you have a peek @ nfs.log on the server side you can see lots of name resolution requests failing. 

I believe that a valid ip of a specified or allowed subnet should be allowed to access even if the DNS resolution fails. 

Curious part is even after fixing the "resolv.conf" on those servers NFS server still stays in its previous state and still provides messages pertaining name resolution failures. 

You have to "force" start the volume again to get it fixed. 

It is wrong to bailout on DNS resolution with valid ip and also it is wrong to perpetuate itself into that situation unless it is restarted. 

Reproducibility: V.Easy
Comment 1 Shehjar Tikoo 2010-12-13 19:41:42 EST
Yeah, there is already a bug filed for it. Will look into it again.
Comment 2 Shehjar Tikoo 2011-01-25 02:37:57 EST
harsha, this is where we discussed this before and the reasoning in the last comment still applies. 

http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=1390#c11

I still hold that view that it is simpler to restart nfs than make the large code change that is needed to fix the problem. What do you think?
Comment 3 Harshavardhana 2011-01-26 17:14:45 EST
(In reply to comment #2)
> harsha, this is where we discussed this before and the reasoning in the last
> comment still applies. 
> 
> http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=1390#c11
> 
> I still hold that view that it is simpler to restart nfs than make the large
> code change that is needed to fix the problem. What do you think?

I don't really understand the idea of NFS doing a reverse lookup and failing all the time even after the issue is fixed. Problem is major when you have to restart the service, the perpetuation of the issue even after DNS fixed is my concern. 

If this is how its going to be, we need to clearly mention in our documentation and what are the expected results on client side when a live i/o is going on.
Comment 4 Shehjar Tikoo 2011-01-26 22:00:27 EST
(In reply to comment #3)
> (In reply to comment #2)
> > harsha, this is where we discussed this before and the reasoning in the last
> > comment still applies. 
> > 
> > http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=1390#c11
> > 
> > I still hold that view that it is simpler to restart nfs than make the large
> > code change that is needed to fix the problem. What do you think?
> 
> I don't really understand the idea of NFS doing a reverse lookup and failing
> all the time even after the issue is fixed. Problem is major when you have to
> restart the service, the perpetuation of the issue even after DNS fixed is my
> concern. 
> 

The issue is not fixed. Just dont think it should be fixed.

> If this is how its going to be, we need to clearly mention in our documentation
> and what are the expected results on client side when a live i/o is going on.

Where would you like this documented? Is the gluster nfs FAQ page accessible enough by you?
Comment 5 Harshavardhana 2011-01-26 22:39:07 EST
> The issue is not fixed. Just dont think it should be fixed.
> 
Ok 
> 
> Where would you like this documented? Is the gluster nfs FAQ page accessible
> enough by you?

Good enough, for support team. It would be easy for them also.
Comment 6 Shehjar Tikoo 2011-02-10 01:03:42 EST
Will be documented by Divya.

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