Service Configuration Repository

Information about each service is stored in the service configuration repository, which is also called the SMF database. The service configuration repository stores information such as the current state of each service instance on the system and the properties of each service and service instance.

The repository stores persistent configuration information as well as SMF runtime data for services.

Persistent configuration information is stored in layers according to the source of the data. See Repository Layers.
Runtime data, or non-persistent configuration information, is not preserved across reboot, and the repository does not store layer information for non-persistent data. Non-persistent data generally hold an active program state.

The repository also stores service template data, such as types, value constraints, and descriptions of properties. Template data is defined in the service manifest. See the smf_template (5) man page for more information about template data.

The service configuration repository can only be manipulated or queried by using SMF interfaces. Use the svcs, svcprop, svcadm, and svccfg commands or the Service Configuration Facility library functions listed in the libscf (3LIB) man page. You can read and write property values and show property values in specified layers and snapshots. For information about layers, see Repository Layers. For information about snapshots, see Repository Snapshots. You can show only the properties of the selected service instance or parent service, or you can show a composed view of properties. In a composed view, both properties set on the parent service and properties set on the service instance are shown; values shown are the values set on the service instance.

Service Bundles

A service bundle is an XML file that contains the information that is stored in the service configuration repository for a service or service instance. Information provided in service bundles is stored in the service configuration repository and can be exported from the repository. Service bundles in standard locations are imported into the repository during system boot.

The two types of service bundles are manifests and profiles.

Manifests

Manifests contain the complete set of properties associated with a specific set of services or service instances.

Profiles

Profiles typically provide customization of a service or service instance that augments or overrides information provided in the manifest. Examples of customizations include additional properties and changed property values.

The standard location for manifests is /lib/svc/manifest. The standard location for profiles is /etc/svc/profile.

When the system is booted or the manifest import service is restarted, manifests are imported and profiles are applied if they are new or changed. An IPS package that delivers a service bundle can specify that the manifest import service should be restarted when the package is installed.

Local customizations can be provided in profile files with an .xml suffix in the /etc/svc/profile/site directory. If the same property in the same repository layer for the same service or instance is defined by multiple manifests or profiles, SMF cannot determine which value to use. When this type of conflict is detected, the instance is placed in the maintenance state. See Repository Layers for more information about layers.

In addition to delivering services into Oracle Solaris, service bundles can also deliver custom configuration across a variety of systems.

A system profile, /etc/svc/profile/generic.xml, is applied during installation. Do not change this profile. Any changes made to this system profile will be overwritten on upgrade. See the smf_bootstrap (5) man page for more information.

Repository Layers

The service configuration repository can store different values for a single property. The repository stores data in layers according to the source of the data. The source can be manifests, system profiles, site profiles, and customizations made by using SMF commands and library interfaces. You can view values in different layers to understand the source of the value in the running configuration: whether a value was assigned in the manifest, in a profile, or was changed by an administrator.

Configuration changes made by using SMF commands and library interfaces appear only in the admin layer. Configuration in other layers is defined in profile and manifest files in standard locations. When a property is added to the repository from a file, the information about that property includes the name of that file.

Layer	Content
`admin`	Any changes that are made by using the SMF commands or library interfaces, by an administrator or by an application. The `admin` layer also includes any changes that are made by importing a manifest or applying a profile from a non-standard location. See Service Configuration Repository \| Importing and Applying Manifests and Profiles for caution about the use of non-standard locations.
`site-profile`	Any values from profile files in the `/etc/svc/profile/site` directory or the legacy `/etc/svc/profile/site.xml` and `/var/svc/profile/site.xml` profiles. Note that `/var/svc/profile` is deprecated as a standard location and should not be used for new profiles.
`system-profile`	Any values from the `/etc/svc/profile/generic.xml` and `/etc/svc/profile/platform.xml` system profiles.
`manifest`	Values from manifests in the `/lib/svc/manifest` and `/var/svc/manifest` directories. Note that `/var/svc/manifest` is deprecated as a standard location and should not be used for new manifests.

Property conflicts are not permitted within any layer. A conflicting property in the admin layer overwrites the previous property. If the same property is delivered by multiple files in any other layer, and is not set at a higher layer, the instance is tagged as in-conflict and is not started until the conflicting definition is removed or the property is set at a higher layer.

You can specify the layer of configuration data to view and therefore identify which data are administrative customizations and which data were delivered with the software. When a client does not specify the layer from which to retrieve configuration data, the topmost layer data is provided. The topmost layer is determined by the following priority order from top to bottom: admin layer, site-profile layer, system-profile layer, manifest layer. If a property has a value in the admin layer, that is the value that the repository delivers. In this way, local customizations are preferred over the values that were provided when the system was installed.

Repository Snapshots

The repository captures a read-only snapshot of each service each time the service is successfully started. These snapshots enable you to easily return to a previous working state if necessary. The following snapshots might be available for any given instance:

initial

Initial configuration when the service and its instances were imported for the first time. An initial snapshot is not created if a profile starts the service or instance before manifest import.

previousSMF automatically takes the following backups of the service configuration repository:

The boot backup is taken immediately before the first change to the repository is made during each system startup.

The manifest_import backups occur before svc:/system/early-manifest-import:default or svc:/system/manifest-import:default completes, if the service imported any new manifests or ran any upgrade scripts.

Four backups of each type are maintained by the system, with the oldest backups deleted as necessary.

You can restore the repository from one of these backups. See How to Restore a Repository From Backup.

Current configuration captured when a manifest import is performed for a service that has already been delivered. The service could have already been delivered by the manifest being imported or by another manifest.

running

The running configuration of the service instance. When you change configuration data, use the svcadm refresh or svccfg refresh command to promote the new values to the running snapshot.

start

Configuration captured during a successful transition to the online state.

Repository Backups

SMF automatically takes the following backups of the service configuration repository:

The boot backup is taken immediately before the first change to the repository is made during each system startup.
The manifest_import backups occur before svc:/system/early-manifest-import:default or svc:/system/manifest-import:default completes, if the service imported any new manifests or ran any upgrade scripts.

Four backups of each type are maintained by the system, with the oldest backups deleted as necessary.

You can restore the repository from one of these backups. See How to Restore a Repository From Backup.

Importing and Applying Manifests and Profiles

When you restart the manifest-import service, manifests in standard locations are imported and profiles in standard locations are applied if they are new or changed. See Service Bundles for manifest and profile standard locations. If importing a manifest or applying a profile results in the service being started or stopped, the appropriate method is executed if one exists.

Specifying a file in a standard location to the svccfg import command restarts the manifest-import service.

Recommended best practice is to put your manifest and profile files in the standard locations and restart the manifest-import service rather than use the svccfg import or svccfg apply commands.

$ svcadm restart manifest-import

When you restart the manifest-import service, the configuration in profiles and manifests in standard locations is applied to the manifest, system-profile, or site-profile layer of affected instances, affected instances are refreshed and validated, and a new snapshot is created.