Hi Clay,
On 06/10/10 11:06 PM, [email protected] wrote:
Hi Jan,
I'm concerned about sc_conv.ksh, it would be good to add a comment
what it's doing exactly and is this expected to be run on the AI
client or AI server, at least for anyone stumbling across it.
I agree - I have added comment section to the beginning of the script -
could you please take a look at that comment and let me know if
it might appropriate clarify the purpose of this script ?
The updated webrev is available at
http://cr.opensolaris.org/~dambi/bug-15723-cr/
Delta webrev
http://cr.opensolaris.org/~dambi/bug-15723-cr-delta/
As far as utilizing XSLT for SC manifest conversion, while I can see
that XSLT is the solution for manipulating XML files in CUD,
I am not convinced that moving to XSLT in sc_conv.ksh is the right thing
to do at this point. sc_conv.ksh is tied to the existing infrastructure
which is going to be removed and replaced with the new one, thus I am
not sure it is worth to invest that effort. Why not to introduce
XSLT integrated with new CUD effort after it is fully exercised ?
Also, looking at XSLT version, it is unnecessarily complex given
its goal. sc_conv.ksh is mostly targeted to the admins who will use it
to convert existing SC manifests. sc_conv.ksh in current form is
easy to understand which I believe is the advantage in case
some minor modifications are desired.
I can see that this might be a good exercise to give XSLT a try,
but I would like to treat that separately, since XSLT is not something
we have appropriately exercised yet, thus might constitute the risk
I believe is not worth to undergo in this particular case.
If it seems plausible, do you think I could file separate bug for this ?
To be honest, I don't understand your concern about polluting our
gate with another shell script given the fact that it will be removed
when no longer needed (as soon as AI/DC manifest rework is integrated).
Please let me know what you think.
Thank you very much for looking into this !
Jan
Reading the shell script, it appears to:
*Have a regular expression which matches any value attribute (roughly)
*Embeds an entire XML file (lines 81-127)
[General infrastructure]
*Checks if the input manifest is available
*Makes a copy of the input manifest
*Determines if the manifest is embedded or not
[Actual reason for existence]
*Copies username, userpass, description, rootpass, timezone and hostname
into the new manifest
This is exactly what XSLT is for and it can be far more readable than
most ksh scripts -- though quite masterfully done, Korn shell is just
not a language for XML processing by itself. Further, I'd like to see
us not introduce more ksh code into a product already schizophrenic as
to if its in C, ksh or Python. Lastly, when a W3C standard is already
provided for to do this type of work, we should try to use it. I've
drafted an XSLT stylesheet and Python script to handle the
infrastructure. I know we don't expect this script to hang around long
but please let me know if this might work okay or if I'm missing
anything. If it would work, perhaps we could use it to get the XML
acumen in our group up and keep the language count down since Python
is becoming predominate and XSLT is XML already?
I've written a Python and XSLT script which does the same (and more)
as the ksh script. They can be found at
http://cr.opensolaris.org/~clayb/SC_using_XSLT/
(The python has been gently code-reviewed by Drew Fisher but the XSLT
should be reviewed still too)
The raw XSLT script can be run against an SC manifest via:
xsltproc convert.xslt /tmp/sc.xml
Or the Python script:
update_sc.py -i /tmp/old_sc.xml -o /tmp/new_sc.xml
-or-
update_sc.py -i /tmp/old_criteria.xml -o /tmp/new_criteria.xml
Lastly, I've included a test_cases directory which has the before and
after valid SC manifests which cause sc_conv.ksh fits but work with
XSLT. Also, talking with Doug McCallum, his team is looking at using
XSLT for updating Share Manager XML files as they need. I think it's
better to start using this technlogy (especially in a throw-away mode)
now rather than being behind the learning curve when we want it.
Thank you,
Clay
On Tue, 8 Jun 2010, 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
