William, thanks for the replies. Follow-ups on a few in-line:
On 09/ 2/10 08:38 AM, William Schumann wrote:
Replies inline.
On 08/31/10 09:05 PM, Dave Miner wrote:
I've reviewed v1.3 of the doc.
v1.4 has a few additions, including the validate-sc subcommand.
Apparently I missed the announcement of a later version?
...
5.3.2
It seems to me that there's a bright line being drawn around inclusion
processing, wherein a given profile can have inclusion on
either the server or client, but not both, which would seem more flexible. What
are the obstacles to providing for both?
For a single given xml file, the XInclude standard does not provide for
inclusions to be done at one time and not the other; all
inclusions are assumed to be performed at once.
One way of extending this would involve adding means of tagging inclusions and
selectively doing the inclusions. Then, instead of
handing the xml file over for xinclude processing in a single pass (through
Python's lxml, for example), input the xml, then
traverse the tree searching for xinclude instances and performing the
inclusions on that node.
Another way might be to use directives, similar to those in Cheetah, to control
when inclusions are done. This seems complicated to
implement. Such software would output xml templates with the directives for
the unprocessed inclusions still in the template.
Is there a reason that wouldn't be preferred?
Although it could reduce the number of profiles due to differences in when
inclusions are performed, it would be a lot of additional
code for a minor gain. Also, it introduces additional embedded coding with
syntax, usage rules, more learning for users, possible
bugs, and user errors. Having separate command line options indicating when
the inclusions are to be performed (per the proposal)
is simpler in several way.
I sincerely doubt users will find the proposed solution simple in any
way. Having to remember the appropriate way to register a manifest in
order to get it to behave correctly is a sure-fire recipe for support
call after support call. Instead, I believe the manifest needs to
express this directly so that there is no ambiguity possible.
You almost got to my suggested solution in your response above, but not
quite. 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?
5.4.3
I'm not seeing the value of providing for script execution during installadm.
It seems to add significant complication to the
interface and implementation,
The code to implement this would be almost identical to the code for the
dynamic version: the environment variables would be more
limited (this would have to be checked in the dynamic version, just with a
different list of environment variables). Yes, there
would be an additional command line option.
while providing comparatively little value since the environmental values
available are so limited. I'd think that essentially
the same value can be provided by users themselves through scripts wrapped
around installadm. What advantages do you feel this
provides?
The format of the static and dynamic scripts would be the same, instead of the
static version being a wrapper. The user would have
to correctly code the wrapper.
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.
...
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.
6.3
Please provide a more complete example in this use case of the profile and
scripts that would be supplied by the administrator
I'm trying to provide an algorithm without delving into code - I'm not sure
that it is necessary. Will try to fill it out a bit.
6.4
The installadm command here seems incomplete in that there is no service
specified. However, I'm a little confused by this use
case. Why wouldn't the site's packages merely install the profiles directly
into /etc/svc/profile? What benefit is the inclusion
supplying here?
It would be one way of selecting profiles from a set of available
mutually-exclusive profiles for customization.
I would think that derived manifests + publishing of distinct packages
could do the same thing. Not sure I have a basis for calling one or the
other superior at this point, but that's something I think needs analysis.
6.5
This use case is interesting, and enlightening. In reviewing it, though, I
wonder if it doesn't indicate functionality that
perhaps should just be built into this project, rather than requiring the user
to write such Cheetah scripts. Thoughts?
Chances are that the functionality is not exactly what the user wants. To take
this example, if the CID is missing from the table
and, consequently, there is no root password defined, this might be considered
a security risk, since the installing user would be
prompted for a root password upon first boot.
Sure, but the security issue is really an implementation detail of the
example. I'm more suggesting that administrators may find AI easier to
use (and integrate with other portions of their infrastructure such as
configuration management databases) if we can consume simple replacement
tables similar to the example here.
Now, we might consider providing scripts, templates, and tables containing SMF
property values for the user to customize. The
scripts could be offered to the user as plugins. These suggestions, however,
would fall outside of the requirements of this proposal.
I think the scope here is malleable, as success is a matter of providing
sufficient value to users. If this sort of feature is needed to do so,
then the scope needs to adjust. And if that means you need more help
for implementation, then that's open for discussion.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
