Sun Cluster Data Service for Network File System (NFS) ガイド (Solaris OS 版)

Kerberos V5 を使用した Sun Cluster HA for NFS の保護

Kerberos V5 を使用した Sun Cluster HA for NFS は、Kerberos クライアントを構成することによって保護できます。この構成では、すべてのクラスタノード上で論理ホスト名に対する NFS の Kerberos 主体を追加する作業も行います。

Kerberos クライアントを構成するには、次の手順を実行します。

ノードの準備。「ノードを準備する」を参照してください。
Kerberos 主体を作成します。「Kerberos 主体を作成する」を参照してください。
セキュア NFS を有効にします。「セキュア NFS の有効化」を参照してください。

ノードを準備する

手順

クラスタノードによって使用される KDC (Key Distribution Center) サーバーを構成します。

詳細は、Solaris Kerberos/SEAM (Sun Enterprise Authentication Mechanism) のマニュアルを参照してください。

時間の同期を設定します。

KDC サーバーは、クラスタノードとの間と、クラスタの Sun Cluster HA for NFS サービスを利用するすべてのクライアントとの間で、時間の同期をとる必要があります。NTP (Network Time Protocol) メソッドはほかのメソッドよりもはるかに密な時間補正を行うため、時間同期の信頼性が高いと言えます。この高い信頼性のメリットを得るには、時間同期に NTP を使用してください。

DNS クライアント構成の検証を行います。

DNS クライアント構成は、すべてのクラスタノードと、クラスタのセキュア NFS サービスを利用するすべての NFS クライアント上で稼働する確実なものである必要があります。DNS クライアント構成の検証には resolv.conf(4) を使用してください。

DNS ドメイン名は、krb5.conf(4) ファイルの domain_realm セクションに DNS ドメイン名をマッピングして、Kerberos 構成に認識させる必要があります。

次に、Kerberos レルム (realm) ACME.COM に DNS ドメイン名 mydept.company.com をマッピングする例を示します。
```
[domain_realm]
.mydept.company.com = ACME.COM
```

クラスタノード上に Kerberos クライアントソフトウェアを構成する場合は、Master KDC サーバーが稼働するようにします。

同一の構成ファイルと同一のサービスキーテーブルファイルがすべてのクラスタノードで利用できるようにします。

/etc/krb5/krb5.conf ファイルは、すべてのクラスタノードで同じ構成にする必要があります。また、デフォルトの Kerberos キータブファイル (サービスキーテーブル) である /etc/krb5/krb5.keytab も、すべてのクラスタノードで同じ構成にする必要があります。これは、ファイルをすべてのクラスタノードにコピーするか、あるいは各ファイルの単一のコピーを広域ファイルシステム上に置き、すべてのクラスタノード上の /etc/krb5/krb5.conf と /etc/krb5/krb5.keytab にシンボリックリンクをインストールすることによって実現できます。

また、フェイルオーバーファイルシステムを使用し、すべてのクラスタノードでファイルが利用できるようにすることも可能です。しかし、フェイルオーバーファイルシステム上の各ファイルを認識できるのは、一度に 1 つのノードだけです。したがって、複数のノードでマスターされている可能性がある複数のリソースグループで Sun Cluster HA for NFS が使用されている場合は、すべてのクラスタノードファイルを認識できません。また、この構成では、Kerberos クライアントの管理作業が複雑になります。

ファイル /etc/nfssec.conf 内のすべての Kerberos 関連エントリがコメント解除されていることを確認します。

すべてのクラスタノードと、クラスタのセキュア NFS サービスを使用するように設定されたすべての NFS クライアント上で、ファイル /etc/nfssec.conf 内のすべての Kerberos 関連エントリがコメント解除される必要があります。nfssec.conf(4) を参照してください。

Kerberos 主体を作成する

次に、必要な Kerberos 主体とキータブのエントリを KDC データベース内に作成する手順を示します。サービス主体を作成するキータブエントリは、クラスタノードごとに、クラスタノードで使用されている Solaris のバージョンによって異なります。

Solaris 8 では、「root」エントリと「host」エントリの両方を作成する必要があります。
Solaris 9 では、作成する必要があるのは「host」エントリだけです。

論理ホスト名に対する「nfs」サービスの主体は 1 つのノード上でだけ作成し、各クラスタノード上のデフォルトの Kerberos キータブファイルに追加します。Kerberos 構成ファイル krb5.conf とキータブファイル krb5.keytab は、広域ファイルシステム上で共有するのではなく、各クラスタノード上に個々のコピーとして保存する必要があります。

手順

各クラスタノードで管理者として KDC サーバーにログインし、クラスタノードごとにホスト主体を作成します。

Solaris 8 では、クラスタノードごとにホスト主体とルート主体の両方を作成する必要があります。

主体は、完全修飾されたドメイン名を使用して作成する必要があります。

これらのエントリは、各ノードのデフォルトのキータブファイルに追加します。これらの作業は、クラスタコンソールユーティリティーを使用することで非常に簡単に行えます (cconsole(1M) を参照)。

次に、ルートエントリとホストエントリを作成する例を示します。この手順は、すべてのクラスタノードで行います。ホスト名の位置には、各クラスタノードの物理ホスト名を入れてください。
# kadmin -p username/admin Enter Password: kadmin: addprinc -randkey host/phys-red-1.mydept.company.com Principal "host/phys-red-1.mydept.company.com@ACME.COM" created.
kadmin: addprinc -randkey root/phys-red-1.mydept.company.com Principal "root/phys-red-1.mydept.company.com@ACME.COM" created.
kadmin: ktadd host/phys-red-1.mydept.company.com Entry for principal host/phys-red-1.mydept.company.com with kvno 2, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin: ktadd root/phys-red-1.mydept.company.com Entry for principal root/phys-red-1.mydept.company.com with kvno 2, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin: quit #

1 つのクラスタノードで、Sun Cluster HA for NFS サービスを提供する論理ホスト名に対する Sun Cluster HA for NFS サービスの主体を作成します。

主体は、完全修飾されたドメイン名を使用して作成する必要があります。この手順は、1 つのクラスタノードでだけ行なってください。

# kadmin -p  username/admin
Enter Password:
kadmin: addprinc -randkey nfs/relo-red-1.mydept.company.com
Principal "nfs/relo-red-1.mydept.company.com@ACME.COM" created.

kadmin: ktadd -k /var/tmp/keytab.hanfs nfs/relo-red-1.mydept.company.com
Entry for principal nfs/relo-red-1.mydept.company.com with kvno 3, 
encryption type DES-CBC-CRC added to keytab WRFILE:/var/tmp/keytab.hanfs.

kadmin: quit
#

上記の例では、relo-red-1 は Sun Cluster HA for NFS で使用される論理ホスト名です。

安全な方法を使用して、手順 2 で指定したキータブデータベース /var/tmp/keytab.hanfs をほかのクラスタノードにコピーします。

安全でないコピー手段 (通常使用される ftp や rcp など) は使用しないでください。クラスタ独自のインターコネクトを使用してデータベースをコピーすれば、安全性がさらに高まります。

次に、データベースをコピーする例を示します。
# scp /var/tmp/keytab.hanfs clusternode2-priv:/var/tmp/keytab.hanfs # scp /var/tmp/keytab.hanfs clusternode3-priv:/var/tmp/keytab.hanfs

すべてのクラスタノードで、論理ホスト名に対する「nfs」サービスのキータブエントリをローカルキータブデータベースに追加します。

次の例では、ktutil(1M) コマンドを使用してエントリを追加しています。一時的なキータブファイル /var/tmp/keytab.hanfs は、デフォルトのキータブデータベース /etc/krb5/krb5.keytab に追加したあとで、すべてのクラスタノードで削除してください。
# ktutil ktutil: rkt /etc/krb5/krb5.keytab ktutil: rkt /var/tmp/keytab.hanfs ktutil: wkt /etc/krb5/krb5.keytab ktutil: quit# # rm /var/tmp/keytab.hanfs

Kerberos クライアント構成の検証を行います。

各クラスタノードでデフォルトのキータブエントリを表示し、「nfs」サービス主体のキーバージョン番号 (KVNO) がすべてのクラスタノードで同じであることを確認してください。

# klist -k
Keytab name: FILE:/etc/krb5/krb5.keytab
KVNO Principal
---- ---------------------------------
2    host/phys-red-1.mydept.company.com@ACME.COM
2    root/phys-red-1.mydept.company.com@ACME.COM
3    nfs/relo-red-1.mydept.company.com@ACME.COM

論理ホストに対する「nfs」サービスの主体は、すべてのクラスタノードで同じ KVNO 番号を持つ必要があります。上記の例では、論理ホストに対する「nfs」サービスの主体は nfs/relo-red-1.mydept.company.com@ACME.COM で、KVNO は 3 です。

(Solaris 9 のみ) ユーザー資格情報データベース gsscred は、クラスタからセキュア NFS サービスにアクセスするすべてのユーザーについて最新の状態でなければなりません。

ユーザー資格情報データベースは、すべてのクラスタノードで次のコマンドを実行して構築してください。
# gsscred -m kerberos_v5 -a
詳細は、gsscred(1M) のマニュアルページを参照してください。

上記の方法は、ユーザー資格情報データベースを一度だけ構築するものです。ユーザー群の変化に合わせてこのデータベースのローカルコピーを最新状態に維持するには、ほかのメカニズム (cron(1M) など) を使用する必要があります。

この手順は、Solaris リリース 10 には不要です。

セキュア NFS の有効化

ファイルシステムを安全に共有するためには、dfstab. resource-name エントリで share(1M) コマンドの -o sec=option オプションを使用してください。具体的なオプション設定の詳細は、nfssec(5) のマニュアルページを参照してください。Sun Cluster HA for NFS リソースをすでに構成し、実行している場合は、「NFS ファイルシステムの共有オプションを変更する」で dfstab.resource-name ファイル内のエントリの更新に関する情報を参照してください。Sun Cluster 構成では sec=dh オプションはサポートされないことに注意してください。