Bug 205997
|
Description
Horst H. von Brand
2006-09-11 12:57:36 UTC
(In reply to comment #0) > Steps to Reproduce: > 1. $HOME automounted via LDAP map, try entering $HOME What do you mean $HOME? Does $HOME actually have a value. > > Actual results: > Not mounted, /home doesn't exist. mount(1) shows nothing automounted. What's in your map? Can you post it pleae. Also post /etc/nsswitch.conf. Ian Created attachment 135989 [details]
/etc/auto.master
Created attachment 135990 [details]
/etc/nsswitch.conf
Created attachment 135991 [details]
/etc/sysconfig/autofs
(In reply to comment #1) > > > > Actual results: > > Not mounted, /home doesn't exist. mount(1) shows nothing automounted. > > What's in your map? > Can you post it pleae. > > Also post /etc/nsswitch.conf. Mmm .. they all look fine. How about postintg the LDAP master map please. And the debug log. Ian > > Ian > Still waiting for LDAP auto.master map? I'm not sure if this is an LDAP problem at all. If I try to access an NFS server via /net (standard autofs configuration files), it lets me see the path up to the mount point, when I access that, I get "No such file or directory", i.e. the NFS server is "nsl01a", the exported mount point is "/vol/linuxlab". I can do "ls /net/nsl01a" and "ls /net/nsl01a/vol" without errors, when I do "ls /net/nsl01a/vol/linuxlab", I get the aformentioned error. When stracing the automount process, I see no activity when I try to access this directory. Needless to say that manually mounting this works ;-). (In reply to comment #7) > If I try to access an NFS server via /net (standard autofs configuration files), > it lets me see the path up to the mount point, when I access that, I get "No > such file or directory", i.e. the NFS server is "nsl01a", the exported mount > point is "/vol/linuxlab". I can do "ls /net/nsl01a" and "ls /net/nsl01a/vol" > without errors, when I do "ls /net/nsl01a/vol/linuxlab", I get the aformentioned > error. When stracing the automount process, I see no activity when I try to > access this directory. Needless to say that manually mounting this works ;-). You logged this against a Rawhide install but what kernel is on the box? We need a debug log. Ensure that syslog is ending daemon.* to somewhere and add "--debug" to the OPTIONS variable in /etc/sysconfig/autofs. Also I'd be interested to know what happens if you change the /etc/auto.net to -hosts in your auto.master. Ian (In reply to comment #8) > (In reply to comment #7) > > If I try to access an NFS server via /net (standard autofs configuration files), > > it lets me see the path up to the mount point, when I access that, I get "No > > such file or directory", i.e. the NFS server is "nsl01a", the exported mount > > point is "/vol/linuxlab". I can do "ls /net/nsl01a" and "ls /net/nsl01a/vol" > > without errors, when I do "ls /net/nsl01a/vol/linuxlab", I get the aformentioned > > error. When stracing the automount process, I see no activity when I try to > > access this directory. Needless to say that manually mounting this works ;-). > > You logged this against a Rawhide install but what kernel > is on the box? > > We need a debug log. > Ensure that syslog is ending daemon.* to somewhere and add > "--debug" to the OPTIONS variable in /etc/sysconfig/autofs. > > Also I'd be interested to know what happens if you change the > /etc/auto.net to -hosts in your auto.master. I've just had a look at the latest Rawhide kernel and I see there's a patch set included that causes a problem I need to fix. I've been thinking about how I should go about this for a couple of weeks now but, while on the face of it it seems like a simple problem to fix, it's not. Perhaps David will be able to help out a little along the way (please David, if you have time). Ian Can you add the output of "showmount -e nsl01a" to the attachments please? David (In reply to comment #9) > > I've just had a look at the latest Rawhide kernel and I see > there's a patch set included that causes a problem I need to > fix. Seems I was mistaken. The problem I was refering to doesn't seem to be present in 2.6.17-1.2647 so what you are seeing must have a different cause. What version of nfs-utils do you have? David, did the changes that lead to the "hosts" mount map failing, that we were discussing recently, find their way into a Rawhide kernel yet? Ian Currently the machine is updating, but I'll attach logs e.a. and try to reproduce the error when it's finished. After the update has finished and I restarted autofs, but without rebooting into the new kernel, it worked for me again. Packages that were updated and I think might have contributed to solving the issue are: nfs-utils-1.0.9-7.fc6 glibc-2.4.90-33 (and related) util-linux-2.13-0.42 For me this matter is resolved. Horst, how about you? (In reply to comment #13) [...] > > For me this matter is resolved. Horst, how about you? I crancked at this for a while. The simptoms where cause by 3 issues. 1 - The deafult variable names that automount uses for the LDAP lookup differ with our LDAP tree. This must be modified in '/etc/sysconfig/autofs'. Basicaly you have to uncomment the alternat LDAP names. DEFAULT_MAP_OBJECT_CLASS="automountMap" DEFAULT_ENTRY_OBJECT_CLASS="automount" DEFAULT_MAP_ATTRIBUTE="ou" DEFAULT_ENTRY_ATTRIBUTE="cn" DEFAULT_VALUE_ATTRIBUTE="automountInformation" 2- The indirect mount schema auto.home belonged to the organizationalUnit class, but automount expexted it to be automount (this had to be modified in the server). should look like this: dn: ou=auto.home,ou=foo,c=bar objectClass: top objectClass: automountMap ou: auto.home 3- The auto.master /home entre had the old automountInformation format. And it seems that automount simply does not like it. Originaly it was like this: automountInformation: ldap:192.168.0.23:ou=auto.home,ou=foo,c=bar it does not work. It should look like this. dn: cn=/home,ou=auto.master,ou=foo,c=bar objectClass: automount objectClass: top cn: /home automountInformation: auto.home <----- here is the big diference. The question now is, does automount 4.x or others that ship with RHEL based distribution work with this new scheme??? I think not, but have no had thetime to test it. I think this is a bug. automount 5 should provide backward compatibility for the old format. (In reply to comment #14) > (In reply to comment #13) > [...] > > > > For me this matter is resolved. Horst, how about you? > > I crancked at this for a while. The simptoms where cause by 3 issues. > 1 - > The deafult variable names that automount uses for the LDAP lookup differ with > our LDAP tree. This must be modified in '/etc/sysconfig/autofs'. Basicaly you > have to uncomment the alternat LDAP names. > > DEFAULT_MAP_OBJECT_CLASS="automountMap" > DEFAULT_ENTRY_OBJECT_CLASS="automount" > DEFAULT_MAP_ATTRIBUTE="ou" > DEFAULT_ENTRY_ATTRIBUTE="cn" > DEFAULT_VALUE_ATTRIBUTE="automountInformation" That's what these entries are for. > > 2- > The indirect mount schema auto.home belonged to the organizationalUnit class, > but automount expexted it to be automount (this had to be modified in the > server). should look like this: > dn: ou=auto.home,ou=foo,c=bar > objectClass: top > objectClass: automountMap > ou: auto.home If you've created maps that aren't quite what they should be because version 4 allowed you to get away with it you should still be able to alter the schema attributes above to match instead of altering the server. > > 3- > The auto.master /home entre had the old automountInformation format. And it > seems that automount simply does not like it. Originaly it was like this: > automountInformation: ldap:192.168.0.23:ou=auto.home,ou=foo,c=bar > it does not work. It should look like this. > dn: cn=/home,ou=auto.master,ou=foo,c=bar > objectClass: automount > objectClass: top > cn: /home > automountInformation: auto.home <----- here is the big diference. > > The question now is, does automount 4.x or others that ship with RHEL based > distribution work with this new scheme??? I think not, but have no had thetime > to test it. > > I think this is a bug. automount 5 should provide backward compatibility for the > old format. Yes. That automountInformation entry should work. How about providing a debug log. Ian Created attachment 138486 [details]
an autofs debug log where it works.
A woking automount log where the variable(entry)
automountInformation: auto.home
Created attachment 138487 [details]
an autofs debug log where it does not work works.
a not working autofs log where the entry
automountInformation: ldap://ldap.foo.bar/ou=auto.home,ou=foo,c=bar
(In reply to comment #17) > Created an attachment (id=138487) [edit] > an autofs debug log where it does not work works. > > a not working autofs log where the entry > automountInformation: ldap://ldap.foo.bar/ou=auto.home,ou=foo,c=bar > Looks like it should work but the master map parser has clearly got it wrong. I'll work on it. Ian (In reply to comment #18) > (In reply to comment #17) > > Created an attachment (id=138487) [edit] [edit] > > an autofs debug log where it does not work works. > > > > a not working autofs log where the entry > > automountInformation: ldap://ldap.foo.bar/ou=auto.home,ou=foo,c=bar > > > > Looks like it should work but the master map parser has > clearly got it wrong. I'll work on it. > It also chokes up on the old format: automountInformation: ldap:ldap.foo.bar:ou=auto.home,ou=foo,c=bar The debug output is exactly the same. Nico (In reply to comment #19) > (In reply to comment #18) > > (In reply to comment #17) > > > > Looks like it should work but the master map parser has > > clearly got it wrong. I'll work on it. > > > > It also chokes up on the old format: > automountInformation: ldap:ldap.foo.bar:ou=auto.home,ou=foo,c=bar > > The debug output is exactly the same. Yep. I'll deal with that also. Ian (In reply to comment #20) Thanks for your effort on this problem. I've been able to duplicate it and fix it, I think. > (In reply to comment #19) > > (In reply to comment #18) > > > (In reply to comment #17) > > > > > > Looks like it should work but the master map parser has > > > clearly got it wrong. I'll work on it. > > > > > > > It also chokes up on the old format: > > automountInformation: ldap:ldap.foo.bar:ou=auto.home,ou=foo,c=bar I think that this is an assumption that's wrong. This format works fine for me. However, the master map tokenizer wasn't admitting numeric hostnames in the LDAP map spec. and I've fixed that. > > > > The debug output is exactly the same. Are you sure? > > Yep. > I'll deal with that also. Try the patch below and let me know how it goes. Ian Created attachment 138558 [details]
Patch to admit numeric host names in LDAP map spec.
I aplied the patch but the problem is still present: automount[15632]: do_connect: lookup(ldap): ldap anonymous bind returned 0 automount[15632]: lookup_read_master: lookup(ldap): searching for "(objectclass=automount)" under "ou=auto.master,ou=foo,c=bar" automount[15632]: lookup_read_master: lookup(ldap): examining entries automount[15632]: master_error: syntax error while parsing map. automount[15632]: unbind_ldap_connection: use_tls: 0 I tested with both old format (above error) and the new format (error below) automount[15882]: lookup_read_master: lookup(ldap): searching for "(objectclass=automount)" under "ou=auto.master,ou=foo,c=bar" automount[15882]: lookup_read_master: lookup(ldap): examining entries automount[15882]: master_echo: / automount[15882]: master_echo: / automount[15882]: master_error: syntax error while parsing map. when he wants to read dn: cn=/home,ou=auto.master,ou=foo,c=bar ObjectClass: automount ObjectClass: top automountInformation: auto.home cn:/home everything is ok if the format is the one above. But it wont work if automountInformation: is either ldap:ldap.foo.bar:ou=auto.home,ou=foo,c=bar or ldap://ldap.foo.bar/ou=auto.home,ou=foo,c=bar nico (In reply to comment #23) > I aplied the patch but the problem is still present: > > automount[15632]: do_connect: lookup(ldap): ldap anonymous bind returned 0 > automount[15632]: lookup_read_master: lookup(ldap): searching for > "(objectclass=automount)" under "ou=auto.master,ou=foo,c=bar" > automount[15632]: lookup_read_master: lookup(ldap): examining entries > automount[15632]: master_error: syntax error while parsing map. > automount[15632]: unbind_ldap_connection: use_tls: 0 > > I tested with both old format (above error) and the new format (error below) > > automount[15882]: lookup_read_master: lookup(ldap): searching for > "(objectclass=automount)" under "ou=auto.master,ou=foo,c=bar" > automount[15882]: lookup_read_master: lookup(ldap): examining entries > automount[15882]: master_echo: / > automount[15882]: master_echo: / > automount[15882]: master_error: syntax error while parsing map. Are you sure the patch applied cleanly? That's exactly what I would expect to see if the patch wasn't applied cleanly. > > when he wants to read > dn: cn=/home,ou=auto.master,ou=foo,c=bar > ObjectClass: automount > ObjectClass: top > automountInformation: auto.home > cn:/home > > everything is ok if the format is the one above. But it wont work if > automountInformation: is either ldap:ldap.foo.bar:ou=auto.home,ou=foo,c=bar or > ldap://ldap.foo.bar/ou=auto.home,ou=foo,c=bar Why do you leave out the other bits of the log. Post the full log. Ian What is the LDAP schema that you are using? (In reply to comment #25) > What is the LDAP schema that you are using? And you'll need to post your /etc/auto.master and your LDAP master map entry. (In reply to comment #26) > (In reply to comment #25) > > What is the LDAP schema that you are using? > > And you'll need to post your /etc/auto.master and your LDAP > master map entry. > I've tried again to make this fail in the way you describe without success. It all works fine for me. Clearly I'm missing something about the way LDAP is setup at your site and I need to understand that to work out exactly what is going wrong here otherwise I won't be able to fix it. We have jumped back and forth at bit and I'm not sure what your complete setup is anymore so, please go through it again, from top to bottom. Ian so I can understand it. (In reply to comment #27) > > so I can understand it. Tell you what, I'll tell you what I have setup and you can tell me where I'm wrong. In /etc/sysconfig/autofs I have enabled the schema: DEFAULT_MAP_OBJECT_CLASS="automountMap" DEFAULT_ENTRY_OBJECT_CLASS="automount" DEFAULT_MAP_ATTRIBUTE="ou" DEFAULT_ENTRY_ATTRIBUTE="cn" DEFAULT_VALUE_ATTRIBUTE="automountInformation" and I have a line "+auto.master" in /etc/auto.master. I also have the entry "automount: files ldap" in /etc/nsswitch.conf. The LDAP entries I have are: # auto.master, themaw.net dn: ou=auto.master,dc=themaw,dc=net objectClass: top objectClass: automountMap ou: auto.master # /ldap, auto.master, themaw.net dn: cn=/ldap,ou=auto.master,dc=themaw,dc=net objectClass: automount cn: /ldap automountInformation: ldap://ldap.themaw.net/ou=auto.indirect,dc=themaw,dc=net # /-, auto.master, themaw.net dn: cn=/-,ou=auto.master,dc=themaw,dc=net objectClass: automount cn: /- automountInformation: ldap://ldap.themaw.net/ou=auto.direct,dc=themaw,dc=net # auto.indirect, themaw.net dn: ou=auto.indirect,dc=themaw,dc=net objectClass: top objectClass: automountMap ou: auto.indirect # bin, auto.indirect, themaw.net dn: cn=bin,ou=auto.indirect,dc=themaw,dc=net objectClass: automount cn: bin automountInformation: budgie:/usr/local/bin # etc, auto.indirect, themaw.net dn: cn=etc,ou=auto.indirect,dc=themaw,dc=net objectClass: automount cn: etc automountInformation: budgie:/usr/local/etc # lib, auto.indirect, themaw.net dn: cn=lib,ou=auto.indirect,dc=themaw,dc=net objectClass: automount cn: lib automountInformation: budgie:/usr/local/lib # /, auto.indirect, themaw.net dn: cn=/,ou=auto.indirect,dc=themaw,dc=net objectClass: automount cn: / automountInformation: budgie:/usr/local/& # auto.direct, themaw.net dn: ou=auto.direct,dc=themaw,dc=net objectClass: top objectClass: automountMap ou: auto.direct # /nfs/budgie/man, auto.direct, themaw.net dn: cn=/nfs/budgie/man,ou=auto.direct,dc=themaw,dc=net objectClass: automount cn: /nfs/budgie/man automountInformation: budgie:/usr/local/man # /nfs/budgie/bin, auto.direct, themaw.net dn: cn=/nfs/budgie/bin,ou=auto.direct,dc=themaw,dc=net objectClass: automount cn: /nfs/budgie/bin automountInformation: budgie:/local/data/bin # /nfs/budgie/etc, auto.direct, themaw.net dn: cn=/nfs/budgie/etc,ou=auto.direct,dc=themaw,dc=net objectClass: automount cn: /nfs/budgie/etc automountInformation: budgie:/usr/local/etc # /nfs/sbin, auto.direct, themaw.net dn: cn=/nfs/sbin,ou=auto.direct,dc=themaw,dc=net objectClass: automount cn: /nfs/sbin automountInformation: budgie:/usr/local/sbin # /tst/budgie/man, auto.direct, themaw.net dn: cn=/tst/budgie/man,ou=auto.direct,dc=themaw,dc=net objectClass: automount cn: /tst/budgie/man automountInformation: budgie:/usr/local/man # /nfs/budgie/sbin, auto.direct, themaw.net dn: cn=/nfs/budgie/sbin,ou=auto.direct,dc=themaw,dc=net objectClass: automount cn: /nfs/budgie/sbin automountInformation: budgie:/usr/local/sbin # /nfs/budgie/test, auto.direct, themaw.net dn: cn=/nfs/budgie/test,ou=auto.direct,dc=themaw,dc=net objectClass: automount cn: /nfs/budgie/test automountInformation: budgie:/usr/local/test # /tst/budgie/etc, auto.direct, themaw.net dn: cn=/tst/budgie/etc,ou=auto.direct,dc=themaw,dc=net objectClass: automount cn: /tst/budgie/etc automountInformation: budgie:/usr/local/etc and this all works fine for me. Where have I gone wrong? Ian Created attachment 138581 [details]
Debug log from test of above schema
Created attachment 138624 [details]
mastermap.ldiff
LDAP master map.
(In reply to comment #28) > (In reply to comment #27) > > > > so I can understand it. > > Tell you what, I'll tell you what I have setup and you can > tell me where I'm wrong. > > In /etc/sysconfig/autofs I have enabled the schema: > [...] OK > > and I have a line "+auto.master" in /etc/auto.master. > I also have the entry "automount: files ldap" in > /etc/nsswitch.conf. OK > The LDAP entries I have are: > > # auto.master, themaw.net > dn: ou=auto.master,dc=themaw,dc=net OK > # /ldap, auto.master, themaw.net > dn: cn=/ldap,ou=auto.master,dc=themaw,dc=net > objectClass: automount > cn: /ldap > automountInformation: ldap://ldap.themaw.net/ou=auto.indirect,dc=themaw,dc=net The only difference is that our also belongs to the objectClass: top. > # /-, auto.master, themaw.net not present in our map > # auto.indirect, themaw.net > dn: ou=auto.indirect,dc=themaw,dc=net ok. > # bin, auto.indirect, themaw.net > dn: cn=bin,ou=auto.indirect,dc=themaw,dc=net The indirect entries are OK. We have no direct entries. nico Created attachment 138627 [details] rpmbuild -bp autofs.spec This is the prep log. Pacth 13 is the proposed in attachment https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138558 aparrently the package was patch and built correctly. Though i had to scrub the CHANGELOG diff, it would get rejected otherways. (im building against the last available src.rpm from development. (In reply to comment #32) > aparrently the package was patch and built correctly. Though i had to scrub the > CHANGELOG diff, it would get rejected otherways. (im building against the last > available src.rpm from development. Sorry, my mistake. There are other patches prior to this. They aren't to this part of the code so shouldn't be a problem. (In reply to comment #32) > Created an attachment (id=138627) [edit] > rpmbuild -bp autofs.spec > > This is the prep log. Pacth 13 is the proposed in attachment > https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=138558 > > aparrently the package was patch and built correctly. Though i had to scrub the > CHANGELOG diff, it would get rejected otherways. (im building against the last > available src.rpm from development. I've just updated my Rawhide instance then built autofs revision 0.rc2.10 with the patch here (less the CHANGELOG of course) and installed. This should be exactly what you're doing as far as I can tell. Once again I'm not able to break autofs with the LDAP map I posted above. There must be something differnet between the setups but I just can't work out what it is. Ian Created attachment 138716 [details]
LDAP map for a schema that reproduces the error
This schema reproduces the error.
Created attachment 138719 [details]
Log file for autofs when mounting the nonworking schema
Created attachment 138720 [details]
Control LDAP map. (it works)
This is my control map. Is the one posted by Ian. Everything went peaches with
this map.
I tried to setup the same environment as Ian's. Everything went ok with his schema. Then I tried my schema and the parse error reapeared. The only sifnifican structural diference is that in my schema the auto.master is under an organizationalUnit Class, and in Ian' shcema is directly under the base dn. nico (In reply to comment #38) > I tried to setup the same environment as Ian's. Everything went ok with his > schema. Then I tried my schema and the parse error reapeared. > The only sifnifican structural diference is that in my schema the auto.master is > under an organizationalUnit Class, and in Ian' shcema is directly under the base dn. I was able to get this to fail also when creating the map under the bas dn. I thought I'd fixed this a while ago but I missed an instance where the search was onelevel and not subtree. However, I get different error messages which concerns me a little so check the logs below and try the patch and we'll see what happens. Ian Created attachment 138744 [details]
Log output from failed subtree schema
Created attachment 138746 [details]
Log output from subtree schema with subtree search patch
Created attachment 138747 [details]
Patch to fix missed subtree search when getting basedn
Please give this patch a try.
(In reply to comment #40) > Created an attachment (id=138744) [edit] > Log output from failed subtree schema > I had this same output when my indirect mount auto.home belonged to the wrong class. If it does not belong to the automountMap the ldap query fails. nico (In reply to comment #42) > Created an attachment (id=138747) [edit] > Patch to fix missed subtree search when getting basedn > > Please give this patch a try. The problem is still present. The error is the same as the before. Parse Error. nico (In reply to comment #43) > (In reply to comment #40) > > Created an attachment (id=138744) [edit] [edit] > > Log output from failed subtree schema > > > > I had this same output when my indirect mount auto.home belonged to the wrong > class. If it does not belong to the automountMap the ldap query fails. But that's not the case with the map we are using here. And it worked fine one I searched the subtree. Ian (In reply to comment #44) > (In reply to comment #42) > > Created an attachment (id=138747) [edit] [edit] > > Patch to fix missed subtree search when getting basedn > > > > Please give this patch a try. > > The problem is still present. The error is the same as the before. Parse Error. Gettin kinda hard this one. How about we see what we get from the patch below. Ian Created attachment 138771 [details]
Lets see what were passing to bison
Created attachment 138808 [details]
autofs log with the verbose patch aplied
This is the extra verbose log for the LDAP map that produces the error.
(In reply to comment #47) > Created an attachment (id=138771) [edit] > Lets see what were passing to bison > The patch has a typo. Easy fix though. :) Created attachment 138811 [details]
Patch to set debug for parse module
This is getting hard.
Apply this one and send the output of the failed parse.
Created attachment 138815 [details]
Parse debug File
Parse Debug file for autofs
(In reply to comment #51) > Created an attachment (id=138815) [edit] > Parse debug File > > Parse Debug file for autofs Oh no ... how stupid of me! I don't admit o or c as valid attributes. I need to put a little more structure around this parse. I get a patch to you fairly soon. Ian Created attachment 138853 [details]
Patch to allow additional common LDAP attributes in map dn
* Sigh *
Can you try this patch please.
That last pacth fix the issues. And autofs mounts cleanly the sample schema. But when It tested it against the production ldap server it complained about not finding tha automountMap. I dug into this and found that our production server auto.home belongs to the "organizationalUnit" class instead of the "automountMap" class. Autofs 4 lets us ge away with this. Is this an issue or just autofs 5 being more picky about the ldap schema? I just tested autofs 4 against the test schema and works cleanly. So it seems that autofs 4 is forward compatible, but autofs 5 is not backward compatible in that sense. nico (In reply to comment #55) > I just tested autofs 4 against the test schema and works cleanly. So it seems At last, phew. > that autofs 4 is forward compatible, but autofs 5 is not backward compatible in > that sense. The map shouldn't belong to the "organizationalUnit" class. That was a misunderstanding from the start. But as I mentioned earlier you should be able to change: DEFAULT_MAP_OBJECT_CLASS="automountMap" to DEFAULT_MAP_OBJECT_CLASS="organizationalUnit" as long as the stuff in LDAP is consistent. Same goes for DEFAULT_ENTRY_OBJECT_CLASS. However, the attribute names are validated against the known schema attributes so you can't do somthing like change "automountMapName" to "dc" for the (first) attribute which names the map. Also, only the attribute names in the schema and the others we discussed here (o and c) are admitted by the lexical analyser so they can't be arbitrary either. Ian (In reply to comment #56) [...] > > The map shouldn't belong to the "organizationalUnit" class. > That was a misunderstanding from the start. But as I mentioned > earlier you should be able to change: > > DEFAULT_MAP_OBJECT_CLASS="automountMap" > to > DEFAULT_MAP_OBJECT_CLASS="organizationalUnit" > > as long as the stuff in LDAP is consistent. I agree. Our map is inconsistent, and should be fixed. The map was fixed in our testing ldap server and i can re-confirm that the patch works. And that the modifications to the map dont break the funtionality or older version of automount (the ones shiped in fedora 5 and RHEL 4). nico autofs-5.0.1-0.rc2.17 has been pushed for fc6, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report. |