This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 147765 - /etc/init.d/autofs: for maptype=yp: map auto_* to auto.*, not just auto_home and auto_mnt
/etc/init.d/autofs: for maptype=yp: map auto_* to auto.*, not just auto_home ...
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeffrey Moyer
Brock Organ
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2005-02-10 20:30 EST by Edgar Hoch
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version: autofs-4.1.4-16
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-04-17 17:44:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)
Patch to solve the problem (403 bytes, patch)
2005-02-10 20:32 EST, Edgar Hoch
no flags Details | Diff

  None (edit)
Description Edgar Hoch 2005-02-10 20:30:00 EST
Description of problem:

In /etc/init.d/autofs there is a mapping
from auto_home to auto.home and from auto_mnt to auto.mount
if maptype=yp. This should be extended to any NIS (yp) map
because the auto.master returned by ypcat
(through the function getnismounts())
contains names like

/mount auto_mount
/home auto_home -nosuid
/rus auto_rus   -nosuid
/- auto_direct

The names of these tables should be mapped like auto_home.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Use NIS (yp) with a automount map of another name
   (see example above).
2. /etc/init.d/autofs start
Actual results:
These maps other than auto_home and auto_mnt will not be mounted.

Expected results:
All NIS (yp) maps should be mounted.

Additional info:

I will attach a patch that works for me since years.
(The problem exists a long time.)
It would be nice if you could include it in the next update
and also send it to the autofs developers.
Comment 1 Edgar Hoch 2005-02-10 20:32:05 EST
Created attachment 110953 [details]
Patch to solve the problem
Comment 2 Jeffrey Moyer 2005-02-15 15:12:16 EST
I've been curious to see if anyone actually used this variable.  I'm fine with
your suggestion (we only did the conversion for 2 maps because that's all that
was handled in the past).  I would like to understand why you need this, though.


Comment 3 Edgar Hoch 2005-06-23 18:33:11 EDT
I need this patch because we still have more automount maps distributed over NIS
than only auto.home and auto.mnt . Ok, I understand that it would be possible
to change this, but then many paths will change in our environment. This is
the reason why I do not change this just for fun.

When I install Fedora (FC2, FC3, FC4) I have a script automatically installed
by my kickstart configuration that runs after the first reboot after kickstart
installation. This script runs many other scripts, one of them changes
/etc/init.d/autofs to solve our needs (the patch as attached). As I know this
problem now I can handle it with my scripts for fresh installations.

But when autofs is updated automatically by yum by the nightly yum cron job
I don't know a not complicated solution to run my script again after
yum has updated autofs. With every new autofs rpm package installed my changes
in /etc/init.d/autofs will be lost. Then some automount directories on our
computers will not available anymore! The users tell me that they can't work

Please could you apply this simple patch to autofs before the next update
of autofs! That would save me and our users the suddenly not anymore working
linux computers that must all be fixed by hand!

The patch does not affect other users of fedora because if one needs to
change the name of auto_home the it is most probable that other maps of
this schema need also change the name by the same algorithm.

Thanks in advance

Comment 4 Edgar Hoch 2006-01-23 05:50:20 EST
I am wondering why you are releasing autofs-1:4.1.4-15 for Fedora Core 4
but not including my patch?

This update (with auto-update with yum) has broken all our FC4 hosts
over the weekend because now autofs /mount directory is empty now
and all the direcories needed by our users are not available!
Now I have to login in every host as root and manually my patch again
and then restart the autofs service!

Please just think about your users suggestions and the results of that
and apply them if possible and not just ask why I need this but do nothing
even if you where told why!

It is a bad idea to break users installations!

When will the chance incorporated into the autofs package?
Comment 5 Jeffrey Moyer 2006-01-23 15:45:05 EST
> I need this patch because we still have more automount maps distributed over 
> NIS than only auto.home and auto.mnt . Ok, I understand that it would be   
> possible to change this, but then many paths will change in our environment. 
> This is the reason why I do not change this just for fun.

I understand your concerns.  I agree that it is a bad idea to break user
installations.  In that light, changing behaviour is likely to break someone,
even if it is a bug fix.  Surely you must understand that?

I've read up on all of the material I could find about the conversion of
underscores to dots.  I would agree that your patch does the right thing.  I
don't think it will break existing installations, but it's impossible for me to
know that.  As such, I propose we fix this in rawhide (fc5).  Until then, you'll
have to continue to maintain your local fix.  I hope this is an acceptable

Comment 6 Edgar Hoch 2006-01-23 16:05:05 EST
Dear Jeffrey,

thank you for your fast answer! Yes, I understand that it may break other
installations too, and we really can´t know all installations to rule out that.

I accept the compromise to put it into fc5 (but it should be in the release).
It´s not a too long time until the release, and I hope not too much other
updates of autofs package.

When the patch is integrated in rawhide and fc5 (test3?) then you can change
the status of this bug report accordingly.


Comment 7 Jeffrey Moyer 2006-04-17 17:44:52 EDT
This should be fixed.  Please re-open if not (CVS says it's fixed, so I'm closing).


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