SMF の概念

この節では、SMF フレームワーク内で使われる用語とその定義をいくつか紹介します。これらの用語は、マニュアル全体で使用されます。SMF の概念を理解するには、これらの用語を理解する必要があります。

SMF サービス

SMF フレームワークでの基本的な管理単位は「サービスインスタンス」です。それぞれの SMF サービスでは、構成された複数のバージョンを保持することができます。さらに、1 つの システム上で同じバージョンの複数のインスタンスが動作できます。「インスタンス」とは、サービスの特定の構成のことです。 Web サーバーはサービスです。ポート 80 で待機するよう構成された Web サーバーデーモンはインスタンスです。Web サーバーサービスの各インスタンスには、異なる構成要件を設定できます。サービスにはシステム全体の構成要件が設定されていますが、各インスタンスでは必要に応じて特定の要件を無効にできます。1 つのサービスの複数のインスタンスは、サービスオブジェクトの子オブジェクトとして管理されます。

サービスは、in.dhcpd や nfsd などの標準の長年続いているシステムサービスだけではなく、ISV アプリケーションを含むさまざまなシステムエンティティーも表します。また、次のような今まであまり使われなかったエンティティーを表すこともできます:

• 物理ネットワークデバイス

• IP アドレス構成

• カーネル構成情報

• マルチユーザー実行レベルなど、システムの init 状態に対応するマイルストーン

一般に、サービスはアプリケーションやほかのサービス (ローカルやリモート) に機能リストを提供するエンティティーです。サービスは、暗黙的および明示的に宣言されたローカルサービスのリストに依存しています。

マイルストーンは特別な種類のサービスです。マイルストーンサービスは、システム即応性のレベルを表します。たとえば、実行レベルは SMF ではマイルストーンによって表されます。また、マイルストーンを使用して、svc:/milestone/name-services:default (ネームサービスの場合) や svc:/milestone/config:default (sysconfig サービスの場合) のようなサービスグループの即応性を示すこともできます。

SMF の依存性

依存性は、サービス間の関係を定義します。これらの関係により、すべてのサービスを再起動するのではなく、障害の影響を直接受けているサービスのみを再起動することにより、障害を的確に封じ込めることができます。依存性により、スケーラブルで再現可能な初期化プロセスも実現します。最後に、正確な依存性の定義によって、すべての独立したサービス群を並列的に起動できるため、並列性の高い最新のマシン群をシステムのスタートアップで利用することが可能になります。

サービスの再起動動作は、依存性ごとの restart_on 属性によって定義されます。依存するサービスがエラーや別の理由で停止した場合、あるいは更新された場合に停止するようサービスを構成できます。このプロセスによってサービスが停止されたあと、依存するサービスが起動するとすぐに、サービスは自動的に再起動されます。たとえば、ssh サービスには、network/ipfilter サービスに対する依存性があります。restart_on 属性は error に設定されています。この場合、network/ipfilter サービスがエラーによって停止すると、ssh サービスが停止され、自動的に再起動されます。ほかの種類のイベントが発生した場合、ssh サービスは停止されません。

サービス識別子

各サービスインスタンスの名前は、障害管理リソース識別子 (FMRI) によって付けられます。FMRI には、サービス名とインスタンス名が含まれます。たとえば、rlogin サービスの FMRI は svc:/network/login:rlogin となり、ここでの network/login はサービスを、rlogin はサービスインスタンスをそれぞれ示します。

次の FMRI の形式はどれも同じです。

• svc://localhost/system/system-log:default

• svc:/system/system-log:default

• system/system-log:default

また、多くの SMF コマンドでは、あいまいさがない場合に、省略したサービス名またはインスタンス名を使用できます。たとえば、長い形式ではなく system-log を直接使用できます。どの FMRI 形式が適切かについては、svcadm(1M) や svcs(1) などの SMF コマンドのマニュアルページを参照してください。

サービス名には、各サービスの目的をわかりやすく表す接頭辞が含まれます。これらの接頭辞には、application、device、milestone、network、system などの名前が含まれます。site 接頭辞はサイト固有のカスタマイズ用に予約されており、この接頭辞を使用するサービスは Oracle Solaris リリースで配布されません。

また、従来の init.d スクリプトは、svc ではなく lrc で始まる FMRI (たとえば、lrc:/etc/rc2_d/S47pppd) で表現されます。レガシーサービスの、システムブート中の初期起動時間は svcs コマンドを使用して表示されます。ただし、SMF を使用してこれらのサービスを管理することはできません。

初期のシステム配備中、/etc/inetd.conf に記述されたサービスは自動的に SMF サービスに変換されます。これらのサービスの FMRI は多少異なります。変換された inetd サービスの構文は次のとおりです:

network/service-name/protocol

また、RPC プロトコルを使用するサービスの構文は次のとおりです。

network/rpc-service-name/rpc_protocol

ここで、service-name は /etc/inetd.conf に定義されている名前であり、protocol はそのサービスに使用されるプロトコルです。inetconv コマンドを使用して、初期システム配備後に inetd.conf エントリを変換することができます。

サービスの状態

svcs コマンドは、サービスインスタンスの状態、開始時刻、および FMRI を表示します。各サービスの状態は次のいずれかになります。

• degraded – サービスインスタンスは有効ですが、限られた能力で実行されています。

• disabled – サービスインスタンスは無効で、実行されていません。

• legacy_run – 従来のサービスは SMF によって管理されませんが、監視することはできます。この状態は従来のサービスでのみ使用されます。

• maintenance – サービスインスタンスに、管理者が解決しなければならないエラーが発生しました。

• offline – サービスインスタンスは有効ですが、サービスが実行されていないか、利用できる状態にありません。

• online – サービスインスタンスは有効で、正常に起動されました。

• uninitialized – この状態は、すべてのサービスの構成が読み込まれる前の初期状態です。

遷移中のインスタンスの状態にはアスタリスク「*」が付加されます。疑問符「?」は、状態が存在しないか、認識されない場合に表示されます。

SMF マニフェスト

SMF マニフェストは、サービスと一連のインスタンスを記述する XML ファイルです。マニフェストをインポートすることにより、サービスのプロパティーとインスタンスがサービス構成リポジトリにロードされます。SMF マニフェストの詳しい内容については、service_bundle(4) のマニュアルページを参照してください。

マニフェストの推奨される場所は /lib/svc/manifest です。この場所に格納されたマニフェストは、ブートプロセスの間、どのサービスが起動するよりも前に svc:/system/early-manifest-import:default サービスによってインポートおよびアップグレードされます。インポートプロセスを早期に実行することにより、サービスが起動するよりも先に、最新のマニフェストに含まれる情報がリポジトリに確実に取り込まれます。通常時は、svcadm restart manifest-import コマンドを実行することによって、これらのマニフェストから情報をインポートすることができます。/var/svc/manifest は互換性のために引き続き使用できますが、この場所にあるマニフェストは、svc:/system/manifest-import:default サービスが実行されるまではインポートもアップグレードもされません。

Oracle またはほかのソフトウェアベンダーによって配布されるマニフェストに変更を加えないでください。アップグレード時にカスタマイズがすべて失われるため、/lib/svc/manifest および /var/svc/manifest 内のマニフェストを直接編集しないでください。代わりに、サイトプロファイルを作成してサービスをカスタマイズするか、svccfg または inetadm コマンドを使用してプロパティーを直接操作してください。/lib/svc/manifest/site および /var/svc/manifest/site ディレクトリも、サイト固有の用途のために予約されています。Oracle Solaris リリースは、これらのディレクトリにはマニフェストを配布しません。

Oracle Solaris 11 リリースでは、複数のマニフェストを使用して単一のサービスを記述することができます。これはたとえば、サービスの既存のマニフェストを変更することなく、サービスの新しいインスタンスを定義するために役立ちます。同じサービスまたはインスタンスの同じプロパティーが複数のマニフェストで定義されている場合、SMF は、どの値を使用するかを決定できません。このような競合が検出された場合、インスタンスは maintenance 状態に置かれます。

SMF プロファイル

SMF プロファイルは、システムによって配布されるサービスおよびインスタンスのカスタマイズに使用する XML ファイルです。プロファイルにより、複数のスクリプトではなく 1 つのファイルを使用してカスタマイズを実行できます。また、配布時またはインストール時に構成をカスタマイズすることも可能になります。

システムが提供するサービスのインスタンスを追加するなど、プロファイルを使用してすべての構成のカスタマイズを行うことができます。

ローカルカスタマイズは、名前の接尾辞が .xml のファイルに記述し、このファイルを /etc/svc/profile/site ディレクトリに置く必要があります。このディレクトリ内のすべてのカスタマイズは、システムのブート時、または svcadm restart manifest-import コマンドの実行時に適用されます。

マニフェストと同様に、/etc/svc/profile/site 内のファイル間で競合する構成定義は競合として扱われ、影響を受けるインスタンスは maintenance 状態に置かれます。

システムプロファイルもインストール中に適用されます。/etc/svc/profile/generic.xml 内のシステムプロファイルへの変更が必要になることはほとんどありません。詳細は、smf_bootstrap(5) のマニュアルページを参照してください。

プロファイルの使用方法については、「SMF プロファイルを適用する方法」を参照してください。

サービス構成リポジトリ

「サービス構成リポジトリ」には、永続的な構成情報と SMF 実行時サービスデータが格納されます。リポジトリは、ローカルメモリーとローカルファイルの間で割り当てられます。サービス構成リポジトリは、SMF インタフェースを使ってのみ操作または照会できます。リポジトリの操作やアクセスの方法については、svccfg(1M) および svcprop(1) のマニュアルページを参照してください。サービス構成リポジトリデーモンについては、svc.configd(1M) のマニュアルページを参照してください。サービス構成ライブラリについては、libscf(3LIB) のマニュアルページを参照してください。

リポジトリ内のプロパティーは、サービスまたはインスタンスのどちらかに対して定義できます。サービスに対して設定されるプロパティーは、そのサービスのすべてのインスタンスによって共有されます。インスタンスに対して設定されるプロパティーはそのインスタンスのみによって使用され、サービスのプロパティーを上書きすることができます。

svccfg コマンドは、プロパティーの生のビューを提供し、プロパティーがサービスとインスタンスのどちらに対して定義されているかを正確に示します。svccfg コマンドを使用してサービスを表示する場合、インスタンスのプロパティーを見ることはできません。インスタンスを表示する場合、サービスのプロパティーを見ることはできません。svcprop コマンドは、インスタンスの合成ビューを提供し、インスタンスのプロパティーとサービスのプロパティーの両方が単一のプロパティー名前空間に結合されます。サービスインスタンスが起動されるときは、そのプロパティーの合成ビューが使用されます。

すべての SMF 構成変更は、Oracle Solaris 監査フレームワークを使用してログに記録することができます。詳細は、『Oracle Solaris の管理: セキュリティーサービス』の「監査サービスの構成 (タスクマップ)」を参照してください。

SMF リポジトリのバックアップ

SMF では、次に示すリポジトリのバックアップを自動的に行います。

• ブートバックアップは、システムを起動するたびに、リポジトリに対する最初の変更が行われる直前に行われます。

• サービスが新しいマニフェストをインポートしたか、アップグレードスクリプトを実行した場合、manifest_import のバックアップは、 svc:/system/early-manifest-import:default または svc:/system/manifest-import:default が完了したあとに発生します。

タイプごとに 4 つのバックアップがシステムによって管理されます。必要に応じて、もっとも古いバックアップから削除されます。バックアップは /etc/svc/repository -type-YYYYMMDD_HHMMSWS という名前で格納されます。ここでの YYYYMMDD (年、月、日) と HHMMSS (時、分、秒) は、バックアップが行われた日時です。時間は 24 時間形式で表されます。

エラーが発生した場合は、これらのバックアップからリポジトリを復元できます。そのためには、/lib/svc/bin/restore_repository コマンドを使用します。詳細は、「破壊されたリポジトリを修復する方法」を参照してください。

SMF スナップショット

サービス構成リポジトリ内のデータには、編集可能な構成情報のほかに「スナップショット」もあります。各サービスインスタンスに関するデータは、スナップショットに格納されます。標準のスナップショットは、次のとおりです。

• initial – 目録の最初のインポート時に取られる

• running – svcadm refresh の実行時に取られる

• start – 最後に起動が成功したときに取られる

SMF サービスは常に running スナップショットを使って実行します。このスナップショットが存在しない場合は、自動的に作成されます。

svccfg コマンドは、現在のプロパティー値を変更するために使用します。それらのプロパティー値は、svcadm コマンドを実行して、実行中のスナップショットにプロパティー値を統合した時点で、サービスから認識できるようになります。svccfg コマンドを使用して、別のスナップショット内のインスタンス構成を参照する、またはその構成に戻すこともできます。

SMF 管理レイヤー

Oracle Solaris 11 リリースで、プロパティー、プロパティーグループ、インスタンス、およびサービスのソースを記録する情報がサービス構成リポジトリに追加されました。ユーザーはこの情報によって、どのデータが管理者によるカスタマイズであり、どのデータがソフトウェアとともに配布されたかを判別できます。

エンティティーのソースを識別しやすくするために、次のレイヤーが定義されています:

• admin レイヤーには、SMF コマンドを使用して、または libscf(3LIB) API を呼び出すことによって行われるすべての変更が含まれます。

• site-profile レイヤーには、/etc/svc/profile/site ディレクトリ内のファイル、またはレガシーの /etc/svc/profile/site.xml および /var/svc/profile/site.xml プロファイルからの値が含まれます。

• system-profile レイヤーには、システムプロファイルの場所である /etc/svc/profile/generic.xml および /etc/svc/profile/platform.xml からの値が含まれます。

• manifest レイヤーには、システムマニフェストディレクトリである /lib/svc/manifest または /var/svc/manifest からの値が含まれます。

プロパティー名ごとに 1 つのプロパティーを想定する既存のクライアントとの互換性を維持するため、またオーバーライド用のポリシーを作成するために、レイヤー化は単純なオーバーライド動作を備えます。admin レイヤーが優先されます。admin レイヤーにプロパティーの値がある場合、この値がサービスによって使用される値となります。そうでない場合、site-profile レイヤー、system-profile レイヤー、そして最後に manifest レイヤーの順に確認が行われます。この動作により、ローカルのカスタマイズが、システムのインストール時に提供された値よりも優先されます。

これらのレイヤーはシステムによって自動的に管理されます。管理者がリポジトリに直接加える変更は、admin レイヤーのみに記録されます。ほかのレイヤーは、標準の場所にファイルを配置するか、標準の場所のファイルを削除することによってのみ、変更されます。ファイルの内容に応じてプロパティーがリポジトリに配置されるとき、そのプロパティーについての情報には、内容の起源であるファイルの名前が含まれます。

管理者が svccfg または libscf の呼び出しを使用して下位レイヤーを直接変更することはできません。svccfg delete、svccfg delpg、または svccfg delprop コマンドを使用するとき、エンティティーは完全に削除されるのではなく非表示になります。通常、ユーザーは削除されたエンティティーを見ることができませんが、非表示のエンティティーは必要に応じて、svccfg listcust コマンドを使用して明示的に探査、また svccfg delcust コマンドを使用して非表示を解除することができます。

svccfg listprop コマンドには、これらのレイヤーの探査を有効にするオプションがあります。たとえば svccfg listprop -l all は、すべてのレイヤーと各レイヤーでの値を出力します。加えて、svccfg listcust コマンドを使用して、カスタマイズのみを一覧表示することができます。

SMF サービスのエラーログ

サービスまたはそのメソッドが生成するエラーなどのサービス固有情報に加えて、有効化アクション、開始時間などについての情報が、サービスインスタンスごとに、/var/svc/log 内の個別ファイルにログとして記録されます。サービスのログファイルの名前を調べるには、svcs -x service コマンドを実行します。

SMF はデフォルトで、管理者による介入が必要な場合 (たとえば、サービスが maintenance 状態になった場合) にのみ、syslog プログラムとコンソールにログメッセージを書き込みます。ほかのオプションも使用可能ですが、めったに使用されません。可能性のあるその他の構成については、svc.startd(1M) のマニュアルページを参照してください。

エラーログに加えて、FMA イベントの発生時、あるいは、サービスが service 状態に (またはその状態から別の状態に) 遷移したときに通知を出すよう、SMF サービスを構成することができます。これらの通知では、SNMP (Simple Network Management Protocol) または SMTP (Simple Mail Transfer Protocol) を使用できます。SMF 通知の設定については、「SMF 遷移イベントの電子メール通知を設定する方法」を参照してください。