Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 156037 - Automount NIS maps with mixed wildcard/non-wildcard entries behaves differently in U5-beta
Summary: Automount NIS maps with mixed wildcard/non-wildcard entries behaves different...
Status: CLOSED DUPLICATE of bug 151668
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: autofs
Version: 3.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeff Moyer
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2005-04-26 20:15 UTC by Paul Waterman
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-04-26 21:34:35 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Paul Waterman 2005-04-26 20:15:27 UTC
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:
Automount NIS maps with mixed wildcard/non-wildcard entries behaves differently in U5-beta.

Assume the scenario where you have an automount map using a mixture of wilcard and non-wildcard entries. E.g.,:

user1   nfs-server:/export/user1
user2   nfs-server:/export/user2
user3   nfs-server:/export/user3
*       &:/export/&

If this map is served via NIS, the map order is not preserved, as NIS is non-order-preserving. Thus, when you perform a ypcat -k auto.[map] you may end up with something like this instead:

user3   nfs-server:/export/user3
*       &:/export/&
user1   nfs-server:/export/user1
user2   nfs-server:/export/user2

In RHEL 3.0 U4 (autofs-4.1.3-47) and prior, this is not a problem. Despite the fact that NIS may return the wildcard entry before other entries, the automounter apparently internally sorts the wildcard entry to the end of the list, and only uses it as a last resort.

In RHEL 3.0 U5-beta (autofs-4.1.3-104), the automounter does not exhibit the same behaviour. Instead, as soon as NIS returns the wildcard entry, the automounter considers it a match and does not consider any remaining entries in the NIS map.

This new behaviour may technically be "correct" behaviour, and given the fact that NIS is non-order-preserving, it's probably foolhardy to have NIS maps containing a mix of wildcard and non-wildcard entries. 

However, this difference in behaviour will very likely break large enterprise configurations (it sure breaks ours!).

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

How reproducible:

Steps to Reproduce:
Create and use an NIS automount map with a mixture of wildcard and non-wildcard entries as shown above (you may need more entries to reliably get a situation where NIS ends up throwing the wildcard into the middle of the map).

Additional info:

Comment 1 Chris Feist 2005-04-26 21:34:35 UTC

*** This bug has been marked as a duplicate of 151668 ***

Comment 2 Paul Waterman 2005-04-26 23:12:42 UTC
Sigh. Once again I'm bitten by the fact that there are multiple products that
appear to indiscriminately be used...

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