Bug 127457

Summary: autofs doesn't treat # character as comment in nsswitch.conf
Product: Red Hat Enterprise Linux 3 Reporter: Geoff Gustafson <grgustaf>
Component: autofsAssignee: Jeff Moyer <jmoyer>
Status: CLOSED ERRATA QA Contact: Brock Organ <borgan>
Severity: low Docs Contact:
Priority: medium    
Version: 3.0CC: greg.marsden
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2005-178 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-05-19 22:05:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
Make the autofs init script terminate processing of a nsswitch.conf line at the commect character. none

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)
Gecko/20040301

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):
autofs-4.1.3-9

How reproducible:
Always

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
/home/<nisdir>/username.

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.

http://rhn.redhat.com/errata/RHBA-2005-177.html