To help get this case back on track, I've been asked to respond to some
of the concerns regarding its relationship to the installation
architecture raised in the discussion so far. Mark and Erik have
responded to questions on the networking-specific aspects of the
architecture (relationship to NWAM, etc.) already and I won't repeat
those points.
As Seb noted in some off-line discussion, it would be helpful to place
this in context with the original Caiman umbrella case (PSARC/2007/039),
as that would seem to most directly cover the questions that have been
raised, and I agree, it's well past time we offered an update. I'll
schedule that in the near future. However, I think this case can and
should proceed in advance of that discussion.
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.
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.
I note that, contrary to speculation offered in some of the comments,
the mechanism proposed here is explicitly not used to configure the
installation environment itself; the networking environment used in
executing a network-based installation such as Automated Install is
necessarily derived from DHCP (x86 or SPARC) or the OBP properties
(SPARC only, not yet working in AI but planned).
Other comments offered related to the set of parameters:
- Why not more interfaces, routes, datalinks, etc.? The interactive
installers are at present only configuring a single interface;
additional networking configuration is expected to be the province of
more complete management tools used post-installation. Thus, we
provided those basic requirements to networking as a starting point for
discussion, leading to this proposal. We would welcome having the
capability to provide more complex network configuration as part of AI,
though, and indeed think it is a requirement long-term; Erik and Mark
have already discussed the issues there.
- Why not LDAP or NIS? They're not part of this case for two reasons.
First, the networking organization doesn't own either one of those
technologies, so it's out of Mark's scope, and second, we just aren't
ready to handle them yet in the installers. Both are candidates for
inclusion in the overall configuration plan once we get farther along;
LDAP, at least, is a certainty in my view.
- Why not just pass over a resolv.conf for DNS? We believe that
providing a basic, initial DNS configuration via SMF properties is
reasonable in order to provide AI users with a relatively
straightforward configuration mechanism using one file, which was one of
the good points of sysidcfg(4). This does not preclude the use of other
mechanisms, such as configuration management tools like cfengine that
replicate configuration files directly, and we are considering ways that
the installers can integrate well with those long-term. The approach
taken by the networking team (and others) in producing serialized,
complex configurations might also demand similar capabilities, and we'll
be continuing that discussion over the coming months.
Finally, for more background on the system configuration work for
installation, I'll note the project page on opensolaris.org[1]. It's
not ready for ARC review at this time, but input via
[email protected] or to me or Jan Damborsky directly would
be welcome.
Dave
[1]http://hub.opensolaris.org/bin/view/Project+caiman/System+Configuration+Project
_______________________________________________
opensolaris-arc mailing list
[email protected]
