Bug 147018

Summary: Autofs ignores proto=tcp option when it gets maps from LDAP
Product: Red Hat Enterprise Linux 3 Reporter: Matthew Riedel <mriedel>
Component: autofsAssignee: Chris Feist <cfeist>
Status: CLOSED WORKSFORME QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: cfeist, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-04-28 22:10:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Matthew Riedel 2005-02-03 18:25:10 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.7.5) Gecko/20041107 Firefox/1.0

Description of problem:
When using autofs in an LDAP environment, it seems that autofs ignores
the proto=tcp argument.  We noticed this when a machine behind a
firewall tries to mount a machine outside of it.  Through the
automount, with proto=tcp specified, the command fails.  However, when
the mount is done by hand, with proto=tcp, the mount succeeds.

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

How reproducible:
Always

Steps to Reproduce:
1. Put a machine behind a firewall that blocks udp nfs traffic
2. Set up an LDAP automount for that machine, and use the option proto=tcp
3. It will fail to automount.  However, mounting by hand with
proto=tcp still works.
    

Actual Results:  The mount is only successful if done by hand.

Expected Results:  autofs should use the options specified in the map
given to it by LDAP

Additional info:

Here is an LDIF for an example:
#
# This file was generated by gq 1.0beta1   (http://biot.com/gq/)
# run by mriedel Thu Feb  3 11:24:12 2005
#
# subtree search on server: ldap://dapper.lanl.gov:389/
#                   binddn:
employeeNumber=182540,ou=CCN-1,ou=people,dc=dapper,dc=lanl,dc=gov
#          searching below:
cn=esmunix,ou=auto.remote,ou=amd,ou=CSD,dc=dapper,dc=lanl,dc=gov
# version: 1
#
dn: cn=esmunix,ou=auto.remote,ou=amd,ou=CSD,dc=dapper,dc=lanl,dc=gov
objectClass: automount
cn: esmunix
automountInformation:
-rw,hard,intr,timeo=10,retrans=100,rsize=8192,wsize=819
 2,proto=tcp csdteam.lanl.gov:/vol/s01/csd/esmunix
description: Space on csdteam for esm unix guys

Comment 1 Jeff Moyer 2005-02-11 19:20:36 UTC
So long as you aren't using replicated server entries, an update for this
problem will be available in RHEL 3 U5.

Chris, I believe this will be addressed by the work you are doing in get_best_mount.

Comment 2 Chris Feist 2005-02-11 22:55:03 UTC
I am unable to replicate this problem on my system.

Can you post the entries from /var/log/messages when autofs fails to
mount?

Comment 3 Chris Feist 2005-03-14 19:44:14 UTC
Could you also try the latest autofs and see if you continue to have
problems?

http://people.redhat.com/jmoyer/autofs-4.1.3-104.i386.rpm

Comment 4 Chris Feist 2005-04-28 22:10:12 UTC
I am unable to replicate the problem and have not recieved any information from
reporter.  Closing bug 'WORKSFORME'.