Bug 213700

Linux automount version 5.0.1-0.rc2.17
kernel version:  2.6.18-1.2798.fc6

(In reply to comment #0)
> Description of problem:
> automount does not mount /net
> This is a fresh install of FC6 with no mods to nfs/mount configuration files and
> selinux is disabled.  All updates have been performed with yum.
> "/etc/auto.net boa" returns:
> -fstype=nfs,hard,intr,nodev,nosuid \
>         /data boa:/data \
>         /home boa:/home
> mount works fine directly.
> "cd /net/boa" enters this in the client log file:
> Nov  2 09:58:46 mamba automount[2108]: lookup_mount: exports lookup failed for boa

Caught. This message is evidence that you aren't using the
auto.net script in auto.master so the output above isn't useful.

Please post the output of showmount -e <export host>

Ian

ok.  My bad.  I thought the "/net -hosts" was some new format and I didn't need
to put the auto.net entry in auto.master.  When I added auto.net, it fixed my
problem.  Sorry for the inconvenience.

"/net -hosts" is the new way of doing things, you are right.  We are attemnpting
to phase out the old auto.net script.  What Ian meant, above, was that running
auto.net by hand does not provide enough information to debug the problem.

So, in the interest of making -hosts a suitable replacement for auto.net, would
you mind providing the output from showmount -e of the server?

I can do that.  Here it is.

Export list for boa:
/data *.s5w.com,192.168.1.27
/home *.s5w.com,192.168.1.27

(In reply to comment #5)
> I can do that.  Here it is.
> 
> Export list for boa:
> /data *.s5w.com,192.168.1.27
> /home *.s5w.com,192.168.1.27
> 

Sorry, but can you show the /etc/exports entry on the server
also please.

Ian

/home   *.s5w.com(rw,sync,no_root_squash)
/data   *.s5w.com(rw,sync,no_root_squash)
/home   192.168.1.27(rw,sync,no_root_squash)
/data   192.168.1.27(rw,sync,no_root_squash)

(In reply to comment #7)
> /home   *.s5w.com(rw,sync,no_root_squash)
> /data   *.s5w.com(rw,sync,no_root_squash)
> /home   192.168.1.27(rw,sync,no_root_squash)
> /data   192.168.1.27(rw,sync,no_root_squash)
> 

And does the host boa match only *.s5w.com?

I'm not sure I understand your question.  There are many machines in the s5w.com
domain.  This export list will allow any machine in that domain to mount those
two directories.  Boa is the NFS server that is exporting these drives.
Just so you know.  The 192.168.1.27 is for a specific machine that is not
resolved through our DNS.  It is also not one of the machines this problem
refers to.

(In reply to comment #9)
> I'm not sure I understand your question.  There are many machines in the s5w.com
> domain.  This export list will allow any machine in that domain to mount those
> two directories.  Boa is the NFS server that is exporting these drives.
> Just so you know.  The 192.168.1.27 is for a specific machine that is not
> resolved through our DNS.  It is also not one of the machines this problem
> refers to.

Ha. Yep that's a stupid question, sorry.

What I'm asking is, what should a client that fails match in
the NFS access control export and is the client hostname
set to an FQDN or simple name?

Ian

FYI, the NFS mount works on this machine if I use auto.net or a manual mount.

Here is the output from 'hostname -f'
mamba

So, I suppose the client is set to a simple name.  However, it is also entered
in the DNS as an FQDN so reverse lookup will return an FQDN which allows NFS to
work.

(In reply to comment #11)
> FYI, the NFS mount works on this machine if I use auto.net or a manual mount.
> 
> Here is the output from 'hostname -f'
> mamba
> 
> So, I suppose the client is set to a simple name.  However, it is also entered
> in the DNS as an FQDN so reverse lookup will return an FQDN which allows NFS to
> work.

Never underestimate my ability to make dumb mistakes!
Looks like I only get the hostname and check that.

I'll fix it.

Ian

(In reply to comment #12)
> (In reply to comment #11)
> > FYI, the NFS mount works on this machine if I use auto.net or a manual mount.
> > 
> > Here is the output from 'hostname -f'
> > mamba
> > 
> > So, I suppose the client is set to a simple name.  However, it is also entered
> > in the DNS as an FQDN so reverse lookup will return an FQDN which allows NFS to
> > work.

Finally got to this issue.

> 
> Never underestimate my ability to make dumb mistakes!
> Looks like I only get the hostname and check that.

However, it appears not so this time.
I can't seem to make this fail for fqdn patern matching.

Could you apply the following patch to the source rpm
so we can see if the fqdn is what is failing please.

Ian

Created attachment 143205 [details]
Debug print for host name matching checks.

(In reply to comment #14)
> Created an attachment (id=143205) [edit]
> Debug print for host name matching checks.
> 

Have you had time to try this?

(In reply to comment #15)
> (In reply to comment #14)
> > Created an attachment (id=143205) [edit] [edit]
> > Debug print for host name matching checks.
> > 
> 
> Have you had time to try this?
> 

Perhaps you could try the latest autofs update before
going to the trouble of applying this patch, in case
the issue is not present any more.

Ian

I will give it a try but I am out of the office until January so it will be a bit.

I tried the latest update to autofs and the error message in the log file
changed to:
Jan  5 12:04:46 mamba automount[3287]: lookup_read_master: lookup(nisplus):
couldn't locat nis+ table auto.master

Does this help?

Scott

(In reply to comment #18)
> I tried the latest update to autofs and the error message in the log file
> changed to:
> Jan  5 12:04:46 mamba automount[3287]: lookup_read_master: lookup(nisplus):
> couldn't locat nis+ table auto.master
> 
> Does this help?

Nop. This just means that you have nisplus as a source in
nsswitch.conf and no map could be found which is probably
correct.

It's noting to do with the problem.

Ian

(In reply to comment #19)
> (In reply to comment #18)
> > I tried the latest update to autofs and the error message in the log file
> > changed to:
> > Jan  5 12:04:46 mamba automount[3287]: lookup_read_master: lookup(nisplus):
> > couldn't locat nis+ table auto.master
> > 
> > Does this help?
> 
> Nop. This just means that you have nisplus as a source in
> nsswitch.conf and no map could be found which is probably
> correct.
> 
> It's noting to do with the problem.

Could you provide the output from:
grep "hosts:" /etc/nsswitch.conf
grep "automount:" /etc/nsswitch.conf

and

getent hosts `hostname`

Please (those are backticks above).

Ian

grep "hosts:" /etc/nsswitch.conf
#hosts:     db files nisplus nis dns
hosts:      files dns

grep "automount:" /etc/nsswitch.conf
automount:  files nisplus

getent hosts `hostname`
::1             mamba localhost.localdomain localhost

Created attachment 145071 [details]
Test program to check host name translation

Could you compile this program using
gcc -o name name.c
and run it then post the output please.

Ian

./name
myname mamba ni->ai_canonname mamba

(In reply to comment #23)
> ./name
> myname mamba ni->ai_canonname mamba
> 

That's a bit of a problem, no domain on the canonical
name.

Can you also post the output from
host mamba

This problem could be resolved by adding
127.0.0.1   mamba.sw5.com mamba localhost.localdomain localhost

and altering (although probably not needed)
::1         mamba.sw5.com mamba localhost.localdomain localhost

but I'm not sure what side effects this may have in your
environment.

Ian

(In reply to comment #24)
> 
> Can you also post the output from
> host mamba

Oh, forget.
Could you also post /etc/resolv.conf.

Ian

host mamba
mamba.s5w.com has address 192.168.1.162

cat /etc/resolv.conf
; generated by /sbin/dhclient-script
search s5w.com
nameserver 192.168.1.160
nameserver 192.168.1.162
nameserver 69.27.0.130
nameserver 69.27.0.131

Why is not having a FQDN in /etc/hosts a problem?  For a machine that can be
plugged to multiple networks, having a FQDN specified at install time (such that
it makes to /etc/hosts) is inappropriate.  Why should autofs demand a FQDN
instead of accepting domain-less names that getent and other name resolution
mechanisms are perfectly happy with?

(In reply to comment #27)
> Why is not having a FQDN in /etc/hosts a problem?  For a machine that can be
> plugged to multiple networks, having a FQDN specified at install time (such that
> it makes to /etc/hosts) is inappropriate.  Why should autofs demand a FQDN
> instead of accepting domain-less names that getent and other name resolution
> mechanisms are perfectly happy with?

autofs isn't demanding anything.
It currently is not able to compare the machine name with a
wildcard domain name in the exports access control list of
the host it wishes to mount from and I'm still not sure
how to get that information about the host in this case.
As you point out there may be multiple interfaces present
so a reverse lookup may not always give the required
information.

Do you have any useful suggestions?

Ian

Couldn't it just try to mount everything and let the server figure out the
access control lists?

(In reply to comment #29)
> Couldn't it just try to mount everything and let the server figure out the
> access control lists?

That wasn't possible when this bug was logged but may be possible
now due to another recent fix. I'll investigate further when I
return to this.

Ian

Created attachment 146678 [details]
Patch to check the interface address fqdn when trying to match an export

This patch should resolve the exports matching.
Are you able to test this in your environment?

I'm reluctant to remove this check and just allow mount
attempts for all the exports because that would mean that
there could potentially be quite a few attempts to mount
the denied mount while navigating around the tree. If for
some reason mount(8) takes a while to return then there
would be a delay on every attempt. So I want to get that
out of the way once at initial access.

Ian

(In reply to comment #29)
> Couldn't it just try to mount everything and let the server figure out the
> access control lists?

btw.

autofs version 5 is meant to resolve the problem of
having to mount all exports on first access and to
umount all exports at expire.

Ian

(In reply to comment #31)
> Created an attachment (id=146678) [edit]
> Patch to check the interface address fqdn when trying to match an export
> 
> This patch should resolve the exports matching.
> Are you able to test this in your environment?

Have you been able to check this?
The patch above has been present since autofs-5.0.1-0.rc3.12.

Ian

Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.