Bug 156037 - Automount NIS maps with mixed wildcard/non-wildcard entries behaves differently in U5-beta
Automount NIS maps with mixed wildcard/non-wildcard entries behaves different...
Status: CLOSED DUPLICATE of bug 151668
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: autofs (Show other bugs)
3.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeffrey Moyer
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-26 16:15 EDT by Paul Waterman
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-26 17:34:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Paul Waterman 2005-04-26 16:15:27 EDT
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):
autofs-4.1.3-104

How reproducible:
Always

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 17:34:35 EDT

*** This bug has been marked as a duplicate of 151668 ***
Comment 2 Paul Waterman 2005-04-26 19:12:42 EDT
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.