次のいずれかが該当する場合は、nssid.shファイル(/opt/novell/oes_installディレクトリの中)を確認します。
現在NSSと共にOES 1 Linuxサーバがインストールされているツリー、または過去にNSSと共に OES 1 LinuxサーバがインストールされたことのあるツリーにNSSと共にOES 2 Linuxサーバをインストールした。
現在NSSと共にOES 1 LinuxサーバまたはOES 2 Linuxサーバがインストールされているツリー、または過去にNSSと共に OES 1 LinuxサーバまたはOES 2 LinuxサーバがインストールされたことのあるツリーにNSSと共にOES 1 Linuxサーバをインストールする。
nssid.shスクリプトファイルが存在している場合、そのサーバ上でそのスクリプトを実行し、特定のシステムユーザに関するファイル所有権情報を同期させる必要があります。
この節では、その理由について説明します。
セクション H.0, OES 2システムユーザおよびグループで説明するように、OES Linuxサーバ上にNSSボリュームを作成する場合、システムレベルで変更を加える必要があります。ただし、それらの変更処理のほとんどは自動的に実行されます。次の規則が適用されます。
デフォルトでは、ApacheやTomcatなどのWebサービス、およびNetStorageなど特定のOESサービスは、OES Linuxサーバ上で、システムによって生成されたPOSIXユーザとして実行されます。
これらのシステム生成ユーザは、OES Linuxサーバ上のすべての種類のボリューム上にあるデータを読み取ることができます。
NSSボリューム上のデータにアクセスできるのは、eDirectory™ユーザだけです。
したがって、サーバ上にNSSボリュームを作成する場合、システム生成ユーザはeDirectoryユーザとして作成され、LUM (Linux User Management)に対して有効になっている必要があります。そうすれば、システム生成ユーザは、POSIXユーザとしてもeDirectoryユーザとしても機能します。その後、システム生成ユーザをローカルシステムから削除する必要があります。
LUMの詳細については、LUM (Linux User Management): eDirectoryユーザのためのLinuxへのアクセスを参照してください。
OES 1 LinuxサーバまたはOES 2 Linuxサーバ上にNSSをインストールする場合、NSSデータにアクセスする必要のあるシステム生成ユーザが、LUM対応のeDirectoryユーザとして自動生成され、ローカルサーバから削除されます。詳細については、セクション H.1, Linux上で作成されるシステムユーザおよびセクション H.3, Linux上で作成されるシステムグループを参照してください。
たとえば、Apache WebサーバがすべてのOES 1 LinuxサーバおよびOES 2 Linuxサーバ上でwwwrunユーザとして動作しているとします。ここで、そのサーバにNSSがインストールされると、wwwrunユーザはeDirectoryに作成され、LUMに対して有効になり、ローカルサーバから削除されます。eDirectoryに作成されたユーザへのUIDの割り当て方法は、最初にどのバージョンのOESがインストールされたかによって異なります。
SLES 9サーバ(および拡張としてOES 1)をApache Webサーバと共にインストールする場合、システム生成のwwwrunローカルユーザにはシステム生成のUIDが割り当てられます。たとえば、そのUIDとして6が割り当てられます。
このサーバにNSSをインストールする場合、初期インストール時またはインストール後に、wwwrunローカルユーザとしてのwwwrunユーザが、同じシステム生成UID (6)と共にeDirectoryに自動的に作成され、属性として格納されます。ローカルのwwwrunユーザはこのサーバから削除されます。
Apache Webサーバは、起動するたびに、wwwrunユーザアカウントとして動作します。このwwwrunユーザは、実際にはeDirectory内に格納されますが、LUMにより、ローカルユーザとしても機能します。wwwrunユーザによって生成および使用されるすべてのファイルの所有者のUIDは、6として表示されます。eDirectoryに格納されているwwwrunユーザのUIDは6なので、Apache Webサーバを起動および実行することができます。
SLES 10 SP1 (および拡張としてOES 2)を開始すると、システム生成ローカルユーザには標準UIDが割り当てられます。たとえば、Apache Webサーバが使用するwwwrunユーザは、常にUIDとして30が割り当てられます。OES 2に固有で、SLES 10基本システムの一部ではないユーザおよびグループも、標準UIDを持ちます。SLES 10 SP1が作成する他のユーザに、その標準UIDを割り当てることはありません。
OES 2 LinuxサーバにNSSをインストールしようとしていて、そのOES 2サーバが、インストールされたNSSのツリーの最初のサーバの場合、wwwrunユーザがUID (30)と共にeDirectoryに作成され、属性として格納され、そのサーバからローカルwwwrunユーザが削除されます。
Apache Webサーバは、起動するたびに、wwwrunユーザアカウントとして動作します。このwwwrunユーザは、実際にはeDirectory内に格納されますが、LUMにより、ローカルユーザとしても機能します。wwwrunユーザによって生成および使用されるファイルの所有者のUIDは、30として表示されます。eDirectoryに格納されているwwwrunユーザのUIDは30なので、Apache Webサーバを起動および実行することができます。
ツリーに追加でインストールされたOES 1 LinuxまたはOES 2 Linuxの各サーバに対して、(OES Linuxサーバと同時に、または後で)NSSをインストールする場合、システムユーザのUIDが、eDirectory内に格納されている対応するシステムユーザのUIDと合致するかが、検査されます。そのツリーに最初にどのバージョンのOES Linuxがインストールされたか、および追加でどのバージョンをインストールしたか、の状況により、後続のサーバインストールでUIDの不一致が起こる場合があります。
表 6-1 ローカルシステムユーザとeDirectory間のUIDの不一致
OES Linuxをインストールすると、ローカルシステムによって生成されたユーザのUIDと、eDirectoryに格納されている同じユーザのUIDが競合していないかどうかが、検査されます。競合が検出された場合、/opt/novell/oes_installディレクトリにnssid.shという名前のシェルスクリプトファイルが生成されます。このスクリプトファイルの目的は、サーバ上でUIDが一致していないすべてのシステムファイルを同期させることだけです。
インストール時、それぞれのシステム生成ユーザが個別に解析され、競合が検出された場合にのみ、スクリプト内にエントリが追加されます。
インストール時にnssid.shスクリプトが自動実行されることはありません。なぜなら、影響を受ける各ユーザとグループのファイルUIDを同期させる処理には時間がかかるからです。短い場合でも10分、ファイルシステムのサイズが大きい場合は数時間かかることもあります。
インストール時に、UIDが競合している可能性について警告されることはありません。
そのため、OES 2 LinuxサーバまたはOES 1 Linuxサーバ上でNSSを使用している場合は、競合の可能性のある組み合わせを表 6-1で調べ、その後、インストールしている各サーバの可能性のある競合に対し、UID情報を同期させるの手順を行うことが必要です。
サーバに競合の可能性がある場合、表 6-1を調査して、サーバ上に競合の可能性が確認されたならば、次の手順を行います。
サーバにrootユーザとしてログインします。
次のファイルが存在しているかどうかを確認します。
/opt/novell/oes_install/nssid.sh
ファイルが存在する場合は、次に示すように、サーバ上でコマンドプロンプトからそのファイルを実行します。
/opt/novell/oes_install/nssid.sh
ファイルが存在しない場合は、なにもする必要がありません。