Bug 147018 - Autofs ignores proto=tcp option when it gets maps from LDAP
Autofs ignores proto=tcp option when it gets maps from LDAP
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: autofs (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Chris Feist
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-03 13:25 EST by Matthew Riedel
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-28 18:10:12 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 Matthew Riedel 2005-02-03 13:25:10 EST
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 Jeffrey Moyer 2005-02-11 14:20:36 EST
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 17:55:03 EST
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 14:44:14 EST
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 18:10:12 EDT
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.