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.
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 ?
...
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.
Jan
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
