Bugzilla – Bug 6994
Need actuator implementation for user images
Last modified: 2009-03-04 18:38:12 UTC
You need to log in before you can comment on or make changes to this bug.
The current SMF based Actuator implementation supports OpenSolaris system images. It was not designed to support cross-platform user images. An Actuator implementation for user images is needed. Some requirements: 1. It must not rely on SMF (which does not exist on all platforms) 2. It must support non-root users. 3. It must not rely on files being installed outside of the user image 4. It must be implementable on a variety of OS platforms The request is to create a UserImageActuator implementation of Actuator that is used only when executing an image plan on a user image.
To generalize the SMF Actuator implementation for UserImageActuator the proposal is to replace the service fmri's with a path to a command. The command is passed a single parameter that reflects the disposition of the hook. Attribute Behavior --------------------------------------------------------------------- user_disable_cmd=cmd Run 'cmd disable' before file is removed user_suspend_cmd=cmd Run 'cmd disable' before file is installed, updated or removed, and then run 'cmd enable' after file is installed, updated, or removed user_restart_cmd=cmd Run 'cmd restart' after file is installed, updated or removed user_refresh_cmd=cmd Run 'cmd refresh' after file is installed, updated or removed Notes: 1. cmd is relative to the User image root 2. cmd is run synchronously before or after the imageplan is evaluated 3. If cmd does not exist or is not executable then it is ignored 4. An imageplan for a User Image will use the UserImageActuator. An imageplan for a system image will use the current Actuator implementation 5. If the same attribute/cmd is specified for multiple file actions it is only executed once either before or after the imageplan is evaluated. Further details can be found here: http://wiki.updatecenter.java.net/Wiki.jsp?page=UC22UserImageActuators
This would allow arbitrary scripting / code to be run as part of the install. To do so is a flagrant violation of our design principles. Another approach is needed. The one that is proposed is not acceptable.
I understand the arbitrary scripting concerns and the design principle, and agree that in the context of an OS system image that design principle must be strictly adhered to. But in the context of a user image I think we have greater flexibility, and this actuator implementation will only be used in the context of a user image. Note that the design includes requirements to preserve the integrity of the installation: o Any failure of a UserImageAcutator hook must not cause an imageplan evaluation to fail o Must not support actuator hooks that perform any form of user interaction I feel the proposed design is a fair compromise between something that satisfies the requirements user images have (cross-platform, non-root, non-SMF, files only installed in user image) and the concerns wrt package scripting -- while staying simple and implementable.
The problem with arbitrary scripting is that it's arbitrary. You essentially have an unbounded operation that can do anything it wants to the system with no recourse for the user. If you must have scripting, then you're going to need to document the specific usage cases and how you intend to sandbox those scripts.
In the context of this design, it will be important to articulate exactly what the design constraint regarding scripting is. I don't think the constraint is as simple as just "no scripting". Rather, the problem with postinstall/preremove scripting in SVR4 packaging is that the scripts are executed in the context of the process doing the installation rather than in the context of the target environment. For example, when a SPARC system is jumpstarted by an x86 system, the scripts are executed on x86 rather than SPARC. The so-called "no scripting" mantra in pkg(5) is about preventing the scripts from executing in the wrong context. The SMF actuators design for pkg(5) allows arbitrary scripting to be delivered within a package. The difference from SVR4 scripting is that the scripts are always executed within the context of the target image, not the installer. The same is true with this design for user image actuators. The design constraint of making sure that scripts are executed in a well-defined, limited context is still preserved.
(In reply to comment #5) There's a considerable amount of nuance that hasn't been addressed in the proposed design. > The SMF actuators design for pkg(5) allows arbitrary scripting to be delivered > within a package. The actuators aren't involved in pkg(5) delivery. One can arbitrarily deliver anything using pkg(5), irrespective of the actuators implementation. > The difference from SVR4 scripting is that the scripts are always executed > within the context of the target image, not the installer. That is one difference. The SMF actuators define how pkg(5) interacts with a service management framework, not how scripts are invoked. > The same is true with this design for user image actuators. The design > constraint of making sure that scripts are executed in a well-defined, > limited context is still preserved. This is contrary to the design explained in comment #1. The actuators get invoked maximally once per package. The proposed design talks about executing code as files and packages are added and removed. Further, the image must be live in order for these operations to complete successfully. The SMF implementation doesn't require a live image, nor do we want to make it a requirement that these types of installs only occur on live images. Looking at this problem from a design standpoint, it's really intractable to have every package deliver its own scripts for image actuators. We've witnessed years of scripting abuse with SYSV, and there's no need to repeat the same mistake. There are other approaches that could solve this problem. It would make sense to find a more generally acceptable one.
I agree the proposal stated in this bug is flawed. Instead of morphing this bug into an alternative approach I'm closing it to make way for a fresh start.