Please review the draft below of the ARC case for phase 1 of the
Enhanced SMF Profiles project.
David
Template Version: @(#)sac_nextcase %I% %G% SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Enhanced SMF Profiles, Phase 1
1.2. Name of Document Author/Supplier:
Author: David Bustos
1.3 Date of This Document:
9 January 2009
4. Technical Description
== Background
The Service Management Facility (SMF) [1] interacts with service
implementations according to configuration data in the Service
Configuration Facility (SCF), commonly referred to as the "SMF
repository". Service authors deliver configuration defaults through
service manifests, which conform to service_bundle(4), and system
administrators customize the configuration. SMF also provides SCF
interfaces for service authors to store service-specific
configuration.
== Problems
1. To deliver a service which will be enabled by default, the SMF
policy [2] directs authors to specify this not in the service's
manifest file with the rest of the configuration, but instead in
system profile files, generic_open.xml and generic_limited_net.xml
in /var/svc/profile .
This isn't sufficient for services introduced after Solaris 10 FCS
because on upgrade the facility doesn't re-apply the profile files,
so changes are not propagated into the SCF repository. This is due
to insufficient functionality: SCF doesn't record whether the
configuration data modified by profiles is customized by the
administrator or not. Without that information, the SMF team chose
not to re-apply the profile files to avoid overwriting
administrative customizations.
Developers of such services have been advised to append upgrade
code to the /var/svc/profile/upgrade file, which the facility
executes as a shell script on each boot. This workaround is
error-prone and raises development costs. The file's stability is
Contracted Project Private so that it may someday be replaced by
more maintainable mechanisms. This issue is recorded as change
request 6510895 "shouldn't need contracted interface to enable
service at boot after upgrade/install".
Developers of services which require modifications to the
platform_*.xml profiles encounter similar problems.
2. The SMF interfaces allow a service developer to deliver a manifest
which prescribes an SMF service without instances, and for tools to
create instances of such a service at runtime. ksslcfg(1M) does
this.
If an administrator upgrades a package with such a service manifest
to a version with different manifest contents, the changes will not
be propagated to the SCF repository. This is because SMF uses the
"last-import" snapshot of service instances to store information
needed to determine which properties have been customized by the
administrator. But SCF doesn't offer snapshots for services
(without instances), so when the manifest prescribes no instances,
no last-import snapshots are created and svccfg cannot determine
whether properties have been customized.
This is documented in change request 6447345 "svccfg import doesn't
upgrade instanceless manifests".
3. SMF only allows profile files to specify whether particular
services should be enabled or disabled. Since the built-in
procedure to replicate SCF customizations across multiple computers
is an SMF profile file (/var/svc/profile/site.xml), the procedure
cannot propagate customizations of service-specific SCF
configuration, or even standard SMF configuration such as
dependencies and method parameters. Some users might view the need
to develop their own software for this purpose as a regression from
plain configuration files. As developers place more configuration
into SCF, this will become more of a problem.
Permitting profile files to modify configuration besides
enabledness would also make some operations simpler and more
maintainable. For example, the Secure By Default project [3] found
that some services should be enabled in the both of the modes
represented by generic_open.xml and generic_limited_net.xml, but
with different service-specific behavior. Although the behaviors
can be controlled by SCF properties, modifying them had to be
hard-coded into the netservices(1M) command. Specifying values for
these properties in the generic_*.xml profiles would simplify the
netservices command, and is required to replace it with generic SMF
commands.
4. SCF allows configuration data to be customized by administrators
and promises to retain customizations across upgrades, but there is
no built-in procedure to determine what has already been
customized. This will become more dissatisfying as developers
place more configuration into SCF.
5. The SCF interfaces to create and populate services and instances
are not atomic. If svccfg is interrupted or encounters a fault
while executing the import subcommand, partially populated services
or instances may be left behind, as may be a temporary service
necessary to create the last-import snapshot mentioned in
problem 2 above. (These temporary services are named with
a "TEMP/" prefix.) The service manager (svc.startd) avoids acting
on partial services and instances because it knows that svccfg
import creates the general/enabled property last. This protocol
isn't documented for other SCF readers to benefit from.
Furthermore, subsequent svccfg import invocations will exit when
they discover the temporary service, and will inform the user that
it must be deleted.
6. Modifications to configuration data through SCF interfaces are
effectively buffered in a staging area. The "svcadm refresh"
command is required to commit pending changes to the "running"
snapshot, which is intended to be the authoritative source for
configuration for each service instance. svccfg import uses the
same modification interfaces to upgrade the configuration of
a service to that prescibed by a new version of the service
manifest. If there are uncommitted changes, svccfg currently
deletes them, which could be confusing to users.
7. If a service developer delivers a new version of a package which
delivers a new version of a service manifest which has had
a service removed, and an administrator upgrades to the new
package, SMF will not delete the old service because it doesn't
record which services are associated with each manifest.
8. If a service manifest in /var/svc/manifest is removed by means
other than the packaging system (most likely because it was placed
there by means other than package delivery), SMF will not delete
the services it delivered. Like problem 7, this is because SMF
doesn't record which services are associated with each manifest.
(Note that this happened when packages were removed from inactive
roots (i.e., pkgrm -R) until 6438829 "SMF svcs are not removed when
performing a pkgrm in an alternate root" was fixed recently.)
== Solutions
- Enhance SCF to record which data has been customized by an
administrator. Introduce a Project Private interface by which
service manifests can be imported atomically and profile files can
be applied without disturbing administrative customizations or
uncommitted changes. Modify the boot process to re-apply the
generic_*.xml and platform_*.xml profiles through this interface
after each upgrade (and perhaps more frequently). This should
obviate many uses of the /var/svc/profile/upgrade file.
SCF will determine which modifications are administrative
customizations by the interface through which they are requested.
Service manifests and profiles applied through the new interface
will be attributed to service authors. All other persistent changes
will be attributed to administrators. This will result in false
positives from programs which modify SCF data for reasons other than
to record administrative desires. For example, services which
automatically disable themselves based on runtime context.
Preventing this may be possible with heuristics, or may require new
interfaces. Both are deferred to a future phase of this project.
- Enhance the service_bundle(4) DTD and the svccfg apply command to
permit profile files to specify values for arbitrary properties on
services and instances.
- Add "listcust" and "delcust" subcommands to the svccfg(1M) command
which list and delete administrative customizations. In addition to
allowing administrators to undo mistaken customizations, delcust is
required to remove false customizations introduced by the process of
upgrading to a svc.configd capable of recording administrative
customizations.
These interfaces require new libscf interfaces, which will be
Project Private.
Note that in anticipation of future changes, the delcust subcommand
will require the "-c" option, and will fail without it.
- Enhance SCF to be able to record the association between service
manifests and the services and instances they deliver. When service
manifests in /var/svc/manifest are changed, use the information to
remove services and instances absent from the new versions.
- Enhance SMF boot functionality to delete services and instances in
SCF associated with service manifests which no longer exist in
/var/svc/manifest.
== Secondary Changes
We believe the changes below are logical corollaries to those above.
- When a service or instance exists due to a service manifest in
/var/svc/manifest, attempts to delete it from the SCF repository
will fail. The primary way to remove such services and instances
will be to remove the package which delivers the manifest file, or
for files manually placed in /var/svc/manifest, a new "delmanifest"
subcommand for svccfg.
- When a service manifest's specification for whether a service
instance should be enabled or disabled is changed, the change will
be propagated into the SCF repository if the administrator has not
customized it. Similarly for changes to service instances'
restarters. (Currently svccfg import always assumes these
properties are customized and never changes them during upgrade.)
- When the generic_*.xml and platform_*.xml profiles (or more
precisely, any profile applied through the new profile application
interface) prescribes property modifications for services or
instances which do not exist, the overrides will be retained and
will be applied when the services or instances are created. The
presence of this data can only be inferred from the files -- public
interfaces to enumerate them in the SCF repository are deferred to
a future phase of this project.
- The netservices command will not override administrative
customizations. When administrative customizations override changes
it prescribes, it will print warnings for the user.
- The running snapshots of the instances of each service will share
a single version of the service's properties. Correspondingly, when
the properties of a service are changed and a refresh operation is
executed for one of the instances, refresh operations will also be
executed for the other instances of the service.
We believe this change in the frequency of the refresh operation to
be backwards compatible, and only list it here for full disclosure.
== References
[1] PSARC 2002/547 Greenline
[2] SMF usage policy
http://opensolaris.org/os/community/arc/policies/SMF-policy/
[3] PSARC 2004/368 Secure By Default, Phase 1
http://opensolaris.org/os/community/arc/caselog/2004/368/
== Binding
This project is intended for a minor release.
== Interfaces Exported
SCF_ERROR_DELIVERED ? Committed
scf_instance_delete Committed
scf_service_delete Committed
/usr/sbin/netservices obsolete XXX
/usr/sbin/svccfg apply semantics Committed
/usr/sbin/svccfg delcust invocation Committed
/usr/sbin/svccfg delmanifest invocation Committed
/usr/sbin/svccfg listcust invocation Committed
/usr/sbin/svccfg output Not-an-interface
/usr/share/lib/xml/dtd/service_bundle.dtd.1 Committed
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
