Bug 147018 - Autofs ignores proto=tcp option when it gets maps from LDAP
Summary: Autofs ignores proto=tcp option when it gets maps from LDAP
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: autofs
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Chris Feist
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-02-03 18:25 UTC by Matthew Riedel
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-04-28 22:10:12 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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'.


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