Bug 127457 - autofs doesn't treat # character as comment in nsswitch.conf
Summary: autofs doesn't treat # character as comment in nsswitch.conf
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: autofs
Version: 3.0
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Jeff Moyer
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2004-07-08 14:44 UTC by Geoff Gustafson
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version: RHBA-2005-178
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-05-19 22:05:37 UTC

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 18:31 UTC, Jeff Moyer
no flags Details | Diff

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:177 normal SHIPPED_LIVE Normal: autofs bug fix update 2005-05-19 04:00:00 UTC
Red Hat Product Errata RHBA-2005:178 normal SHIPPED_LIVE autofs bug fix update 2005-06-09 04:00:00 UTC

Description Geoff Gustafson 2004-07-08 14:44:49 UTC
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 Jeff Moyer 2004-07-08 14:51:07 UTC
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 15:11:05 UTC
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 Jeff Moyer 2004-07-08 17:10:44 UTC
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 Jeff Moyer 2005-02-11 18:31:53 UTC
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 Jeff Moyer 2005-02-11 18:35:17 UTC
This fix will make RHEL 3 U5 and RHEL 4 U1.

Comment 6 Dennis Gregorovic 2005-05-19 22:05:38 UTC
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.