Jan,
Thanks for the review. Submitting for a second review at
http://cr.opensolaris.org/~wmsch/profile2/
Please find my responses inline below:
On 01/17/11 01:18 PM, Jan Damborsky wrote:
On 01/14/2011 03:22 PM, William Schumann wrote:
Jan,
Please find my responses inline.
On 01/12/11 02:30 PM, Jan Damborsky wrote:
auto_install.c
--------------
Since code for parsing SC manifest is no longer in use,
should we remove it - e.g. stuff in auto_parse.c file ?
I have one question, though. Due to the unsatisfied external dependences,
hostname and timezone SC parameters are still being configured by the installer
itself (in ICT phase), not by new SC framework.
Would that still work even if the installer does not obtain that information
from SC manifest ?
The timezone is needed before the transfer phase, so that timestamps on the
incipient BE match the requested timezone, ideally.
This means that we still need to parse profiles for the timezone regardless. My planned approach is to restore the old
processing code for hostname and timezone, but examining *all* profiles for the properties. When SMF fixed are implemented, the
installer code can be removed.
Due to the fact that setting the timezone before the installation will result in correct file dates, retained the processing of the
profile to extract and set the timezone, instead searching all profiles for the timezone property. Hostname processing for now
should be unaltered - will track the issue of setting hostname in SMF.
ok. Out of curiosity, how that phase will look like after AI is converted to
CUD ?
I am asking, since AI->CUD document indicates that manifests will be
read into DOC. Is this a plan for SC manifests as well or will they just be
copied to the target ?
Profiles will not be included in DOC.
...
ict.py
------
- In original code,'svccfg apply -n' was called to validate generatedSC
profile.
That code was removed - is it intentional ?
The profiles are validated two times prior to that, but validation would be bypassed if a user inappropriately edited a profile
during AI, or an invalid profile were introduced through some other means. So, since validation is a low-cost operation, and the
user would want to be informed, perhaps it is better to restore it.
ok.
- It seems like code allows several SC profiles land in /etc/svc/profile/
directory.
How is it assured they all get applied by smf(5) ?
I am asking, since I thought that smf(5) only applies well-defined set of
profiles
from /etc/svc/profile/ directory.
Right now, the installers utilize 'site.xml' one - it is created as a symbolic
link
to /etc/svc/profile/sc_profile.xml populated by ICT.
Or is it just an interim solution until CR6961214 is addressed ?
No - it is assumed that this CR is addressed to correctly process multiple
profiles. I will take up this issue.
Thank you. You could also check with Wenling, since AFAIK this bug
is on the list of things which SC project depends on.
I modified the code with the assumption that CR6961214 is fixed, which means that it writes profiles to /etc/src/profiles/site/.
Removed references to site.xml in ict.py.
Thank you,
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
