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 defines a series of conventions for importing the configuration contained within a service manifest or pro-
       file into a repository.

   Manifest loading at boot
       At system start, svc.startd(1M) run in default mode begins processing the manifests located  in	/var/svc/manifest  and	importing  new	or
       changed manifests into the repositorty.

       The decision to import a service manifest is based on the existence of a property group in the svc:/smf/manifest service with the following
       characteristics:

	 o  The name of the property group is the name of the imported manifest with non-alphanumeric characters replaced by underscore (_)  char-
	    acters.

	 o  The properties of the property group are set based on the manifest contents.

       The  manifest  is not reimported in the event that configuration changes are made to the repository by an administrator. Such configuration
       changes might include the deletion of one or more services or service instances contained within the manifest.  The  /var/svc/manifest/site
       directory is provided for site-specific customizations.

       The  deletion  of  a  property group by means of svccfg(1M) or libscf(3LIB) interfaces allows the manifest to be reimported on a subsequent
       system boot.

   Manifest handling during packaging operations
       Service manifests within packages are 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. Any services in the manifest with no remaining
       instances are also deleted.

   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
       svcadm(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.10							    27 Aug 2004 						  smf_bootstrap(5)