Bug 193251

Well, auto.net and auto.smb are program maps.  However, in v5, we should not
need the auto.net map.  That functionality should be available via "-hosts".  I
can see shipping it for backwards compatibility maybe.  Ian, what was the
thinking there?

auto.matser and auto.misc should not be executable.  In samples/Makefile, we find:
                install -v -c auto.master -m 755 $(MASTER) \
                                $(INSTALLROOT)$(autofsmapdir)/auto.master ; \

There's a similar line for auto.misc.  The mode should be 0644, I think.  Ian,
-c is ignored in current "install" commands.  Do you really want -C?

       -C     Install  file,  unless target already exists and is the same as
              the new file, in which case  the  modification  time  won't  be
              changed.

For now, I'll fix the makefile to install the master and misc maps with the
correct mode bits set.

Ian, also suspicious is the auto.net and auto.smb lines that would install the
scripts as "*.new" with mode 644.  Harmless, I guess, but is that what's intended?

Thanks for the bug report!

autofs version 5.0.0_beta3-2 was just built into rawhide.  So, upon your next
update, this problem should be addressed.  Please confirm when you get the chance.

Thanks!

> Well, auto.net and auto.smb are program maps

True, but they are not executed independently and so far, over years,
they did work without 'x' permissions.

As a matter of fact I tried with the current version another, rewritten,
variant of auto.net, without 'x' bits, and this did work too (for some
definition of "work" - autofs, or maybe NFS, seems to have some issues with
mounting/unmounting multiple file systems in a tree and that independently
of what hald is doing; but I do not know about that much yet).

If auto.net can be now replaced then maybe all this is moot but
this is really my main use of autofs so I would prefer to have
this functionality in a working condition.

In previous versions of autofs (4.x), the way to tell whether a map was a file
map or a program map was to test to see if the execute bit was set.  Thus, if
you removed that bit, I highly doubt things would work as expected.  Of course,
you can simply override that by manually specifying that the map is of type
'program.'

Your other issue should be addressed by newer versions of HAL.  Please see (and
contribute to) bz #191863.

I'd like to keep the focus of this bugzilla quite narrow.  Let's address the
execute permissions problem.  If you have other issues with multimounts, then
please open another bugzilla and provide the information requested under the
"Filing bug reports" section of the following web page:
  http://people.redhat.com/jmoyer/

Thanks!

Jeff

(In reply to comment #0)
> Description of problem:
> 
> Look here:
> 
> # rpm -qlv autofs | grep /etc/au
> -rwxr-xr-x    1 root    root              343 May 25 09:57 /etc/auto.master
> -rwxr-xr-x    1 root    root              581 May 25 09:57 /etc/auto.misc
> -rwxr-xr-x    1 root    root             1292 May 25 09:57 /etc/auto.net
> -rwxr-xr-x    1 root    root             1292 May 25 09:57 /etc/auto.smb
> 
> I fail to see anything in documentation and how things operate which
> would justify that change.  Do I really miss something?

Certainly, I've inadvertently changed the modes on auto.master
and auto.misc. I'll change that.

But the two program maps should have the execute bit set as
they are program maps. The previous version of autofs installed
them with the execute bit set so I'm not sure how this has suddenly
changed for you. In any case they are program maps and will need
to have the execute bit set so that they can be distinguished from
plain file maps. I'll check to see if this was checked correctly
in previous versions and add a warning to the release notes in any
case.

Looking at the code I see I may need to tighten this checking
up a bit for the new version.

Sorry for the confusion.

Ian

(In reply to comment #1)
> Well, auto.net and auto.smb are program maps.  However, in v5, we should not
> need the auto.net map.  That functionality should be available via "-hosts".  I
> can see shipping it for backwards compatibility maybe.  Ian, what was the
> thinking there?
> 
> auto.matser and auto.misc should not be executable.  In samples/Makefile, we find:
>                 install -v -c auto.master -m 755 $(MASTER) \
>                                 $(INSTALLROOT)$(autofsmapdir)/auto.master ; \
> 
> There's a similar line for auto.misc.  The mode should be 0644, I think.  Ian,
> -c is ignored in current "install" commands.  Do you really want -C?
> 
>        -C     Install  file,  unless target already exists and is the same as
>               the new file, in which case  the  modification  time  won't  be
>               changed.

Yep. I'll look into that.
Oddly, I don't see a -C option on install.

> 
> For now, I'll fix the makefile to install the master and misc maps with the
> correct mode bits set.
> 
> Ian, also suspicious is the auto.net and auto.smb lines that would install the
> scripts as "*.new" with mode 644.  Harmless, I guess, but is that what's intended?

No. That's an error on my part.
I'll fix that.

Ian

(In reply to comment #3)
> > Well, auto.net and auto.smb are program maps
> 
> True, but they are not executed independently and so far, over years,
> they did work without 'x' permissions.

Program maps will need to have the execute bit set to be
recognised as such.

As I said I'll add a warning to the release notes.

Once again, oops, sorry.

Ian

(In reply to comment #3)
> 
> As a matter of fact I tried with the current version another, rewritten,
> variant of auto.net, without 'x' bits, and this did work too (for some
> definition of "work" - autofs, or maybe NFS, seems to have some issues with
> mounting/unmounting multiple file systems in a tree and that independently
> of what hald is doing; but I do not know about that much yet).

We know there's a issue with hal which is being worked on.

Apart from that program maps should still function as before however
multiple mount map entries are handled very differently internally
now. So the behaviour may appear different but should still end up
providing the same service.

Time is short so please file another bug so we can sort out any
issues.

> 
> If auto.net can be now replaced then maybe all this is moot but
> this is really my main use of autofs so I would prefer to have
> this functionality in a working condition.

The hall issue will remain either way.

The "hosts" map is new and I expect will need work before everyone
is satisfied with it so please try it out and give us feedback.

Ian

(In reply to comment #1)
> 
> Ian, also suspicious is the auto.net and auto.smb lines that would install the
> scripts as "*.new" with mode 644.  Harmless, I guess, but is that what's intended?

This was the result discussing how existing files should be handled.

It was added to the make file so that people installing from the
upstream tarball don't have their customised maps and configuration
overwritten.

At least that's the intent.

Ian

I believe this was fixed a while ago.
Michal, can you check and let me know please.

> I believe this was fixed a while ago.

Yes, indeed. One can do 'rpm -qvlf /etc/auto.master |grep etc'
to see that this the case. :-)