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 |
| Any changes that are made by using the SMF commands or library interfaces, by an administrator or by an application. The |
| Any values from profile files in the |
| Any values from the |
| Values from manifests in the |
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
bootbackup is taken immediately before the first change to the repository is made during each system startup.The
manifest_importbackups occur beforesvc:/system/early-manifest-import:defaultorsvc:/system/manifest-import:defaultcompletes, 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.