Dave Miner wrote: > Jan Damborsky wrote: >> Hi Dave, >> >> >> Dave Miner wrote: >>> Jan Damborsky wrote: >>> ... >>>> I see - thank you for clarifying this. >>>> Looking at Alok's preliminary webrev, it is going to introduce >>>> new 'net' instance of svc:/system/filesystem/root SMF service >>>> which will be enabled in case there is a boot from network >>>> detected - it contains all network related stuff necessary >>>> to establish working AI environment. >>>> >>>> I am thinking if that might be the viable place to absorb >>>> this fix, as it deals with network configuration. Assuming >>>> that the fix would be decomposed into functions for better >>>> readability, following logic would be added to that new 'net' >>>> SMF instance: >>>> >>>> . /lib/svc/share/net_fs_include.sh >>>> >>>> INIT_NET_STRATEGY=`determine_network_boot_strategy()` >>>> >>>> if [ "$INIT_NET_STRATEGY" != "dhcp" -a "$INIT_NET_STRATEGY" != >>>> "manual" ] ; then >>>> # network strategy not determined, report failure and abort >>>> exit $SMF_EXIT_ERR_FATAL >>>> fi >>>> >>>> configure_network($INIT_NET_STRATEGY) >>>> # process return code >>>> >>>> [...] >>>> >>>> if [ "$INIT_NET_STRATEGY" == "manual" ] ; then >>>> configure_dns() >>>> # process return code >>>> fi >>>> >>>> >>>> Do you think it might be suitable place for those modifications >>>> or might it be better to consider different approach ? >>>> >>> >>> I tend to think that this really should be in something like the >>> network/physical service, although the code to set up resolv.conf in >>> the general cases appears in network/service (note that script is >>> also invoked in other contexts such as NWAM to do that work). Have >>> you looked at that as an option? >> >> I was looking at existing SMF network services in general when >> evaluating the bug, >> but didn't think about putting the fix there, as I didn't consider >> exposing this >> functionality outside of the installer technology. >> >> If my understanding is correct (based on your previous response), you >> would >> prefer that code to become part of ON network configuration ? >> > > I would prefer that the installation boot scenarios be integrated into > the standard services as much as possible. This helps to minimize the > likelihood of other projects and bug fixes breaking installation > inadvertently.
I agree. I was just checking if my understanding of the preferred strategy to solve that problem was correct :-) > >> Thinking about this and comparing with ON network services, as you >> pointed out, >> there seem to be two levels of network configuration when "manual" >> network strategy >> is used with wanboot: >> >> [1] NIC configuration >> --------------------- >> I am thinking that part of code might become part of network/physical - >> however, there would be at least following issues to be looked at: >> >> * netstrategy(1M) command is used to determine network configuration >> strategy. >> It doesn't work for our scenario, as it reports for "manual wanboot >> case": >> >> # /sbin/netstrategy >> ufs none none >> >> The desirable output would be something like >> >> # /sbin/netstrategy >> ufs bge0 manual >> >> * /lib/svc/method/net-physical would need to be enhanced to be able >> to configure >> NIC when "manual" network configuration strategy is used >> > > The whole "netstrategy" thing has always been pretty sketchy; if you > look at the program, it's got a lot of heuristics that are based on > older scenarios around diskless support, for example. > >> Another possibility would be to integrate that code into the kernel part >> dealing with configuration of NIC in "boot from network scenario" - >> this might >> be actually better place as it seems to handle "boot from net" NIC >> configurations >> in other cases as well: >> > > That would be interesting, and I think it would obviate some of the > issues with netstrategy. Love to hear more about your ideas here, I > haven't thought about it in a long time. Looking at the existing code, there seems to be two steps with respect to bringing up network before premordial init(1) process is spawned: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/os/main.c#main [1] plumbing boot NIC --------------------- If it is recognized that system was booted from network, boot NIC is explicitly plumbed by calling strplumb(): http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/strplumb.c#strplumb It is either called from vfs_mountroot()->rootconf() if NFS is recognized to be used as root filesystem or later from main(). [2] Configuring network for boot NIC (IP, netmask, default route) ----------------------------------------------------------------- While step [1] is always done if boot from network is detected, this phase is only carried out if NFS is identified as root filesystem (when I assume bringing up the network is the necessary condition to be able to mount and access "/"). In that case, NIC as well as default route is configured from NFS mount_root()->init_config(): http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/nfs/nfs_dlinet.c#init_config It seems three mechanisms are tried as far as obtaining network configuration is concerned: [a] boot properties (host-ip, subnet-mask, router-ip, ...) http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/nfs/nfs_dlinet.c#bp_netconfig [b] cached DHCP response (available as bootp-response property) http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/nfs/nfs_dlinet.c#dhcpinit [c] RARP http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/nfs/nfs_dlinet.c#whoami If we compare with what suggested fix for 9549 does, at the first glance it seems it mimics behavior provided by [a]. I am wondering if we might take advantage of the fact that the code already exists. [b] would take care of configuring network in "dhcp" case. I am thinking about following questions we would need to answer: * Is there any special reason, why is network configured only for "root on NFS", but not for generic "boot from net" scenario ? * What problems would be encountered if we would like to let kernel always take care of basic network configuration when system is booted from network ? > >> [2] DNS configuration (might be handled by network/service) >> ----------------------------------------------------------- >> As you mentioned, DNS configuration would likely belong into this >> service (/lib/svc/method/net-svc), as it handles DNS configuration >> in other scenarios. >> >> However, we would need to think about how DNS configuration would be >> provided to the service - we currently use install.conf private file >> generated by AI server - this mechanism is not stable at this point >> as it is planned to be changed. >> > > Right, we should probably sort that out sooner than later. This is on list of tasks to be addressed as part of AI robustness project, I am not sure about current priority - it might need to be increased if we decide to go this way. > >> >> Thinking about how all those changes would be delivered, I am >> wondering if >> the correct approach would be to file appropriate bugs against >> networking >> along with all investigations and proposed solutions captured and we >> would >> cooperate with team in charge as far as testing and the integration is >> concerned ? >> > > We'll definitely need the RFE's at some point. I see. This is what I was thinking about - cooperation with team in charge would be involved. Thank you, Jan
