Jan,
Looking at the copy of the webrev at:
http://cr.opensolaris.org/~dambi/bug-15723-cr
General comment/question - In relation to static IP support, what is the
timing in accordance with the changes from the networking team and
this putback? Preferably, it would be the same build, and a flag day
would note how to use the updated SC profile to specify static IP.
perform_slim_install.c - 423-424 - Any reason why the user password
is processed differently than the others? Isn't it possible that if the
call
to nvlist_lookup_string() fails, that garbage can be left in upasswd?
ict.py - 2249 - nit - "take effect" -> "be applied"
system-config.xml - 92-103, 112-114 - Are these properties all listed
here in the service's definition manifest to define type?
system-config.xml - 96-97 - Are these defining default values for these
properties?
svc-system-config - 102 - Perhaps name this variable to be more attune
to what its used for so that its more clear? Like,
SMF_UNCONFIGURED_VALUE?
svc-system-config - 128 - typo - "vlaue"
svc-system-config - 148-154 - Its not clear to me what value this check
adds. First, it seems rather constricting; this service only supports
properties that are of type 'astring' and 'count' today, but what if that
changes?
Second, if we're worried that the property being read in from the live
repo must be the same type as what we're expecting that property type
to be, it seems we would need to define the types of each property locally
and compare the type that we read in from the live repo with that value.
svc_system-config - 172 - Does this mean that we're not expecting this
service to ever support a property of type 'count' that a user will provide
a value of '0' for in the profile?
thanks,
-ethan
On 06/08/10 01:37, Jan Damborsky wrote:
Hi,
could I please ask for reviewing changes enhancing
Automated Installer with support for new SMF based System
Configuration framework [3c] ?
Following bugs cover those changes:
15723 Teach AI to use new SMF based System Configuration framework for
configuring user and root accounts
15410 The installer delivered SMF manifests should be relocated to
/lib/svc/manifest
13737 Automated Installer needs support for setting terminal type from
AI manifest
Webrev:
http://cr.opensolaris.org/~dambi/bug-15723/
Please see below for more details as well as testing accomplished.
Joe offered to review the changes (thanks Joe !) and if possible,
I would like Ethan to take a look at AI portion in order to be
sure AI expectations are met.
As usual, anybody else is of course welcome to take a look as well.
Please provide your comments before COB Monday 6/14.
Thank you very much,
Jan
[1] Summary of changes
* support for new SMF based SC framework in AI (bug 15723)
AI has been modified to handle SC manifest as SMF profile. During ICT
phase,
the profile is syntactically validated and copied to the appropriate
directory
on the target (/a/etc/svc/profile/). It is then processed during
first boot of installed system as part of Early Manifest Import process
(aka EMI) - see [3a] for more details.
The legacy SC parser in AI is still in place and it processes the
existing SC parameters which are not yet transfered to SMF properties
(hostname, timezone). The legacy parser will be removed once those
parameters can be configured via SMF properties.
In order to minimize number of incompatible changes affecting users,
AI can still process SC manifest in legacy format.
The big bang (breaking backward compatibility) is planned to be synced
with the integration of AI/DC manifest rework.
If legacy format is detected, SC manifest is converted to the new format
during the installation. User is informed in log file that legacy SC
manifest
was provided and that the support for this might be removed at any time
without previous notice.
For purposes of the transition, conversion script is delivered into
the AI image. That conversion script can be also used on AI server
side to convert legacy SC manifests to the new format. The script
can handle both standalone SC manifests as well as SC manifest embedded
into AI manifest.
It addresses the common use case when admins have bunch of SC manifests
which are being re-used with every new build coming. Conversion tool
allows to automate the process of transitioning to the new format of
SC manifest.
* new System Configuration SMF service is introduced (bug 15723)
This SMF service takes care of configuring user and root accounts.
See design spec [3b] for more details.
* SMF services residing in install gate now take advantage of EMI (bug
15410)
This changes was needed for correct work of new System Configuration
SMF service. In general, it is required that SMF properties are applied
before 1st SMF service is launched. While there, all SMF services
in slim-source gate were modified.
* NWAM is now configured in SC manifest
As a preparation for static networking configuration in AI, AI was
modified
to enable/disable NWAM via SC manifest - related code was removed from
ICT.
[2] Testing accomplished
* Following types of images were built (based on build 140):
- x86: AI, text installer, GUI
- Sparc: AI, text installer
Installations with built images were tested to guarantee no regressions
were introduced.
* Several scenarios for configuring root&user account were tested -
see following document for list of test cases:
http://cr.opensolaris.org/~dambi/tc_user_root/tc_user_root.txt
* It was verified that old AI image (legacy SC parser) fails
appropriately
when provided with new SC manifests - it fails with following messages
in /tmp/install_log:
...
<AI Jun 8 09:25:19> Parsing system configuration manifest
<AI_E Jun 8 09:25:19> Could not parse property from SC manifest
<AI Jun 8 09:25:19> Automated Installation failed in parser module
<AI Jun 8 09:25:19> Invalid System Configuration manifest provided
* It was verified that new AI image can handle both new as well as
legacy SC manifests.
* It was verified that conversion tool can convert both standalone
as well as embedded legacy SC manifest into new format
* It was verified that installadm(1M) can process new SC manifest -
in particular that 'installadm add' has not been broken by the changes.
[3] References
[3a]
http://hub.opensolaris.org/bin/download/Community+Group+smf/smf_design_docs/emidesignmar09.html
[3b]
http://hub.opensolaris.org/bin/download/Project+caiman/System+Configuration+Project/scsmfdesignv0.1.pdf
[3c]
http://hub.opensolaris.org/bin/view/Project+caiman/System+Configuration+Project
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
