I see that you maybe answered your primary question yourself, but to
hopefully provide more clarity on a couple of points:
On 06/ 2/10 01:33 PM, James Carlson wrote:
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?
I wouldn't use "fixed media" as the dividing principle here, because
that's not how I expect it'll be long term, even if it sort of works
that way right now.
Yes, we expect that in many, if not most, cases, the users of Automated
Install will choose non-NWAM configurations for the installed system, at
least in NWAM's current form. Interactive installers may or may not
offer a choice between the two; we'll be explicit about the behavior of
each interactive installer in its case. The GUI is currently explicit
about only supporting NWAM. The text installer case (2010/165) is
coming for review in a couple of weeks.
Dave
_______________________________________________
opensolaris-arc mailing list
[email protected]
