Hi William,
I've reviewed v1.3 of the doc. I'm getting a better picture of the
proposal, I think, and I think we're headed in a useful direction.
Comments and questions below.
Dave
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? Is there a reason that
wouldn't be preferred?
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, 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?
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.
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.
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.
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?
5.7.2
The example here is confusing; what happened to the "SC_profile/"
portion of the path in the include_file specification? Are multiple
include_file directives allowed? 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.
5.7.2.2
Please elaborate on when (i.e. what SMF service) the user-level wanboot
program would be executed.
5.8/5.9
I'm unclear how this proposed database layout relates to the existing
database. Please elaborate.
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?
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?
6.3
Please provide a more complete example in this use case of the profile
and scripts that would be supplied by the administrator
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?
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?
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
