We need to support an extensible set of "actions", which we define as reversible operations that a package can request to enable its later function on the target image.
Packages need a limited set of operations on individual files to manipulate the configuration. The current class actions are given in Appendix A. It appears that if "manifest" and "rbac" were supported, along with some management of editable files (preserve, renamenew, initd, renameold), then the remaining operations could be deferred to image instantiation.
From the legacy packaging system, we can inspect the class action scripts and the postinstall scripts to identify the set of common actions.
- depend
- Declare dependency on other packages.
- directory
- All directories.
- driver
- Package contains device driver Module loading will be disabled during operations on live images.
- file
- All other files. Preservation and rename handling are managed as optional tags.
- hardlink, link
- All hard and symbolic links.
- service
- Package contains service description. Inventoried services will be temporarily disabled during operations on live images.
- set
- Set a package tag.
- user, group
- Package requires user, group, or other package-reference managed resource.
XXX Is this set sufficient to boot? Should we somehow discriminate them from non-booting actions?
- legacy
- Record package attributes into legacy packaging metadata.
- license
- License files, which deliver into the image metadata rather than the image's filesystems.
XXX Do we have a hard-reboot, reconfigure-reboot, and/or soft-reboot action? Otherwise we are going to build path knowledge somewhere else in the packaging system.
Interface summary:
<interface> <action name="dependency" payload="false" commitment="Committed" /> <action name="directory" payload="false" commitment="Committed" /> <action name="hardlink" payload="false" commitment="Committed" /> <action name="legacy" payload="false" commitment="Committed" /> <action name="license" payload="true" commitment="Committed" /> <action name="link" payload="false" commitment="Committed" /> <action name="driver" payload="false" commitment="Committed" /> <action name="file" payload="true" commitment="Committed" /> <action name="group" payload="false" commitment="Committed" /> <action name="service" payload="true" commitment="Committed" /> <action name="user" payload="false" commitment="Committed" /> </interface>
- Custom actions
It is discouraged, but certainly possible to deliver custom actions into the appropriate $PYTHONROOT/vendor-packages/pkg directory, by including those actions in a separate package that the new package requires, and invoking the pkg(1) client twice--once to deliver the custom actions and once to use them to install the new package. (Rescanning pkg.actions would complicate the image plan/package plan evaluations.)
The deployer may wish to deny such actions from operating. For this case, the set of known actions is fixed elsewhere in the pkg modules and updated with subsequent versions. A global and per-image policy, known-actions-only, allows the deployer to disallow operations on packages utilizing actions of unknown provenance.
Interface:
<interface> <policy name="known-actions-only" scope="global,image" type="boolean" commitment="Committed"> Deployer control over execution of unknown actions. </policy> <interface>
Appendix A. Current class actions on Solaris NV.
Command output
> $ grep -v none /tmp/summary | > egrep 1[ef] | > cut -d -f 3 | > sort | uniq -c | sort -nr > 152 manifest > 129 preserve > 45 renamenew > 32 rbac > 30 initd > 30 fontsdir > 17 fontsalias > 16 appservenv > 10 ttmapsdir > 10 encodingsdir > 8 renameold > 6 build > 5 tiservices > 5 master > 5 asenv > 4 smfyes > 4 services > 4 immodules > 4 fontsupr > 4 fontsscale > 4 fontenc > 3 OWconfig > 2 smfno > 2 smf > 2 sendmail > 2 sed > 2 owfontpath > 2 fonttmap > 2 devlink > 2 append > 1 ypnicknames > 1 vfstab > 1 ttysrch > 1 ttydefs > 1 ttmapkoi8 > 1 ttmap13 > 1 syslogconf > 1 svmpreserve > 1 sshdconfig > 1 sock2path > 1 shadow > 1 sdconf > 1 scsivhciconf > 1 scsa2usbconf > 1 sampleslist > 1 rOWconfig > 1 qlc > 1 publickey > 1 powerconf > 1 policyconf > 1 pkcs11confbase > 1 passwd > 1 papersize > 1 pamconf > 1 opensslcnf > 1 nsswitch > 1 nscd > 1 nfssecconf > 1 netconfig > 1 ncalogd > 1 ncakmod > 1 nametomajor > 1 minorperm > 1 mailxrc > 1 mach > 1 logindevperm > 1 logadmconf > 1 localprofile > 1 locallogin > 1 krbconf > 1 keytable > 1 kclasses > 1 kcfconfbase > 1 iuap > 1 iscsiconf > 1 ipsecalgsbase > 1 initupdate > 1 inittab > 1 init > 1 inetdconf > 1 ibnexconf > 1 hosts > 1 group > 1 ftpusers > 1 ftpaccess > 1 fstypes > 1 fpconf > 1 fonttmap9 > 1 fonttmap7 > 1 fonttmap5 > 1 fonttmap4 > 1 fonttmap2 > 1 fonttmap15 > 1 fontenc9 > 1 fontenc7 > 1 fontenc5 > 1 fontenc4 > 1 fontenc13 > 1 etcsystem > 1 etcrpc > 1 etcremote > 1 etcprofile > 1 EtcDefLu > 1 drvalias > 1 dialers > 1 dhcpinittab > 1 devpolicy > 1 devlinktab > 1 defsu > 1 defrpcnisd > 1 defpasswd > 1 defnfs > 1 deflogin > 1 definit > 1 cronroot > 1 configmapconf > 1 bootenvrc > 1 automaster > 1 ataconf > 1 adpconf > 1 AddNoUpdate >