Red Hat Bugzilla – Bug 156037
Automount NIS maps with mixed wildcard/non-wildcard entries behaves differently in U5-beta
Last modified: 2007-11-30 17:07:07 EST
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.,:
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:
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):
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).
*** This bug has been marked as a duplicate of 151668 ***
Sigh. Once again I'm bitten by the fact that there are multiple products that
appear to indiscriminately be used...