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 /
(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
(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
Created attachment 138412 [details] file with infos and logs
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
(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
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
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
(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
Created attachment 138423 [details] Admit "/" as valid in LDAP attribute string
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.
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
(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
(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
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.]
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
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.