mount 127.0.0.1:/ can fail if DNS is down
and mountd has been restarted without re-run of exportfs -r,
because /var/lib/nfs/etab contains wrong hostname ("localhost"
instead of "127.0.0.1") and mountd cannot determine that
these are the same. This was explained in my previous mail.
Here is another, lesser problem:
If mountd was restarted _with_ prior run of exportfs -r, etab is correct
and mount succeeds, but with ~10 sec delay because of:
nfs_export *
auth_authenticate(char *what, struct sockaddr_in *caller, char *path)
{
nfs_export *exp = NULL;
char epath[MAXPATHLEN+1];
char *p = NULL;
struct hostent *hp = NULL;
struct in_addr addr = caller->sin_addr;
enum auth_error error;
if (path [0] != '/') {
xlog(L_WARNING, "bad path in %s request from %s: \"%s\"",
what, inet_ntoa(addr), path);
return exp;
}
strncpy(epath, path, sizeof (epath) - 1);
epath[sizeof (epath) - 1] = '\0';
auth_fixpath(epath); /* strip duplicate '/' etc */
xlog(L_ERROR, "auth_authenticate(): get_reliable_hostbyaddr start"); //vda:
===> hp = get_reliable_hostbyaddr((const char*)&caller->sin_addr, sizeof(struct in_addr),
AF_INET);
^^^^^^^^^^^^^^^^^ gethostbyaddr inside. we will wait for DNS reply (or timeout)
if (!hp)
hp = get_hostent((const char*)&caller->sin_addr, sizeof(struct in_addr),
AF_INET);
if (!hp)
return exp;
This DNS query is not needed in my case.
Shall we first try to authenticate against numeric IP of client
and retry with hostname returned from get_reliable_hostbyaddr()
only if we fail auth against numeric IP?
--
vda
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Meanwhile, this patch prevents exportfs from translating
numeric IPs into hostnames for /var/lib/nfs/etab.
Adheres to principle of least surprise. Avoids DNS lookups.
--
vda
> > > mount 127.0.0.1:/ can fail if DNS is down
> > > and mountd has been restarted without re-run of exportfs -r,
> > > because /var/lib/nfs/etab contains wrong hostname ("localhost"
> > > instead of "127.0.0.1") and mountd cannot determine that
> > > these are the same. This was explained in my previous mail.
> > >
> > > Here is another, lesser problem:
> > >
> > > If mountd was restarted _with_ prior run of exportfs -r, etab is correct
> > > and mount succeeds, but with ~10 sec delay because of DNS timeout
> > [snip]
> >
> > I've cooked up a patch.
> > Now my mount 127.0.0.1:/ /mnt/tmp succeeds instantly,
> > regardless of whether 127.0.0.1 resolves to 'localhost' or not.
> >
> > This is accomplished by first trying to auth against numeric IP,
> > and only if that fails, we resolve IP into name and try again.
> >
> > Please comment/apply.
>
> sorry, but this has been tried before, and it doesn't work.
>
> From the ChangeLog
>
> 2001-09-12 NeilBrown <[email protected]>
>
> * utils/mountd/auth.c (auth_authenticate_internal): Reverse
> change from 2000-08-02: It causes problems if someone exports
> to both a hostname and IP addresses. nfs-utils must be
> consistant about the canonical name that it chooses.
> ...
> 2000-08-02 H.J. Lu <[email protected]>
>
> * utils/mountd/auth.c (auth_authenticate_internal): Try to
> avoid the reverse name lookup.
>
> It is only safe to avoid the DNS lookup if there are *no* names in the
> /etc/exports file. If everything is one of "*", "ip.ad.dr.es" or
> "ne.t-.wo.rk/mask" then it is OK, If there is any domain.name or
> @netgroup, then you always need to find the name.
What about '*.domain.name' style wildcards?
> The problem arises if someone exports one filesystem to an IP address,
> and another to the DNS name. Confusion and failure results.
Like this? /etc/exports:
/home 1.2.3.4(rw)
/public joker(rw)
What is the failure scenario? I don't quite understand where is the problem.
--
vda
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Wed, Mar 09, 2005 at 10:49:13AM +0200, Denis Vlasenko wrote:
[snip]
> > The problem arises if someone exports one filesystem to an IP address,
> > and another to the DNS name. Confusion and failure results.
>
> Like this? /etc/exports:
>
> /home 1.2.3.4(rw)
> /public joker(rw)
>
> What is the failure scenario? I don't quite understand where is the problem.
/home 1.2.3.0/24(ro)
/home joker(rw)
If Joker -> 1.2.3.4 then you need to do the lookup because joker is more
specific than 1.2.3.0/24.
You could get around this by converting host names to IPs at export
time.
The precedence of exports is important as well. To do the least amount
of look up you need to make it:
IP address
hostname (or get rid of these and only use IP addresses)
networks
wildcards
Now if you find and IP you are done. If there are not hostnames and you
find a network you are done. Otherwise you do the DNS lookup and look
for wildcards.
Allen Morris
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Friday 04 March 2005 14:24, Denis Vlasenko wrote:
> mount 127.0.0.1:/ can fail if DNS is down
> and mountd has been restarted without re-run of exportfs -r,
> because /var/lib/nfs/etab contains wrong hostname ("localhost"
> instead of "127.0.0.1") and mountd cannot determine that
> these are the same. This was explained in my previous mail.
>
> Here is another, lesser problem:
>
> If mountd was restarted _with_ prior run of exportfs -r, etab is correct
> and mount succeeds, but with ~10 sec delay because of DNS timeout
[snip]
I've cooked up a patch.
Now my mount 127.0.0.1:/ /mnt/tmp succeeds instantly,
regardless of whether 127.0.0.1 resolves to 'localhost' or not.
This is accomplished by first trying to auth against numeric IP,
and only if that fails, we resolve IP into name and try again.
Please comment/apply.
--
vda
On Saturday March 5, [email protected] wrote:
> On Friday 04 March 2005 14:24, Denis Vlasenko wrote:
> > mount 127.0.0.1:/ can fail if DNS is down
> > and mountd has been restarted without re-run of exportfs -r,
> > because /var/lib/nfs/etab contains wrong hostname ("localhost"
> > instead of "127.0.0.1") and mountd cannot determine that
> > these are the same. This was explained in my previous mail.
> >
> > Here is another, lesser problem:
> >
> > If mountd was restarted _with_ prior run of exportfs -r, etab is correct
> > and mount succeeds, but with ~10 sec delay because of DNS timeout
> [snip]
>
> I've cooked up a patch.
> Now my mount 127.0.0.1:/ /mnt/tmp succeeds instantly,
> regardless of whether 127.0.0.1 resolves to 'localhost' or not.
>
> This is accomplished by first trying to auth against numeric IP,
> and only if that fails, we resolve IP into name and try again.
>
> Please comment/apply.
sorry, but this has been tried before, and it doesn't work.
From the ChangeLog
2001-09-12 NeilBrown <[email protected]>
* utils/mountd/auth.c (auth_authenticate_internal): Reverse
change from 2000-08-02: It causes problems if someone exports
to both a hostname and IP addresses. nfs-utils must be
consistant about the canonical name that it chooses.
...
2000-08-02 H.J. Lu <[email protected]>
* utils/mountd/auth.c (auth_authenticate_internal): Try to
avoid the reverse name lookup.
It is only safe to avoid the DNS lookup if there are *no* names in the
/etc/exports file. If everything is one of "*", "ip.ad.dr.es" or
"ne.t-.wo.rk/mask" then it is OK, If there is any domain.name or
@netgroup, then you always need to find the name.
The problem arises if someone exports one filesystem to an IP address,
and another to the DNS name. Confusion and failure results.
A patch which checked is this was the case, and always avoided DNS
lookup if it was would be seriously considered for acceptance.
Thanks,
NeilBrown
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs