Replies inline.
On 09/ 2/10 06:22 PM, Dave Miner wrote:
...
If we do decide to allow for both server-side and client-side inclusion, why not just provide an appropriate tag in the manifest
and pre-process it internally with something like XSLT (or something even simpler, really) that replaces the tag with an xinclude
syntax?
Please elaborate - there just isn't enough here. Why replace the tag with
XInclude code? How would this look?
I'd suggest that if you prefer internal tagging, that it be limited to a single tag specifying when the inclusions are to be done
for a given profile, defaulting to first boot. It would be very simple and look something like this:
<inclusions type="static"/>
which would be parsable as XML.
or as a directive:
#inclusions static
or as metadata within a comment:
<!-- %inclusions=static% -->
...
Now, I would say that these are relatively minor advantages, and I would be amenable to forgoing the script option during
installadm.
I don't yet see compelling value for keeping it.
That is what I am saying.
...
5.11.4-5.11.5.6
I'd suggest reworking this as essentially a set of proposed diffs to the
installadm man page, with examples. I'm not getting a
particularly clear picture of the step-by-step process that a user would
encounter, which indicates that there's a use case to be
written here. However, it all seems awfully manual; why wouldn't we try to
aggregate the p12split and keymgmt functions (at
least) into a single subcommand that does a more complete job?
I will consider ways of consolidating the commands, but will say at this point
that they were designed this way for specific
reasons. The example given here is the most complicated: two-way
authentication with each client having its own certificate.
Two things:
- Suggest adding a second example that is of the "server authentication only"
variety
- The wanboot tooling design is rooted more in the Jumpstart ethos of "here's a pile of parts, assemble a jalopy of your liking".
Ending up with an environment that's as complex to set up as secure wanboot is something I'd categorize as a failure.
This proposal, as I have said previously, is attempting to maintain compatiblity with wanboot security as well as leveraging the
existing code base and all of the engineering that went into it. Done as such, the SC profile security can become transparent for a
user of wanboot security. I would not want to be the one to tell a wanboot user that if they want secure SC profiles, that they
have to do even more configuration.
Is it important that the solution is compatible or transparent to the wanboot
security solution?
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
