Thanks for writing this up, Alan. And thanks to both Anurag and Alan for wading through all of this!!
Comments in-line. On Thu, Nov 12, 2009 at 05:45:16PM +0000, Alan Maguire wrote: [...] > 1. add project=default entries to the netadm/netcfg > users in /etc/user_attr. Needed to prevent startd > (the SMF master restarter) getting hung in project > lookups to nsswitch-specified name services as > discussed in getdefaultproj(3PROJECT). When > methods are run as non-root user (such as nwam's > methods) the default project is looked up for that user > and we can get snared in nameservice lookups. > > 2. to prevent nis/client is going into maintenance due to being > restarted too quickly, we may need to use smf_kill_contract > to empty the contract rather than the simple :kill stop method. > > 3. copy /etc/nsswitch.files to /etc/nsswitch.conf during do_ns() > as part of location application prior to disabling name services. > This prevents us from having references to nis in /etc/nsswitch.conf > when nis/client is disabled. I think all of these make sense. I seem to remember Alan mentioning some risks associated with doing #2, but I don't remember what those were--am I remembering that correctly, Alan? Any concerns with doing this? > 4. At present, we call nwamd_fini_ncus() as part of NCP switch > on the old NCP. Then we refresh nwamd, and another fini > is done. We can't really get rid of the first fini since it's done > on the basis of the set of the NCUs in the old NCP,and after > the SIGHUP the new NCP is active. So we probably should > still fini the NCUs prior to NCP switch. > > 5. Does name-service-cache need to depend on network/physical? > Probably not - it already depends on network/location. Agreed that we should not do either of these. > 6. We may need to revisit how often network/location gets refreshed. > At present we refresh when we get DHCP info (just in case name > service info has been retrieved), but this leads to lots of > unnecessary refreshes, particularly when name service config is not > garnered via DHCP. I think this is worth investigating, but (assuming we can get a reasonable fix for 12567 without it) should be separate, follow-on work. Let's file an RFE or lower-priority bug to track it. > 7. When activating locations, if a manual location is specified > it is activated regardless of whether any IP NCUs are available. > We should revert to activating NoNet in that case. Definitely. So, can we get a test build with items 1, 2, 3, and 7 in it, and see how that works? Or has that combination already been tested? That seems like the right combination to me, but of course it needs to work, too... -renee
