Dave Miner wrote: > First, I hope that the use of SMF profiles as a replacement for the > sysidcfg(4) mechanism is neither surprising nor controversial, as it's > been the plan of record since the inception of the new installer four > years ago and is something I've talked about in every presentation on > the program. Indeed, it's a significant driver for enhancements > delivered by PSARC/2009/371 and PSARC/2010/157, and conversion of > existing miscellaneous configuration data to SMF is the subject of other > existing (PSARC/2010/183) and forthcoming cases.
That's certainly not surprising to me. > The interfaces provided by this case will be leveraged in the > installation architecture in two ways. First, we require a way to > transfer configuration information gathered by the interactive > installers (GUI and Text) to the installed system. Second, we require a > way for administrators to express the desired configuration of the > installed system to an Automated Install (AI). Install will be using > this case's interfaces to satisfy both of those requirements. > Interactive installers will generate SMF profiles that are applied at > first boot, while AI users will, at least for now pending any future > work on AI tooling, supply SMF profiles directly. The remaining doubt I have about the project revolves around the network/physical instances. Currently, when OpenSolaris is installed from a CD, unlike legacy Solaris, it enables NWAM by default. Given the way this project is translating SMF properties into /etc/* information, though, it seems that install profiles based on this project might be required to disable physical:nwam and enable physical:default instead. Otherwise, NWAM will just walk all over the configuration bits. (That might be what someone wants, but then that same someone likely wouldn't want any of the unused static configuration bits from this project.) Is that a reasonable understanding? That installing OpenSolaris from fixed media will result in NWAM being enabled, but that automated installs will result in NWAM (at least usually) being disabled? If so, then what's the longer-term plan? Will we want to keep the nwam/default fork as it proves useful here? Or might there be a future NWAM that knows how to read these SMF properties? Or are we perhaps going a different direction altogether? That's the part that still confuses me. I'd expected that, just as installation was "based on" NWAM in OpenSolaris, this would be the pattern for the future as well. -- James Carlson 42.703N 71.076W <[email protected]> _______________________________________________ opensolaris-arc mailing list [email protected]
