Standards, Environments, and Macros              smfbootstrap(5)



NAME
     smfbootstrap - 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 pro-
     files.

  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 configura-
     tion  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 man-
     ifest 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  sub-
     system.  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 sys-
     tem 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 attri-
     butes(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.



SunOS 5.11          Last change: 25 Sep 2008                    1






Standards, Environments, and Macros              smfbootstrap(5)



     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 servicebundle(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  reposi-
     tory 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. Pro-
     perty  groups  declared as Unstable can contain overrides on
     any property. The exception to this behavior is for the sta-
     bility  property  itself,  which can be modified to identify
     incipient change to the interface presented by the service.

  Property Group Deletion
     The servicebundle(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) automati-
     cally 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.




SunOS 5.11          Last change: 25 Sep 2008                    2






Standards, Environments, and Macros              smfbootstrap(5)



     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),   servicebundle(4),  attri-
     butes(5), smf(5), smfsecurity(5)

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









































SunOS 5.11          Last change: 25 Sep 2008                    3