.. CDDL HEADER START
.. The contents of this file are subject to the terms of the
Common Development and Distribution License (the "License").
You may not use this file except in compliance with the License.
.. You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
See the License for the specific language governing permissions
and limitations under the License.
.. When distributing Covered Code, include this CDDL HEADER in each
file and include the License file at usr/src/OPENSOLARIS.LICENSE.
If applicable, add the following below this CDDL HEADER, with the
fields enclosed by brackets "[]" replaced with your own identifying
information: Portions Copyright [yyyy] [name of copyright owner]
.. CDDL HEADER END
.. Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
.. :vim:set expandtab:
Supported Actions
-----------------
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>
1. 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
>