In investigating defect 12567, Anurag and I have
discovered  a number of changes that we may need to
make. I'll try and summarize them here, and we can try
and reach consensus on what we should do. Not all of them
may directly pertain to fixing that bug, but we should probably
do some of them anyway. Let us know what you think...

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.

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.

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.

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.

Reply via email to