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, describ-
       ing 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  mani-
       fests 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  exis-
       tence 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 reposi-
       tory 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 ser-
       vice.

   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 pro-
       file.

	 /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.

SunOS 5.11							    25 Sep 2008 						  smf_bootstrap(5)