+++ This bug was initially created as a clone of Bug #156035 +++ From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050414 Description of problem: The autofs RPM included in RHEL 3.0 U5 beta (autofs-4.1.3-104) will use a local /etc file map in preference to NIS if one exists, regardless of /etc/nsswitch.conf settings or the configuration of the master map. Version-Release number of selected component (if applicable): autofs-4.1.3-104 How reproducible: Always Steps to Reproduce: 1. Create an auto.master map (NIS or /etc/auto.master) with an entry for an NIS map. E.g., /home auto_home -rw,nosuid,nobrowse,intr 2. Create a file in /etc with the same name as the NIS map. E.g., /etc/auto_home 3. Start autofs (service autofs start). 4. Run ps to verify that the automounter is using the /etc map when it should be using the NIS map: % ps -auxww | fgrep auto_home root 12687 1.2 0.0 1844 844 tty1 S 14:50 0:00 /usr/sbin/automount --timeout=60 /home file /etc/auto_home -rw,nosuid,nobrowse,intr Note that it will use the /etc map regardless of the settings in /etc/nsswitch.conf. Actual Results: The automount executable uses the /etc file map. Expected Results: The automount executable should use the NIS map. Additional info: This may cause unexpected failures for users when they upgrade to U5 if they happen to have old map files sitting in /etc that they expect the automounter to ignore. -- Additional comment from jmoyer on 2005-04-26 18:18 EST -- The logic in the init script does not appear to have changed. How is this a change in behaviour from U4? Thanks. -- Additional comment from jmoyer on 2005-04-26 18:26 EST -- I just answered my own question. Before if a map name was not an absolute path, you would just look for it in the current working directory. This was reported as a bug, and we fixed this by attempting to read it from /etc. Now, because of this, a failure to find a file map results in success, whereas before you would fall through to the yp case. This is tricky. Fix one bug, and you break things for others. The only way to make everybody happy is to do this the right way (by consulting /etc/nsswitch.conf). For U5, however, this isn't in the cards. I will attempt to put this logic after the yp case. -- Additional comment from paulwaterman on 2005-05-26 18:54 EST -- The specific behaviour described in this bug is fixed in autofs-4.1.3-130 as officially released in RHEL 3.0 U5. Therefore, this bug should probably be closed. -- Additional comment from paulwaterman on 2005-05-26 19:00 EST -- Whoops. Never mind. Somebody re-imaged my U5 test machine back to U4. This problem DOES still exist in autofs-4.1.3-130 -- drop a file in /etc with the same name as an NIS automount map and watch it override the NIS map. -- Additional comment from jmoyer on 2005-06-08 13:07 EST -- Paul, I think this is a dup of your bug 145152. However, I am going to leave this bug open, since it documents a regression that has not been addresses in U5. If this is really causing you pain, please let me know. Otherwise, I'm going to work on the proper fix for this problem for Update 6. Thanks.
This bug was put on Proposed while waiting for the autofs package to get put on the approved list. Now that autofs is approved, we'd like to get a qa_ack for this BZ, and move it to CanFix. Please ack.
I built an updated version of autofs which addresses the problems reported in this bug. Please test the package found here: http://people.redhat.com/jmoyer/rhel4u4-autofs/ There are builds for every architecture. The changes to this package are fairly invasive and, as such, I'd like to get testing feedback as soon as possible. If there is any unexpected change in behaviour, please be sure to report it. Thanks in advance! Jeff
A fix for this bug was just committed to the RHEL 4 U4 patch pool. It will be available in autofs version 4.1.3-179 and later.
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-2006-0464.html