On 07/28/10 12:38 PM, William Schumann wrote:
Resulting from previous discussions on SC profiles, a second draft
document proposing changes to SC profiles is now on opensolaris.org at:
http://hub.opensolaris.org/bin/download/Project+caiman/System+Configuration+Project/SCProfileProposal.odt
Thanks for the revised document, it's easier to digest this as a whole.
General issue 1: Please number sub-sections to aid in references both in
the document and in review discussions.
General issue 2: For each element of the proposal, please clearly
delineate the proposed solution under a "Proposal" sub-heading or
similar. It's hard at present to differentiate the alternatives
examined vs. what's actually being proposed.
General issue 3: This really needs use cases walking through the various
tasks administrators will be performing. The current descriptions are
not detailed enough to fully evaluate the proposal. If you need
examples, try the examples at the end of the image management design.
Section 5, Overview:
There seems to be an assumption here that delivering a single profile to
a client is desired, and perhaps the requirement. However, SMF allows
multiple site-level profiles to be applied; is there a reason to not
provide for multiple profile delivery?
I don't understand the statement "supports storing properties in
tables". What does this mean, and why is it desirable?
Section 5, Static vs. Dynamic:
Please explain the difference between install time and first boot time
(I understand it, but most readers may not).
Under the "Deferring inclusion until first boot" section, I am actually
quite confused. From an architectural perspective, we would like system
configuration to be an SMF profile. Your proposal here seems to be some
super-set format of the SMF profile DTD. True? If so, what does this
buy us that can't be provided through other means? And, in particular,
how would this interplay with the SMF manifest importation process
during first boot?
Section 5, Scalability:
You seem to be proposing the scripting option, but this needs much more
detail to evaluate its suitability: when are the scripts executed, under
what identity, what functionality is allowed, etc.
Section 5, Basing SC profiles...
It's left unclear here whether you are proposing to implement
rules-based criteria? If so, what are the proposed additions to
installadm? What is the rationale for adding the new include_file
setting to wanboot.conf? Why wouldn't we just extend wanboot-cgi to
build this functionality in automatically?
Section 5, installadm optison and subcommands
It's fine to summarize this here, but providing references from
elsewhere in the document would have been helpful. However, I really
don't understand the table. Which installadm sub-commands does each
option apply to? There is little logical mapping of the short options
to the extended options; why both? These questions are perhaps best
resolved by answering my request for fleshed-out use cases.
Section 5, Security
First question is, does this proposal improve security of server-stored
information without requiring the use of any encryption or
authentication? In particular, the problems noted in bug 15362.
The adaptation of the cert & key management functions to installadm
seems to be very simple, but it's not clear whether this is in fact a
comprehensive solution for the user; do we end up with 30 pages of docs
to actually get a secure solution implemented? (Hint: the answer needs
to be no :-). Not to be a broken record, but this is exactly what
fleshing out the use cases will answer.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
