Bug 127457 - autofs doesn't treat # character as comment in nsswitch.conf
autofs doesn't treat # character as comment in nsswitch.conf
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: autofs (Show other bugs)
x86_64 Linux
medium Severity low
: ---
: ---
Assigned To: Jeffrey Moyer
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2004-07-08 10:44 EDT by Geoff Gustafson
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2005-178
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-19 18:05:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Make the autofs init script terminate processing of a nsswitch.conf line at the commect character. (336 bytes, patch)
2005-02-11 13:31 EST, Jeffrey Moyer
no flags Details | Diff

  None (edit)
Description Geoff Gustafson 2004-07-08 10:44:49 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2)

Description of problem:
autofs on U3/x86_64 works differently than on U2/i386. If NIS is
turned on, but /etc/auto.home is not present, autofs will mount /home
to some unknown, apparently bogus, location. May be the same with
auto.misc and /misc, not fully tested.

When /home is mounted, typing 'mount' and finding the PID of the
automount associated with /home, then cat /proc/<pid>/cmdline | od -ax
shows "YP" instead of "FILE" - apparently this means the source of the
mount information used. It's possible the problem lies in NIS.

There may be an intentional behavior change, but the man pages are
dated '97 and '00 so no update there. And it just seems wrong for
/home to be rendered unusable.

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

How reproducible:

Steps to Reproduce:
1. Set up NIS and Kerberos settings in authconfig
2. Copy /etc/auto.master, auto.kickstart, and auto.accounts from a
working U2 box with NIS to local /etc
3. Reboot, try to log in with NIS account.
4. Type 'mount'

Actual Results:  Step 3 shows /home/<nisdir>/username doesn't exist.

Step 4 shows both /home and /home/<nisdir> mounted.

/home appears to be entirely bogus, you can't create files, etc.

Expected Results:  Step 3 should have completed fine, mounting

Step 4 should show no /home mounted separately from /home/<nisdir>

Additional info:

Workaround: touch /etc/auto.home to prevent this new automatic default
mounting of /home.
Comment 1 Jeffrey Moyer 2004-07-08 10:51:07 EDT
nsswitch.conf listed files nis.  the auto.master used by autofs will
be the concatination of /etc/auto.master and the nis auto.master. 
Thus, you got the /home entry from nis.  Commenting out nis didn't
help because the init script doesn't look for comments.  I'll work on
a fix for that.
Comment 2 Geoff Gustafson 2004-07-08 11:11:05 EDT
True, so maybe it's the expected behavior that when the auto.home file
is not present it moves on to nis and finds a map for /home. It's
still interesting that U2/i386 behaved differently (with the same
nsswitch.conf entry).
Comment 3 Jeffrey Moyer 2004-07-08 13:10:44 EDT
The reason for this is that there exists a bug in the init script for
autofs-3.1.7, whereby if two maps have a matching string in the
mount-point name, then the second in the list is ignored.  Consider,
in your case, the following:

/home   /etc/auto.home
/home/boston  /etc/auto.accounts

The old init script would equate the two, due to a bug in the regular
expression for matching previously handled keys.

As such, you got lucky with the old behaviour.
Comment 4 Jeffrey Moyer 2005-02-11 13:31:53 EST
Created attachment 110981 [details]
Make the autofs init script terminate processing of a nsswitch.conf line at the commect character.

There are also patches in the tree now which allow for using only one
auto.master map.  Either one of these fixes would address this problem.
Comment 5 Jeffrey Moyer 2005-02-11 13:35:17 EST
This fix will make RHEL 3 U5 and RHEL 4 U1.
Comment 6 Dennis Gregorovic 2005-05-19 18:05:38 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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