Jan,
Lots of great work here. Comments below.
John
svc-system-config
create_initial_user_profile()
line 407 should use $INITIAL_DOT_BASHRC like line 412
create_user_account()
print statement at line 513 seems out of place or needs different
starting indentation in quote.
several places use the term aborting (lines 539, 549, 559) while
others do not (line 568, 583, 599) but still exit with
SMF_EXIT_ERR_FATAL. These should all use the same terms for
failure to be consistent.
set_expiration_date call at line 638 seems out of place
stylistically
compared to how the rest of the properties are established
within
the function.
expire=$(get_astring_prop $PROP_USER_EXPIRE)
if $(astring_prop_configured $expire); then
print "setting $login expire date $expire"
set_expiration_date "$login" "$expire"
fi
verses
set_expiration_date "$login" $PROP_USER_EXPIRE
create_initial_user_profile call at line 644 -- same comment as
above
nit - formatting of comment should be corrected in lines 661-663
configure_root_account()
similar comments for the configure_account_type and
set_expiration_date
calls as with the create_user_account(). I suppose being
consistent
between the 2 function (configure_*_account()) is as important as
being consistent within the function itself. So either way.
main()
It would be good if all the successful output from the
subfunction under
root and user configuration was indented under the subfunction
title:
|Configuring root account
| Setting root password
| Configuring <roo> account as type <root_account/type>
| ...
|Configuring user account
| ...
A failure would start at column 0 like the subfunction title.
This
makes it easier to glance at what is being performed for which
account.
sc_conv.ksh
Is it always true that the sc_embedded_manifest is always at the
end of the manifest file? Or can it be embedded anywhere within
the file? If it can be anywhere within the file then the
create_new_manifest function assumes that it is always at the end
which is
a problem.
On 06/ 8/10 01:37 AM, 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
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
