unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (SunOS-5.10)
Page:
Section:
Apropos / Subsearch:
optional field

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



NAME
       smf_bootstrap  -  service management facility boot, packaging, and com-
       patibility 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  mani-
            fest  with  non-alphanumeric characters replaced by underscore (_)
            characters.

         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 mani-
       fest. 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  func-
       tional 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 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 mani-
       fest import tools to delete this property group from the repository. If
       the  delete  attribute is absent or present but set to false, the prop-
       erty group in the repository is preserved.

       Property groups declared as Stable or Evolving are not  deleted.  Prop-
       erty  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),  lib-
       scf(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)