On 06/ 2/10 03:02 PM, William Schumann wrote:
This proposal addresses specific deficiencies in customizing SC
manifests, and proposes enhancements to increase usability and security.
[remainder ellided]
After reading through this a couple of times, several comments and
questions.
Before proceeding further on this work, I think it's necessary to
clearly list the goals and requirements that are being addressed. It
would be especially helpful if this were cross-referenced against
existing bugs and RFE's against the project. Until we agree on the
problems to be solved, the rest of this discussion is going to be
difficult at best.
Section I: Has consideration been given to just overloading the existing
manifest management commands and making them capable of auto-detecting
the type of manifest being expressed and adjusting their behavior
automatically?
Section Ib: What would the contents of a default SC manifest be? Do we
in fact actually require one? AI requires a manifest in order to know
what to install, but why wouldn't we expect that services would be able
to prompt for configuration if required? In fact, your text suggests
this behavior, so there seems to be incongruity here.
Section Ic: No argument about separating the manifests, but what's the
advantage of using a multi-part MIME encoding vs. other alternatives,
such as delivering the SC manifest in the wanbootfs?
Section Ie: I'm puzzled at the contention that no suitable use case was
found for multiple manifest files. The use cases in Section IIa clearly
show the utility of composing configuration from multiple files, but
seem to only consider relatively complex XML inclusion technology when
SMF is already providing a capability which seems to meet many of the
requirements without the complexity described here. What are the
advantages we derive from this approach?
Section II: The entire section makes no mention of how this derivation
might relate to, or work in combination with, the AI manifest derivation
design that's already in consideration. Why would we propose a
completely different methodology for the system configuration manifest
when it would seem that the requirements are extremely similar? That
fundamental question needs addressing before evaluating this further.
Section III: I'll repeat the need for requirements to be clearly
identified. For example, can we ensure that configuration manifests are
only served to the clients that meet their criteria without going to the
bother of SSL authentication? That seems to be a relatively
straightforward problem to solve and would seem to address the most
pressing issue in AI's security (excessive disclosure of configuration
data). I think any proposal on client and server authentication in AI
also needs to consider how it will relate to the authentication features
in pkg(5); we'd much prefer to leverage between the two since they need
to work in concert.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
