Bug 205997 - autofs doesn't mount $HOME described in LDAP
autofs doesn't mount $HOME described in LDAP
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
rawhide
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Ian Kent
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-11 08:57 EDT by Horst H. von Brand
Modified: 2007-11-30 17:11 EST (History)
7 users (show)

See Also:
Fixed In Version: autofs-5.0.1-0.rc2.16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-19 22:29:01 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)
/etc/auto.master (626 bytes, text/plain)
2006-09-11 09:42 EDT, Horst H. von Brand
no flags Details
/etc/nsswitch.conf (1.68 KB, text/plain)
2006-09-11 09:43 EDT, Horst H. von Brand
no flags Details
/etc/sysconfig/autofs (1.39 KB, text/plain)
2006-09-11 09:44 EDT, Horst H. von Brand
no flags Details
an autofs debug log where it works. (4.52 KB, text/plain)
2006-10-14 00:05 EDT, Nicolas Troncoso Carrere
no flags Details
an autofs debug log where it does not work works. (3.10 KB, text/plain)
2006-10-14 00:07 EDT, Nicolas Troncoso Carrere
no flags Details
Patch to admit numeric host names in LDAP map spec. (959 bytes, patch)
2006-10-16 04:38 EDT, Ian Kent
no flags Details | Diff
Debug log from test of above schema (11.39 KB, text/plain)
2006-10-16 11:00 EDT, Ian Kent
no flags Details
mastermap.ldiff (462 bytes, application/octet-stream)
2006-10-16 17:23 EDT, Nicolas Troncoso Carrere
no flags Details
rpmbuild -bp autofs.spec (2.45 KB, text/plain)
2006-10-16 17:47 EDT, Nicolas Troncoso Carrere
no flags Details
LDAP map for a schema that reproduces the error (3.08 KB, application/octet-stream)
2006-10-17 16:20 EDT, Nicolas Troncoso Carrere
no flags Details
Log file for autofs when mounting the nonworking schema (3.22 KB, text/plain)
2006-10-17 16:22 EDT, Nicolas Troncoso Carrere
no flags Details
Control LDAP map. (it works) (2.93 KB, application/octet-stream)
2006-10-17 16:25 EDT, Nicolas Troncoso Carrere
no flags Details
Log output from failed subtree schema (1.84 KB, application/octet-stream)
2006-10-18 00:13 EDT, Ian Kent
no flags Details
Log output from subtree schema with subtree search patch (7.94 KB, application/octet-stream)
2006-10-18 00:15 EDT, Ian Kent
no flags Details
Patch to fix missed subtree search when getting basedn (414 bytes, patch)
2006-10-18 00:18 EDT, Ian Kent
no flags Details | Diff
Lets see what were passing to bison (608 bytes, patch)
2006-10-18 06:44 EDT, Ian Kent
no flags Details | Diff
autofs log with the verbose patch aplied (7.31 KB, text/plain)
2006-10-18 12:55 EDT, Nicolas Troncoso Carrere
no flags Details
Patch to set debug for parse module (288 bytes, patch)
2006-10-18 13:59 EDT, Ian Kent
no flags Details | Diff
Parse debug File (28.46 KB, text/plain)
2006-10-18 14:20 EDT, Nicolas Troncoso Carrere
no flags Details
Patch to allow additional common LDAP attributes in map dn (2.76 KB, patch)
2006-10-19 00:04 EDT, Ian Kent
no flags Details | Diff

  None (edit)
Description Horst H. von Brand 2006-09-11 08:57:36 EDT
Description of problem:
The LDAP server is on CentOS 4.4, containing the description of the accounts.
autofs claims the map has a syntax error, and doesn't mount any accounts. NFS
works (autofs mounts just fine via /net). Downgrading to the autofs from FC5
fixes this.

Version-Release number of selected component (if applicable):
autofs-5.0.1-0.rc2.1

How reproducible:
Always

Steps to Reproduce:
1. $HOME automounted via LDAP map, try entering $HOME
2.
3.
  
Actual results:
Not mounted, /home doesn't exist. mount(1) shows nothing automounted.

Expected results:
Access to $HOME

Additional info:
Comment 1 Ian Kent 2006-09-11 09:15:52 EDT
(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
Comment 2 Horst H. von Brand 2006-09-11 09:42:49 EDT
Created attachment 135989 [details]
/etc/auto.master
Comment 3 Horst H. von Brand 2006-09-11 09:43:45 EDT
Created attachment 135990 [details]
/etc/nsswitch.conf
Comment 4 Horst H. von Brand 2006-09-11 09:44:39 EDT
Created attachment 135991 [details]
/etc/sysconfig/autofs
Comment 5 Ian Kent 2006-09-11 10:25:30 EDT
(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
> 

Comment 6 Ian Kent 2006-09-18 06:52:06 EDT
Still waiting for LDAP auto.master map?
Comment 7 Nils Philippsen 2006-09-20 11:29:54 EDT
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 ;-).
Comment 8 Ian Kent 2006-09-20 11:54:52 EDT
(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
Comment 9 Ian Kent 2006-09-20 12:29:05 EDT
(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
Comment 10 David Howells 2006-09-20 12:53:49 EDT
Can you add the output of "showmount -e nsl01a" to the attachments please?

David
Comment 11 Ian Kent 2006-09-21 09:20:53 EDT
(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
Comment 12 Nils Philippsen 2006-09-22 08:45:22 EDT
Currently the machine is updating, but I'll attach logs e.a. and try to
reproduce the error when it's finished.
Comment 13 Nils Philippsen 2006-09-22 11:46:47 EDT
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?
Comment 14 Nicolas Troncoso Carrere 2006-10-13 22:37:08 EDT
(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. 
Comment 15 Ian Kent 2006-10-13 23:01:47 EDT
(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
Comment 16 Nicolas Troncoso Carrere 2006-10-14 00:05:28 EDT
Created attachment 138486 [details]
an autofs debug log where it works.

A woking automount log where the variable(entry)
automountInformation: auto.home
Comment 17 Nicolas Troncoso Carrere 2006-10-14 00:07:10 EDT
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
Comment 18 Ian Kent 2006-10-15 12:20:55 EDT
(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
Comment 19 Nicolas Troncoso Carrere 2006-10-15 16:13:30 EDT
(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
Comment 20 Ian Kent 2006-10-15 21:44:00 EDT
(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
Comment 21 Ian Kent 2006-10-16 04:37:14 EDT
(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
Comment 22 Ian Kent 2006-10-16 04:38:59 EDT
Created attachment 138558 [details]
Patch to admit numeric host names in LDAP map spec.
Comment 23 Nicolas Troncoso Carrere 2006-10-16 08:10:44 EDT
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
Comment 24 Ian Kent 2006-10-16 09:34:44 EDT
(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
Comment 25 Ian Kent 2006-10-16 09:38:05 EDT
What is the LDAP schema that you are using?
Comment 26 Ian Kent 2006-10-16 09:51:43 EDT
(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.
Comment 27 Ian Kent 2006-10-16 10:13:34 EDT
(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.

Comment 28 Ian Kent 2006-10-16 10:56:33 EDT
(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

Comment 29 Ian Kent 2006-10-16 11:00:25 EDT
Created attachment 138581 [details]
Debug log from test of above schema
Comment 30 Nicolas Troncoso Carrere 2006-10-16 17:23:50 EDT
Created attachment 138624 [details]
mastermap.ldiff

LDAP master map.
Comment 31 Nicolas Troncoso Carrere 2006-10-16 17:29:37 EDT
(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
Comment 32 Nicolas Troncoso Carrere 2006-10-16 17:47:54 EDT
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.
Comment 33 Ian Kent 2006-10-16 21:18:23 EDT
(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.

Comment 34 Ian Kent 2006-10-17 03:24:39 EDT
(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
Comment 35 Nicolas Troncoso Carrere 2006-10-17 16:20:10 EDT
Created attachment 138716 [details]
LDAP map for a schema that reproduces the error

This schema reproduces the error.
Comment 36 Nicolas Troncoso Carrere 2006-10-17 16:22:31 EDT
Created attachment 138719 [details]
Log file for autofs when mounting the nonworking schema
Comment 37 Nicolas Troncoso Carrere 2006-10-17 16:25:35 EDT
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.
Comment 38 Nicolas Troncoso Carrere 2006-10-17 16:29:00 EDT
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
Comment 39 Ian Kent 2006-10-18 00:10:12 EDT
(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

Comment 40 Ian Kent 2006-10-18 00:13:12 EDT
Created attachment 138744 [details]
Log output from failed subtree schema
Comment 41 Ian Kent 2006-10-18 00:15:51 EDT
Created attachment 138746 [details]
Log output from subtree schema with subtree search patch
Comment 42 Ian Kent 2006-10-18 00:18:16 EDT
Created attachment 138747 [details]
Patch to fix missed subtree search when getting basedn 

Please give this patch a try.
Comment 43 Nicolas Troncoso Carrere 2006-10-18 00:32:29 EDT
(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
Comment 44 Nicolas Troncoso Carrere 2006-10-18 00:44:57 EDT
(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
Comment 45 Ian Kent 2006-10-18 04:55:56 EDT
(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

Comment 46 Ian Kent 2006-10-18 06:41:05 EDT
(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
Comment 47 Ian Kent 2006-10-18 06:44:01 EDT
Created attachment 138771 [details]
Lets see what were passing to bison
Comment 48 Nicolas Troncoso Carrere 2006-10-18 12:55:48 EDT
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.
Comment 49 Nicolas Troncoso Carrere 2006-10-18 12:57:04 EDT
(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. :)
Comment 50 Ian Kent 2006-10-18 13:59:50 EDT
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.
Comment 51 Nicolas Troncoso Carrere 2006-10-18 14:20:43 EDT
Created attachment 138815 [details]
Parse debug File

Parse Debug file for autofs
Comment 52 Ian Kent 2006-10-18 14:32:02 EDT
(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
Comment 53 Ian Kent 2006-10-19 00:04:09 EDT
Created attachment 138853 [details]
Patch to allow additional common LDAP attributes in map dn

* Sigh *

Can you try this patch please.
Comment 54 Nicolas Troncoso Carrere 2006-10-19 14:11:23 EDT
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?
Comment 55 Nicolas Troncoso Carrere 2006-10-19 14:16:05 EDT
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
Comment 56 Ian Kent 2006-10-19 14:39:23 EDT
(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
Comment 57 Nicolas Troncoso Carrere 2006-10-19 17:20:50 EDT
(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
Comment 58 Fedora Update System 2006-10-24 16:18:41 EDT
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.

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