On 06/13/10 08:31, William Schumann wrote:
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.
AI manifests are added into install services, and also regulated by
the criteria as the selection mechanism for clients. SC manifests, per
this proposal, will be usable by multiple services/clients across the
whole install server. Also, as an intentional result of separating the
SC manifest from the AI manifest, it is no longer regulated by the
criteria set, but associated directly with services or client-specific
setups.
I think these differences make it difficult to re-use the command
set used for AI manifests, since there are at least a couple of options
(for example the specification of the install service) that don't apply
to SC manifests, but do apply to AI manfiests.
Having said that though, one way it could be done, would be to make
the install service specification optional, and make its presence or
absence imply the type of manifest.
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.
While I agree in principle with this point, it doesn't seem that loading
up a default configuration with hardcoded values for hostname, root
password, user and user password make things any easier for the main
targeted use case for AI. Having a bunch of systems end up with the
same hostname at least, has been a pain for some.
-ethan
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
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
