The auto.net script that comes with autofs5 is broken

Bug #912030 reported by Paul Smith
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
autofs5 (Fedora)
Fix Released
Medium
autofs5 (Ubuntu)
New
Medium
Unassigned

Bug Description

A long time ago I reported a bug in the autofs package: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/111612

That bug was fixed, but now I've discovered that the same bug still exists in the autofs5 package. Please see the above bug for the issue and the fix (I applied the fix by hand to my current system and it did solve the problem). Without this fix, the autofs /net map is simply non-functioning in many common Enterprise environments.

~$ dpkg -S auto.net
autofs5: /usr/share/autofs5/conffiles/auto.net

~$ lsb_release -r -d
Description: Ubuntu 10.10
Release: 10.10

~$ apt-cache policy autofs5
autofs5:
  Installed: 5.0.5-0ubuntu2.1
  Candidate: 5.0.5-0ubuntu2.1
  Version table:
 *** 5.0.5-0ubuntu2.1 0
        500 http://us.archive.ubuntu.com/ubuntu/ maverick-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     5.0.5-0ubuntu2 0
        500 http://us.archive.ubuntu.com/ubuntu/ maverick/main amd64 Packages

Revision history for this message
In , Paul (paul-redhat-bugs) wrote :

Created attachment 555563
Fix auto.net to ignore duplicate export partitions

Description of problem:

For NFS servers which export the same partition with different options (for example, a partition might be exported to one system with root privileges enabled and all other systems with root squash enabled--this is a common scenario in Enterprise environments), the /net automount map fails to find ANY exported partitions.

Version-Release number of selected component (if applicable):

This issue is present in all versions of autofs 4 and autofs 5 that I've checked.

How reproducible:

100%.

Steps to Reproduce:
1. Configure an NFS server to export the same partition in two different ways and export them. When you run showmount -e against that host you should see multiple entries like this:
~$ showmount -e snap-dev01
Export list for snap-dev01:
/user 172.0.0.0/8
/tools 172.0.0.0/8
/projects 172.0.0.0/8
/user devtools
/tools devtools
/projects devtools
The server doesn't have to be running Red Hat (or even Linux); it's not a server problem.

2. On a client (running Red Hat), attempt to access one of these partitions through the /net automount map as it comes configured by default:

Actual results:

~$ ls /net/snap-dev01/tools/.
ls: cannot access /net/snap-dev01/tools/.: No such file or directory

Expected results:

~$ ls /net/snap-dev01/tools/.
bin etc info man sbin
dist include lib share tmp

Additional info:

I filed a bug against Ubuntu autofs4 back in 2007 and they did fix it there:

https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/111612

I've recently discovered that this problem still exists in the latest Ubuntu for autofs5 and I filed a bug there as well:

https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/912030

The bug is in the default auto.net handling script that comes with autofs, so I also sent a bug report upstream to the autofs maintainers at <email address hidden> but unfortunately that mailing list doesn't appear to be archived anywhere anymore so I can't give you a link.

I've attached my patch to fix the problem here as well.

Dave Walker (davewalker)
Changed in autofs5 (Ubuntu):
importance: Undecided → Medium
Revision history for this message
In , yanfu (yanfu-redhat-bugs) wrote :

From Ian's advice:
This is a change to the auto.net script which is not our recommended way to use the hosts map. So, I think sanity only is sufficient for this one.
The old /etc/auto.net is below:
$SHOWMOUNT | LC_ALL=C sort -k 1 | \
Confirm the /etc/auto.net in new autofs-5.0.5-54.el6:
$SHOWMOUNT | LC_ALL=C cut -d' ' -f1 | LC_ALL=C sort -u | \

Revision history for this message
In , errata-xmlrpc (errata-xmlrpc-redhat-bugs) wrote :

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0951.html

Changed in autofs5 (Fedora):
importance: Unknown → Medium
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.