Bug 575863

Same here. I'd raise the severity if I could (although there is a quick workaround).

The problem is that the lexer file recognizes your line as the following sequence:

PATH
DNSERVER
DNNAME
OPTION
COMMA
OPTION

while it should be:

PATH
MAPTYPE
COLON
MAPNAME
OPTION
COMMA
OPTION

(see forthcoming attachment)

Quick fix for you (and me):

replace yp by e.g. yp,sun ; this will prevent the wrong dn match. Alternatively, you may put a space after the column.

Fix for autofs: I don't know / don't wanna know.

Created attachment 401871 [details]
standalone tokenizer extracted from autofs-5.0.5-22.fc12

This illustrates the problem. It's a trimmed down and bastardized version of master_tok.l and just prints the token list:

/tmp $ flex a.l         
/tmp $ gcc lex.yy.c -lfl
/tmp $ ./a.out /etc/auto.master
(prints the tokens)

(In reply to comment #1)
> Same here. I'd raise the severity if I could (although there is a quick
> workaround).
> 
> The problem is that the lexer file recognizes your line as the following
> sequence:

Yeah, it's the change that allows the LDAP location attribute
("l") that has caused this, sorry. It's not specific enough. I
was afraid I'd get caught with something like this, but I didn't
see any problems when I tested it. I obviously didn't check this.

snip ...

> 
> Quick fix for you (and me):
> 
> replace yp by e.g. yp,sun ; this will prevent the wrong dn match.
> Alternatively, you may put a space after the column.

Yep, that should work, or you can use nsswitch to tell
autofs what map sources you are using and leave out the
"yp:" altogether. Although you can get caught when a map
is present in multiple sources, such as when you have
"automount: files nis" in nsswitch.conf and your map
exists in /etc and in NIS. In this case the file map
would (well should) be used instead of NIS.

> 
> Fix for autofs: I don't know / don't wanna know.    

Hahaha, yeah, working on it.

Created attachment 401915 [details]
Patch - add locality as valid ldap master map attribute fix

I believe this fixes the problem.

While it's unfortunate you have been inconvenienced by this
it looks like the bug has been present for some time and the
locality change just exposed it.

autofs-5.0.5-23.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/autofs-5.0.5-23.fc12

A build which includes the patch in comment #4 has been done
and I have requested it be pushed to the testing repository.

The build may also be found at:
http://kojipkgs.fedoraproject.org/packages/autofs/5.0.5/23.fc12

Please test this new build and report back.

(In reply to comment #6)
> A build which includes the patch in comment #4 has been done
> and I have requested it be pushed to the testing repository.
> 
> The build may also be found at:
> http://kojipkgs.fedoraproject.org/packages/autofs/5.0.5/23.fc12
> 
> Please test this new build and report back.    

works here. thanks.

E.

Works for me(In reply to comment #7)
> > The build may also be found at:
> > http://kojipkgs.fedoraproject.org/packages/autofs/5.0.5/23.fc12
> > 
> > Please test this new build and report back.    
> 
> works here. thanks.
> 

Works for me as well

autofs-5.0.5-23.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update autofs'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/autofs-5.0.5-23.fc12

autofs-5.0.5-23.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/autofs-5.0.5-23.fc13

autofs-5.0.5-23.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

autofs-5.0.5-23.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.