Hide Forgot
Description of problem: After updating to autofs-5.0.0-beta, my NIS autofs maps are no longer honoured. Previously --- for many releases --- I have had a NIS auto.master map which lists a /local map for local shares, plus /home and /net: $ ypcat -k auto.master /local auto.local /home auto.home /net auto.net As long as NIS is enabled, autofs has been able to pick this up and manage all of these filesystems automatically. As soon as I updated an existing working rawhide to autofs-5.0.0-beta, this broke; /etc/auto.master is used exclusively in preference to any NIS master map. Version-Release number of selected component (if applicable): glibc-2.4.90-10 autofs-5.0.0_beta3-6 kernel-2.6.16-1.2232_FC6xen0 How reproducible: 100% Steps to Reproduce: 1. Create and export a NIS auto.master as described above 2. Bind to it and enable autofs 3. Reboot Actual results: NIS auto.master map ignored Expected results: NIS auto.master map honoured. Additional info: I can only work around this by editing /etc/sysconfig/autofs to replace #DEFAULT_MASTER_MAP_NAME="/etc/auto.master" with DEFAULT_MASTER_MAP_NAME="auto.master" _and_ removing /etc/auto.master. /etc/nsswitch.conf contains automount: files nis but has not been touched since the previous, working setup, which did prefer nis over files.
(In reply to comment #0) > I can only work around this by editing /etc/sysconfig/autofs to replace > #DEFAULT_MASTER_MAP_NAME="/etc/auto.master" > with > DEFAULT_MASTER_MAP_NAME="auto.master" > _and_ removing /etc/auto.master. Your correct, however, changing the config should be all that is needed. You shouldn't need to remove /etc/auto.master. I'll check what's going on with that. This was done to better align with the Solaris automount behaviour but perhaps I still haven't got this quite right. I expect that, if /etc/auto.master doesn't exist I don't automatically go to the nsswitch to find it. I'll check that also. Ian
OK, but surely it's more important to align with *our* prior behaviour than Solaris's? Until recently, setting up a NIS master on a host was sufficient to allow autofs to Just Work right, fetching the master and mount maps over NIS. Note that I've had a lot of problem with the new autofs, so it's possible that some of the other problems were confusing the debugging and that the /etc/auto.master removal may not be strictly necessary; I'll go back and double-check that. Thanks!
Yes, confirmed --- even with DEFAULT_MASTER_MAP_NAME="auto.master" the /etc/auto.master is picked up first. Note that nsswitch contains automount: files nis ie. preferring files to nis. Indeed, if I switch it to automount: nis files then it does pick up the NIS map first. But my old nsswitch.conf has been in service for months unchanged, so this is still a change in behaviour; I guess we need to decide whether setting up NIS should automatically pick up the NIS auto.master or not, and then decide whether that indicates changing the nsswitch is appropriate.
(In reply to comment #2) Before I start talking about the goal of Solaris compatibility let me say that I've put some time into this today and I believe that the version I submitted this afternoon will be closer to the previous behaviour. However, with the introduction of the nsswitch I'm faced with a bit of a catch 22. Anyway, to cut a short story shorter I'm going to ignore the "files" nsswitch entry if present because the default is a file anyway. You'll still need to change the autofs config but, in my defense, it's marked as noreplace in the spec file so it should be a once only change. I've also added a note to the release notes in the tarball about this. Sorry. > OK, but surely it's more important to align with *our* prior behaviour than > Solaris's? Until recently, setting up a NIS master on a host was sufficient to > allow autofs to Just Work right, fetching the master and mount maps over NIS. The focus for version 5 has been 100% Solaris compatibility to facilitate integration into data centers that already have a considerable Solaris presence. I dougbt we will get all the way there, especially since we need to maintain as much backward compatability as we can. Yours is a case in point. All I can do is appologise and urge you to continue to help iron out the bugs. I'll do whatever I can to make autofs fit in both camps but inevitably there will be some consessions on both sides. Sigh.. > > Note that I've had a lot of problem with the new autofs, so it's possible that > some of the other problems were confusing the debugging and that the > /etc/auto.master removal may not be strictly necessary; I'll go back and > double-check that. Sorry you wasted your time on this. I wasn't quick enough to reply. As I said above I have pushed a new version that I believe addresses the problems you reported. Please let me know how it goes. Look for autofs-5.0.0_beta4-1 or grab the srpm from CVS. Ian
OK, I've built 5.0.0_beta4-1 locally from distCVS, and my wildcard problems are fixed. I'll know about the /net map reload shortly once the initial mounts expire. ... No, that bit is still broken. Will report against the specific bugs concerned.
Regarding the Solaris compatibility, do we just want to aim for the same level of functionality, or do we actually want to change our default configurations too to match Solaris's? If we are willing to change defaults, then using simply "auto.master" as the default master map name, and "nis files" ordering in nsswitch, may be desirable. I certainly find it extremely convenient that new hosts pick up these maps from NIS by default on current distros; and unlike autofs, NIS has its own pages on firstboot and can be configured via dhcp, so the old defaults really did make it trivial to set up new boxes to simply drop into an existing NIS+autofs environment.
(In reply to comment #6) > Regarding the Solaris compatibility, do we just want to aim for the same level > of functionality, or do we actually want to change our default configurations > too to match Solaris's? > > If we are willing to change defaults, then using simply "auto.master" as the > default master map name, and "nis files" ordering in nsswitch, may be desirable. > I certainly find it extremely convenient that new hosts pick up these maps from > NIS by default on current distros; and unlike autofs, NIS has its own pages on > firstboot and can be configured via dhcp, so the old defaults really did make it > trivial to set up new boxes to simply drop into an existing NIS+autofs environment. Good point. I'll think about it and we'll get Jeff Moyer to comment when he returns. Ian
You should *not* default to files first for the master map; always use nsswitch. The default master map in solaris reads: +auto_master If we did this, then sct's configuration would just work. Of course, I'm assuming you'll replace the '_' with a '.' in the above.
(In reply to comment #8) > You should *not* default to files first for the master map; always use nsswitch. > > The default master map in solaris reads: > > +auto_master So your suggesting we replace the default auto.master (or auto_master) in the v5 install with this one and use nsswitch always. Correct? Sounds simple enough. > > If we did this, then sct's configuration would just work. Of course, I'm > assuming you'll replace the '_' with a '.' in the above. Yep. I added that in recently, the nis module will replace "_" with "." if the map has them and redo the lookup are per the Sun doco. Ian
That sounds like it would address one part of the problem. My *current* configuration would work; but a default out-of-the-box one would still fail to read the NIS auto.master, because nsswitch still lists files first. So the second question is whether nsswitch should default to files first, or nis first. The latter behaviour is extremely convenient for reasons described in comment #6. And previous behaviour of autofs implicitly read nis first.
Ian Wrote: > So your suggesting we replace the default auto.master (or > auto_master) in the v5 install with this one and use nsswitch > always. Correct? Right. > Yep. I added that in recently, the nis module will replace "_" with > "." if the map has them and redo the lookup are per the Sun doco. Hmm. I'll have to take a look at the code. This sounds dubious. ;) sct wrote: > but a default out-of-the-box one would still fail to > read the NIS auto.master, because nsswitch still lists files first. Not quite. If the only entry in the auto.master is +auto.master, and /etc/nsswitch.conf is configured as "automount: files nis", then the nis map *will* be read since the file map includes the nis map.
re comment #11: The default config has "auto.net" and "auto.misc" in /etc/auto.master, _not_ "+auto.master". So the default config will still ignore NIS, which is a change from previous releases.
(In reply to comment #11) > > > Yep. I added that in recently, the nis module will replace "_" with > > "." if the map has them and redo the lookup are per the Sun doco. > > Hmm. I'll have to take a look at the code. This sounds dubious. ;) Got you thinking now. That's what the Sun doco says so that's what I did. > > sct wrote: > > but a default out-of-the-box one would still fail to > > read the NIS auto.master, because nsswitch still lists files first. > > Not quite. If the only entry in the auto.master is +auto.master, and > /etc/nsswitch.conf is configured as "automount: files nis", then the nis map > *will* be read since the file map includes the nis map. OK. So no changes to the map name (ie "." to "_"). Make autofs.master the internal default instead of /etc/auto.master and add a +auto.master line to the default installed auto.master. Then the rest just happens. That will fit in with v4. Refering to Stephens comment following this one we could simply add the + entry below auto.misc and auto.net which would merge the maps. Of course if there are common keys the first read map kays would take precedence.
Yes, that should work, at least for /net, which basically can't be a NIS map because it is scripted. And I can easily work around /net and /misc being reserved for local maps.
(In reply to comment #14) > Yes, that should work, at least for /net, which basically can't be a NIS map > because it is scripted. And I can easily work around /net and /misc being > reserved for local maps. Hi Stephen, I'm going through my bzs and was wondering if there is anything further I need to do to resolve this? Ian
(In reply to comment #15) > (In reply to comment #14) > > Yes, that should work, at least for /net, which basically can't be a NIS map > > because it is scripted. And I can easily work around /net and /misc being > > reserved for local maps. > > Hi Stephen, > > I'm going through my bzs and was wondering if there is anything > further I need to do to resolve this? > I'm closing this as I haven't heard anything. Stephen, reopen if this isn't correct.