Responses to questions are inline. Other points will be addressed in a
revision of the proposal.
On 06/ 4/10 09:29 PM, Dave Miner wrote:
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.
...
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?
AI vs. SC manifest? This was not considered. It would save adding
another option, although it is potentially confusing for the user not
expecting this convenience.
Section Ib: What would the contents of a default SC manifest be?
The current default.xml has such entries:
root password: opensolaris, user: jack, password: jack
These are useful for configuring a system with a minimum of user
intervention.
Do we in fact actually require one?
No. Enhanced SMF profiles project will result in prompting on first
boot if required properties are missing.
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?
Again, we are aiming at automation. The Automated Installer should
offer ease-of-use defaults that can be customized or eliminated by the user.
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?
It does makes sense to try to include the SC manifest in the wanbootfs,
which would work for SPARC, since the bootfs is assembled by the
webserver. For an x86 client, there is not an equivalent storage
location. It might be better if the methods of delivering the SC
manifest were consistent across platforms. Sarah expressed an opinion
on this as well - response forthcoming.
Section Ie: I'm puzzled at the contention that no suitable use case
was found for multiple manifest files.
The proposal will be changed to discuss XInclude, proposed in lieu of
multiple SC 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?
Some points about multiple SC manifest files vs. XInclude or other
derivation techniques:
- It's not complex to include a file: <xi:include file.xml> The xi:
namespace is already defined in the DTD schema service_bundle.dtd.1
- XInclude provides a table lookups as indicated in the use cases.
- If multiple SC manifest files were input, there are still
complications: e.g., Can the user edit the previously submitted files
individually (delete, replace)? Are the individually submitted files
subsumed into the AI server database (which would protect them), or are
they just pathnames to files that are uploaded at install time? How
would duplicate properties be handled - is the order of the files an
issue? Is an interactive UI necessary? Not to say that it is not
possible - only that it presents its own set of complications, despite
its ostensible simplicity.
I have added a section to the proposal addressing this, with sample code.
RE: leveraging AI manifest derivation:
I think that the nature of the sysconfig information is different. From
the use cases in the proposal, they don't require calculations that
derived AI manifests supports - just table lookups and replacements
based on service name, IP address, network, IP, MAC, etc. Simple tag
replacement would suffice.
RE: IPS security:
Like the proposal for SC manifest security, IPS secures repositories
with SSL keys and certificates. I think that they are compatible and
that the same keys and certificates could be used if desired.
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
