1smf_bootstrap(5) Standards, Environments, and Macros smf_bootstrap(5)
2
3
4
6 smf_bootstrap - service management facility boot, packaging, and com‐
7 patibility behavior
8
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
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
113 The present version of smf(5) does not support multiple repositories.
114
115
116
117SunOS 5.11 25 Sep 2008 smf_bootstrap(5)