SMF_BOOTSTRAP(5) Standards, Environments, and Macros SMF_BOOTSTRAP(5)


NAME


smf_bootstrap - service management facility boot, packaging, and
compatibility behavior

DESCRIPTION


The service management facility establishes conventions for delivering
service manifests, incorporating service manifest changes, describing
service configuration stability, using service configuration overrides,
and the use of service profiles.

Manifest Loading at Boot


The svc:/system/manifest-import:default service uses svccfg(1M) to import
certain manifest files from the /var/svc/manifest directory tree into the
service configuration repository. The service imports files that it has
not imported previously and those files which have changed since the last
time they were imported by the service. When a manifest is imported by
the service, a hash of the file that includes its contents is recorded in
a property group of the svc:/smf/manifest service. The manifest-import
service uses the hash to determine whether the file has changed. See
svccfg(1M) for information on the svccfg import behavior for services
that already exist in the repository.

Manifest Handling During Packaging Operations


Service manifests within packages should be identified with the class
manifest. Class action scripts that install and remove service manifests
are included in the packaging subsystem. When pkgadd(1M) is invoked, the
service manifest is imported.


When pkgrm(1M) is invoked, instances in the manifest that are disabled
are deleted. Instances in the manifest that are online or degraded are
disabled first and then deleted. Any services in the manifest with no
remaining instances are also deleted.


If the -R option is supplied to pkgadd(1M) or pkgrm(1M), the actions
described in this section will be done when the system is next rebooted
with that alternate root path.

Stability Declarations


Each service group and each property group delivered in a manifest should
declare a stability level based on attributes(5) definitions. With
knowledge of the stability level, an application developer can determine
the likelihood that feature development based on the existence or
components of a service or object is likely to remain functional across a
release boundary.


In an smf(5) context, the stability value also identifies the expected
scope of the changes to properties within the property group across a
release boundary for the service, which can include patches for that
service. The following two sections discuss this in more detail.

Property Overrides


The service_bundle(4) document type definition includes an override
attribute that is applicable to each property in a service manifest. If
set to true, the attribute instructs svccfg(1M) and other manifest import
tools to replace the current value of a property in the repository with
the one from the manifest. If the override attribute is absent or present
but set to false, the current value in the repository is preserved.


Property groups declared as Stable do not contain override attributes on
enclosed properties. Property groups declared as Evolving do so only to
correct an erroneous setting. Property groups declared as Unstable can
contain overrides on any property. The exception to this behavior is for
the stability property itself, which can be modified to identify
incipient change to the interface presented by the service.

Property Group Deletion


The service_bundle(4) document type definition includes a delete
attribute, applicable to each property group in a service manifest. If
set to true, the delete attribute instructs svccfg(1M) and other manifest
import tools to delete this property group from the repository. If the
delete attribute is absent or present but set to false, the property
group in the repository is preserved.


Property groups declared as Stable or Evolving are not deleted. Property
groups declared as Unstable can be deleted across any release boundary.

Profile Application


The first time the existence of each of the three service profiles listed
below is detected, svc.startd(1M) automatically applies the profile.

/var/svc/profile/generic.xml
/var/svc/profile/platform.xml
/var/svc/profile/site.xml


The svc:/smf/manifest service is used in a similar fashion.


Additional service profiles that characterize the activation of various
groups of service instances might be present in /var/svc/profile. None of
the /var/svc/profile profiles are automatically applied to the
repository. A profile can be manually applied or re-applied using
svccfg(1M).

SEE ALSO


pkgadd(1M), pkgrm(1M), svcadm(1M), svccfg(1M), svc.startd(1M),
libscf(3LIB), service_bundle(4), attributes(5), smf(5), smf_security(5)

NOTES


The present version of smf(5) does not support multiple repositories.


September 25, 2008 SMF_BOOTSTRAP(5)