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): autofs-4.1.3-28 How reproducible: Allways. Steps to Reproduce: 1. Use NIS (yp) with a automount map of another name (see example above). 2. /etc/init.d/autofs start 3. 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.
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. Thanks, Jeff
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 anymore! 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 Edgar
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 compromise. Thanks.
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. Thanks, Edgar
This should be fixed. Please re-open if not (CVS says it's fixed, so I'm closing). Thanks!