(In reply to comment #0)
> The maps:
> 
> auto.master fragment
> 
> .namnt/netapps  /etc/auto.netapps       --timeout=600   ro,intr,hard

Do you mean /.namnt/netapps ?

> 
> auto.netapps
> 
> .mnt -rw \
>         / server:/usr/netapps/Linux./.mnt  \
>         /apps01 server:/export/apps/apps01 \

Do the directories such as /export/apps/apps01 always exist
on the server?

Could I have a debug log please?
Directions on how to produce one can be found at
http://people.redhat.com/jmoyer.

Ian

(In reply to comment #1)
> (In reply to comment #0)
> > The maps:
> > 
> > auto.master fragment
> > 
> > .namnt/netapps  /etc/auto.netapps       --timeout=600   ro,intr,hard
> 
> Do you mean /.namnt/netapps ?
> 
> > 
> > auto.netapps
> > 
> > .mnt -rw \
> >         / server:/usr/netapps/Linux./.mnt  \
> >         /apps01 server:/export/apps/apps01 \
> 
> Do the directories such as /export/apps/apps01 always exist
> on the server?

More importantly do the mount point directories such as
/usr/netapps/Linux./.mnt/apps01, etc., exist on the remote
NFS server filesystem?

Ian

Well, /export/apps/apps01, etc., and their descendents exist, of course.

But, I think you are asking, does this work under Solaris (long ago - 9)?  The 
answer is yes, but not in quite the same form, and also under IRIX, AIX, etc., 
at least in the past when we had such clients.  The NIS map for Solaris is a 
direct map:

[root@client ~]# ypcat -k auto.direct
/netapps -rw  /             server:/usr/netapps/$OSNAME.$OSREL \
              /.mnt/apps01  server:/export/apps/apps01 \
...

I've changed the name of the server to match the previous example, and deleted 
umpty lines of the same thing with subtle variations in the names.   

This results in a situation where /netapps/.mnt/apps01 on the server (or a 
Solaris client) contains server:/export/apps/apps01, and /netapps/apps, 
/netapps/bin, /netapps/lib, etc., contains links (mounted with /usr/netapps/
$OSNAME.$OSREL) into ../.mnt/apps01, etc., appropriate for the file in 
question on the $OSNAME.$OSREL platform.  

Direct mounting didn't work in Linux when I first ported this and indirect 
mounting conceals the local file structure under the mount point, hence in 
Linux we indirect mount in /.namnt/netapps and link /netapps to that.  

C. FC3 I had to switch from two separate maps, one to mount /netapps and one 
to mount the apps01, etc., directories under it, to the multiple indirect 
mount scheme presented.  In that approach I mount the subdirectories 
of /usr/netapps/Linux., not the directory itself.  Hence the clause

* -rw   server:/usr/netapps/Linux./&

in /etc/auto.netapps

I realize that a mount within a mount presents certain technical issues.   
It's a legacy situation I wouldn't recommend to anyone for future use.  

=======

On the server (as example of Solaris system):

[108] > ls -laF /netapps/.mnt/apps01
total 183918
drwxr-xr-x  78 root     root        2048 Apr 21  2005 ./
drwxr-xr-x   9 root     other        512 Jul 18  2004 ../
-rwxr-xr-x   1 root     other        498 Dec  6  1999 .findit*
drwxr-sr-x   6 root     root         512 Jul 20  2000 411-3.0/
drwxr-xr-x   2 root     other        512 Jan 13  2005 ActiveTcl/
...
[109] > df
...
/netapps/.mnt/apps01(/export/apps/apps01):24624798 blocks  5698347 files
...

Created attachment 148550 [details]
General background information requested

Created attachment 148552 [details]
/var/log/messages

(In reply to comment #4)
> Created an attachment (id=148550) [edit]
> General background information requested
> 

Not quite what I asked for but reveals an interesting
problem none the less.

The log message:

Feb 21 16:44:49 rye automount[25336]: read_one: lookup(file): bad map entry
"-rw,hard,intr      / jeeves.boulder.nist.gov:/usr/netapps/Linux./.mnt     
/apps01 jeeves.boulder.nist.gov:/export/apps/apps01     /apps02
jeeves.boulder.nist.gov:/export/apps/apps02     /apps03
jeeves.boulder.nist.gov:/export/apps/apps03 \ ..." for key ".mnt"
---------------------------------------------^

This is claiming that there is a space or tab (looks like a space)
following the escape character before the newline, which is illegal.

At first I thought that it was saying that there was white space in
the blank line following the entry which produces a similar message.
This check is meant to catch the problem above and the case where
the "\" is missing within multi-mount entries. Thinking about it
there are a couple of other cases where the handling is questionable.
But that's another issue.

Ian

a) If between comments 3-5 you didn't get what you want, let me know what it 
is was.  I tried to follow the instructions at the link you specified.  

b) Interesting comment on "tabs not legal" in this construction.  The man page 
for auto.master specifies that whitespace may consist of arbitrary number of 
blanks or tabs.   The man page for autofs(5) says nothing except for one 
comment about options being comma-separated.  I remember the bad old days of 
tabs or the absence of tabs in certain places (NIS, make, ...) causing all 
hell to break loose, and shudder to imagine that they are still with us.  
Surely we are beyond these prejudices about what is whitespace and what is 
not?  If in this context we are not, may I submit removal of "tab not allowed" 
as a feature request?   :-)

c) Nevertheless, since code trumps docs any day, I removed all tabs from 
auto.netapps and, for good measure, from auto.master.  I reloaded autofs.  I 
regret to report that the symptoms are the same.   The first of the multiple 
mounts is mounted, the others are not.  Just in case I restarted autofs.  
Still no dice.  

d) But as long as I'm grousing about man pages (and my apologies for that and 
this, which no doubt reflect material inherited from the good old days), 
please note that the autofs(5) man page is remarkably obscure about the 
relationships among the auto.master key, the subordinate map key, and the 
mountpoint field in the case of multiple indirect mounts.  This is a case 
where one example might say volumes.  In any event, it would be nice to know 
if the constructed path is key1 key2 mountpoint or something else, and for at 
least the first and second mounts in the list, in case it is different.  

Thanks for all your time on this issue!

(In reply to comment #7)
> a) If between comments 3-5 you didn't get what you want, let me know what it 
> is was.  I tried to follow the instructions at the link you specified.  

Sorry to sound ungreatful. I'm certainly not.
It's uncommon to have people that are willing to provide
comprehensive information promptly as you have, thanks.

The amount of information is great but what I usually need
most is the debug log in full. It lets me know what isn't broken
and sometimes points me to completely unexpected faults.

The other thing to consider in reading my replies is that it's
essential for me to reproduce the probelm and it's always hard
to get that right. So I take a "one step at a time" approach and
build on each step. I've started building the model and I'm
picking it appart in bits as I go.

> 
> b) Interesting comment on "tabs not legal" in this construction.  The man page 
> for auto.master specifies that whitespace may consist of arbitrary number of 
> blanks or tabs.   The man page for autofs(5) says nothing except for one 
> comment about options being comma-separated.  I remember the bad old days of 
> tabs or the absence of tabs in certain places (NIS, make, ...) causing all 
> hell to break loose, and shudder to imagine that they are still with us.  
> Surely we are beyond these prejudices about what is whitespace and what is 
> not?  If in this context we are not, may I submit removal of "tab not allowed" 
> as a feature request?   :-)

I guess this demonstrates the difficulties of working
through problems when not present first hand.

I wasn't suggesting white space is not allowed.
I was saying is that, looking closely at the map and working
to reproduce the problem, I get that message in the log when
the line continuation has whitespace between the escape and
the newline, which I'm sure you're aware is not allowed.

I also noticed that this check might catch a line
continuation followed by whitespace on the next blank
line, which is not intended and would need to be fixed.

So can you please confirm:
There was no line continuation with embedded white space
in the original map?
There is no white space on the blank line following the map
entry?

> 
> c) Nevertheless, since code trumps docs any day, I removed all tabs from 
> auto.netapps and, for good measure, from auto.master.  I reloaded autofs.  I 
> regret to report that the symptoms are the same.   The first of the multiple 
> mounts is mounted, the others are not.  Just in case I restarted autofs.  
> Still no dice.  

OK, but see above.

So I'm haveing trouble reproducing the problem.
I'll continue trying to set this up and likely I'll have
questions about the bits I'm not clear on as we go.

> 
> d) But as long as I'm grousing about man pages (and my apologies for that and 
> this, which no doubt reflect material inherited from the good old days), 
> please note that the autofs(5) man page is remarkably obscure about the 
> relationships among the auto.master key, the subordinate map key, and the 
> mountpoint field in the case of multiple indirect mounts.  This is a case 
> where one example might say volumes.  In any event, it would be nice to know 
> if the constructed path is key1 key2 mountpoint or something else, and for at 
> least the first and second mounts in the list, in case it is different.  

Good suggestion, but that's another issue.

> 
> Thanks for all your time on this issue!

There's a way to go yet.

Ian

Created attachment 148727 [details]
The log file, in full, intact, since first started.  

After deleting the extra character and possible problem initial characters, I
restarted and retried the mount.  Finally, I rebooted and tried aagin.	 This
file hasn't been adjusted since it was first opened.   

I will send the two maps, too.

Created attachment 148728 [details]
auto.master

Created attachment 148729 [details]
auto.netapps

Created attachment 148898 [details]
Correct file map lexer to accept blank lines with only white space

Could you try this patch please.

It should prevent autofs from reporting an error when blank
lines in the map have (only) white space in them (as yours
does).

Line continuations clearly must be an escaped newline
without any intervening white space, as always. If there
is any space betwwen the escape and the newline then the
entry will be reported as bad.

Ian

I will do that as soon as I figure out how.  The general procedure is obvious, 
of course, but I've never actually done it in Linux before, and not too many 
times or recently in Solaris.  I'm not really a c programmer, just a lowly 
application support person and occasional writer of scripts.  I pipe the diff 
into rpm, right?  I'm kidding, but I really do have to do a little quick 
research on patching procedure.  

By way of an expedient test, I deleted all the blank lines from the 
auto.master and auto.netapps maps and restarted autofs.  (I checked that there 
were no new volunteers after \ in these maps, too, just in case.)  Sure 
enough, that fixed it.  I will let you know if the patch agrees with the text 
editor.  

I also did a quick check of my maps sitation on systems with earlier releases 
of Fedora (all rigorously updated), and the blank lines have been there since 
at least FC4 without causing problems.  I expect the parsing code was 
tightened up recently, catching up with my slapdash non-canonical commenting 
practices.  I definitely appreciate the relaxation of the syntax on my 
behalf.  It's really great to have this working, Ian!  

The very defintiely incorrect tab character after the backslash was a recent 
screw up on my part.  However, I'm thinking of submitting a bug request asking 
for invisible real characters to be displayed with an intermittent twinkling 
effect.   As soon as I figure out where to submit it.  It may require a 
rewrite of the human vision driver.  

OK, with a little help from Brad the Mad at 
http://bradthemad.org/tech/notes/patching_rpms.php, I have now applied your 
patch, Ian, and I am please to report that it corrects my problem with blank 
lines.   Do you need the debug report?

(In reply to comment #13)
> I will do that as soon as I figure out how.  The general procedure is obvious, 
> of course, but I've never actually done it in Linux before, and not too many 
> times or recently in Solaris.  I'm not really a c programmer, just a lowly 
> application support person and occasional writer of scripts.  I pipe the diff 
> into rpm, right?  I'm kidding, but I really do have to do a little quick 
> research on patching procedure.  

Sorry, I probably should have built a test rpm and had
that pushed but that would have cost us another day or so.
I'll go ahead and update the package now.

> 
> By way of an expedient test, I deleted all the blank lines from the 
> auto.master and auto.netapps maps and restarted autofs.  (I checked that there 
> were no new volunteers after \ in these maps, too, just in case.)  Sure 
> enough, that fixed it.  I will let you know if the patch agrees with the text 
> editor.  
> 
> I also did a quick check of my maps sitation on systems with earlier releases 
> of Fedora (all rigorously updated), and the blank lines have been there since 
> at least FC4 without causing problems.  I expect the parsing code was 
> tightened up recently, catching up with my slapdash non-canonical commenting 
> practices.  I definitely appreciate the relaxation of the syntax on my 
> behalf.  It's really great to have this working, Ian!  

That's great .. that's what it looked like in the log.

Version 5 (in FC6) is much tighter as far as syntax goes.

Not allowing for an all whitespace blank line is a bug in my
opinion and that's fixed now thanks to our effort here.

> 
> The very defintiely incorrect tab character after the backslash was a recent 
> screw up on my part.  However, I'm thinking of submitting a bug request asking 
> for invisible real characters to be displayed with an intermittent twinkling 
> effect.   As soon as I figure out where to submit it.  It may require a 
> rewrite of the human vision driver.  

Haha ... the autofs mailing list is at autofs.org.
See http://linux.kernel.org/mailman/listinfo/autofs.

However, I think it may be really ugly to have blinking characters
in syslog.

Ian

(In reply to comment #14)
> OK, with a little help from Brad the Mad at 
> http://bradthemad.org/tech/notes/patching_rpms.php, I have now applied your 
> patch, Ian, and I am please to report that it corrects my problem with blank 
> lines.   Do you need the debug report?

No thanks, I've checked it against the test suite and it
doesn't appear to have any bad side affects so I'll merge
it upstream and get on with the update.

Ian

(In reply to comment #16)
> (In reply to comment #14)
> > OK, with a little help from Brad the Mad at 
> > http://bradthemad.org/tech/notes/patching_rpms.php, I have now applied your 
> > patch, Ian, and I am please to report that it corrects my problem with blank 
> > lines.   Do you need the debug report?
> 
> No thanks, I've checked it against the test suite and it
> doesn't appear to have any bad side affects so I'll merge
> it upstream and get on with the update.
> 

autofs-5.0.1-0.rc3.25 is built and on it's way to testing.
In case I've made any mistakes, could you verify that it
resolves this issue when appears on the mirrors please.

Ian

> Ian
> 
> 

I got a copy of autofs-5.0.1-0.rc3.25 from 
http://download.fedora.redhat.com/pub/fedora/linux/core/updates/testing/6/i386/
and it works.