hey all,
so in an effort to get pkg image-update to work with zones, i've been
prototyping support for linked images within pkg(5). i don't have a fully
functional prototype to pass around yet, but i have documented some
aspects of my prototype in an initial design doc. i've attached that doc
so that people can take a look, see what i'm thinking, provide feed
back, etc. all comments and criticism are welcome.
ed
" please ensure that the vim modeline option is not disabled
vim:textwidth=72
------------------------------------------------------------------------------
ips pkg(5) zones integration - v0.3
----------
** 00 - Summary **
To allow for support of pkg(5) within zones and the automatic management
and upgrading of zones during global zone pkg(5) operations, this
proposal describes enhancements to pkg(5) to support "linked images".
The pkg(5) linked images functionality proposed herein is intended to
be generic, with zones being one type of linked images that can be
supported. In addition to supporting zones linked images we also propose
supporting another "default" type of linked images. The details of how
these linked image types differ will be explained in more detail below.
Another goal of the pkg(5) linked image support is to make all the
linked image functionality visible to other pkg(5) subsystems common,
and to isolate code dealing with the different linked image types within
well defined modules contained within the linked image subsystem. ie,
while other pkg(5) subsystems may need to be aware of linked images,
they should not have to worry about specific linked image types.
Linked images will have properties associated with them. The set of
available properties may vary across different linked image types. The
storage location for these properties values (ie, linked image metadata)
may be plugin specific. For the "default" plugin, property data
configuration will live within a /var/pkg configuration file. For the
"zones" linked image plugin, property configuration will be derived from
the zones subsystem (some properties will have implicit values, others
may be derived from zonecfg(1m) parameters, etc.)
The rest of this proposal is broken up into the following sections:
** 01 - zones requirements **
** 02 - linked image types **
** 03 - out of scope **
** 04 - pkg(5) linked image overview **
** 05 - pkg(1) cli enhancements, private interfaces **
** 06 - pkg(1) cli enhancements, public interfaces **
------------------------------------------------------------------------------
** 01 - zones requirements **
The design for pkg(5) linked images as proposed herein is primarily being
driven by the need to support zones. Hence, before jumping into the
specifics of linked images support it is worth discussing some
requirements placed upon the linked image design by the need to support
zones.
Zones is a OS level virtualization technology, so essentially it
provides a mechanism to run multiple userland execution environment on a
single kernel. Each of these userland execution environments is a
separate virtual machine, with it's own filesystem, processes, network
stack, etc. The default execution environment (ie, the one you get when
you install Solaris or OpenSolaris) is called the global zone.
Subsequent execution environments are called non-global zones and can be
created and managed via zonecfg(1M) and zoneadm(1M).
All the zones on a system share the same kernel, and the kernel is
managed by the global zone. Non-global zone can not supply their own
kernel modules. Hence, any software within a zone which spans the
user/kernel boundary must be kept in sync with the kernel installed in
the global zone. This puts constraints on what software can be
installed within zones. The basic requirements here can be summed up
as:
- software installed in a non-global zone that depends on specific
kernel functionality must be kept in sync with the kernel software
installed within the global zone.
- software that depends on specific kernel functionality can only be
installed in a non-global zone if the corresponding kernel
functionality is installed within the global zone.
Since non-global zones separate virtual machines with their own
filesystems and software, these machines (and their software contents)
may not be trusted by the global zone. Hence any software management
operations being done on non-global zone should not be able to affect
the global zone. Effectively this means that all actions performed on a
zone cannot safely be done from the global zone environment. This
means that software management operations initiated from a global zone
will either have to "enter" the zone (if it's running) to perform their
operation, or setup a safe environment (commonly called a scratch zone)
which they can enter to perform the requested operation. But the basic
requirements here can be summed up as:
- software management operations will need to span multiple processes
operating in different zones.
- since zones are untrusted execution environment, global zone pkg(5)
operations should not be required to read data from non-global zone.
ie, any data flow required to support linked images must be from a
global zone to a non-global zone, and never in the reverse direction.
Lastly, since non-global zones are separate virtual machines, they will
normally not have access to the contents of the global zone. Yet the
software that can be run in non-global zones is constrained by the
software installed in the global zone. Hence:
- all the constraints required to perform software management operations
within a non-global zone must be available within that zone.
------------------------------------------------------------------------------
** 02 - linked image types **
So in addition to supporting zones linked image, the design herein has
also considered other planned and possible linked image types. So before
going into the details of the linked image design it's worth while to
first describe all the possible linked image types to understand when
and where they might be used.
---------
Zones linked images
Support for zones linked images is included in this proposal. Users
will not be able to directly create or manage zones linked images.
Instead the system will automatically manage zones linked images when
zones are used. Zones linked images should provide us with with a means
to do the following:
- allow for the creation of non-global zone images where the contents of
those images is based on a defined content policy and the software
installed in the global zone.
- allow for the updating of software within an existing non-global zone
based on a defined content policy and the software installed in the
global zone.
- allow pkg(5) operations initiated from the global zone to update
non-global zone images as required based on a content policy and the
software being updated in the global zone.
- allow for pkg(5) operations initiated directly upon non-global zone
image to take into account the constraints placed upon then by the
content policy and software installed in the global zone.
---------
Default linked images
Support for default linked images is included in this proposal. These
types of linked images will be very similar to zone linked images. All
the features listed above that will be available for zones linked images
will also be available for default linked images. But unlike zone
linked images, the system administrator will be able to create and
manage default linked images themselves.
Support for default linked images is included in this proposal because
default linked images will be used internally by the zones subsystem
when managing scratch root zones. More information on this specific
usage is available below. Also, having a "default" linked image type
will greatly facilitate the testing of linked image functionality, the
large majority of which is common to all linked image types.
---------
User linked images
Support for user linked images is NOT included in this proposal. These
type of images would be managed very differently from zones or default
linked images. User linked images could provide us with the following
functionality:
- allow for arbitrary users to create user linked images, where
the contents of that image is based on a user specific policy and the
software installed in another image.
- allow for a user to update the software within an existing user
linked image based on a user specific policy and the software
installed in another image.
- allow for pkg(5) operations initiated upon a user linked image to take
into account the constraints placed upon then by the content policy and
software installed in another image.
- allow for the auditing of a user linked image to verify that it is in
sync with it's content policy and software installed in another image.
So here's an example of how a user linked image might work. Say a user
named Ed wants to run a copy of SpamAssassin on a system named jurassic,
but jurassic doesn't have SpamAssassin installed. Ed could then create a
"user" linked image that has a content policy of "augment" and that is
linked to the jurassic system image. Then he could install SpamAssassin
into that image. Pkg(5) would install a version of SpamAssassin that is
compatible with the software contents already installed on jurassic. (In
the process of doing this pkg(5) would also install into the user image
any dependencies required by SpamAssassin that were missing from
jurassic.) Ed could then run this version of SpamAssassin without having
to worry about his software being out of sync with the system. The
system administrator would have no knowledge of user images that might
be created on a system, hence, if the administrator updates the software
on a system then any user images may now be out of sync. In this case,
Ed would be able to perform an audit of all his user linked images to
determine if they are in sync with their specified policy and the
contents of the system they are being used on. If they were out of sync
(due to the system being updated) he could then initiate a sync
operation to update them and bring them back in sync.
---------
Diskless client linked images
Support for user linked images is NOT included in this proposal. These
types of images would probably not be managed directly, but would
probably be managed indirectly by diskless client management tools. One
possible deployment model for diskless clients would be to create a
master image which represents the standard diskless client configuration
deployment, and then to create linked images all parented to that one
master image. These linked images would actually be the diskless client
root filesystems. Subsequent software management operations could be
performed on the master image, with changes automatically propagated to
all the client images automatically based on the content policy of the
linked images.
------------------------------------------------------------------------------
** 03 - out of scope **
There are many components which will probably be required to allow
pkg(5) and zones to work seamlessly together. This proposal does not
address all of them. Specifically, the following features may need to
be delivered by future projects.
----------
1) The system publisher. When managing zone linked images, it's
critical that certain packages be kept in sync between global and
non-global zones. This means that zones must have access to any
packages that must be kept in sync between the images, regardless of the
zones publisher configuration. Some additional complications to this
problem are that for zones which are not running, we may not be able to
instantiate their network configuration, so we may not be able to talk
to any of their configured publishers. We also eventually plan to use
scratch zones to provide security when upgrading zones, and currently
scratch zones do not have any networking configuration. The generally
discussed solution to these problems has been the "system publisher".
This would be a publisher that would appear within running and scratch
zones and make available any packages required to keep the images in
sync. How this mechanism would look, work, what packages would be made
available, etc is all out of scope for this proposal.
Initially, zones linked image support will not use scratch zones and
will rely on zones having a publisher configuration which provides
access to all the packages required to keep the zone in sync.
It has also been pointed out to me that the "system publisher" may be a
poor name for this functionality, since it's highly likely that this
functionality will not want to actually "publish" any new packages. it
will simply want to make packages available to an image via a different
mechanism. (it might be more appropriate to call this functionality the
"system pkg depot", "system repo", "system pkg proxy", etc.)
----------
2) Offline zone install. This proposal does nothing to address the
current requirement that an active network connection to a valid package
repository be available during most pkg(5) operations. If anything, this
proposal will increase the number of operations that may require such a
connection to be available.
----------
3) Zones image locking. When performing pkg(5) operations in a global
zone that affect the contents of the global zone, we need a locking
mechanism to prevent concurrent operations from being done within a
non-global zone. We also need a locking mechanism that allows for the
reverse. Ie, if a zone is in the middle of a pkg(5) operation we don't
want to initiate an operation from the global zone which might also
require updating that zone. Other scenarios that we will probably also
need to protect against include a zone changing state while we're
performing a pkg(5) operation on that zone. For example, if we're
installing a package in a global zone which results in us also
installing a package in a non-global zone, we need to prevent that
non-global zone from rebooting while we're installing the package.
Another example is that if we're installing or removing a package from a
global zone, we will probably want to prevent a concurrent install of a
non-global zone since that could results in the freshly installed zone
being out of sync with the global zone. This proposal does not address
any of the possible race conditions wrt pkg(5) and zone linked image
operations.
----------
4) Pkg(5)/beadm(1M) image filesystem management. Currently, beadm(1M)
allows for versioning (via snapshotting and cloning) of multiple
filesystem in a global zone image, assuming all those filesystems are
zfs based and are all children of the current root filesystem. beadm(1M)
treats any other filesystems in the current BE as shared and lofs mounts
them into any other alternate BE. This means that if any pkg(5)
software is installed into these "shared" filesystems that software will
become out of sync wrt some BE. Pkg(5) and beadm(1M) do not do any do
any check to ensure that all the software being installed installed is
not being installed into "shared" filesystems. This same problem also
affects zones. This proposal does not address this issue in any way and
assumes that eventually pkg(5) or beadm(1M) will provide more flexible
and robust functionality to manage images that span multiple filesystem.
----------
5) Beadm(1M) support for linked images. Currently, beadm(1M) can be run
within the global zone to manage global zone boot environments and their
associated zones. But beadm(1M) does not support running within a
non-global zone and creating snapshots of zone boot environments from
within a zone. Beadm(1M) support within a zone is a requirements for
supporting pkg(5) image-update within a zone. (Since image-update only
operates on alternate boot environments.) It is also the case that other
pkg(5) operations may refuse to operate on the currently running image
and may only be run on cloned and offline boot environments. Since
beadm(1M) can not be run within a zone, we can't create cloned boot
environments within a zone, so none of these operations will be
supported.
Additionally, beadm(1M) is currently aware of zones images, but
eventually, beadm(1m) should probably become linked image aware, since
all linked images should be snapshotted, cloned, and upgraded in sync.
Enhancing beadm(1M) will be required to support non-zone types of linked
images that live outside the current boot environment. Once this
project delivers initial pkg(5) linked image interfaces it will be
possible to update beadm(1M) to consume these interfaces so that it can
be aware of all linked images on the system, instead of just zone
images. These beadm(1M) enhancements are out of the scope of this
proposal.
------------------------------------------------------------------------------
** 04 - pkg(5) linked image overview **
pkg(5) linked images will always always have a master and slave
relationship (which may also be referred to as a parent / child
relationship). Master images may have multiple slaves, but each slave
image may only have one master. It's possible for there to be multiple
levels of linked images, for example, you could have a user linked image
which is a child of a zone linked image.
----------
** 04.1 - pkg(5) linked image naming **
All pkg(5) linked images are uniquely identified by a name. A fully
qualified linked image name is <linked image type>:<linked image name>.
The linked image name must begin with an alphanumeric character and can
contain alphanumeric characters, underscores (_), hyphens (-), and dots
(.). Additional restrictions on the <linked image name> format may be
defined by the linked image plugin which the corresponding image type.
----------
** 04.2 - pkg(5) linked image constraint data **
When an pkg(1) operation is performed on a linked image, we must take
into account the constraints placed on that image by it's corresponding
master image. Those constrains consist of the linked image type, the
content policy of the linked image, and the relevant portions of package
contents of the master image (as required by the content policy).
When performing a pkg(1) operation in a linked image, all the image
constraints data must be directly accessible within the slave image
without requiring access the master image. The reasons for this policy
are two-fold. First, we may want to be able to perform operations on
linked images when no master image is available. For zones linked images
this will be the common case when pkg(1) is run within a zone. It may
also be the common case when attempting to attach a linked image to a
new system. (more information about attaching and detaching linked
images is presented below.) Second, in the case of nested images it
quickly becomes untenable to reach back through multiple parent images
in an attempt to extract image constraints data.
Hence, linked images will provide a facility to mange image constraints
data independently of other pkg(1) operations. This will be done via a
image constraints data export or import. A given linked image type will
usually support either export or import of master image constraint data.
For example, for zones linked image the master image will export
constraint data to zones linked images whenever the master image is
updated. For another example, a given master image may not be aware of
user linked user images that have been created, because of this user
linked images will need to import constraint data from a given master
image before performing linked image operations.
Within an image, master data will reside in one of the following
locations (depending on if the linked image type supports exporting or
importing of linked image constraints):
/var/pkg/linked/master/export
/var/pkg/linked/master/import
The specific data that will always be available in one of these
locations is:
- the linked image type
- the linked image content policy
- a minimal list of package contents of the master image
required to enforce the selected pkg policy
Also, if a pkg(1) operation is in progress on a master image, and that
master image supports exporting of data to a linked image, then the
export directory may also contain:
- a minimal list of planned package contents of the master image
required to enforce the selected pkg policy
In general, a master image is only aware of linked images which support
exporting of constraint data. This is required to allow the master image
to perform operations on slave images. (Examples of these types of
linked images would be default and zones linked images.) Linked image
types which support only support importing of constraint data will
generally be unknown to their master image and will be managed
independently of that image. (An example of this type of linked image
would be a user linked image.)
----------
** 04.3 - pkg(5) linked image constraint representation **
When an pkg(1) operation is performed on a linked image, pkg(1) must
take into account the current constraints placed on that image by it's
associated master image. These constraints are available in a raw form
from within the linked image itself as described above. Within pkg (1)
itself, these constraints will be represented by dynamic package that do
not exist in any repository or on disk, but instead only exist in memory
when pkg(1) is running.
These special packages will be referred to as in-core only packages. We
are reserving the publisher name "none" for these in-core only packages
so that they may have a fully qualified name. The pkg(1) command will
not attempt to write information for any package from the "none"
publisher to disk and it will never try to download data for packages
from the "none" publisher. A pkg(1) list will display in-core only
packages and pkg(1) contents can be used to display the contents of
in-core only packages.
The constraints imposed upon a linked image are represented by the
following in-core package which will always appear as installed within a
linked image:
pkg://none/linkedimage/constrai...@0,0-0:<timestamp>
The constraints on the image are represented within this package by by
"incorporate" and "exclude" actions. For example, if the image has a
"sync-cip" content policy, then there will be a "incorporate" entry
within the package above for every cip installed within the global zone.
There will also be an "exclude" dependency for every cip in the known
package catalog that is not installed within the global zone.
It's worth noting that the "incorporate" entries within this package are
different from most normal incorporations in that they specify packages
versions which include a timestamp. (Normally incorporation actions only
specify package versions which do not include a timestamp.)
If a linked image is not in sync with it's current constraints, then the
package listed above will appear to be installed within the image, but
it will have no contents. This is because if the package did contain
contents which represented the constraints on the image then the image
would be self inconsistent wrt package metadata, and the pkg solver
would be unable to make any valid changes to the image since it's
initial state is invalid. In this case there will be an additional
in-core package which will be available in the known package catalog:
pkg://none/linkedimage/constrai...@0,0-1:<timestamp>
This package will contain the constraint data that would normally be
contained within the aforementioned package. To bring an out-of-sync
image in sync with it's constraints, we will need to install this new
package. Since currently the pkg(1) command will not remove packages by
default, the user may be required to remove packages from within the
linked image manually for this operation to be successful. Also, for
this procedure to work we assume that syncing up the image would not
involve downgrading any packages within the image, ie, it would only
involve installing new packages or upgrading packages to newer versions.
This type of operation would be the basis for features like zone
update-on-attach, where a zone is moved from one host to another and
then it is updated to be in sync with the new host so that it can be
attached and booted.
Finally, there is one last in-core only package that may be available
within a linked image:
pkg://none/linkedimage/constrai...@0,0-2:<timestamp>
This package will be available if an update operation is in progress
within the master image. In this case the constraints imposed upon the
linked image may be changing, so this new package will represent the new
linked image constraints. When planning updates to the linked image we
must ensure that this new package is included within any resultant pkg
plan so that the linked image stays in sync with it's master image.
----------
** 04.4 - pkg(5) linked image properties **
As mentioned earlier in the summary, each linked image will have
properties associated, some properties will be common to all images
while others may be specific to certain image types. the storage
location for these properties values (ie, linked image metadata) may be
plugin specific and in the case of zones will probably be stored outside
of pkg(5) itself.
Initially the following properties will be supported.
-----
<li-type> - This denotes the plugin that is used to manage the linked
image. This property will be common to all linked image types.
-----
<li-path> - This is the filesystem path by which the image is accessible.
This property will be common to all linked image types.
It's possible for a linked image to exist but not be accessible; an
example of this would be when a non-root user runs a pkg command, all
zone linked image paths will not be accessible. In these cases pkg(1)
will simply report the path as "<inaccessible>". If pkg is attempting
to do a read-only operation on an image that has inaccessible child
linked images, pkg(1) will simply skip over the inaccessible children.
If pkg(1) is attempting to do an operation which requires writing to an
image, all children must be accessible and if any child is not
accessible the operations will fail and no updates will be made to any
image.
-----
<li-content-policy> - This controls the policy used to manage the content
of the associated linked image. This property will be common to all
linked image types. Possible content policy settings are:
"sync-cip" - Ensures that a linked image has certain "core image
packages" in sync with the master image. a "core image package" is a
'cip' package. these packages will be defined by a property within the
package. If a cip is installed in a linked image, it must also be
installed and at the same version (including pkg timestamp) in the
master image. This policy is the default for zones.
"sync-all" - Ensures that the package contents of a linked image
exactly match that of the master image. This includes keeping all pkg
versions (including pkg timestamp) in sync. This would provide users
with an zones deployment experience similar to that provided by sparse
root zones in solaris 10.
"superset" - Implies "sync-cip". Also ensures that any non-core
image packages which are installed in the master image are also
installed in the linked image, but no version constraints are imposed on
the non-core image packages. Such a policy could be useful in
environments where administrators want slave images to contain all the
packages installed within the master image, but they also want to retain
the ability to install packages into slave images without requiring that
they be installed in the associated master image.
----------
<li-update-policy> - This controls how pkg(1m) image-update operations
initiated from a master image deal with slave images. This property only
exists for linked image types which support exporting of constraint
data. Possible update policies are:
"independent" - In this case, we will first determine the pkg
updates possible in the master image independently of the slave image.
Once we determine what updates can be done to the master image, we will
also do a separate image-update operation for each slave image, taking
into account any policy constraints imposed by the planed update for the
master image. This policy is the default for zones.
"independent-minimal" - In this case, we will first determine
the pkg updates possible in the master image independently of the slave
image. Once we determine what updates can be done to the master image,
we will then attempt to determine the minimal amount of changes required
to the slave image to keep it in sync with its content policy and the
planned changes within the master image.
Using either policy above, it's possible the we may discover that we are
unable to perform the master image updates because doing so would result
in a slave image which no longer in sync with its content policy. In
this case it will be the administrators responsibility to remove the
slave image (in the case of a zone, the administrator could detach it)
or by making some other adjustment to the image (perhaps by removing a
package or pkg constraint which is preventing the update).
-----
<li-master-path> - The filesystem path to a linked images corresponding
master image. This property only exists for linked image types which
support importing of constraint data.
----------
** 04.5 - pkg(5) linked image operation planning **
Currently pkg(1) has multiple stages of operation when manipulating
images. The stages most relevant to linked image operations are:
1 - Package install/uninstall/upgrade planning
2 - Package action planning
3 - Package content downloading
4 - Action execution
Since dealing with zones will involve performing pkg operations that
span multiple processes, it would be convenient to have a mechanism
where by the stages above could be split among multiple processes. To
this end a new option will be added to pkg(1) to allow the saving of pkg
operation planning data to disk and to support subsequent re-loading of
the data to resume execution of subsequent stages. This same mechanism
can also be leveraged to facilitate the exporting of pkg plans from a
master image to slave images.
XXX: eventualy, perhaps this can be done away with by using a pipe
to sync operations across multiple package processes?
------------------------------------------------------------------------------
** 05 - pkg(1) cli enhancements, private interfaces **
----------
pkg(1) [--runid=%d] [--plan={default|pkgs|actions|download|execute}] ...
The --runid and --plan options are used internally within pkg(1) when
spawning subprcess to work on linked images.
If pkg(1) is run without specifying a runid, the runid will default to
the current pkg(1) process pid. The runid is used when:
- saving package and action plans to disk
- loading package and action plans from disk
- exporting a master package plan to a slave image.
- loading a master package plan within a slave image.
The pkg(1) --plan option tells pkg(1) what operation it should be doing.
If --plan is not specified this is equilivant to --plan=default If
--plan=pkgs is specified then pkg(1) will plan possible package updates,
save them to disk, and exit. If --plan=actions is specified, then
pkg(1) will load a package plan from disk (previously created with
--plan=pkgs), plan what actions are required to implement the planned
package changes, save the action plan to disk, and exit. If
--plan=download is specified, pkg(1) will load a package and action
plans from disk, download any content required to execute the actions,
and exit. If --plan=execute is specified, pkg(1) will load a package
and action plans from disk and execute them.
------------------------------------------------------------------------------
** 06 - pkg(1) cli enhancements, public interfaces **
----------
pkg(1) linked-list
List all known images associated with the current image. When listing
images, each image has a type, name, and path. The image type
corresponds to the plugin used to manage the image.
Example output of this command might be:
---8<---
$ pkg linked-list
TYPE NAME PATH
default scratch_root /var/pkg/images/scratch_root
zone zone1 <inaccessible>
$ pfexec pkg linked-list
TYPE NAME PATH
default scratch_root /var/pkg/images/scratch_root
zone zone1 /export/zones/zone1/root
---8<---
In the example above, in the first invocation of pkg we see that the
zone linked image path is inaccessible to the current user. In the
second invocation of pkg (using pfexec), the zone linked image path is
displayed.
----------
pkg(1) linked-property [-l <name>]
All linked images have properties. These properties may be plugin
specific. This interface allows us to view all the properties associated
with a specific linked image. If no linked image is specified then if
the current image is a linked image it's known properties are listed.
Example output of this command might be:
---8<---
# pkg linked-property
Image has no linked properties
# pkg linked-property -l zone1
PROPERTY VALUE
li-content-policy sync-cip
li-path /export/zones/zone1/root
li-type zone
---8<---
----------
pkg(1) linked-export {-a|-l <name>}
pkg(1) linked-import
These pkg(1) commands export or import master image constraints data to
a linked image.
When exporting constraint data the caller must specify -a for all images
or the name of a specific image to export constraint data. If we attempt
to export data to a linked image type that only supports importing of
constraint data, an implicit constraint import will be done on the
linked image.
When importing constraints via linked-import, the constraint data is
always imported to the current image. If the current image is not a
linked image, or if the current image linked image type does not support
importing of constraint data, or if the current images master image
isn't accessible, an error will be generated.
----------
pkg(1) linked-audit [-l <name>]
Linked-audit will verify that the contents of a linked image are in sync
with the master image constraints stored within the linked image. If no
linked image is specified with the -l option, then the current image
will be assumed to be a linked image and will be used as the target of
the audit.
This functionality will be used by the zones framework whenever we boot
a zone to verify that a zones image contents match its specified content
policy. Prior to invoking the linked-audit, the zones framework will
first do a linked-export to ensure that the constraint data contained
within the zone is in sync with the global zone.
----------
pkg(1) linked-sync [-l <name>]
Linked-sync will attempt to bring an image in sync with the master image
content constraints stored within the image. If the current linked image
is already in sync (ie, if a linked-audit operation would not return an
error) then this operation would be a no-op.
This functionality will be used by the zones framework to implement
zones update-on-attach.
----------
pkg(1) linked-unlink [-l <name>]
Linked-unlink will disassociate a linked image from it's master image.
If -l is not specified, the current image must be a linked image that
only supports importing of master constraint data. (Ie, the master
image must not be aware of the current image.)
----------
pkg(1) image-create {--linked=<name>|-l <name>}
-o li-type=<...> [-o <...>=<...>] <path>
Create a linked image that is a slave of the current image. Currently
only the li-type options is required to be specified, although future
linked image plugins may require additional options to be specified.
By default the linked image publisher configuration will be copied from
the current image. Eventually, once there is a system publisher that
linked images can use, no default publisher configuration will be
installed into the new image.
If the type of linked image being created support exporting of linked
image data, then the existence of this image will be recorded within the
master image and subsequent master linked image operations will be aware
of this image. If the type of linked image being created only supports
importing of master image data, then the master image will be unaware of
the newly created linked image.
----------
pkg(1) -I <name> ...
Normally, when pkg(1) performs an operation which affects linked images,
that operation will be applied to all known linked images. The -I option
tells package to ignore a specific linked image when performing an
operation.
----------
pkg(1) image-destroy {<path>|-l <name>}
Allows a user to destroy an image specified by <path> or a linked image
specified by "<name>". Certain linked image types (like zones) may not
support this functionality (since zone images are intended to be managed
via zoneadm(1m) commands and not directly via pkg(1) commands).
----------
pkg(1) linked-set-property [-l <name>] <propname> <propvalue>
This command can be used to change properties on certain types of linked
images. Changing "li-content-policy" can result in packages being added,
removed, or updated within the specified linked image. This command can
also be used to update the name and path associated with a linked image.
(In the case of updating the path, pkg(1) will not actually move the
contents of the image from the old path to the new path. It is the
responsibility of the caller to do that.)
------------------------------------------------------------------------------
XXX
Old stuff below, needs to eventually be re-integrated.
------------------------------------------------------------------------------
** pkg(5) "default" and "zones" linked image plugins **
The "default" linked image plugin will store linked image information
and properties within in the master image in /var/pkg/li_cache. It will
also store linked image property values within the linked image itself.
When this plugin is operating on images it will use publishers and keys
configured within the master image when planning updates to linked
image. (Eventually this behavior could be configurable by a linked
image property.)
The pkg(5) "zones" linked image plugin will for the most part be a thin
wrapper around the "default" plugin. The main difference will be in how
linked image configuration information is stored. In the case of the
"zones" linked image plugin, linked image information will not be stored
within the master image in /var/pkg, instead the zones plugin will be
able to obtain (or derive) linked image configuration values from the
zonecfg xml files.
------------------------------------------------------------------------------
** beadm(1m)/libbeadm integration **
XXX
------------------------------------------------------------------------------
** scratch zones and untrusted linked images **
Currently in Solaris 10 and Nevada, the process of upgrading and
patching zones is done via scratch zones. Scratch zones are described
in detail in: PSARC/2005/474 Zones Upgrade (Ashanti and Zulu).
The scratch zone concept can be though of as an improved chroot()
environment. (A chroot() environment could be used in place of scratch
zones, but chroot() has known security issues that are fixed with
scratch zones.) Scratch zones also add a bit of complexity to the zones
framework, but luckily, with the advent of pkg(5) for image management
there are aspects of the scratch zones design that can be revisited and
simplified.
One of the most complex components of the scratch zone implementation is
that scratch zones attempt to create an safe execution that is in sync
with the global zone, but doesn't expose any of the (possibly sensitive)
configuration from the global zone. This is accomplished by using a
mishmash of lofs mounts from both the global and non-global zone. (For
example, within the scratch zone /usr is mounted from the global zone,
while /etc is lofs mounted from the non-global zone to avoid exposing
any global zone configuration files in /etc, then additionally /etc/fs
is lofs mounted from the global zone because it contains binaries we
might want.) Happily, pkg(5) makes the generation of new system images
easy, and utilizing linked images we can easily create a new and safe
image that can be utilized as the root within a scratch root
environment. So when a linked image is created for which the
"li-trusted" property is "False", the "default" plugin will create a new
linked image in /var/pkg/images/scratch_root that can be read-only lofs
mounted for use within scratch zones.
Another aspect of scratch zones which can be simplified is that
currently scratch zones are always associated with a configured zone.
This is because, currently, when a scratch zone is mounted we mount any
filesystems specified within the zones configuration file. This is
unnecessary and undesirable. The problem is that filesystem specified
within a zone configuration are shared across boot environments. Since
these filesystem are shared we can't modify any software stored within
these shared filesystem, since upgrading them in one environment would
cause that software to be out of sync in another. To avoid this the
scratch zone mechanism can be separated from a particular zone instance.
With these two simplifying assumptions we can generalize the scratch
zone mechanism to allow the "default" linked image plugin to utilize it
for upgrading any untrusted linked image. The zoneadm(1m) mount command
(which is the command used to create scratch zones) will be modified to
allow for for the following invocation:
zoneadm -z <zonename> mount <scratch_root_path> <image_path>
If <zonename> does not correspond to any zone on the system, a new zone
with the specified name will be instantiated in the kernel,
<scratch_root_path> will be lofs mounted as the root of the scratch
zone, and <image_path> will be lofs mounted as /a within the scratch
zone environment. The "default" linked image plugin can instantiate
these dynamic scratch zone root environments whenever it needs to
manipulate a untrusted linked image.
If <zonename> corresponds to an existing zone on the system, then the
command will function in the same was as described above, but any
additional filesystems specified in the zonecfg(1m) for that zone will
also be mounted. (This mechanism can be used by non-native brands to
manipulate zone images that may span filesystems.)
------------------------------------------------------------------------------
** Rejected: representing constraints in the pkg namespace **
XXX
------------------------------------------------------------------------------
** Rejected: unified li-update-policy **
"unified" - In this case, when attempting to determine what pkg
updates are possible, we can have the sat solver look at all possible
package updates to the master and slave images at the same time. For
example, if we have a master image with the pkg A installed, and we have
the following sat solver rules:
A -> A'
Then the sat solver will tell us we can upgrade A to A'. Now if we had
a master and slave image, one way to evaluate the upgrade possibilities
would be to evaluate both images at the same time. Say M.A represents
package A installed in the master image and S.A represents A installed
in the slave image. also, pkg A must be kept in sync between the two
images. so to evaluate our upgrade possibilities we could run the sat
solver with the following rules:
M.A -> M.A'
S.A -> S.A'
!M.A | !S.A
!M.A' | !S.A'
Using this policy can result in master image updates being constrained by
the contents of slave images.
------------------------------------------------------------------------------
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
