Bug 208833 - autofs5 delete leading / when resolving a nisMapName
autofs5 delete leading / when resolving a nisMapName
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
6
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Ian Kent
Brock Organ
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-02 06:15 EDT by Heinz Deinhart
Modified: 2008-05-06 12:26 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 12:26:18 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)
file with infos and logs (7.55 KB, text/plain)
2006-10-13 05:30 EDT, Heinz Deinhart
no flags Details
another log file of autofs --debug on client (8.09 KB, text/plain)
2006-10-13 08:12 EDT, Heinz Deinhart
no flags Details
Admit "/" as valid in LDAP attribute string (502 bytes, patch)
2006-10-13 08:37 EDT, Ian Kent
no flags Details | Diff
Admit "/" included in LDAP map name - revised (538 bytes, patch)
2006-10-13 08:56 EDT, Ian Kent
no flags Details | Diff

  None (edit)
Description Heinz Deinhart 2006-10-02 06:15:07 EDT
Description of problem:

I am using autofs with ldap. When entering a line like this

/homes ldap:nisMapName=/newhomes,dc=x,dc=y,dc=z

in the auto.master file then autofs5 deletes the / from the request.
Autofs4 did not do that.

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

i tried the fc6t3 version and autofs-5.0.1-0.rc2.8 from devel

How reproducible:

To test you need running ldap server and a line in /etc/ldap.master
  
Actual results:

In the ldap logfile:

Oct  2 12:06:58 iglo slapd[15791]: conn=526 op=1 SRCH
base="nisMapName=newhomes,dc=x,dc=y,dc=z" scope=0 deref=0
filter="(objectClass=nisMap)"


Expected results:

Oct  2 12:06:58 iglo slapd[15791]: conn=526 op=1 SRCH
base="nisMapName=/newhomes,dc=x,dc=y,dc=z" scope=0 deref=0
filter="(objectClass=nisMap)"

Additional info:

My main problem is that i want to support autofs4 and autofs5 clients with the
same ldap configuration. That means i can't just remove the slash from the name
in the ldap directory, because autofs4 client would fail then.

My current workaround is to duplicate the nisMapName tree without a /
Comment 1 Ian Kent 2006-10-02 06:54:42 EDT
(In reply to comment #0)
> Description of problem:
> 
> I am using autofs with ldap. When entering a line like this
> 
> /homes ldap:nisMapName=/newhomes,dc=x,dc=y,dc=z
> 
> in the auto.master file then autofs5 deletes the / from the request.
> Autofs4 did not do that.

OK. I'll check this out.

Ian
Comment 2 Ian Kent 2006-10-04 05:44:34 EDT
(In reply to comment #1)
> (In reply to comment #0)
> > Description of problem:
> > 
> > I am using autofs with ldap. When entering a line like this
> > 
> > /homes ldap:nisMapName=/newhomes,dc=x,dc=y,dc=z
> > 
> > in the auto.master file then autofs5 deletes the / from the request.
> > Autofs4 did not do that.
> 
> OK. I'll check this out.

I can't see where this is happening.
Could you get me a debug log please.

Add "--debug" to the OPTIONS= line in /etc/sysconfig/autofs
and ensure that syslog is sending daemon.* to a logfile.

Ian

Comment 3 Heinz Deinhart 2006-10-13 05:30:36 EDT
Created attachment 138412 [details]
file with infos and logs
Comment 4 Heinz Deinhart 2006-10-13 05:32:14 EDT
Comment on attachment 138412 [details]
file with infos and logs

Sorry for the delay, i did some logging now. If yo need any more info please
ask for it.

Thanks, Heinz
Comment 5 Ian Kent 2006-10-13 05:48:08 EDT
(In reply to comment #2)
> 
> Add "--debug" to the OPTIONS= line in /etc/sysconfig/autofs
> and ensure that syslog is sending daemon.* to a logfile.

Are you sure syslog is sending deamon.* to a log file?

The log you posted doesn't have what I need to help track
this down. I'm actually interested in the full autofs debug
log. The LDAP log may help later but I'm assuming I have a
parsing error somewhere so I need the autofs commentary.

Sorry for the hastle.

Ian
Comment 6 Heinz Deinhart 2006-10-13 08:12:09 EDT
Created attachment 138420 [details]
another log file of autofs --debug on client

Okay, i logged a service autofs restart this time with *.* in syslog, maybe it
logs to local and not daemon?

Thanks, Heinz
Comment 7 Heinz Deinhart 2006-10-13 08:17:37 EDT
Sorry i missed to explain something: The logs are from my config where the
master is read from ldap and not from /etc/ldap.master, which i wrote in the
beginning of the  thread. Using ldap.master file is just an easier way to
reproduce the problem and on my site both methods fail with the same problem. 

Thanke Heinz
Comment 8 Ian Kent 2006-10-13 08:34:36 EDT
(In reply to comment #6)
> Created an attachment (id=138420) [edit]
> another log file of autofs --debug on client
> 
> Okay, i logged a service autofs restart this time with *.* in syslog, maybe it
> logs to local and not daemon?

autofs logs to facility daemon.
No matter I've got what I wanted, thanks.

Notice that
Oct 13 14:04:52 ti34 automount[4829]: master_echo: /
twice in the log. The "/" is being ignored by flex.

Whould you happen to have two entries like this in this
master map?

Unfortuneately, the attribute value parsing is still quite
primitive at this stage. However, adding "/" as a valid
character should be OK.

Could you give the following patch a try please.

Ian
Comment 9 Ian Kent 2006-10-13 08:37:15 EDT
Created attachment 138423 [details]
Admit "/" as valid in LDAP attribute string
Comment 10 Ian Kent 2006-10-13 08:56:25 EDT
Created attachment 138425 [details]
Admit "/" included in LDAP map name - revised

A bit tricky - can't be a slash alone as that's the wildcard in LDAP maps.
Comment 11 Heinz Deinhart 2006-10-13 09:06:16 EDT
Thanks a lot, i applied the patch to the development rpm (autofs-5.0.1-0.rc2.10)
and it works now.

> Whould you happen to have two entries like this in this
master map?

Well, i have two because i can't play around with my homes, or my users will
have no homedirs :)

I need a / as first characters because if i don't the directory on the client
does not seem to be created. Isnt it supposed to work like this?

Anyway, thanks for the fix,
Heinz
Comment 12 Ian Kent 2006-10-13 09:57:29 EDT
(In reply to comment #11)
> Thanks a lot, i applied the patch to the development rpm (autofs-5.0.1-0.rc2.10)
> and it works now.
> 
> > Whould you happen to have two entries like this in this
> master map?
> 
> Well, i have two because i can't play around with my homes, or my users will
> have no homedirs :)
> 
> I need a / as first characters because if i don't the directory on the client
> does not seem to be created. Isnt it supposed to work like this?

Not really.
The "/" shouldn't make any difference.
Your entries should be something like:

# auto_master, themaw.net
dn: automountMapName=auto_master,dc=themaw,dc=net
objectClass: top
objectClass: automountMap
automountMapName: auto_master

# /ldap, auto_master, themaw.net
dn: description=/ldap,automountMapName=auto_master,dc=themaw,dc=net
objectClass: top
objectClass: automount
automountKey: /ldap
description: /ldap
automountInformation: auto_indirect

# bin, auto_indirect, themaw.net
dn: automountKey=bin,automountMapName=auto_indirect,dc=themaw,dc=net
objectClass: top
objectClass: automount
automountKey: bin
automountInformation: budgie:/usr/local/bin

as an example. You will need to translate to the corresponding
nisMap names. If you can't them I'll have a look around and see
what I can find.

Ian


Ian
Comment 13 Ian Kent 2006-10-13 10:01:36 EDT
(In reply to comment #12)
> (In reply to comment #11)
> > Thanks a lot, i applied the patch to the development rpm (autofs-5.0.1-0.rc2.10)
> > and it works now.
> > 
> > > Whould you happen to have two entries like this in this
> > master map?
> > 
> > Well, i have two because i can't play around with my homes, or my users will
> > have no homedirs :)
> > 
> > I need a / as first characters because if i don't the directory on the client
> > does not seem to be created. Isnt it supposed to work like this?
> 
> Not really.
> The "/" shouldn't make any difference.

Course this could be something related to version 4.
I'd need to investigate.

Ian
Comment 14 Matthew Miller 2007-04-06 13:14:52 EDT
Fedora Core 5 and Fedora Core 6 are, as we're sure you've noticed, no longer
test releases. We're cleaning up the bug database and making sure important bug
reports filed against these test releases don't get lost. It would be helpful if
you could test this issue with a released version of Fedora or with the latest
development / test release. Thanks for your help and for your patience.

[This is a bulk message for all open FC5/FC6 test release bugs. I'm adding
myself to the CC list for each bug, so I'll see any comments you make after this
and do my best to make sure every issue gets proper attention.]
Comment 15 Bug Zapper 2008-04-03 23:53:56 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 16 Bug Zapper 2008-05-06 12:26:16 EDT
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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