Executable maps

Executable maps

[Techie]

Hi Ian, List,

2 questions..

1) Has a fix been released for the Admin or "$" shares in regards to
cifs yet? The automounter fails to mount them even though the path
looks ok. It mounts the non admin shares fine. I can mount them fine
from the CLI.

2) I have modified the auto.smb script to create a direct map since
the indirect fails to mount admin shares. Can a direct map be used as
an executable map? My feeling from my reading of the manpage is no but
maybe there is a way.

Thanks
TC

Re: Executable maps

[Ian Kent]

On Mon, 2010-06-07 at 16:33 -0700, Techie wrote:
> Hi Ian, List,
> 
> 2 questions..
> 
> 1) Has a fix been released for the Admin or "$" shares in regards to
> cifs yet? The automounter fails to mount them even though the path
> looks ok. It mounts the non admin shares fine. I can mount them fine
> from the CLI.

Not sure, since there was no feedback from the thread:
http://www.mail-archive.com/autofs@linux.kernel.org/msg07896.html

but the patch posted there has been committed and is available on
kernel.org. There may well be other patches in the series that it
depends on so beware.

> 
> 2) I have modified the auto.smb script to create a direct map since
> the indirect fails to mount admin shares. Can a direct map be used as
> an executable map? My feeling from my reading of the manpage is no but
> maybe there is a way.

Don't think that could work.
There's no way for a program map to enumerate the entire map at initial
startup and I don't want to add something that allows that because
program maps are dynamic and that introduces all sorts of difficulties
for the handling of direct mounts. And there is no way to use a program
map for a direct mount that has not been mounted (at startup).

Ian

Re: Executable maps

[H. Peter Anvin]

On 06/13/2010 09:44 PM, Ian Kent wrote:
> 
> Don't think that could work.
> There's no way for a program map to enumerate the entire map at initial
> startup and I don't want to add something that allows that because
> program maps are dynamic and that introduces all sorts of difficulties
> for the handling of direct mounts. And there is no way to use a program
> map for a direct mount that has not been mounted (at startup).
> 

Sorry for a *way late* reply.

There isn't a reason why a protocol for a program map to enumerate
itself couldn't be constructed, probably invoking the program map
without an argument, and receiving an enumeration on stdout; either
null- or LF-separated.

Obviously not all program maps will be capable of being enumerated, but
that's true for any map set.

	-hpa

Re: Executable maps

[Ian Kent]

On Fri, 2010-07-02 at 15:02 -0700, H. Peter Anvin wrote:
> On 06/13/2010 09:44 PM, Ian Kent wrote:
> > 
> > Don't think that could work.
> > There's no way for a program map to enumerate the entire map at initial
> > startup and I don't want to add something that allows that because
> > program maps are dynamic and that introduces all sorts of difficulties
> > for the handling of direct mounts. And there is no way to use a program
> > map for a direct mount that has not been mounted (at startup).
> > 
> 
> Sorry for a *way late* reply.
> 
> There isn't a reason why a protocol for a program map to enumerate
> itself couldn't be constructed, probably invoking the program map
> without an argument, and receiving an enumeration on stdout; either
> null- or LF-separated.
> 
> Obviously not all program maps will be capable of being enumerated, but
> that's true for any map set.

I think I more or less nacked that idea a while back but it is the
obvious and sensible way to do it.

Of course there is the bonus that any program map that doesn't check the
passed in key, assuming it's non-null, will likely SEGV, which would
make it all worth while.

Hehe, but seriously automount should be able to cope with crashing
program maps. I'm fairly sure I've tested that on occasion.

So, sounds good, I'll give it a go and we'll see what happens.
Ian