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 ? 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 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: [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. 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 ? Thank you, Jan
