Bug 213700 - automount does not mount /net
automount does not mount /net
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ian Kent
Brock Organ
bzcl34nup
:
Depends On:
Blocks: 231950
  Show dependency treegraph
 
Reported: 2006-11-02 12:07 EST by sbevan
Modified: 2008-08-02 19:40 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 12:40:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Debug print for host name matching checks. (592 bytes, patch)
2006-12-09 01:50 EST, Ian Kent
no flags Details | Diff
Test program to check host name translation (680 bytes, text/x-csrc)
2007-01-08 11:27 EST, Ian Kent
no flags Details
Patch to check the interface address fqdn when trying to match an export (4.00 KB, patch)
2007-01-26 08:32 EST, Ian Kent
no flags Details | Diff

  None (edit)
Description sbevan 2006-11-02 12:07:15 EST
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
and this in the host log file:
Nov  2 09:58:46 boa rpc.mountd: export request from 192.168.1.35

I have tried to automount from several different hosts that all work with other
clients with the same result.
Comment 1 sbevan 2006-11-02 12:11:31 EST
Linux automount version 5.0.1-0.rc2.17
kernel version:  2.6.18-1.2798.fc6
Comment 2 Ian Kent 2006-11-02 12:24:23 EST
(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
Comment 3 sbevan 2006-11-02 12:40:24 EST
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.
Comment 4 Jeffrey Moyer 2006-11-02 13:07:05 EST
"/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?
Comment 5 sbevan 2006-11-02 13:16:37 EST
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
Comment 6 Ian Kent 2006-11-02 22:26:28 EST
(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
Comment 7 sbevan 2006-11-03 10:22:18 EST
/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)
Comment 8 Ian Kent 2006-11-03 11:35:51 EST
(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?
Comment 9 sbevan 2006-11-03 13:10:50 EST
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.
Comment 10 Ian Kent 2006-11-03 13:36:42 EST
(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


Comment 11 sbevan 2006-11-03 15:18:43 EST
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.
Comment 12 Ian Kent 2006-11-03 20:27:56 EST
(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
Comment 13 Ian Kent 2006-12-09 01:48:41 EST
(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
Comment 14 Ian Kent 2006-12-09 01:50:30 EST
Created attachment 143205 [details]
Debug print for host name matching checks.
Comment 15 Ian Kent 2006-12-19 02:55:26 EST
(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?
Comment 16 Ian Kent 2006-12-19 02:57:38 EST
(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
Comment 17 sbevan 2006-12-21 11:11:59 EST
I will give it a try but I am out of the office until January so it will be a bit.
Comment 18 sbevan 2007-01-05 15:26:12 EST
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
Comment 19 Ian Kent 2007-01-05 20:40:25 EST
(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
Comment 20 Ian Kent 2007-01-05 22:00:16 EST
(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
Comment 21 sbevan 2007-01-08 10:46:07 EST
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
Comment 22 Ian Kent 2007-01-08 11:27:45 EST
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
Comment 23 sbevan 2007-01-08 13:03:21 EST
./name
myname mamba ni->ai_canonname mamba
Comment 24 Ian Kent 2007-01-08 20:24:06 EST
(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
Comment 25 Ian Kent 2007-01-08 20:25:36 EST
(In reply to comment #24)
> 
> Can you also post the output from
> host mamba

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

Ian
Comment 26 sbevan 2007-01-10 12:42:08 EST
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
Comment 27 Alexandre Oliva 2007-01-22 08:20:55 EST
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?
Comment 28 Ian Kent 2007-01-22 09:34:51 EST
(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
Comment 29 Alexandre Oliva 2007-01-22 11:14:00 EST
Couldn't it just try to mount everything and let the server figure out the
access control lists?
Comment 30 Ian Kent 2007-01-22 11:23:02 EST
(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
Comment 31 Ian Kent 2007-01-26 08:32:51 EST
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
Comment 32 Ian Kent 2007-01-29 01:01:19 EST
(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
Comment 33 Ian Kent 2007-02-14 01:00:02 EST
(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
Comment 34 Bug Zapper 2008-04-04 00:21:49 EDT
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
Comment 35 Bug Zapper 2008-05-06 12:40:17 EDT
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.

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