1smf_bootstrap(5)      Standards, Environments, and Macros     smf_bootstrap(5)
2
3
4

NAME

6       smf_bootstrap  -  service management facility boot, packaging, and com‐
7       patibility behavior
8

DESCRIPTION

10       The service management facility establishes conventions for  delivering
11       service  manifests,  incorporating service manifest changes, describing
12       service configuration stability, using service configuration overrides,
13       and the use of service profiles.
14
15   Manifest Loading at Boot
16       The  svc:/system/manifest-import:default  service  uses  svccfg(1M)  to
17       import certain manifest files from the /var/svc/manifest directory tree
18       into  the  service  configuration repository. The service imports files
19       that it has not imported previously and those files which have  changed
20       since  the last time they were imported by the service. When a manifest
21       is imported by the service, a hash of the file that includes  its  con‐
22       tents is recorded in a property group of the svc:/smf/manifest service.
23       The manifest-import service uses the hash to determine whether the file
24       has changed. See svccfg(1M) for information on the svccfg import behav‐
25       ior for services that already exist in the repository.
26
27   Manifest Handling During Packaging Operations
28       Service manifests within packages should be identified with  the  class
29       manifest.  Class  action  scripts that install and remove service mani‐
30       fests are included in  the  packaging  subsystem.  When  pkgadd(1M)  is
31       invoked, the service manifest is imported.
32
33
34       When  pkgrm(1M) is invoked, instances in the manifest that are disabled
35       are deleted. Instances in the manifest that are online or degraded  are
36       disabled  first  and then deleted. Any services in the manifest with no
37       remaining instances are also deleted.
38
39
40       If the -R option is supplied to pkgadd(1M) or  pkgrm(1M),  the  actions
41       described in this section will be done when the system is next rebooted
42       with that alternate root path.
43
44   Stability Declarations
45       Each service group and each property  group  delivered  in  a  manifest
46       should  declare  a  stability level based on attributes(5) definitions.
47       With knowledge of the stability level,  an  application  developer  can
48       determine  the  likelihood  that feature development based on the exis‐
49       tence or components of a service or object is likely  to  remain  func‐
50       tional across a release boundary.
51
52
53       In  an smf(5) context, the stability value also identifies the expected
54       scope of the changes to properties within the property group  across  a
55       release  boundary  for  the service, which can include patches for that
56       service. The following two sections discuss this in more detail.
57
58   Property Overrides
59       The service_bundle(4) document type  definition  includes  an  override
60       attribute that is applicable to each property in a service manifest. If
61       set to true, the attribute  instructs  svccfg(1M)  and  other  manifest
62       import  tools to replace the current value of a property in the reposi‐
63       tory with the one from the  manifest.  If  the  override  attribute  is
64       absent or present but set to false, the current value in the repository
65       is preserved.
66
67
68       Property groups declared as Stable do not contain  override  attributes
69       on enclosed properties. Property groups declared as Evolving do so only
70       to correct an erroneous setting. Property groups declared  as  Unstable
71       can  contain  overrides on any property. The exception to this behavior
72       is for the stability property itself, which can be modified to identify
73       incipient change to the interface presented by the service.
74
75   Property Group Deletion
76       The  service_bundle(4)  document  type  definition  includes  a  delete
77       attribute, applicable to each property group in a service manifest.  If
78       set  to true, the delete attribute instructs svccfg(1M) and other mani‐
79       fest import tools to delete this property group from the repository. If
80       the  delete  attribute is absent or present but set to false, the prop‐
81       erty group in the repository is preserved.
82
83
84       Property groups declared as Stable or Evolving are not  deleted.  Prop‐
85       erty  groups  declared  as  Unstable  can be deleted across any release
86       boundary.
87
88   Profile Application
89       The first time the existence of each  of  the  three  service  profiles
90       listed below is detected, svc.startd(1M) automatically applies the pro‐
91       file.
92
93         /var/svc/profile/generic.xml
94         /var/svc/profile/platform.xml
95         /var/svc/profile/site.xml
96
97
98
99       The svc:/smf/manifest service is used in a similar fashion.
100
101
102       Additional service profiles that characterize the activation of various
103       groups  of service instances might be present in /var/svc/profile. None
104       of the /var/svc/profile  profiles  are  automatically  applied  to  the
105       repository.  A profile can be manually applied or re-applied using svc‐
106       cfg(1M).
107

SEE ALSO

109       pkgadd(1M), pkgrm(1M),  svcadm(1M),  svccfg(1M),  svc.startd(1M),  lib‐
110       scf(3LIB), service_bundle(4), attributes(5), smf(5), smf_security(5)
111

NOTES

113       The present version of smf(5) does not support multiple repositories.
114
115
116
117SunOS 5.11                        25 Sep 2008                 smf_bootstrap(5)
Impressum