Bug 203467 - autofs initscript in 4.1.3-187 breaks NIS mapping
autofs initscript in 4.1.3-187 breaks NIS mapping
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: autofs (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Moyer
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2006-08-21 18:44 EDT by Link Dupont
Modified: 2007-11-16 20:14 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-13 16:30:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
autofs-4.1.3-187-basename.patch (335 bytes, patch)
2006-08-21 18:44 EDT, Link Dupont
no flags Details | Diff
Updated for 64-bit (828 bytes, text/plain)
2006-09-05 10:52 EDT, Link Dupont
no flags Details

  None (edit)
Description Link Dupont 2006-08-21 18:44:19 EDT
Description of problem:
automounts from NIS no longer mounting with certain NIS map configurations

Version-Release number of selected component (if applicable):
autofs-4.1.3-187 & 4.1.3-186

Our NIS environment has NIS maps that look like the following:
/ypsrc/auto.build --timeout=60
/ypsrc/auto.home --timeout=60

The latest autofs initscript (that uses the new nsswitch binary for NIS map
parsing) does not take these prefix pathes into account, and subsequently fails
when trying to parse the maps.
This was worked around before by running basename on the $map before parsing it.

The attached patch adds back in 1 line into the autofs initscript which runs
basename on the $map before handing it off to nsswitch. This patch does fix our
environment, though I don't know if you want to apply this type of fix in the
nsswitch binary itself, or in the autofs initscript.
Comment 1 Link Dupont 2006-08-21 18:44:20 EDT
Created attachment 134604 [details]
Comment 2 Roger Lin 2006-09-01 18:03:35 EDT
Thanks for the quick fix. I can confirm that map names get '/etc' prepended.
Comment 3 Link Dupont 2006-09-05 10:52:53 EDT
Created attachment 135564 [details]
Updated for 64-bit

Apparently the first patch shell didn't apply on 64-bit systems because if the
lib64 naming scheme, so this script should correctly detect the architecture of
the machine and patch accordingly.
Comment 4 Jeff Moyer 2006-09-07 14:38:25 EDT
thanks for the effort, but this is the wrong place to fix the problem.  Please
try this patch, instead.

Comment 5 Jeff Moyer 2006-09-13 16:30:53 EDT
Closing as a duplicate.  I've added those on the CC list here to the CC list of

*** This bug has been marked as a duplicate of 202860 ***
Comment 6 Jeff Moyer 2006-09-20 09:34:35 EDT
It turns out that prefixing maps with /ypsrc/ was done to indicate that the maps
should come from NIS.  This is not a supported convention;  I think it worked by
accident, before.  The maps can be changed to use yp: instead of /ypsrc/, or you
can simply rely upon the name service switch configuration to determine the
source of the maps.

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