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. > 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. > [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. > > 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. Dave
