This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 359871 - autofs NIS map multi-mount
autofs NIS map multi-mount
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: autofs (Show other bugs)
3.8
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Jeffrey Moyer
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-31 06:02 EDT by Brendan Watt
Modified: 2008-01-08 11:46 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-08 11:46:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Brendan Watt 2007-10-31 06:02:42 EDT
Description of problem:
autofs issue with RHE3U8 autofs RPM AND RHE4U5 RPM, but problem does not exist 
with RHE3U7 autofs RPM.
We have 2 different Linux distribution builds each one use they're own RHE 
version (3 and 4).
Specific issue is that for this given extract from our auto.master file, not 
all files are seen under /ed as expected and /var/log/messages indicate an 
issue with the maps it won't make available.  Details below:

NIS-MAP
-------------------------------
/ed/s3d/caspian auto.s3d_caspian
/ed/s3d/barents auto.s3d_barents
/ed/s2d/caspian auto.s2d_caspian
/ed/s2d/barents auto.s2d_barents
/ed/s3d/south auto.s3d_south
/ed/s3d/north auto.s3d_north
/ed/s2d/south auto.s2d_south
/ed/s2d/north auto.s2d_north
/ed/partners auto.partners
/ed/datawork auto.datawork
/ed/develop auto.develop_i2d_i3d
/ed/caspian auto.caspian_i2d_i3d
/ed/barents auto.barents_i2d_i3d
/ed/s2data auto.develop_s2data
/ed/south auto.south_i2d_i3d
/ed/north auto.north_i2d_i3d
/ed/data auto.ed_data

/var/log/messages output with RHE3U8/RHE4U5 autofs RPM
------------------------
Oct 30 13:12:30 svgcls001 nsswitch: nsswitch: couldn't find map auto.s3d_north
Oct 30 13:12:30 svgcls001 nsswitch: nsswitch: couldn't find map auto.s2d_south
Oct 30 13:12:30 svgcls001 nsswitch: nsswitch: couldn't find map auto.s2d_north
Oct 30 13:12:31 svgcls001 nsswitch: nsswitch: couldn't find map 
auto.develop_i2d_i3d
Oct 30 13:12:31 svgcls001 nsswitch: nsswitch: couldn't find map 
auto.caspian_i2d_i3d
Oct 30 13:12:31 svgcls001 nsswitch: nsswitch: couldn't find map 
auto.barents_i2d_i3d
Oct 30 13:12:31 svgcls001 nsswitch: nsswitch: couldn't find map 
auto.develop_s2data
Oct 30 13:12:31 svgcls001 nsswitch: nsswitch: couldn't find map 
auto.south_i2d_i3d
Oct 30 13:12:31 svgcls001 nsswitch: nsswitch: couldn't find map 
auto.north_i2d_i3d
Oct 30 13:12:31 svgcls001 nsswitch: nsswitch: couldn't find map auto.ed_data
Oct 30 13:12:31 svgcls001 autofs: automount startup succeeded


Version-Release number of selected component (if applicable):
autofs-4.1.3-168 (RHE3U7 RPM which works fine)
autofs-4.1.3-186 (RHE3U8 RPM has problem)
autofs-4.1.3-199 (RHE4U5 RPM has problem)

How reproducible:
Everytime

Steps to Reproduce:
1. Install RH3U8 autofs RPM autofs-4.1.3-168
2. Stop/start autofs or reboot
  
Actual results:
# ls /ed
datawork  partners  s2d  s3d
# ls /ed/s2d
# ls /ed/partners
group  projects  sinterp_p1
# ls /ed/s3d
#
# df -k /ed/s2d
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda3            231997940   8002224 212210836   4% /


Expected results:
With RHE3U7 RPM the following correct entry is seen:
#ls /ed
barents  caspian  data  datawork  develop  north  partners  s2d  s2data  s3d  
south
# ls /ed/s2d
barents  caspian  north  south


Additional info:
Workaround currently is to use the RHE3U7 RPM, but this is not ideal or 
preferred.
It's a big task for us to re-organise our NIS maps, so a fix is preferred.
Comment 1 Jeffrey Moyer 2007-10-31 09:49:19 EDT
What does the following command show?

ypcat -k auto.s3d_north

Do you have the UNDERSCORETODOT variable set in /etc/sysconfig/autofs?  What
does the automount: line read in /etc/nsswitch.conf?
Comment 2 Brendan Watt 2007-11-01 05:18:22 EDT
With problematic autofs installed, but still no access to this area 
in /ed/s2d/north:
# rpm -qa | grep -i autofs
autofs-4.1.3-199.3

ALWAYS PROBLEMATIC EXAMPLE
# ypcat -k auto.s3d_north
p10 -rw,proto=tcp,rsize=16384,wsize=16384,nosuid        netapp01:/vol/vol22/ed-
s3d-north-p10
# ypcat -k auto_s3d_north
No such map auto_home. Reason: No such map in server's domain

ONLY A FEW WORKED ALWAYS AND HAVE ENCLUDED ONE SUCH FOR COMPARISON
# ypcat -k auto.ed_data
develop-logs -rw,proto=tcp,rsize=16384,wsize=16384,nosuid       
netapp01:/vol/vol15/ed-data-develop-logs
# ypcat -k auto_ed_data
No such map auto_ed_data. Reason: No such map in server's domain

ANOTHER EXAMPLE WHICH DOESN'T WORK BUT APPEARS SAME ENTRY IN auto.master AS 
ABOVE
# ypcat -k auto.develop_s2data
p2 -rw,nfs3,proto=tcp,rsize=16384,wsize=16384,nosuid      netapp01:/vol/vol6/ed-
s2data-p2
# ypcat -k auto_develop_s2data
No such map auto_develop_s2data. Reason: No such map in server's domain


/etc/nsswitch.conf.....automount:  files nis

In both occurences, the same /etc/sysconfig/autofs is used.  UNDERSCORETODOT=1
Have just tested with UNDERSCORETODOT=0 and restarted autofs which has fixed 
the problem.  Given the additional example above which appears to be 
constructed the same but works always, was wondering if this is still a bug.

Thanks for you're help.
Comment 3 Jeffrey Moyer 2007-11-01 10:02:35 EDT
The only way to determine if your example is a bug is to get the output of:

bash -x /etc/init.d/autofs start

Then we can see what options are passed to nsswitch and to the automounter to
determine the source of the map.

The change in behaviour is due to a bug that was filed against autofs.  The
UNDERSCORETODOT variable was expected to change all underscores to dots, but it
originally only converted the underscores in select few maps.

Is setting UNDERSCORETODOT=0 an acceptable fix for this problem for you?
Comment 4 Jeffrey Moyer 2008-01-02 11:25:32 EST
Please provide a response to comment #3.
Comment 5 Jeffrey Moyer 2008-01-08 11:46:24 EST
Since you state that setting UNDERSCORE_TO_DOT to 0 fixes the problem for you
(and because I can't get further response from you), I'm closing this bug.

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