Hi William,
On 01/26/2011 03:18 PM, William Schumann wrote:
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.
Just to clarify, hostname can be already configured via smf properties,
populating hosts(4) file is the reason why installer still needs to keep
notion
of hostname configured for target. This issue is tracked by CR6996436.
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.
ok.
...
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.
ok.
I have looked at updated webrev - I have just couple of comments:
ai_get_manifest.py
------------------
- it is missing in updated webrev - should it be included ?
auto_install.c
--------------
- since regcomp/regxec are used, we should be perhaps including
regex.h
- I think that regfree() should be called somewhere to release memory
allocated by regcomp().
Thank you,
Jan
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
