On Fri, Feb 27, 2009 at 01:55:22PM -0800, Bart Smaalders wrote:
> Joseph Di Pol wrote:
>>
>> I have created the following RFE:
>>
>> 6994 Need actuator implementation for user images
>> http://defect.opensolaris.org/bz/show_bug.cgi?id=6994
>>
>> Joseph Di Pol wrote:
>>>
>>> The Update Center team has a need for a cross-platform Actuator
>>> implementation that supports User Images.
>>>
>>> Tom and I have put together a proposal that we'd like to get
>>> feedback on:
>>>
>>> http://wiki.updatecenter.java.net/Wiki.jsp?page=UC22UserImageActuators
>>>
>>> Keep in mind this implementation would only be used on user images and
>>> would not be in play for OpenSolaris system images.
>>>
>>> If there isn't an RFE on this already I'll go ahead and create one.
>>>
>>> Joe
>
>
> I'm not exactly sure why this is needed, since the commands invoked as
> side effects run w/ the same priv. level as the components that are
> being run from the image.... this seems to propose a rich service-based
> architecture for user-images, the details of which aren't disclosed here.
This is part of my objection. The need for actuators in user images
seems to imply that a cross-platform service library should be
constructed. However, the approach the proposal takes is to allow
arbitrary code to execute as a side effect of the installation. This
violates our maxim against no scripting / no arbitrary code.
One of the design specifications listed for UserImageActuators states:
o Any failure of a UserImageAcutator hook must not cause an
imageplan evaluation to fail
Unforuntately, this is unenforceable if arbitrary code is executing.
It would make more sense to enhance the actions that are available for
user images. If service framework is really needed -- what problem are
we trying to solve anyway? -- it might make sense to extend actuators to
work with another service management framework. Let's not create another
mechanism to invoke arbitrary methods. We don't want non-deterministic
behavior in the install.
-j
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
