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.
...
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.
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.
5.4.3.2
The set of status codes here seems over-specified. SMF, for example, gets by with fewer for its methods, despite a larger range
of functionality. I'd think a smaller set of codes coupled with appropriate messaging would be sufficient.
That seems fine. The user would have less detailed work to do, and at this point, there is no entity in the design to make use of
the numeric codes. Reducing the number of codes to reflect success, warning, failure.
5.4.4
It's unclear whether you are proposing to leverage AI manifest derivation here. I'm inferring not based on the rest of the
document, but please be explicit and discuss the reasons.
Will provide a use case of how AI manifest derivation can be leveraged.
5.6
Needs more clarity. As I mention later, perhaps it would be best to present diffs to the installadm man page as an appendix. I
assume that the options in the first table apply to
The second table on page 11 is unreadable.
:)
Will fix table margin error and review for clarity.
5.7
I'm unclear as to when (and by what program) the separate HTTP GET that's proposed would be issued. Can you place this in context
with the other portions of the AI client boot process?
Indeed. The HTTP GET for the wanbootfs is fairly trivial, and is very similar
to the AI service request. Will supply explanation.
5.7.2
The example here is confusing; what happened to the "SC_profile/" portion of the path in the include_file specification?
The SC_profile directory is scanned by the AI client. All files in the directory will appear on the AI client wanbootfs to be
copied to the proper directory for first boot processing. Will clarify.
Are multiple include_file directives allowed?
I'd say so, but for these purposes, only one is needed. I think multiples
could be easily implemented.
Additionally, please don't use /tmp in the examples here. /var/run is the system-secured equivalent that avoids the problems of
both excessive disclosure to, and interference by, non-privileged processes.
OK
5.7.2.2
Please elaborate on when (i.e. what SMF service) the user-level wanboot program
would be executed.
OK
5.8/5.9
I'm unclear how this proposed database layout relates to the existing database.
Please elaborate.
OK. It is just a single new table in the existing database.
5.11.2
This discussion of IPS feels incomplete. In particular, I don't have a feel for how a customer would set up a client to have
secure, authenticated access to both AI services and a pkg repository. My guess, based on the current document, is that there
isn't any leverage between the two, and so they are essentially orthogonal and additive in terms of effort by the administrator;
that is, there's a complex setup process for each that provides for little sharing of effort. Can you elaborate, perhaps with a
use case that covers such a scenario?
OK. I think that, for the case that that separate certificates are not needed per client, a single certificate might work for AI
server, AI services, AI clients, and IPS server(s).
5.11.3 nit: example path here says /etc/wanboot yet I'm sure it means to say
/etc/netboot
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.
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.
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.
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.
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
