On 09/ 3/10 11:07 AM, William Schumann wrote:
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% -->
I made the XInclude suggestion in the hope that all our code would have
to do is a simple replacement (thus it's about at the complexity of a
nawk script) and then let XInclude handle the it from there, rather than
us inventing some other technology to combine multiple XML files. If
that's approximately what you're proposing, then we're probably in
mildly violent agreement. I'm just not sure that's the way to interpret
your suggestion.
...
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.
OK.
...
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?
We could probably do some data mining to get a sense of how commonly
used secure wanboot is. To my mind, compatibly leveraging the design
and core implementation is useful, but I'm doubtful that has to
translate to maintaining compatibility with the user interface, such as
it was.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
