On 07/ 6/10 07:05 AM, Jan Damborsky wrote:
Hi Keith,
thank you very much for looking into this.
Please see my response in line.
Jan
On 06/29/10 12:47 AM, Keith Mitchell wrote:
Hi Jan,
Like Joe, I couldn't find very much wrong with these changes.
Nevertheless, I can always nit at something and I've got a few
questions as well.
install-finish:
Based on the webrev and bug comments, I don't quite understand the
strategy going forward. It looks like for liveCD and Text Install,
the SC profile is copied over; for AI no keyboard setting is done -
does this mean that on first boot after an AI install, the user is
prompted for keyboard choice? Or is the setting applied elsewhere?
As far as AI is concerned, it originally did not support configuring
keyboard layout -
it was hardcoded to US-English (see bug 4585).
For AI, the overall strategy is to configure things via SC manifest
which is in form
of SMF profile. Since this mechanism is now available (push has
happened earlier today),
I have enhanced scope of these changes with AI related modifications.
They are merely about enhancing default AI manifest with default
configuration for
keymap SMF service - the updated webrev is available at [1].
Related bug:
4585 Automated Installer needs support for setting keyboard layout
from AI manifest
I think I understand now. In the AI case, the ICT
"apply_sysconfig_profile" takes care of applying the settings; for
interactive installers, the ICT "keyboard_layout" is still required (for
now).
ict.py:keyboard_layout():
The method for applying the sc_profile does not seem extensible in
this fashion. What happens if, before ICTs are removed as such, we
need to apply a different sc_profile change? I suggest a different
approach - during ICT.__init__, read the sc_template in (either as an
lxml.etree or a plain string). Modify the in-memory representation
during ICT execution, and then write the file to the destination
after all ICTs have completed (as a separate ICT function perhaps).
The following XPath expression would get the appropriate location
here, assuming the lxml.etree route:
layout_element =
sc_template_etree_object.xpath("//servi...@name='system/keymap']/instan...@name='default']/property_gro...@name='keymap']/propv...@name='layout']")[0]
#xpath returns a list, but there should only be one default instance
layout_element.set("value", layout)
Using etree/Xpath also means that the results will be more consistent
- consider what would happen if the sc_template had a second
"US-English" string somewhere in it. The parameter to the Xpath call
can, of course, be statically defined somewhere.
In general, I agree with your points and the proposed mechanism
is definitely not the final solution, but as I pointed out,
rather proof of concept and its scope is limited to configuring
keyboard layout and maybe hostname.
The current plan is that this mechanism will be replaced by XML
compliant generator of SC profile as part of 'interactive SC tool'
effort (which I believe we will cooperate on soon :-)
Please let me know if it addressed your concerns.
(I admit I got sidetracked by xpath... though it was fun to delve into
that for a moment)
I'm still concerned with how "hostname" would have to be handled, since
it will have to write to the same destination file. If it follows the
same structure, it will clobber the previously written keyboard layout,
since it would end up reading the "sc_profile_src" from the sc_template.
Perhaps the simplest solution would be to rename the "keyboard_layout"
ICT to "generate_sc_profile", and then simply have any interim
SC-related changes for interactive installers get dropped in there. That
would at least make it easy to manage until the final solution comes along.
1309-1311:
Would it be simpler to just set /etc/svc/profile/site.xml as the
destination in the first place?
We intentionally create site.xml as a symlink to final SC profile -
it would not be needed in this particular case, but this code
is shared with AI where it is part of workaround for the fact that
SMF profiles are currently applied twice during first boot
of installed system (during Early as well as Late Manifest Import) -
this confuses SMF service responsible for configuring user and
root accounts in case of AI.
That SMF service runs before LMI and removes site.xml symlink
while keeping SC profile for debugging purposes or for taking a look.
There is a bug 6961214 filed against SMF asking that profiles
in /etc/svc/profile/site/ directory are applied only during EMI
(not during LMI).
Once that bug is fixed, the plan is to just drop SC profile
into /etc/svc/profile/site/ directory.
That makes sense.
Thank you for the explanations.
- Keith
The updated webrev [1] reflects AI changes pushed earlier today
and thus shows how AI and interactive installers coexist in that
area.
References:
[1] http://cr.opensolaris.org/~dambi/bug-15678-4585/
- Keith
On 06/25/10 01:45 AM, Jan Damborsky wrote:
Hi,
could I please get a review of the changes for:
15678 /etc/default/kbd is to be obsoleted by 6944480, installers
need to be accommodated
Webrev:
http://cr.opensolaris.org/~dambi/bug-15678
For reference, here are related ON changes
(they are being reviewed separately):
http://cr.opensolaris.org/~dambi/bug-6944480/
related PSARC:
http://arc.opensolaris.org/caselog/PSARC/2010/183/
From high level point of view, this changes might be
considered as a proof of concept [*] demonstrating approach
we are going to follow in realm of interactive System Configuration.
As far as integration is concerned, the synchronized push
of ON and install changes is scheduled for build 145.
Please provide your comments before COB Friday 7/2.
I plan to address all comments en-bloc after I am back from
vacation in a week of 7/5 - 7/9.
Thank you very much,
Jan
Tests accomplished
------------------
Following images were built using modified Distro Constructor:
x86: AI, LiveCD, text install
Sparc: AI, text install
Installation was done using built images.
It was verified that on installed system, keyboard
layout was correctly configured.
Notes
-----
* Yes, XSLT will be used as a final solution for generating
resulting SC profiles when switching to DOC paradigm ;-)
_______________________________________________
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
