1 Template Version: @(#)sac_nextcase %I% %G% SMI 2 This information is Copyright 2009 Sun Microsystems 3 1. Introduction 4 1.1. Project/Component Working Name: 5 Enhanced SMF Profiles, Phase 1 6 1.2. Name of Document Author/Supplier: 7 Author: David Bustos 8 1.3 Date of This Document: 9 27 January 2009 10 4. Technical Description 11 12 == Background 13 14 The Service Management Facility (SMF) [1] interacts with service 15 implementations according to configuration data in the Service 16 Configuration Facility (SCF), commonly referred to as the "SMF 17 repository". Service authors deliver configuration defaults through 18 service manifests, which conform to service_bundle(4), and system 19 administrators customize the configuration. SMF also provides SCF 20 interfaces for service authors to store service-specific 21 configuration. 22 23 == Problems 24 25 1. To deliver a service which will be enabled by default, the SMF 26 policy [2] directs authors to specify this not in the service's 27 manifest file with the rest of the configuration, but instead in 28 system profile files, generic_open.xml and generic_limited_net.xml 29 in /var/svc/profile . 30 31 This isn't sufficient for services introduced after Solaris 10 FCS 32 because on upgrade the facility doesn't re-apply the profile files, 33 so changes are not propagated into the SCF repository. This is due 34 to insufficient functionality: SCF doesn't record whether the 35 configuration data modified by profiles is customized by the 36 administrator or not. Without that information, the SMF team chose 37 not to re-apply the profile files to avoid overwriting 38 administrative customizations. 39 40 Developers of such services have been advised to append upgrade 41 code to the /var/svc/profile/upgrade file, which the facility 42 executes as a shell script on each boot. This workaround is 43 error-prone and raises development costs. The file's stability is 44 Contracted Project Private so that it may someday be replaced by 45 more maintainable mechanisms. This issue is recorded as change 46 request 6510895 "shouldn't need contracted interface to enable 47 service at boot after upgrade/install". 48 49 Developers of services which require modifications to the 50 platform_*.xml profiles encounter similar problems. 51 52 2. The SMF interfaces allow a service developer to deliver a manifest 53 which prescribes an SMF service without instances, and for tools to 54 create instances of such a service at runtime. ksslcfg(1M) does 55 this. 56 57 If an administrator upgrades a package with such a service manifest 58 to a version with different manifest contents, the changes will not 59 be propagated to the SCF repository. This is because SMF uses the 60 "last-import" snapshot of service instances to store information 61 needed to determine which properties have been customized by the 62 administrator. But SCF doesn't offer snapshots for services 63 (without instances), so when the manifest prescribes no instances, 64 no last-import snapshots are created and svccfg cannot determine 65 whether properties have been customized. 66 67 This is documented in change request 6447345 "svccfg import doesn't 68 upgrade instanceless manifests". 69 70 3. SMF only allows profile files to specify whether particular 71 services should be enabled or disabled. Since the built-in 72 procedure to replicate SCF customizations across multiple computers 73 is an SMF profile file (/var/svc/profile/site.xml), the procedure 74 cannot propagate customizations of service-specific SCF 75 configuration, or even standard SMF configuration such as 76 dependencies and method parameters. Some users might view the need 77 to develop their own software for this purpose as a regression from 78 plain configuration files. As developers place more configuration 79 into SCF, this will become more of a problem. 80 81 Permitting profile files to modify configuration besides 82 enabledness would also make some operations simpler and more 83 maintainable. For example, the Secure By Default project [3] found 84 that some services should be enabled in the both of the modes 85 represented by generic_open.xml and generic_limited_net.xml, but 86 with different service-specific behavior. Although the behaviors 87 can be controlled by SCF properties, modifying them had to be 88 hard-coded into the netservices(1M) command. Specifying values for 89 these properties in the generic_*.xml profiles would simplify the 90 netservices command, and is required to replace it with generic SMF 91 commands. 92 93 4. SCF allows configuration data to be customized by administrators 94 and promises to retain customizations across upgrades, but there is 95 no built-in procedure to determine what has already been 96 customized. This will become more dissatisfying as developers 97 place more configuration into SCF. 98 99 5. The SCF interfaces to create and populate services and instances 100 are not atomic. If svccfg is interrupted or encounters a fault 101 while executing the import subcommand, partially populated services 102 or instances may be left behind, as may be a temporary service 103 necessary to create the last-import snapshot mentioned in 104 problem 2 above. (These temporary services are named with 105 a "TEMP/" prefix.) The service manager (svc.startd) avoids acting 106 on partial services and instances because it knows that svccfg 107 import creates the general/enabled property last. This protocol 108 isn't documented for other SCF readers to benefit from. 109 Furthermore, subsequent svccfg import invocations will exit when 110 they discover the temporary service, and will inform the user that 111 it must be deleted. 112 113 6. Modifications to configuration data through SCF interfaces are 114 effectively buffered in a staging area. The "svcadm refresh" 115 command is required to commit pending changes to the "running" 116 snapshot, which is intended to be the authoritative source for 117 configuration for each service instance. svccfg import uses the 118 same modification interfaces to upgrade the configuration of 119 a service to that prescibed by a new version of the service 120 manifest. If there are uncommitted changes, svccfg currently 121 deletes them, which could be confusing to users. 122 123 7. If a service developer delivers a new version of a package which 124 delivers a new version of a service manifest which has had 125 a service removed, and an administrator upgrades to the new 126 package, SMF will not delete the old service because it doesn't 127 record which services are associated with each manifest. 128 129 8. If a service manifest in /var/svc/manifest is removed by means 130 other than the packaging system (most likely because it was placed 131 there by means other than package delivery), SMF will not delete 132 the services it delivered. Like problem 7, this is because SMF 133 doesn't record which services are associated with each manifest. 134 (Note that this happened when packages were removed from inactive 135 roots (i.e., pkgrm -R) until 6438829 "SMF svcs are not removed when 136 performing a pkgrm in an alternate root" was fixed recently.) 137 138 == Solutions 139 140 - Enhance SCF to record which data has been customized by an 141 administrator. Introduce a Project Private interface by which 142 service manifests can be imported atomically and profile files can 143 be applied without disturbing administrative customizations or 144 uncommitted changes. Modify the boot process to re-apply the 145 generic_*.xml and platform_*.xml profiles through this interface 146 after each upgrade. This should obviate many uses of the 147 /var/svc/profile/upgrade file. 148 149 SCF will determine which modifications are administrative 150 customizations by the interface through which they are requested. 151 Service manifests and profiles applied through the new interface 152 will be attributed to service authors. All other persistent changes 153 will be attributed to administrators. This will result in false 154 positives from programs which modify SCF data for reasons other than 155 to record administrative desires. For example, services which 156 automatically disable themselves based on runtime context. 157 Preventing this may be possible with heuristics, or may require new 158 interfaces. Both are deferred to a future phase of this project. 159 160 - Enhance the service_bundle(4) DTD and the svccfg apply command to 161 permit profile files to specify values for arbitrary properties on 162 services and instances. 163 164 - Add "listcust" and "delcust" subcommands to the svccfg(1M) command 165 which list and delete administrative customizations. In addition to 166 allowing administrators to undo mistaken customizations, delcust is 167 required to remove false customizations introduced by the process of 168 upgrading to a svc.configd capable of recording administrative 169 customizations. 170 171 These interfaces require new libscf interfaces, which will be 172 Project Private. 173 174 Note that in anticipation of future changes, the delcust subcommand 175 will require the "-c" option, and will fail without it. 176 177 - Enhance SCF to be able to record the association between service 178 manifests and the services and instances they deliver. When service 179 manifests in /var/svc/manifest are changed, use the information to 180 remove services and instances absent from the new versions. 181 182 - Enhance SMF boot functionality to delete services and instances in 183 SCF associated with service manifests which no longer exist in 184 /var/svc/manifest. 185 186 == Secondary Changes 187 188 We believe the changes below are logical corollaries to those above. 189 190 - When a service or instance exists due to a service manifest in 191 /var/svc/manifest, attempts to delete it from the SCF repository 192 via "svccfg delete", scf_service_delete(3SCF), or 193 scf_instance_delete(3SCF) will fail. The way to remove such 194 services and instances depends on how the manifest was delivered. 195 If it was delivered by a package, then the package should be 196 removed and the packaging system will direct SCF to remove all 197 services and instances delivered by the manifest. 198 199 For manifests placed in /var/svc/manifest by a user outside of the 200 packaging system, we'll provide a new "delmanifest" subcommand of 201 svccfg. The user should remove the manifest and then invoke 202 svccfg delmanifest to remove all services and instances associated 203 with the file. 204 205 - When a service manifest's specification for whether a service 206 instance should be enabled or disabled is changed, the change will 207 be propagated into the SCF repository if the administrator has not 208 customized it. Similarly for changes to service instances' 209 restarters. (Currently svccfg import always assumes these 210 properties are customized and never changes them during upgrade.) 211 212 - When the generic_*.xml and platform_*.xml profiles (or more 213 precisely, any profile applied through the new profile application 214 interface) prescribes property modifications for services or 215 instances which do not exist, the overrides will be retained and 216 will be applied when the services or instances are created. The 217 presence of this data can only be inferred from the files -- public 218 interfaces to enumerate them in the SCF repository are deferred to 219 a future phase of this project. 220 221 - The netservices command will not override administrative 222 customizations. When administrative customizations override changes 223 it prescribes, it will print warnings for the user. 224 225 - The running snapshots of the instances of each service will share 226 a single version of the service's properties. Correspondingly, when 227 the properties of a service are changed and a refresh operation is 228 executed for one of the instances, refresh operations will also be 229 executed for the other instances of the service. 230 231 This change is only in the frequency of the refresh operation. We 232 believe it to be backwards compatible, so it is only listed here for 233 full disclosure. 234 235 == References 236 237 [1] PSARC 2002/547 Greenline 238 239 [2] SMF usage policy 240 http://opensolaris.org/os/community/arc/policies/SMF-policy/ 241 242 [3] PSARC 2004/368 Secure By Default, Phase 1 243 http://opensolaris.org/os/community/arc/caselog/2004/368/ 244 245 == Binding 246 247 This project is intended for a minor release. 248 249 == Interfaces Exported 250 251 SCF_ERROR_DELIVERED ? Committed 252 253 scf_instance_delete Committed 254 scf_service_delete Committed 255 256 /usr/sbin/netservices obsolete XXX 257 258 /usr/sbin/svccfg apply semantics Committed 259 /usr/sbin/svccfg delcust invocation Committed 260 /usr/sbin/svccfg delmanifest invocation Committed 261 /usr/sbin/svccfg listcust invocation Committed 262 /usr/sbin/svccfg output Not-an-interface 263 264 /usr/share/lib/xml/dtd/service_bundle.dtd.1 Committed 265 266 6. Resources and Schedule 267 6.4. Steering Committee requested information 268 6.4.1. Consolidation C-team Name: 269 ON 270 6.5. ARC review type: FastTrack 271 6.6. ARC Exposure: open 272
Indexes created Fri Nov 27 18:53:17 UTC 2009
Terms of Use |
Privacy |
Trademarks |
Copyright Policy |
Site Guidelines |
Help
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Use.
Copyright © 1995-2008 Sun Microsystems, Inc.