Red Hat Bugzilla – Bug 147765
/etc/init.d/autofs: for maptype=yp: map auto_* to auto.*, not just auto_home and auto_mnt
Last modified: 2007-11-30 17:11: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
/home auto_home -nosuid
/rus auto_rus -nosuid
The names of these tables should be mapped like auto_home.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Use NIS (yp) with a automount map of another name
(see example above).
2. /etc/init.d/autofs start
These maps other than auto_home and auto_mnt will not be mounted.
All NIS (yp) maps should be mounted.
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.
Created attachment 110953 [details]
Patch to solve the problem
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.
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
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?
> 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
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.
This should be fixed. Please re-open if not (CVS says it's fixed, so I'm closing).