管理の委任

l ノードを管理する主要な責任は中央のシステム管理者にあります。Solaris Resource Manager では割り当てと管理が可能ないくつかの資源制御を使用しますが、一定の管理特権を root 以外のユーザーに選択して割り当てて、ユーザー管理の負担を分散できます。

適切なユーザーに管理特権を割り当てるには、そのユーザーの uselimadm または admin フラグを設定します。uselimadm フラグが設定されているユーザーは、limadm(1MSRM) プログラムの中ではスーパーユーザーと同じ管理特権を持ちます。admin フラグが設定されているグループヘッダーユーザーは副管理者と呼ばれ、そのスケジューリンググループ内のユーザーに対し次の特権を持ちます。

中央のシステム管理者は、root を親に持つスケジューリンググループに対し制限値を設定して、割り当てることによって、システム資源の全体的な配分を制御します。副管理者も、通常、これと同じ資源制御を行いますが、対象はスケジューリンググループ内のユーザーに限定されます。副管理者が配分する資源は、グループに割り当てられた資源 (たとえば、グループヘッダーの l ノードに割り当てられた資源) だけです。副管理者は、スケジューリンググループ内のユーザーに admin フラグを割り当て、管理責任を分割できます。

副管理者は次のことができます。

1. スケジューリンググループ内のユーザーの資源制限値を変更できます。

   副管理者は資源の制限値としてグループの制限値より大きい値を設定できます。しかし、グループメンバーが使用した資源はグループヘッダーが使用した資源でもあるため、グループヘッダーの制限値を超えそうになると、個々のユーザーの制限値が適用されます。

2. スケジューリンググループ内の l ノードのフラグまたは属性 (flag.uselimadm と cpu.usage を除く) を変更できます。

   さらに、副管理者は、自分が所有していない特権をユーザーに与えることはできません。この制約により、副管理者が Solaris Resource Manager のセキュリティを侵害するのを防ぐことができます。

副管理者が使用する主なツールは limadm(1MSRM) と limreport(1SRM) コマンドです。limadm プログラムでは、制限値、フラグなど、既存ユーザーの Solaris Resource Manager 属性に対する操作を行います。レポート作成ツールである limreport とともに使うことにより、他の独立したスケジューリンググループの資源の割り当てや管理に関係なく、スケジューリンググループを別個に自己管理することができます。

スーパーユーザーにはどの資源制限値も適用されず、フラグの設定値とは関係なく常にすべての管理者特権を持ち、ユーザーアカウントの追加、削除、および変更を行うことができます。また、limadm コマンドを使ってどの l ノードの使用量、制限値、またはフラグの値でも変更できます。

セキュリティ

Solaris Resource Manager は Solaris システムの管理に広範囲に影響を与えるため、Solaris Resource Manager のインストールや保守にあたっては、システムのセキュリティを損なわないようにすることが重要です。

システム管理者が Solaris Resource Manager のセキュリティを維持するための方法はいくつかあります。最も重要なことは、Solaris システムの場合と同様、root パスワードの機密を保護することです。root パスワードを知っていれば、だれでも中央のシステム管理者と同じようにシステム資源に無制限にアクセスできます。

Solaris Resource Manager のユーザーに与えることができる特別な管理特権がいくつかあります。そのためには、ユーザーの l ノードにあるシステムフラグを設定する必要があります。この方法では、ユーザーに完全なスーパーユーザー特権を与えることなく、特権を獲得したユーザーが必要な作業を実行できるため、システムのセキュリティが向上します。

これらの特権の中には簡単に与えてはならないものがあります。この特権を獲得するとユーザーは広範囲に権限を持つことになるからです。これらの特権を持つユーザーのパスワードは、スーパーユーザーのパスワードと同様、厳格に保護される必要があります。

副管理者が、与えられた管理特権を誤用することがないように、Solaris Resource Manager ではセキュリティに関していくつかの予防策が用意されています。「一般的なアプリケーションサーバー」と 「l ノードの保守プログラム」を参照してください。

中央のシステム管理者は、スケジューリングツリーの構造を注意深く扱わないと、システムのセキュリティが侵害される場合があります。そのため、スケジューリングツリーを適切に変更する方法を理解し、現在の構造の潜在的な問題を発見する方法を知ることが重要です。これについては、「スケジューリングツリーの構造」で説明しています。

副管理者 l ノードの推奨構造

副管理者にとって、グループの制限値をグループメンバーと共有していることが問題になる場合があります。たとえば、グループヘッダーの l ノードにプロセスの制限値が設定されている場合には、グループヘッダーを含むグループ全体で使用できるプロセス数が制御されます。さらに制限が加えられない限り、スケジューリンググループのどのユーザーも、自分のプロセスリミットを超過することによって、副管理者が新しいプロセスを作成するのを妨げることができます。

これを防ぐ 1 つの方法は、副管理者がグループメンバーのそれぞれに個別に制限を設定することです。しかし、これを効果的なものにするには、制限を過度に厳しくしなければならないかもしれません。さらに、副管理者に個別の制限値を管理させるのは、階層的資源制御という Solaris Resource Manager の目標に反しています。

この問題を解決する別の方法は、管理者がグループ内の l ノードの構造を変えることです。管理者の l ノードの下に直接ユーザーを置く代わりに、副管理者の l ノードの下に唯一の子 l ノードとして「制御」 l ノードを作成し、ユーザーを制御 l ノードの子にします。この構造を次に示します。

図 5-1 副管理者 l ノードの構造

図 5-1 で、副管理者のアカウントのユーザー ID は、「Actual」というラベルがあるツリーの親である l ノードのユーザー ID に対応します。admin フラグはこの l ノードに設定します。「Control」l ノードにはダミーアカウントを作成します。このアカウントに対してはログインを許可する必要はありません。「A」、「B」、「C」のラベルがある l ノードは副管理者の制御下にあるユーザーです。

この場合、プロセスリミットを「Actual」l ノード 100、「Control」l ノード 90、個々のユーザー 0 とするとします。そうすれば、ユーザー A、B、C が合わせて 90 のプロセスを使用しても (すべて許可されます)、副管理者はまだ 10 のプロセスを作成できます。

この場合でも、各ユーザーは他のユーザーがプロセスを作成するのを妨げることがあります。これを避ける唯一の方法は、各ユーザーに個別の制限値を設定することです。この例の場合、個別の制限値をそれぞれ 40 にすれば、1 人のユーザーが他のユーザーを完全に除外することはなく、柔軟性が保たれます。

さらに、この例では、管理者が「Control」l ノードの子として新しいユーザーの l ノードを作成しても、制限値のバランスが崩れる心配はありません。