検索

管理ガイド

download PDF
Red Hat Directory Server 10

Directory Server 10.6 の更新

概要

本ガイドでは、Directory Server インスタンスおよびデータベースを管理する GUI およびコマンドラインの手順を説明します。
このドキュメントは維持されなくなりました。詳細は、非推奨のドキュメント を参照してください。

非推奨のドキュメント

重要
2020 年 11 月 30 日にて、Red Hat Directory Server 10 のサポート終了は終了しました。詳細は、「Red Hat Directory Server Life Cycle policy」を参照してください。Red Hat は、Directory Server 10 を最新バージョンに更新することを推奨します。
本製品のメンテナンスフェーズの終了により、本ドキュメントは更新されなくなりました。参照資料としてのみご使用ください。

第1章 Red Hat Directory Server の基本設定

Red Hat Directory Server にはディレクトリーサービス、複数のサーバーインスタンスを管理する管理サーバー、およびグラフィカルインターフェースを使用してサーバーインスタンスを管理するための Java ベースのコンソールが含まれています。本章では、ディレクトリーサービスを管理する基本的なタスクの概要を説明します。
Directory Server は、ユーザーおよびリソースのエンタープライズ全体のディレクトリーを管理するために設計された、堅牢でスケーラブルなサーバーです。LDAP(Lightweight Directory Access Protocol)と呼ばれるオープンシステムサーバープロトコルに基づいています。サーバーはディレクトリーデータベースを管理し、クライアント要求に応答します。
Directory Server は、連携する複数のコンポーネントで構成されています。
  • Directory Server は、コア LDAP サーバーデーモンです。これは LDAP v3 標準に準拠しています。このコンポーネントには、データベースのエクスポートやバックアップなどの一般的な操作を行うためのコマンドラインサーバー管理プログラムおよびスクリプトが含まれます。
  • Directory Server コンソールは、ユーザー、グループ、およびその他の LDAP データの管理を簡素化するユーザーインターフェースです。コンソールは、バックアップ、セキュリティー、レプリケーション、データベース設定、サーバーの監視、統計の表示など、サーバー管理のすべての側面に使用されます。
  • 管理サーバーは、Directory Server インスタンスを管理する管理エージェントです。Directory Server コンソールと通信し、Directory Server インスタンスで操作を実行します。また、簡単な HTML インターフェースおよびオンラインヘルプページも提供します。
コマンドラインユーティリティーを使用して Directory Server を管理できますが、Directory Server コンソールを使用することもできます。

1.1. システム要件

1.2. ファイルの場所

1.3. Directory Server 管理コンソールの起動

管理コンソールは、以下のような管理タスクを実行できるグラフィカルユーザーインターフェースを提供します。
  • Directory Server インスタンスの管理
  • 管理サーバーの管理
  • ユーザーおよびグループの管理
注記
管理コンソールは Java を使用します。サポートされる Java ランタイム環境およびバージョンの詳細は、『 Red Hat Directory Server リリースノート』を参照してください
管理コンソールを開くには、次のコマンドを入力します。
# redhat-idm-console

1.3.1. Directory Server コンソールを開く

  1. Directory Server 管理コンソールを起動します。
    # redhat-idm-console
  2. cn=Directory Manager ユーザーとしてログインします。
  3. Servers and Applications タブで administration_domain_namehost_nameServer GroupDirectory Server(instance_name) に移動し、Open をクリックします。

1.3.2. 管理コンソールを開く

  1. Directory Server 管理コンソールを起動します。
    # redhat-idm-console
  2. cn=Directory Manager ユーザーとしてログインします。
  3. Servers and Applications タブで administration_domain_namehost_nameServer GroupAdministration Server に移動し、Open をクリックします。

1.4. Directory Server インスタンスの起動および停止

1.4.1. コマンドラインを使用した Directory Server インスタンスの起動および停止

systemctl ユーティリティーを使用して、インスタンスを起動、停止、または再起動します。
  • インスタンスを起動するには、以下のコマンドを実行します。
    # systemctl start dirsrv@instance_name
  • インスタンスを停止するには、以下のコマンドを実行します。
    # systemctl stop dirsrv@instance_name
  • インスタンスを再起動するには、以下のコマンドを実行します。
    # systemctl restart dirsrv@instance_name
必要に応じて、システムの起動時に Directory Server インスタンスが自動的に起動するようにすることができます。
  • 単一のインスタンスの場合:
    # systemctl enable dirsrv@instance_name
  • サーバー上のすべてのインスタンスの場合:
    # systemctl enable dirsrv.target
詳細は、『Red Hat システム管理者』 ガイドのシステムサービスの管理 セクションを参照してください。

1.4.2. コンソールを使用した Directory Server インスタンスの起動および停止

コマンドラインの横にある Directory Server コンソールを使用して、インスタンスの起動、停止、再起動を行うことができます。
重要
SELinux を Enforcing モードで実行する場合は、コンソールを使用してインスタンスの起動または停止を行うことはできません。この問題を回避するには、コマンドラインを使用してサービスを管理します。「Directory Server インスタンスの起動および停止」 を参照してください。
重要
インスタンスの TLS 暗号化を有効にすると、インスタンスの起動時に Directory Server は TLS 証明書のパスワードを要求します。Directory Server コンソールでは、GUI にこのパスワードプロンプトを表示できません。この問題を回避するには、以下を実行します。
Directory Server インスタンスを起動、停止、または再起動するには、以下を実行します。
  1. Directory Server コンソールを起動し、cn=Directory Manager ユーザー名を使用してログインします。
    詳細は、「管理コンソールを開く」 を参照してください。
  2. Servers and Applications タブで administration_domain_namehost_nameServer GroupDirectory Server(instance_name) に移動し、Open をクリックします。
  3. Tasks タブで、実行するタスクをクリックします。
  4. Yes をクリックして確定します。
タスクが終了すると、操作が成功したか、失敗した場合に、コンソールにメッセージが表示されます。

1.5. Directory Server 管理サーバーサービスの起動と停止

管理コンソールは、Directory Server コンソール(Directory Server を管理する GUI)を提供します。

1.5.1. コマンドラインを使用した管理サーバーサービスの起動と停止

systemctl ユーティリティーを使用して、管理サーバーサービスを起動、停止、または再起動します。
  • サービスを起動するには、以下を実行します。
    # systemctl start dirsrv-admin
  • サービスを停止するには、以下を実行します。
    # systemctl stop dirsrv-admin
  • サービスを再起動するには、以下を実行します。
    # systemctl restart dirsrv-admin
必要に応じて、システムの起動時に管理サーバーが自動的に起動するようにします。
# systemctl enable dirsrv-admin
詳細は、『Red Hat システム管理者』 ガイドのシステムサービスの管理 セクションを参照してください。

1.5.2. コンソールを使用した管理サーバーのサービスの再起動および停止

管理サーバーサービスを再起動または停止するには、以下を実行します。
  1. Directory Server コンソールを起動し、cn=Directory Manager ユーザー名を使用してログインします。
    詳細は、「管理コンソールを開く」 を参照してください。
  2. Servers and Applications タブで administration_domain_namehost_nameServer GroupAdministration Server に移動し、Open をクリックします。
  3. Tasks タブで、実行するタスクをクリックします。
  4. Yes をクリックして確定します。
タスクが終了すると、操作が成功したか、失敗した場合に、コンソールにメッセージが表示されます。

1.6. LDAPI の有効化

IPC( Inter-process communication )は、Unix マシン上のプロセスや、ネットワークが互いに直接通信するための方法です。LDAPI により、LDAP 接続は IPC 接続で実行できます。つまり、LDAP 操作は Unix ソケット上で実行できます。これらの接続は、通常の LDAP 接続よりもはるかに高速で、より安全です。
LDAPI は、2 つの設定属性を使用して有効になります。
  • nsslapd-ldapilisten Directory Server の LDAPI を有効にするには、以下を実行します。
  • nsslapd-ldapifilepath Unix ソケットファイルを参照する
LDAPI を有効にするには、以下を実行します。
  1. nsslapd-ldapilisten を変更して LDAPI をオンにし、ソケットファイル属性を追加します。
    # ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
    
    dn: cn=config
    changetype: modify
    replace: nsslapd-ldapilisten
    nsslapd-ldapilisten: on
    -
    add: nsslapd-ldapifilepath
    nsslapd-ldapifilepath: /var/run/slapd-example.socket
  2. サーバーを再起動して、新しい設定を適用します。
    # systemctl restart dirsrv@instance

1.7. Directory Server ポート番号の変更

Directory Server が使用する標準およびセキュアな LDAP ポート番号は、Directory Server Console で変更するか、dse.ldifcn=config エントリー下の nsslapd-port または nsslapd-secureport 属性の値を変更することで変更できます。
注記
o=NetscapeRoot サブツリーを維持する Configuration Directory Server の標準またはセキュアなポート番号を変更することは、Directory Server コンソールを介して行う必要があります。

1.7.1. 標準ポート番号の変更

  1. Directory Server コンソールの Configuration タブを選択し、左側のペインのナビゲーションツリーでトップエントリーを選択します。
  2. 右側のペインで Settings タブを選択します。
  3. ポート番号を変更します。Port フィールドで TLS 以外の通信に使用するサーバーのポート番号。デフォルト値は 389 です。
  4. Save をクリックします。
  5. コンソールは警告を返します。設定ディレクトリーのポート番号を変更します。これは、このディレクトリーを使用するすべての管理サーバーに影響が及ぶため、新しいポート番号で更新する必要があります。ポート番号を変更してもよろしいですか?Yes をクリックします。
  6. その後、サーバーが再起動するまで変更が反映されないことを示すダイアログが表示されます。OK をクリックします。
    注記
    この時点で Directory Server を再起動しないでください。有効にすると、コンソールを介して管理コンソールに必要な変更を加えることはできません。
  7. 管理コンソールを開きます。
  8. Configuration タブで Configuration DS タブを選択します。
  9. LDAP ポート フィールドで、Directory Server インスタンスの新しい LDAP ポート番号を入力します。
  10. Directory Server ポートの SELinux ラベルを変更し、新しいポート番号を Directory Server ポリシーで使用できるようにします。以下に例を示します。
    # semanage port -a -t ldap_port_t -p tcp 1389
    警告
    SELinux ラベルがリセットされない場合、Directory Server は再起動できなくなります。
  11. Directory Server コンソールの Tasks タブで、Restart Directory Server をクリックします。サーバーを再起動することを確認するダイアログ。Yes をクリックします。
  12. 管理コンソールの Configuration DS タブを開き、Save を選択します。
    ダイアログが表示され、読み取り Directory Server 設定が変更されました。変更を有効にするには、管理サーバーとサーバーグループのすべてのサーバーをシャットダウンする必要があります。OK をクリックします。
  13. 管理コンソールの Tasks タブで、Restart Admin Server をクリックします。管理サーバーが正常に再起動したことを示すダイアログが開きます。Close をクリックします。
    注記
    コンソールで その他の操作を行う前に、コンソールを閉じて再度開く必要があります。更新してもコンソールを更新できず、何も実行しようとすると、Unable to contact LDAP server という警告が表示されます。

1.7.2. LDAPS ポート番号の変更

設定ディレクトリーまたはユーザーディレクトリーのポートを変更するか、またはポート番号の変更には以下のような要件があります。
  • また、管理サーバー設定で Directory Server のポート番号も更新する必要があります。
  • 設定またはユーザーディレクトリーを参照するその他の Directory Server インスタンスがある場合は、これらのサーバーを更新して新しいポート番号を指定します。
LDAPS ポートを変更するには、以下を実行します。
  1. Directory Server インスタンスの証明書を発行するために使用する CA 証明書が Administration Server 証明書データベースにあることを確認します。Administration Server の CA 証明書のインポートは、「CA 証明書のインストール」 で説明されている Directory Server プロセスと同じです。
  2. 「標準ポート番号の変更」 のプロセスと同様に、Directory Server Console を使用してセキュアなポートを設定できます( 暗号化ポート フィールドに値のみの設定のみ)。ただし、同じマシンに複数の Directory Server インスタンスがある場合など、Directory Server コンソールからポート番号を変更できない場合があります。ldapmodify を使用してポート番号を変更 することが推奨されます。
    以下に例を示します。
    # ldapmodify -x -h server.example.com -p 1389 -D "cn=Directory Manager" -W
    dn: cn=config
    replace: nsslapd-securePort
    nsslapd-securePort: 1636
  3. Administration Server 設定(o=netscaperoot)で Directory Server インスタンスの対応するポート設定を編集します。
    まず、現在の設定を検索します。
    # ldapsearch -x -h config-ds.example.com -p 389 -D "cn=Directory Manager" -W -b "cn=slapd-ID,cn=389 Directory Server,cn=Server Group,cn=server.example.com,ou=example.com,o=NetscapeRoot" -s base "(objectclass=*)"
    nsSecureServerPort
    
    dn: cn=slapd-ID,cn=389 Directory Server,cn=Server Group,cn=server.example.com,ou=example.com,o=NetscapeRoot
    nsSecureServerPort: 636
    次に、設定を編集します。
    # ldapmodify -x -h config-ds.example.com -p 389 -D "cn=Directory Manager" -W
    
    dn: cn=slapd-ID,cn=389 Directory Server,cn=Server Group,cn=server.example.com,ou=example.com,o=NetscapeRoot
    replace: nsSecureServerPort
    nsSecureServerPort: 1636
  4. インスタンスの Directory Server コンソールを起動し、新しい LDAPS ポート番号が Configuration タブに一覧表示されていることを確認します。
  5. 必要に応じて、Console で SSL を使用する チェックボックスを選択します。
  6. Directory Server ポートの SELinux ラベルを変更し、新しいポート番号を Directory Server ポリシーで使用できるようにします。以下に例を示します。
    # semanage port -a -t ldap_port_t -p tcp 1636
    警告
    SELinux ラベルがリセットされない場合、Directory Server は再起動できなくなります。
  7. Directory Server インスタンスを再起動します。

1.8. Directory Server インスタンスの管理

1.8.1. 新規 Directory Server インスタンスの作成

詳細は、『Red Hat Directory Server インストールガイド』 の該当するセクションを参照してください。

1.8.2. Directory Server インスタンスの削除

1.8.2.1. コマンドラインを使用した Directory Server インスタンスの削除
その他のインスタンスをすべてアンインストールしたり、管理サーバーインスタンスを削除したり、パッケージを削除したりせずに Directory Server の 1 つのインスタンスを削除できます。
# remove-ds.pl -i slapd-instance_name -a
remove-ds.pl スクリプトは、- a (all)オプションが指定されている場合は、関連するファイルおよびディレクトリーを削除します。ただし、Directory Server インスタンスは、設定 Directory Server から登録解除されません。
デフォルトでは、鍵と証明書 ファイルは インスタンス設定ディレクトリーに残り、設定ディレクトリーの名前が slapd-instance-name.removed になります。(以下に示すように) -a オプションを使用すると、セキュリティーデータベースも削除されます。
注記
インストールの失敗やサーバーを再起動するなど、Directory Server に問題が発生した場合には、remove-ds.pl スクリプトの実行に失敗します。この場合は、- f オプションを試して、強制的に削除プロセスを実行します。
1.8.2.1.1. Directory Server インスタンスおよび管理サーバーの削除
Directory Server と管理サーバーの両方を削除できます(同じシステムに設定されている場合)。
削除操作を実行するには、- y オプションが必要です。それ以外の場合は、remove-ds-admin.pl スクリプトはドライランを実行しますが、サーバーは削除されません。
-a オプションは必須ではありませんが、Directory Server または管理 Server インスタンスが後で再設定できる場合は推奨されます。デフォルトでは、すべてのセキュリティーデータベースは削除スクリプトで保持されます。-a オプションは、セキュリティーデータベースも削除します。
注記
サーバーにバインドするスクリプトには、Directory Server インスタンスが実行している必要があります。
注記
インストールの失敗やサーバーを再起動するなど、Directory Server に問題が発生した場合には、remove-ds-admin.pl スクリプトの実行に失敗します。この場合は、- f オプションを試して、強制的に削除プロセスを実行します。

1.8.3. コンソールを使用した Directory Server インスタンスの削除

  1. Directory Server コンソールを開きます。詳細は、「Directory Server コンソールを開く」 を参照してください。
  2. サーバーインスタンスを右クリックし、Remove Server を選択します。
  3. Yes をクリックして確定します。

1.9. Directory Server プラグインの使用

Directory Server には、レプリケーション、サービスのクラス、属性構文などのコア Directory Server 機能を設定するデフォルトプラグインが多数含まれています。コアプラグインはデフォルトで有効になり、完全に設定されます。
他のデフォルトプラグインは、一貫したユーザー定義で、DNA、属性の一意性、および属性リンクを提供することにより、Directory Server の機能を拡張します。これらのプラグインは利用可能ですが、すべてのプラグインがデフォルトで有効または設定される訳ではありません。
プラグインを使用すると、Directory Server を簡単に拡張できるため、お客様は独自のサーバープラグインを作成してデプロイし、特定のデプロイメントに必要なディレクトリー操作を実行することができます。
詳細は、以下を参照してください。

1.9.1. プラグインを動的に有効化

Directory Server は、Directory Server を再起動せずに有効にできる動的プラグインをサポートします。動的な有効化されたプラグインを可能にすると、サーバーの管理がより容易になります。動的プラグインを使用すると、サーバーを複数回再起動して、プラグインをインストールおよび設定することができます。これにより、Directory Server のソフトウェアアプリケーションをデプロイする方がはるかに速くなります。
各プラグインは、nsslapd-pluginEnabled 属性の値を切り替えることで有効または無効にできます。以下に例を示します。
# ldapmodify -x -D 'cn=Directory Manager' -W
dn: cn=Plug-in_name,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on
cn=config エントリーで nsslapd-dynamic-plugins スイッチを指定した場合、プラグインを再設定するときに Directory Server を再起動する必要はありません。動的プラグイン機能を有効にするには、nsslapd-dynamic-plugins 属性を on に設定します。
dn: cn=config
nsslapd-dynamic-plugins: on
動的プラグイン機能を無効にするには、nsslapd-dynamic-plugins 属性を off に設定します。
dn: cn=config
nsslapd-dynamic-plugins: off
デフォルトでは、nsslapd-dynamic-pluginsoff に設定されます。

1.9.2. プラグインの有効化

1.9.2.1. コマンドラインでプラグインの有効化
コマンドラインでプラグインを無効化または有効にするには、ldapmodify ユーティリティーを使用して nsslapd-pluginEnabled 属性の値を編集します。以下に例を示します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: cn=ACL Plugin,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on
1.9.2.2. Directory Server コンソールでプラグインの有効化
Directory Server コンソールを使用してプラグインを有効または無効にするには、以下を実行します。
  1. Directory Server コンソールで、Configuration タブを選択します。
  2. ナビゲーションツリーの Plugins フォルダーをダブルクリックします。
  3. Plugins 一覧からプラグインを選択します。
  4. プラグインを無効にするには、有効 の チェックボックスの選択を解除 します。プラグインを有効にするには、このチェックボックスを選択します。
  5. Save をクリックします。
  6. Directory Server を再起動します。
    # systemctl restart dirsrv@instance
注記
プラグインが無効になっていると、そのバージョンやベンダーなど、プラグインに関する詳細はすべて Directory Server コンソールに表示されません。すべての詳細フィールドには NONE が表示されます。
プラグインを有効にすると、Directory Server が再起動(新しいプラグイン設定のロード)後、Directory Server コンソールが更新されるまで、これらの詳細がコンソールに表示されません。

1.9.3. プラグインの設定

Directory Server 9 以前では、nsslapd-pluginarg* 属性を使用してプラグインを設定しました。Directory Server 10 は、特定のプラグインに特定の設定属性のサポートを追加しました。
重要
プラグイン固有の設定属性と非推奨の nsslapd-pluginarg* 属性がプラグインの設定に設定されている場合、Directory Server はプラグイン固有の属性の設定のみを使用します。
以下の 2 つの例は、Referential Integrity プラグインで同じ設定を使用しますが、異なる設定オプションを使用します。

例1.1 設定属性を使用したプラグイン設定

referint-update-delay: 0
referint-logfile: /var/log/dirsrv/slapd-localhost/referint
referint-logchanges: 0
referint-membership-attr: member
referint-membership-attr: uniquemember
referint-membership-attr: owner
referint-membership-attr: seeAlso
注記
Red Hat は、設定プラグイン固有の属性のみを使用することを推奨します。プラグイン固有の属性については、Red Hat Directory Server の設定、コマンド、およびファイルリファレンスの該当するセクションを参照してください

例1.2 プラグイン引数属性を使用したプラグイン設定(非推奨)

nsslapd-pluginarg0: 0
nsslapd-pluginarg1: /var/log/dirsrv/slapd-localhost/referint
nsslapd-pluginarg2: 0
nsslapd-pluginarg3: member
nsslapd-pluginarg4: uniquemember
nsslapd-pluginarg5: owner
nsslapd-pluginarg6: seeAlso
1.9.3.1. コマンドラインでプラグインの設定
ldapmodify ユーティリティーを使用してプラグインを設定するには、以下を実行します。
  1. 新しい値を設定します。たとえば、Referential Integrity プラグインの更新遅延を 0 に設定するには、次のコマンドを実行します
    # ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
    
    dn: cn=referential integrity postoperation,cn=plugins,cn=config
    changetype: modify
    replace: referint-update-delay
    referint-update-delay: 0
  2. Directory Server インスタンスを再起動します。
    # systemctl restart dirsrv@instance_name
1.9.3.2. コンソールを使用したプラグインの設定
Directory Server コンソールを使用してプラグインを設定するには、以下を実行します。
  1. Directory Server コンソールを起動し、cn=Directory Manager ユーザー名を使用してログインします。
    詳細は、「管理コンソールを開く」 を参照してください。
  2. Servers and Applications タブで administration_domain_namehost_nameServer GroupDirectory Server(instance_name) に移動し、Open をクリックします。
  3. プラグイン に移動し、 設定するプラグインを選択します。
  4. 右側のパネルで Advanced ボタンをクリックします。
    注記
    Red Hat は、プラグイン固有の属性を使用する Property Editor を使用してプラグインを設定することを推奨します。
  5. プラグイン固有の属性を設定します。
  6. OK をクリックして、Property Editor を閉じます。
  7. Directory Server を再起動します。詳細は、「コンソールを使用した管理サーバーのサービスの再起動および停止」 を参照してください。

1.9.4. プラグインの優先順位の設定

プラグインの優先順位は、プラグインの実行順序にある優先順位です。操作前および操作後のプラグインでは、次のプラグインの開始前に 1 つのプラグインを実行して完了することができます。これにより、2 番目のプラグインが最初のプラグインの結果を活用できるようになります。
プラグインの設定エントリーの優先順位は、プラグインの設定エントリーの nsslapd-pluginPrecedence 属性で設定されます。この属性の値は、1(最も高い優先度)から 99(最も低い優先度)です。属性が設定されていない場合、デフォルト値は 50 になります。
重要
Red Hat サポートから指示されない限り、デフォルトの Directory Server プラグインにプラグインの優先順位を設定しないでください。プラグインの優先順位属性は、主にコア Directory Server プラグイン の動作を変更しない、カスタムプラグインの動作を管理することです。
nsslapd-pluginPrecedence 属性は ldapmodify コマンドを使用して設定されます。以下に例を示します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: cn=My Example Plugin,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginPrecedence
nsslapd-pluginPrecedence: 1

1.10. サーバー設定属性

Directory Server は、cn=config エントリーで維持される設定を /etc/dirsrv/slapd-instance_name/dse.ldif ファイルに保存します。新規インスタンスを設定すると、Directory Server はこのファイルで変更された設定属性のみを保存します。一覧にない属性には、デフォルト値を使用します。
これを使用すると、以下が可能になります。
  • /etc/dirsrv/slapd-instance_name/dse.ldif ファイルを表示して、このインスタンスに設定したすべての設定パラメーターを特定します。
  • パラメーターを削除してデフォルト値を復元します。
    設定パラメーターを削除すると、このパラメーターは /etc/dirsrv/slapd-instance_name/dse.ldif ファイルに一覧表示されなくなりました。ただし、LDAP プロトコルを使用して cn=config エントリーのパラメーターを検索すると、パラメーターとそのデフォルト値が表示されます。
    表1.1「削除できない設定属性」 に記載のパラメーターを削除して、デフォルトにリセットすることはできません。削除を試みると、サーバーは要求を拒否し、Server is unwilling to perform(53) エラーを発生させます。
  • 新しい Directory Server バージョンで提供される最新のデフォルト値を使用します。
    多くの場合、新しいバージョンは最適化された設定を提供し、セキュリティーが強化されます。たとえば、passwordStorageScheme 属性を設定しないと、Directory Server は、サポートされていて利用可能な、そして最も強力なパスワードストレージスキームを使用します。今後の更新で、セキュリティーを向上させるためにデフォルト値を変更すると、パスワードを設定する際に、新しいストレージスキームを使用してパスワードが自動的に暗号化されます。
    注記
    パラメーターを手動でデフォルトと同じ値に設定すると、値は更新されません。これは、新しいバージョンのデフォルト値が異なる場合に発生します。
表1.1 削除できない設定属性
nsslapd-accesslog nsslapd-auditlog nsslapd-bakdir
nsslapd-certdir nsslapd-certmap-basedn nsslapd-conntablesize
nsslapd-errorlog nsslapd-instancedir nsslapd-ldifdir
nsslapd-localhost nsslapd-localuser nsslapd-lockdir
nsslapd-rootpw nsslapd-referral nsslapd-referralmode
nsslapd-rundir nsslapd-saslpath nsslapd-schemadir
nsslapd-tmpdir nsslapd-workingdir

第2章 ディレクトリーデータベースの設定

ディレクトリーはデータベースに保存され、ディレクトリーツリーはデータベース全体に分散されます。本章では、接尾辞 の作成、ディレクトリーツリーの分岐点、および各接尾辞に関連付けられたデータベースの作成方法を説明します。本章では、リモートサーバーでデータベースを参照するデータベースリンクを作成する方法と、参照を使用してクライアントにディレクトリーデータの外部ソースを指定する方法も説明します。

2.1. 接尾辞の作成および維持

ディレクトリーツリーのさまざまな部分をさまざまなデータベースに保存でき、そのデータベースを複数のサーバーに分散できます。ディレクトリーツリーには、ノード と呼ばれる分岐点が含まれます。このノードはデータベースに関連付けられている可能性があります。接尾辞は、特定のデータベースに関連するディレクトリーツリーのノードです。たとえば、簡単なディレクトリーツリーは、図2.1「1 つのルート接尾辞があるディレクトリーツリー」 のように表示されます。

図2.1 1 つのルート接尾辞があるディレクトリーツリー

1 つのルート接尾辞があるディレクトリーツリー
ou=people 接尾辞と、その下のすべてのエントリーおよびノードは 1 つのデータベースに保存され、ou=groups 接尾辞は別のデータベースに保存され、ou=contractors 接尾辞はまた別のデータベースに保存される可能性があります。

2.1.1. 接尾辞の作成

root 接尾辞は、 サブ接尾辞の親です。これは、Directory Server 用に設計された大規模なツリーの一部になります。サブ接尾辞は、root 接尾辞の下にあるブランチです。root 接尾辞とサブ接尾辞はどちらも、ディレクトリーツリーのコンテンツを整理するために使用されます。root 接尾辞およびサブ接尾辞のデータはデータベースに含まれます。
ディレクトリーには、複数のルート接尾辞が含まれる場合があります。たとえば、ISP は複数の Web サイト(example.com 用)と redhat .com 用など、複数の Web サイトをホストする場合があります。ここでは、2 つのルート接尾辞が必要です。1 つは dc=example,dc=com 命名コンテキストに対応し、図2.2「2 つのルート接尾辞があるディレクトリーツリー」 のように、dc =redhat,dc=com 命名コンテキストに対応するものになります。

図2.2 2 つのルート接尾辞があるディレクトリーツリー

2 つのルート接尾辞があるディレクトリーツリー
また、検索操作からディレクトリーツリーの一部を除外するために、ルート接尾辞を作成することもできます。たとえば、Example Corporation は、一般的な Example Corporation ディレクトリーの検索から、ヨーロッパのオフィスを除外します。これを実行するには、2 つのルート接尾辞を作成します。1 つのルート接尾辞は、一般的な Example Corporation ディレクトリーツリー dc=example,dc=com に対応します。また、1 つのルート接尾辞は、ディレクトリーツリーのヨーロッパブランチ l=europe,dc=example,dc=com に対応します。クライアントアプリケーションの観点では、ディレクトリーツリーは 図2.3「検索操作に対するルート接尾辞の Off 制限があるディレクトリーツリー」 で説明されています。

図2.3 検索操作に対するルート接尾辞の Off 制限があるディレクトリーツリー

検索操作に対するルート接尾辞の Off 制限があるディレクトリーツリー
クライアントアプリケーションがディレクトリーの dc=example,dc=com ブランチで検索を実行すると、ディレクトリーの l=europe,dc=example,dc=com ブランチは別のルート接尾辞となるため、エントリーを返しません。
一般的な検索で、ディレクトリーツリーのヨーロッパブランチにエントリーを含める場合は、ヨーロッパのブランチに、一般的なブランチのサブ接尾辞を指定します。これには、Example Corporation、dc =example,dc=com のルート接尾辞を作成し、ヨーロッパのディレクトリーエントリー l=europe,dc=example,dc=com の下にサブ接尾辞を作成します。クライアントアプリケーションの観点からは、ディレクトリーツリーは 図2.4「従属接尾辞が含まれるディレクトリーツリー」 に示されるように表示されます。

図2.4 従属接尾辞が含まれるディレクトリーツリー

従属接尾辞が含まれるディレクトリーツリー
本セクションでは、Directory Server Console またはコマンドラインのいずれかを使用して、ディレクトリーの root およびサブ接尾辞を作成する方法を説明します。
2.1.1.1. コンソールを使用した新規ルート接尾辞の作成
  1. Directory Server コンソールで、Configuration タブを選択します。
  2. 左側のナビゲーションペインで Data を右クリックし、ポップアップメニューから New Root Suffix を選択します。
  3. New suffix フィールドに一意の接尾辞 を入力します。
    接尾辞は、dc =example,dc=com などの dc 命名規則を持つ行に指定する必要があります
  4. Create associated database automatically を選択して、新しいルート接尾辞と同時にデータベースを作成し、example2 などの Database name フィールドに新規データベースの一意の名前を入力します。名前は、英数字、ダッシュ(-)、およびアンダースコア(_)の組み合わせになります他の文字は使用できません。
    チェックボックスの選択を解除して、後で新しいルート接尾辞のデータベースを作成します。このオプションは、データベースが作成されるディレクトリーを指定します。新しいルート接尾辞は、データベースが作成されるまで無効になります。
新しいルート接尾辞が Data フォルダーに表示されます
2.1.1.2. コンソールを使用した新しい従属接尾辞の作成
  1. Directory Server コンソールで、Configuration タブを選択します。
  2. 左側のナビゲーションペインの Data で、新しいサブ接尾辞を追加する接尾辞を選択します。接尾辞を右クリックし、ポップアップメニューから New Sub Suffix を選択します。
    Create new sub suffix ダイアログボックスが表示されます。
  3. New suffix フィールドに一意の接尾辞名を入力します。接尾辞の名前は、dc の命名規則 (例: ou=groups)を持つ行に指定する必要があります
    root 接尾辞は名前に自動的に追加されます。たとえば、サブ接尾辞 ou=groupsdc=example,dc=com 接尾辞の下に作成される場合、コンソールには ou=groups,dc=example,dc=com という名前が自動的に付けられます
  4. Create associated database automatically チェックボックスを選択し、新しいサブ接尾辞と同時にデータベースを作成し、example2 などの Database name フィールドに新規データベースの一意の名前を入力します。名前は、英数字、ダッシュ(-)、およびアンダースコア(_)の組み合わせになります他の文字は使用できません。
    このチェックボックスを選択しないと、新しいサブ接尾辞のデータベースよりも後で作成する必要があります。データベースが作成されるまで、新しいサブ接尾辞が無効になります。
接尾辞は、左側のナビゲーションペインの Data ツリーのルート接尾辞の下に自動的に表示されます。
2.1.1.3. コマンドラインでのルート接尾辞およびサブ接尾辞の作成
接尾辞の設定情報は cn=mapping tree,cn=config エントリーに保存されます。ldapmodify ユーティリティーを使用して、新しい接尾辞をディレクトリーに追加します。
ルート接尾辞の作成
たとえば、dc =example,dc=com のルート接尾辞を追加するには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: cn="dc=example,dc=com",cn=mapping tree,cn=config
changetype: add
cn: dc=example,dc=com
objectclass: top
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: backend
nsslapd-backend: UserData
従属接尾辞の作成
サブ接尾辞の作成は、root 接尾辞の作成と同様です。違いは、nsslapd-parent-suffix に親接尾辞を設定する点です。
たとえば、dc= example,dc =com ルート接尾辞の下に ou= groups サブ接尾辞を作成するには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: cn="ou=groups,dc=example,dc=com",cn=mapping tree,cn=config
changetype: add
cn: ou=groups,dc=example,dc=com
objectclass: top
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: backend
nsslapd-backend: GroupData
nsslapd-parent-suffix: dc=example,dc=com

2.1.2. 接尾辞の維持

2.1.2.1. デフォルトの命名コンテキストの表示
命名コンテキストは接尾辞に類似しており、命名ディレクトリーエントリーのルート構造です。ディレクトリーとデータ構造によっては、複数の命名コンテキストが存在する場合があります。たとえば、標準の Directory Server 設定には、dc =example,dc=comcn=config の設定接尾辞である o=netscaperoot などのユーザー接尾辞があります。
多くのディレクトリーツリーには複数の命名コンテキストがあり、異なるタイプのエントリーや論理データ分割で使用されます。Directory Server にアクセスするクライアントは、使用する必要がある命名コンテキストを認識しない場合があります。Directory Server には、デフォルトの命名コンテキストが他に認識されていない場合に、デフォルトの命名コンテキストがクライアントに通知するサーバー設定属性があります。
デフォルトの命名コンテキストは、cn=confignsslapd-defaultnamingcontext 属性に設定されます。この値はルート DSE (Directory Server Agent Service Entry) に伝播され、ルート DSE の defaultnamingcontext 属性を確認してクライアントが匿名でクエリーできます。
# ldapsearch -p 389 -h server.example.com -x -b "" -s base | egrep namingcontext
namingContexts: dc=example,dc=com
namingContexts: dc=example,dc=net
namingContexts: dc=redhat,dc=com
defaultnamingcontext: dc=example,dc=com
重要
設定の整合性を維持するには、nsslapd-allowed-to-delete-attrs 一覧から nsslapd-defaultnamingcontext 属性を削除しないでください。
デフォルトでは、nsslapd-defaultnamingcontext 属性は、nsslapd-allowed-to-delete-attrs 属性に削除 できる 属性の一覧に含まれます。これにより、現在のデフォルトの接尾辞を削除してから、適切にサーバー設定を更新できます。
何らかの理由で削除可能な設定属性の一覧から nsslapd-defaultnamingcontext 属性を削除すると、その属性への変更は保持されません。デフォルトの接尾辞を削除すると、その変更はサーバー設定に伝播できません。つまり、nsslapd-defaultnamingcontext 属性は、空白 (削除) ではなく古い情報を保持することを意味します。これは正しい現在の設定です。
2.1.2.2. 接尾辞の無効化
特定の状況では、ディレクトリーの接尾辞を無効にする必要があります。接尾辞が無効になっていると、その接尾辞に関連するデータベースのコンテンツは、クライアントがアクセスできなくなります。
2.1.2.2.1. コマンドラインでの接尾辞の無効化
コマンドラインで接尾辞を無効にするには、対応する接尾辞エントリーの nsslapd-state 属性を disabled に設定します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
dn: cn=suffix_DN,cn=mapping tree,cn=config
changetype: modify
replace: nsslapd-state
nsslapd-state: disabled
2.1.2.2.2. コンソールを使用した接尾辞の無効化
コンソールを使用して接尾辞を無効にするには、以下を実行します。
  1. Directory Server コンソールで、Configuration タブを選択します。
  2. 左側のナビゲーションペインで Data で、接尾辞をクリックして無効にします。
  3. Suffix Setting タブをクリックし、Enable this suffix チェックボックスの選択を解除します。
2.1.2.3. 接尾辞の削除
接尾辞が不要になった場合は、その接尾辞をデータベースから削除します。
警告
接尾辞を削除すると、その接尾辞に関連するデータベースエントリーおよびレプリケーション情報もすべて削除されます。
2.1.2.3.1. コマンドラインを使用した接尾辞の削除
コマンドラインで接尾辞を削除するには、以下を実行します。
  1. マッピングツリーから接尾辞を削除します。
    # ldapdelete -D "cn=Directory Manager" -W -p 389 -h server.example.com -x "cn="suffix_DN",cn=mapping tree,cn=config"
  2. 接尾辞が別のデータベースを使用する場合は、データベースを削除します。
    # ldapdelete -D "cn=Directory Manager" -W -p 389 -h server.example.com -x "cn=database_name,cn=ldbm database,cn=plugins,cn=config"
2.1.2.3.2. コンソールを使用した接尾辞の削除
コンソールを使用して接尾辞を削除するには、以下を行います。
  1. Directory Server コンソールで、Configuration タブを選択します。
  2. 左側のナビゲーションペインで Data の下で、削除する接尾辞を選択します。
  3. 接尾辞を右クリックし、メニューから Delete を選択します。
  4. Delete this suffix およびそのサブ接尾辞のすべてを選択 するか 、この接尾辞のみを削除します

2.2. データベースの作成および維持

ディレクトリーデータを整理するための接尾辞を作成したら、そのディレクトリーのデータを含むデータベースを作成します。

2.2.1. データベースの作成

ディレクトリーツリーは、複数の Directory Server データベースに配布できます。複数のデータベースにデータを分散する方法は 2 つあります。
各接尾辞に 1 つのデータベース各接尾辞のデータは個別のデータベースに含まれます。
個別の接尾辞に含まれるデータを格納するために、3 つのデータベースが追加されます。
このツリーユニットの分割は、たとえば次の 3 つのデータベースに対応しています。
この例では、DB1 には ou=people のデータおよび dc=example,dc=com のデータが含まれ、クライアントが dc=example,dc=com に基づいて検索を実行できるようにします。ただし、DB2 には ou=groups のデータのみが含まれ、DB3 には ou=contractors のデータのみが含まれます。
1 つの接尾辞に複数のデータベースがあります。
ディレクトリーツリーの ou=people ブランチ内のエントリー数が非常に大きくなると、2 つのデータベースを格納しなければならないとします。この場合、ou=people に含まれているデータは 2 つのデータベースに分散できます。
DB1 には A-K からの名前の人が含まれ、DB2 には L-Z からの名前が含まれます。DB3 には ou=groups のデータが含まれ、DB4 には ou=contractors のデータが含まれます。
カスタムプラグインは、複数のデータベースにまたがってデータを単一の接尾辞から分散します。Directory Server のディストリビューションロジックの作成方法は、Red Hat コンサルティングにお問い合わせください。
2.2.1.1. コンソールを使用した既存の接尾辞の新規データベースの作成
  1. Directory Server コンソールで、Configuration タブを選択します。
  2. 左側のペインで Data を展開し、新しいデータベースを追加する接尾辞をクリックします。
  3. 接尾辞を右クリックし、ポップアップメニューから New Database を選択します。
  4. example2 などのデータベースの一意の名前を入力します。データベース名は、英数字、ダッシュ(-)、およびアンダースコア(_)の組み合わせになります
    Create database in フィールドには、デフォルトのデータベースディレクトリー(/var/lib/dirsrv/slapd-instance/db)と新規データベースの名前が自動的に入力されます。また、別のディレクトリーの場所を入力またはブラウズすることもできます。
2.2.1.2. コマンドラインから単一の接尾辞用の新規データベースの作成
ldapmodify コマンドラインユーティリティーを使用して、ディレクトリー設定ファイルに新しいデータベースを追加します。データベース設定情報は cn=ldbm database,cn=plugins,cn=config エントリーに保存されます。たとえば、新しいデータベースをサーバー example1 に追加します。
  1. ldapmodify を実行して、新規データベースのエントリーを作成します。
    # ldapmodify -a -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
    
    dn: cn=UserData,cn=ldbm database,cn=plugins,cn=config
    changetype: add
    objectclass: extensibleObject
    objectclass: nsBackendInstance
    nsslapd-suffix: ou=people,dc=example,dc=com
    追加されたエントリーは、root またはサブ接尾辞 ou=people,dc=example,dc=com のデータが含まれる UserData という名前のデータベースに対応します。
  2. 「コマンドラインでのルート接尾辞およびサブ接尾辞の作成」 の説明に従って、ルートまたは従属接尾辞を作成します。DN 属性で指定されるデータベース名は、接尾辞エントリーの nsslapd-backend 属性の値に対応している必要があります。
2.2.1.3. 単一の接尾辞に複数のデータベースの追加
1 つの接尾辞は、複数のデータベースに分散できます。ただし、接尾辞を配布するには、ディレクトリーを拡張するためにカスタムディストリビューション機能を作成する必要があります。カスタムディストリビューション機能の作成に関する詳細は、Red Hat コンサルティングにお問い合わせください。
注記
エントリーが分散されたら、再分散できません。以下の制限が適用されます。
  • ディストリビューション機能は、エントリーディストリビューションのデプロイ後は変更できません。
  • エントリーを異なるデータベースに分散させる可能性がある場合は、LDAP modrdn 操作を使用してエントリーの名前を変更することができません。
  • 分散ローカルデータベースは複製できません。
  • エントリーを異なるデータベースに分散させる可能性がある場合は、ldapmodify 操作を使用してエントリーを変更することができません。
これらの制限に違反すると、Directory Server はエントリーを正しく特定して返さないようにします。
カスタムディストリビューションロジックプラグインを作成したら、そのプラグインをディレクトリーに追加します。
ディストリビューションロジックは、接尾辞で宣言された関数です。この関数は、この接尾辞に到達するすべての操作に対して呼び出されます。これには、接尾辞の前に開始するサブツリー検索操作が含まれます。ディストリビューション機能は、コンソールとコマンドラインインターフェースの両方を使用して接尾辞に挿入できます。
2.2.1.3.1. Directory Server コンソールを使用したカスタムディストリビューション機能の接尾辞への追加
  1. Directory Server コンソールで、Configuration タブを選択します。
  2. 左側のナビゲーションペインで Data を展開します。ディストリビューション機能を適用する接尾辞を選択します。
  3. 右側のウィンドウで Databases タブを選択します。
  4. 接尾辞に関連付けられているデータベースは、Databases タブにすでにリストされています。Add をクリックして、追加のデータベースを接尾辞に関連付けます。
  5. ディストリビューションライブラリーへのパスを入力します。
  6. Function name フィールドにディストリビューション機能の名前を入力します。
2.2.1.3.2. コマンドラインを使用したカスタムディストリビューション機能の接尾辞への追加
  1. ldapmodify を実行します。
    # ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
  2. 以下の属性を接尾辞エントリー自体に追加し、カスタムディストリビューションロジックに関する情報を提供します。
    dn: suffix
    changetype: modify
    add: nsslapd-backend
    nsslapd-backend: Database1
    -
    add: nsslapd-backend
    nsslapd-backend: Database2
    -
    add: nsslapd-backend
    nsslapd-backend: Database3
    -
    add: nsslapd-distribution-plugin
    nsslapd-distribution-plugin: /full/name/of/a/shared/library
    -
    add: nsslapd-distribution-funct
    nsslapd-distribution-funct: distribution-function-name
    nsslapd-backend 属性は、この接尾辞に関連付けられたすべてのデータベースを指定します。nsslapd-distribution-plugin 属性は、プラグインが使用するライブラリーの名前を指定します。nsslapd-distribution-funct 属性は、ディストリビューション機能自体の名前を提供します。
ldapmodify コマンドラインユーティリティーの使用に関する詳細は、「コマンドラインでエントリーの管理」 を参照してください。

2.2.2. Directory データベースの維持

2.2.2.1. 読み取り専用モードでのデータベースの配置
データベースが読み取り専用モードの場合は、エントリーを作成、変更、または削除することはできません。読み取り専用モードが役立つ状況の 1 つは、コンシューマーを手動で初期化する場合や、Directory Server からデータをバックアップまたはエクスポートする前です。読み取り専用モードは、特定の時点でのこれらのデータベースの状態の正確なイメージを保証します。
Directory Server コンソールおよびコマンドラインユーティリティーは、エクスポート操作またはバックアップ操作の前にディレクトリーを読み取り専用モードに自動的に配置しません。これは、ディレクトリーの更新で利用できなくなるためです。ただし、マルチマスターレプリケーションでは、これは問題ではない可能性があります。
2.2.2.1.1. コンソールを使用したデータベースの読み取り専用の設定
  1. Directory Server コンソールで、Configuration タブを選択します。
  2. 左側のペインで Data を展開します。データベースが含まれる接尾辞を展開して、読み取り専用モードにします。
  3. 読み取り専用モードに設定するデータベースを選択します。
  4. 右側のペインで、Database Settings タブを選択します。
  5. データベースが読み取り専用 チェックボックスにチェックマークを入れます。
この変更は即座に有効になります。
データベースをインポートまたは復元する前に、操作の影響を受けるデータベースが読み取り専用モード ではないことを確認してください
読み取り専用モードを無効にするには、Directory Server Console でデータベースを再度開き、データベースが読み取り専用 チェックボックスの選択を解除します。
2.2.2.1.2. コマンドラインからデータベースの読み取り専用の設定
データベースを読み取り専用モードに手動で配置するには、以下を実行します。
  1. ldapmodify を実行します。
    # ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
  2. read-only 属性を on に変更します。
    dn: cn=database_name,cn=ldbm database,cn=plugins,cn=config
    changetype: modify
    replace: nsslapd-readonly
    nsslapd-readonly: on
注記
デフォルトでは、インストール時に作成されるデータベースの名前は userRoot です。
2.2.2.1.3. 読み取り専用モードでの Directory Server の配置
Directory Server が複数のデータベースを維持し、すべてのデータベースを読み取り専用モードで配置する必要がある場合は、1 回の操作で実行できます。
警告
この操作は、Directory Server 設定が読み取り専用であるため、サーバー設定の更新、プラグインの有効化または無効化、読み取り専用モードの場合は Directory Server を再起動することはできません。読み取り専用モードを有効にすると、コンソールから元に戻す ことはできません。設定ファイルを変更する必要があります。
注記
Directory Server にレプリカが含まれている場合は、レプリケーションを無効にするため、読み取り専用モードを使用 しないでください
Directory Server を読み取り専用モードにするには、以下を実行します。
  1. Directory Server コンソールの Configuration タブを選択し、左側のペインのナビゲーションツリーでトップエントリーを選択します。
  2. 右側のペインで Settings タブを選択します。
  3. Make Entire Server Read-Only チェックボックスを選択します。
  4. Save をクリックし、サーバーを再起動します。
2.2.2.2. データベースの削除
データベースを削除すると、そのデータベースの設定情報とエントリーのみが削除され、物理データベース自体は削除されません。
  1. Directory Server コンソールで、Configuration タブを選択します。
  2. Data フォルダーを展開し、接尾辞を選択します。
  3. 削除するデータベースを選択します。
  4. データベースを右クリックし、ポップアップメニューから Delete を選択します。
  5. Delete Database ダイアログボックスでデータベースを削除する必要があることを確認します。
2.2.2.3. トランザクションログディレクトリーの変更
トランザクションログにより、Directory Server は、インスタンスが予期せずにシャットダウンした後にデータベースを復元できます。特定の状況では、管理者はトランザクションログへのパスを変更したい場合があります。たとえば、Directory Server データベースとは異なる物理ディスクに保存するには、以下のコマンドを実行します。
注記
パフォーマンスを向上させるには、場所を変更する代わりに、トランザクションログが含まれるディレクトリーに高速ディスクをマウントします。詳細は、『Red Hat Directory Server パフォーマンスチューニングガイド』の該当するセクションを参照してください
トランザクションログディレクトリーの場所を変更するには、以下を行います。
  1. Directory Server インスタンスを停止します。
    # systemctl stop dirsrv@instance_name
  2. トランザクションログ用に新しい場所を作成します。以下に例を示します。
    # mkdir -p /srv/dirsrv/instance_name/db/
  3. Directory Server のみがディレクトリーにアクセスできるように、パーミッションを設定します。
    # chown dirsrv:dirsrv /srv/dirsrv/instance_name/db/
    # chmod 770 /srv/dirsrv/instance_name/db/
  4. 以前のトランザクションログディレクトリーからすべての __db.* ファイルを削除します。以下に例を示します。
    # rm /var/lib/dirsrv/slapd-instance_name/db/__db.*
  5. 以前のトランザクションログディレクトリーから新しいトランザクションログディレクトリーに、すべての log.* ファイルを移動します。以下に例を示します。
    # mv /var/lib/dirsrv/slapd-instance_name/db/log.* \
         /srv/dirsrv/instance_name/db/
  6. SELinux が enforcing モードで実行している場合は、ディレクトリーに dirsrv_var_lib_t コンテキストを設定します。
    # semanage fcontext -a -t dirsrv_var_lib_t /srv/dirsrv/instance_name/db/
    # restorecon -Rv /srv/dirsrv/instance_name/db/
  7. /etc/dirsrv/slapd-instance_name/dse.ldif ファイルを編集し、cn=config,cn=ldbm database,cn=plugins,cn=config エントリーの nsslapd-db-logdirectory パラメーターを更新します。以下に例を示します。
    dn: cn=config,cn=ldbm database,cn=plugins,cn=config
    ...
    nsslapd-db-logdirectory: /srv/dirsrv/instance_name/db/
  8. インスタンスを起動します。
    # systemctl start dirsrv@instance_name

2.5. 参照の使用

リファーラルは、特定の情報についてどのサーバーに接続するかをクライアントアプリケーションに通知します。このリダイレクトは、クライアントアプリケーションが、ローカルサーバーに存在しないディレクトリーエントリーを要求するか、メンテナンスのためにデータベースがオフラインになったときに発生します。本セクションでは、リファーラルに関する以下の情報を提供します。
ディレクトリーでリファーラル部分を使用する方法に関する概念情報は、『Red Hat Directory Server デプロイメントガイド』 を参照してください。

2.5.1. リファーラルモードでのサーバーの起動

リファーラルは、現在のサーバーが利用できない場合や、クライアントが現在のサーバーに保持されない情報を要求する場合に、クライアントアプリケーションを別のサーバーにリダイレクトするために使用されます。 たとえば、Directory Server の設定変更がある間に Directory Server を起動すると、そのサーバーが利用できない場合にすべてのクライアントを別のサプライヤーに参照します。リファーラルモードで Directory Server を起動するには、refer コマンドを使用します。
refer オプションを指定して nsslapd を実行します。
# ns-slapd refer -D /etc/dirsrv/slapd-instance_name [-p port] -r referral_url
  • /etc/dirsrv/slapd-instance_name/ は、Directory Server 設定ファイルがあるディレクトリーです。これは、Red Hat Enterprise Linux 7 上のデフォルトの場所です。
  • port は、参照モードで開始する Directory Server のオプションのポート番号です。
  • referral_url は、クライアントに返される参照先です。LDAP URL の形式は、「付録C LDAP URL」を参照してください。

2.5.2. デフォルト参照の設定

デフォルトの参照は、ディレクトリーが維持する接尾辞内に含まれていない DN に操作を送信するクライアントアプリケーションに返されます。以下の手順では、コンソールおよびコマンドラインユーティリティーを使用して、ディレクトリーのデフォルトリファーラルを設定する方法を説明します。
2.5.2.1. コンソールを使用したデフォルトのリファーラルの設定
  1. Directory Server コンソールで、Configuration タブを選択します。
  2. 左側のペインで、ナビゲーションツリーでトップエントリーを選択します。
  3. 右側のペインで Settings タブを選択します。
  4. 参照の LDAP URL を入力します。
    複数の参照 URL をスペースで区切って入力します。
    "ldap://dir1.example.com:389/dc=example,dc=com" "ldap://dir2.example.com/"
    LDAP URL の詳細は、付録C LDAP URL を参照してください。
2.5.2.2. コマンドラインからのデフォルトリファーラルの設定
ldapmodify は、ディレクトリーの設定ファイルの cn=config エントリーにデフォルトの参照を追加できます。たとえば、1 つの Directory Server の dir1.example.com から dir2.example.com という名前のサーバーに新しいデフォルトリファーラルを追加するには、新しい行を cn=config エントリーに追加します。
  1. ldapmodify ユーティリティーを実行し、デフォルトの参照を dir2.example.com サーバーに追加します。
    # ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
    
    dn: cn=config
    changetype: modify
    replace: nsslapd-referral
    nsslapd-referral: ldap://dir2.example.com/
ディレクトリーの cn=config エントリーにデフォルトの参照を追加した後、ディレクトリーはクライアントアプリケーションによるリクエストに対してデフォルトの参照を返します。Directory Server を再起動する必要はありません。

2.5.3. スマートリファーラルの作成

スマートリファーラルは、ディレクトリーエントリーまたはディレクトリーツリーを特定の LDAP URL にマッピングします。スマートリファーラルを使用すると、クライアントアプリケーションは特定のサーバーまたは特定のサーバーの特定のエントリーを参照できます。
たとえば、クライアントアプリケーションは、ディレクトリーエントリー uid=jdoe,ou=people,dc=example,dc=com を要求します。サーバー directory.europe.example.com のエントリー cn=john doe,o=people,l=europe,dc=example,dc=com を参照するクライアントにスマートリファーラルが返されます。
ディレクトリーがスマートリファーラルを使用する方法は、RFC 2251 セクション 4.1.11 で指定された標準仕様に準拠します。RFC は、http://www.ietf.org/rfc/rfc2251.txt でダウンロードできます。
2.5.3.1. Directory Server コンソールを使用したスマートリファーラルの作成
  1. Directory Server コンソールで、Directory タブを選択します
  2. 左側のナビゲーションペインでツリーを参照して、参照を追加するエントリーを選択します。
  3. エントリーを右クリックし、Set Smart Referrals を選択します。
  4. Enable Smart Referral チェックボックスを選択します。(オプションにチェックを入れると、エントリーからすべてのスマート参照を削除し、エントリーから 参照 オブジェクトクラスを削除します。)
  5. Enter a new Smart Referral フィールドに、LDAP URL 形式でリファーラルを入力し、Add をクリックします。LDAP URL は以下の形式である必要があります。
    ldap://server:port/[optional_dn]
    Server は、サーバーのホスト名、IPv4 アドレス、または IPv6 アドレスになります。optional_dn は、サーバーが要求するクライアントアプリケーションに戻るための明示的な DN です。
    構成は、参照の追加プロセスを指示するウィザードが開きます。
    スマート参照 リスト は、選択したエントリーに対して現在参照情報を一覧表示します。参照のリスト全体が、すべてのオペレーションの場合は Return Referrals リクエストに対応してクライアントアプリケーションに返されます。またSuffix Settings タブの Update Operations オプションの場合は Return Referrals が返されます。これは Configuration タブで利用できます。
    一覧を変更するには、Edit をクリックして選択したリファーラルを編集するか、Delete をクリックして選択した参照を削除します。
  6. 別の認証情報を使用するように参照を設定するには、Authentication をクリックし 適切な DN とパスワードを指定します。この認証は、コンソールが閉じられるまでのみ有効です。その後、コンソールへのログインに使用されるのと同じ認証にリセットされます。
2.5.3.2. コマンドラインからのスマートリファーラルの作成
ldapmodify コマンドラインユーティリティーを使用して、コマンドラインからスマートリファーラルを作成します。
スマートリファーラルを作成するには、関連するディレクトリーエントリーを作成し、参照 オブジェクトクラスを追加します。このオブジェクトクラスは単一の属性 ref を許可します。ref 属性には LDAP URL が含まれている必要があります。
たとえば、以下を追加して、既存のエントリー uid=jdoe のスマートリファーラルを返します。
dn: uid=jdoe,ou=people,dc=example,dc=com
objectclass: referral
ref: ldap://directory.europe.example.com/cn=john%20doe,ou=people,l=europe,dc=example,dc=com
注記
LDAP URL のスペースに続く情報は、サーバーで無視されます。このため、参照として使用する LDAP URL 内の領域の代わりに %20 を使用します。
directory.europe .example.com にリファーラルを持つ uid=jdoe,ou=people,dc= example,dc=com エントリーを追加するには、インポート前に LDIF ファイルに以下を追加します。
dn: uid=jdoe,ou=people,dc=example,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: referral
cn: john doe
sn: doe
uid: jdoe
ref: ldap://directory.europe.example.com/cn=john%20doe,ou=people,l=europe,dc=example,dc=com
DN パスにすでにリファーラルがある場合は、ldapmodify-M オプションを使用します。スマートリファーラルの詳細は、『 『Red Hat Directory Server デプロイメントガイド』を参照してください』。

2.5.4. バグ修正参照の作成

以下の手順では、接尾辞 にリファーラルを作成する方法を説明します。これは、接尾辞のプロセスがデータベースまたはデータベースリンクではなく、リファーラルを使用して処理されることを意味します。
警告
リファーラルを返すように接尾辞を設定すると、接尾辞に関連付けられたデータベースに含まれる ACI は無視されます。
2.5.4.1. コンソールを使用した接尾辞リファーラルの作成
参照を使用して、クライアントアプリケーションを別のサーバーに一時的にポイントできます。たとえば、接尾辞にリファーラルを追加して、接尾辞と関連したデータベースを、Directory Server データベースのユーザーに影響を与えずに、メンテナンスのために、接尾辞に関連付けられたデータベースをオフにできます。
接尾辞でリファーラルを設定するには、以下を実行します。
  1. Directory Server コンソールで、Configuration タブを選択します。
  2. 左側のペインの Data で、参照を追加する接尾辞を選択します。
  3. Suffix Settings タブをクリックし、Return Referrals for ... を選択します。operations ラジオボタン。
    Update Operations で Return Referrals を選択すると、ディレクトリーは更新および書き込みリクエストのみを読み取り専用データベースにリダイレクトします。たとえば、ディレクトリーデータのローカルコピーがあり、そのデータは検索に利用できますが、更新には利用できないため、複数のサーバーに複製されます。Directory Server が更新要求に対してのみ参照を有効にすると、クライアントがエントリーの更新を要求すると、クライアントはデータを所有するサーバー(変更要求を続行できる)と呼ばれます。
  4. Referrals タブをクリックします。LDAP URL を入力します。[1] Enter a new referral フィールドで、Construct をクリックして LDAP URL を作成します
  5. Add をクリックして、参照を一覧に追加します。
    複数の参照を入力できます。ディレクトリーは、クライアントアプリケーションからのリクエストに対応して参照のリスト全体を返します。
2.5.4.2. コマンドラインからの接尾辞リファーラルの作成
cn=mapping tree,cn=config ブランチ下のディレクトリー設定ファイルの root またはサブ接尾辞エントリーに接尾辞リファーラルを追加します。
ldapmodify を実行し、接尾辞リファーラルを ou=people,dc=example,dc=com root 接尾辞に追加します。
# ldapmodify -a -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: cn=ou=people,dc=example,dc=com,cn=mapping tree,cn=config
changetype: add
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: referral
nsslapd-referral: ldap://zanzibar.com/
nsslapd-state 属性は reference に設定されます。つまり この接尾辞に作成されたリクエストに対して参照が返されます。nsslapd-referral 属性には、接尾辞によって返される参照の LDAP URL が含まれます(この場合は、za nzibar.com サーバーへの参照 )。
nsslapd-state 属性は、更新時に参照に 設定することもできます。つまり、更新リクエスト以外のすべての操作にデータベースが使用されます。クライアントアプリケーションが更新時に 参照セットに設定された接尾辞の更新リクエストを行うと、 クライアントは参照を受け取ります。
接尾辞設定属性の詳細は、「コマンドラインでのルート接尾辞およびサブ接尾辞の作成」 を参照してください。


[1] 付録C LDAP URL には、LDAP URL の構造に関する詳細が記載されています。

第3章 ディレクトリーエントリーの管理

本章では、Directory Server Console および ldapmodify および ldapdelete コマンドラインユーティリティーを使用して、ディレクトリーの内容を変更する方法を説明します。
Active Directory に保存されているエントリーは、Windows Sync を介して Directory Server に追加できます。Windows User Sync で同期されたエントリーを追加または変更する方法は、16章Red Hat Directory Server と Microsoft Active Directory の同期 を参照してください。

3.1. コマンドラインでエントリーの管理

コマンドラインを使用して LDAP 操作を実行するには、openldap-clients パッケージをインストールします。このパッケージによりインストールされるユーティリティーを使用すると、以下が可能になります。
  • 新規エントリーの追加
  • 既存のエントリーへの新規属性の追加
  • 既存のエントリーおよび属性の更新
  • エントリーからエントリーおよび属性を削除します
  • 一括操作の実行
openldap-clients パッケージをインストールするには、以下を実行します。
# yum install openldap-clients
注記
LDAP 操作を実行するには、適切なパーミッションが必要です。アクセス制御の詳細は、「18章アクセス制御の管理」を参照してください。

3.1.1. ldapaddldapmodify、および ldapdelete ユーティリティーへの入力の提供

ディレクトリー内のエントリーまたは属性を追加、更新、または削除する場合は、ユーティリティーのインタラクティブモードを使用して LDAP データ交換形式 (LDIF) ステートメントを入力するか、LDIF ファイルをこれらのファイルに渡します。
LDIF の詳細は、「LDIF ファイルの形式の概要」を参照してください。
3.1.1.1. インタラクティブモードでの入力の提供
インタラクティブモードでは、ldapaddldapmodify、および ldapdelete ユーティリティーはコマンドラインから入力を読み取ります。インタラクティブモードを終了するには、Ctrl+D (^D) のキーの組み合わせを押して End Of File (EOF) エスケープシーケンスを送信します。
インタラクティブモードでは、ユーティリティーは、Enter を 2 回押したときに、または EOF シーケンスを送信するときに、ステートメントを LDAP サーバーに送信します。
対話型モードを使用します。
  • ファイルを作成せずに LDIF ステートメントに入るには、次を実行します。

    例3.1 ldapmodify インタラクティブモードを使用した LDIF ステートメントの入力

    以下の例では、インタラクティブモードで ldapmodify を開始し、telephoneNumber 属性を削除し、cn=manager_name,ou=people,dc=example,dc=com 値を持つ manager 属性を uid=user,ou=people,dc=example,dc=com エントリーに追加します。最後のステートメントの後に Ctrl+D を押して、インタラクティブモードを終了します。
    # ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
    
    dn: uid=user,ou=people,dc=example,dc=com
    changetype: modify
    delete: telephoneNumber
    -
    add: manager
    manager: cn=manager_name,ou=people,dc=example,dc=com
    ^D
  • 別のコマンドで出力される LDIF ステートメントを Directory Server にリダイレクトするには、次を実行します。

    例3.2 リダイレクトされたコンテンツでの ldapmodify インタラクティブモードの使用

    以下の例では、command_that_outputs_LDIF コマンドの出力を ldapmodify にリダイレクトします。対話モードは、リダイレクトされたコマンドの終了後に自動的に終了します。
    # command_that_outputs_LDIF | ldapmodify -D "cn=Directory Manager" \
         -W -p 389 -h server.example.com -x
3.1.1.2. LDIF ファイルを使用した入力の提供
インタラクティブモードでは、ldapaddldapmodify、および ldapdelete ユーティリティーは、ファイルから LDIF ステートメントを読み取ります。このモードを使用して、多数の LDIF ステートメントを Directory Server に送信します。

例3.3 LDIF ステートメントを持つファイルを ldapmodify に渡す

  1. LDIF ステートメントでファイルを作成します。たとえば、以下のステートメントで ~/example.ldif ファイルを作成します。
    dn: uid=user,ou=people,dc=example,dc=com
    changetype: modify
    delete: telephoneNumber
    -
    add: manager
    manager: cn=manager_name,ou=people,dc=example,dc=com
    この例では、telephoneNumber 属性を削除し、cn=manager_name,ou=people,dc=example,dc=com 値を持つ manager 属性を uid=user,ou=people,dc=example,dc=com エントリーに追加します。
  2. -f file_name オプションを使用して、ファイルを ldapmodify コマンドに渡します。
    # ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x \
         -f ~/example.ldif

3.1.2. 継続的操作モード

複数の LDIF ステートメントを Directory Server に送信し、1 回の操作に失敗すると、プロセスは停止します。ただし、エラーが発生する前に処理されるエントリーは、正常に追加、変更、または削除されています。
エラーを無視してバッチでさらに LDIF ステートメントの処理を続けるには、-c オプションを ldapadd および ldapmodify に渡します。以下に例を示します。
# ldpamodify -c -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

3.1.3. エントリーの追加

新しいエントリーをディレクトリーに追加するには、ldapadd ユーティリティーまたは ldapmodify ユーティリティーを使用します。ldapadd/bin/ldapmodify へのシンボリックリンクであることに注意してください。そのため、ldapaddldapmodify -a と同じ操作を実行します。
注記
親エントリーがすでに存在する場合のみ、新しいディレクトリーエントリーを追加できます。たとえば、 ou=people,dc=example,dc=com の親エントリーが存在しない場合は、cn=user,ou=people,dc=example,dc=com エントリーを追加できません。
3.1.3.1. ldapadd を使用したエントリーの追加
ldapadd ユーティリティーを使用して、たとえば cn=user,ou=people,dc=example,dc=com ユーザーエントリーを追加するには、以下を実行します。
# ldapadd -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,ou=People,dc=example,dc=com
uid: user
givenName: given_name
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
sn: surname
cn: user
注記
ldapadd を実行すると、changetype: add 操作が自動的に実行されます。そのため、LDIF ステートメントで changetype: add を指定する必要はありません。
コマンドで使用されるパラメーターの詳細は、ldapadd(1) の man ページを参照してください。
3.1.3.2. ldapmodify を使用したエントリーの追加
ldapmodify ユーティリティーを使用して、たとえば cn=user,ou=people,dc=example,dc=com ユーザーエントリーを追加するには、以下を実行します。
# ldapmodify -a -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,ou=People,dc=example,dc=com
uid: user
givenName: given_name
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
sn: surname
cn: user
注記
-a オプションを ldapmodify コマンドに渡すと、ユーティリティーは changetype: add 操作を自動的に実行します。そのため、LDIF ステートメントで changetype: add を指定する必要はありません。
コマンドで使用されるパラメーターの詳細は、ldapmodify(1) の man ページを参照してください。
3.1.3.3. ルートエントリーの作成
dc=example,dc=com などのデータベース接尾辞のルートエントリーを作成するには、cn=Directory Manager ユーザーとしてバインドし、エントリーを追加します。
DN は、データベースのルートまたは従属接尾辞の DN に対応します。
たとえば、dc=example,dc=com 接尾辞を追加するには、次のコマンドを実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: dc=example,dc=com
changetype: add
objectClass: top
objectClass: domain
dc: example
注記
ルートオブジェクトは、接尾辞に 1 つのデータベースがある場合にのみ追加できます。複数のデータベースに保存されている接尾辞を作成する場合は、-n back_end オプションを指定して ldif2db ユーティリティーを使用し、新しいエントリーを保持するデータベースを設定する必要があります。詳細は、「コマンドラインからのインポート」 を参照してください。

3.1.4. ディレクトリーエントリーの更新

ディレクトリーエントリーを変更する場合は、changetype: modify ステートメントを使用します。change 操作に応じて、エントリーから属性を追加、変更、または削除できます。
ldapmodify ユーティリティーを使用して、LDIF ステートメントを Directory Server に送信します。たとえば、インタラクティブモードでは、以下のようになります。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
ldapmodify コマンドで使用されるパラメーターの詳細は、ldapmodify(1) の man ページを参照してください。
3.1.4.1. エントリーへの属性の追加
エントリーに属性を追加するには、add 操作を使用します。
たとえば、555-1234567 の値を持つ telephoneNumber 属性を uid=user,dc=people,dc=example,dc=com エントリーに追加するには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,dc=people,dc=example,dc=com
changetype: modify
add: telephoneNumber
telephoneNumber: 555-1234567
属性が多値である場合、属性名を複数回指定して、1 つの操作ですべての値を追加できます。たとえば、uid=user,dc=people,dc=example,dc=com に 2 つの telephoneNumber 属性を同時に追加するには、以下のコマンドを実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,dc=people,dc=example,dc=com
changetype: modify
add: telephoneNumber
telephoneNumber: 555-1234567
telephoneNumber: 555-7654321
3.1.4.2. 属性の値の更新
属性の値を更新する手順は、属性が単値であるか多値であるかによって異なります。
単値属性の更新
単値属性を更新する場合は、replace 操作を使用して既存の値を上書きします。以下のコマンドは、uid=user,dc=people,dc=example,dc=com エントリーの manager 属性を更新します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,dc=people,dc=example,dc=com
changetype: modify
replace: manager
manager: uid=manager_name,dc=people,dc=example,dc=com
多値属性の特定値の更新
多値属性の特定の値を更新するには、最初に置き換えるエントリーを削除してから、新しい値を追加する必要があります。以下のコマンドは、uid=user,dc=people,dc=example,dc=com エントリーの現在 555-1234567 に設定されている telephoneNumber 属性だけを更新します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,dc=people,dc=example,dc=com
changetype: modify
delete: telephoneNumber
telephoneNumber: 555-1234567
-
add: telephoneNumber
telephoneNumber: 555-9876543
3.1.4.3. エントリーからの属性の削除
エントリーから属性を削除するには、delete 操作を実行します。
属性の削除
たとえば、uid=user,dc=people,dc=example,dc=com エントリーから manager 属性を削除するには、以下のコマンドを実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,dc=people,dc=example,dc=com
changetype: modify
delete: manager
注記
属性に複数の値が含まれる場合、この操作によりすべての値が削除されます。
多値属性から特定の値の削除
多値属性から特定の値を削除する場合は、LDIF ステートメントに属性とその値を一覧表示します。たとえば、uid=user,dc=people,dc=example,dc=com エントリーから 555-1234567 に設定されている telephoneNumber 属性だけを削除するには、以下のコマンドを実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,dc=people,dc=example,dc=com
changetype: modify
delete: telephoneNumber
telephoneNumber: 555-1234567

3.1.5. エントリーの削除

エントリーを削除すると、ディレクトリーからエントリーが削除されます。
注記
子エントリーのないエントリーのみを削除できます。たとえば、uid=user,ou=People,dc=example,dc=com エントリーがまだ存在している場合は、ou=People,dc=example,dc=com エントリーを削除できません。
3.1.5.1. ldapdelete を使用したエントリーの削除
ldapdelete ユーティリティーを使用すると、1 つまたは複数のエントリーを削除できます。たとえば、uid=user,ou=People,dc=example,dc=com エントリーを削除するには、次のコマンドを実行します。
# ldapdelete -D "cn=Directory Manager" -W -p 389 -h server.example.com -x "uid=user,ou=People,dc=example,dc=com"
1 つの操作で複数のエントリーを削除するには、コマンドに追加します。以下に例を示します。
# ldapdelete -D "cn=Directory Manager" -W -p 389 -h server.example.com -x \
     "uid=user1,ou=People,dc=example,dc=com" \
     "uid=user2,ou=People,dc=example,dc=com"
使用されるパラメーターの詳細は、ldapdelete(1) の man ページを参照してください。
3.1.5.2. ldapmodify を使用したエントリーの削除
ldapmodify ユーティリティーを使用してエントリーを削除するには、changetype: delete 操作を使用します。たとえば、uid=user,ou=People,dc=example,dc=com エントリーを削除するには、次のコマンドを実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,dc=people,dc=example,dc=com
changetype: delete

3.1.6. エントリーの名前変更および変更

エントリーの名前変更時に、ldapmodify ユーティリティーを使用して LDIF ステートメントを Directory Server に送信します。たとえば、インタラクティブモードでは、以下のようになります。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
ldapmodify コマンドで使用されるパラメーターの詳細は、ldapmodify(1) の man ページを参照してください。
注記
moddn アクセス制御リスト (ACL) を使用して、エントリーを移動するパーミッションを付与します。詳細は 「ソースおよび宛先 DN のターゲット」を参照してください。
3.1.6.1. 名前変更操作のタイプ
以下の名前変更操作が存在します。
エントリーの名前変更
エントリーの名前を変更すると、modrdn 操作はエントリーの RDN (Relative Distinguished Name) を変更します。
サブエントリーの名前変更
サブツリーエントリーの場合、modrdn 操作はサブツリーと子エントリーの DN コンポーネントの名前を変更します。
大規模なサブツリーでは、このプロセスに多くの時間とリソースが必要になる可能性があることに注意してください。
エントリーを新しい親へ移動
サブツリーの名前を変更する同様のアクションは、エントリーをあるサブツリーから別のサブツリーに移動することです。これは、modrdn 操作の拡張タイプで、エントリーの名前を同時に変更し、newSuperior 属性を設定して、エントリーを別の親に移動します。
3.1.6.2. エントリーの名前変更に関する考慮事項
名前変更の操作を実行する場合は、以下の点に留意してください。
  • root 接尾辞の名前を変更することはできません。
  • サブツリー名前変更操作によるレプリケーションへの影響は最小限に抑えられます。レプリカ合意は、データベースのサブツリーではなく、データベース全体に適用されます。そのため、サブツリーの名前変更操作ではレプリカ合意の再設定は必要ありません。サブツリーの名前変更操作後のすべての名前の変更は、通常どおり複製されます。
  • サブツリーの名前を変更し、同期合意を再設定する必要がある場合があります。同期合意は、接尾辞またはサブツリーレベルで設定されます。そのため、サブツリーの名前を変更すると、同期が中断する可能性があります。
  • サブツリーの名前を変更するには、サブツリーに設定されたサブツリーレベルのアクセス制御命令 (ACI) を手動で再設定し、サブツリーの子エントリーに設定されたエントリーレベルの ACI (エントリーレベルの ACI) を手動で再設定する必要があります。
  • ou から dc への移行など、サブツリーのコンポーネントを変更しようとすると、スキーマ違反で失敗する可能性があります。たとえば、organizationalUnit オブジェクトクラスには ou 属性が必要です。この属性がサブツリーの名前の一部として削除されると、操作は失敗します。
  • グループを移動すると、MemberOf プラグインは memberOf 属性を自動的に更新します。ただし、グループが含まれるサブツリーを移動する場合は、cn=memberof task エントリーでタスクを手動で作成するか、fixup-memberof.pl を使用して関連する memberOf 属性を更新する必要があります。
    memberOf 属性参照のクリーンアップに関する詳細は、「memberOf 値の同期」 を参照してください。
3.1.6.3. deleteOldRDN パラメーター
エントリーの名前を変更すると、deleteOldRDN パラメーターは古い RDN が削除されるかどうかを制御します。
deleteOldRDN: 0
既存の RDN は、新しいエントリーの値として保持されます。生成されるエントリーには、古い属性と新しい共通名 (CN) を持つ 2 つの cn 属性が含まれます。
たとえば、以下の属性は、deleteOldRDN: 0 パラメーターを設定して、cn=old_group,dc=example,dc=com からcn=new_group,dc=example,dc=com に名前を変更したグループに属しています。
dn: cn=new_group,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: old_group
cn: new_group
deleteOldRDN: 1
Directory Server は古いエントリーを削除し、新しい RDN を使用して新しいエントリーを作成します。新しいエントリーには、新しいエントリーの cn 属性のみが含まれます。
たとえば、以下のグループは、deleteOldRDN: 1 パラメーターを設定して、cn=new_group,dc=example,dc=com に名前を変更しました。
dn: cn=new_group,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: groupofuniquenames
cn: new_group
3.1.6.4. エントリーまたはサブツリーの名前変更
エントリーまたはサブツリーの名前変更には、changetype: modrdn 操作を使用し、newrdn 属性に新しい RDN を設定します。
たとえば、cn=old_group,ou=Groups,dc=example,dc=com エントリーの名前を cn= new_group,ou=Groups,dc=example,dc=com に変更するには、次のコマンドを実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: cn=old_group,ou=Groups,dc=example,dc=com
changetype: modrdn
newrdn: cn=new_group
deleteOldRDN: 1
deleteOldRDN の詳細は、deleteOldRDN パラメーター」を参照してください。
3.1.6.5. エントリーを新しい親へ移動
エントリーを新しい親に移動するには、changetype: modrdn 操作を使用して、以下の属性を設定します。
newrdn
移動したエントリーの RDN を設定します。RDN が同じままであっても、このエントリーを設定する必要があります。
newSuperior
新しい親エントリーの DN を設定します。
たとえば、uid=ユーザーエントリーを ou= Engineering,ou=People,dc=example,dc=com から ou= Marketing,ou=People,dc=example,dc=com に移動するには、以下を実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,ou=Engineering,ou=People,dc=example,dc=com
changetype: modrdn
newrdn: uid=user
newSuperior= ou=Marketing,ou=People,dc=example,dc=com
deleteOldRDN: 1
deleteOldRDN の詳細は、deleteOldRDN パラメーター」を参照してください。

3.1.7. 特殊文字の使用

コマンドラインを使用する場合は、スペース ( )、アスタリスク (*)、バックスラッシュ (\) などのコマンドラインインタープリターに特別な意味を持つ文字を引用符で囲みます。コマンドラインインタープリターに応じて、一重引用符または二重引用符を使用します。
たとえば、cn=Directory Manager ユーザーとして認証するには、ユーザーの DN を引用符で囲みます。
# ldapmodify -a -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
また、DN にコンポーネントのコンマが含まれる場合は、バックスラッシュを使用してエスケープします。たとえば、uid=user,ou=People,dc=example.com Chicago, IL ユーザーとして認証するには、次のコマンドを実行します。
# ldapmodify -a -D "cn=uid=user,ou=People,dc=example.com Chicago\, IL" \
     -W -p 389 -h server.example.com -x

3.1.8. Binary 属性の使用

特定の属性は、jpegPhoto 属性などのバイナリー値をサポートします。このような属性を追加または更新すると、ユーティリティーはファイルから属性の値を読み取ります。このような属性を追加または更新するには、ldapmodify ユーティリティーを使用できます。
たとえば、uid=user,ou=People,dc=example,dc=com エントリーに jpegPhoto 属性を追加し、/home/user_name/photo.jpg ファイルから属性の値を読み取るには、次のコマンドを実行します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,ou=People,dc=example,dc=com
changetype: modify
add: jpegPhoto
jpegPhoto:< file:///home/user_name/photo.jpg
重要
:< の間には、スペースがないことに注意してください。

3.1.9. 国際化されたディレクトリーにおけるエントリーの更新

属性の値を英語以外の言語で使用するには、属性の値を言語タグに関連付けます。
ldapmodify を使用して言語タグが設定されている属性を更新する場合は、値と言語タグを正確に一致させる必要があります。そうでないと、操作は失敗します。
たとえば、lang-fr 言語タグが設定された属性値を変更するには、modify 操作にタグを追加します。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user,ou=People,dc=example,dc=com
changetype: modify
replace: homePostalAddress;lang-fr
homePostalAddress;lang-fr: 34 rue de Seine

3.2. ディレクトリーコンソールを使用したエントリーの管理

Directory Server コンソールの Directory タブおよび Property Editor を使用して、エントリーを個別に追加、変更、または削除できます。
複数のエントリーを同時に追加するには、「コマンドラインでエントリーの管理」 で説明されているコマンドラインユーティリティーを使用します。
注記
適切なアクセス制御ルールが設定されない限り、ディレクトリーは変更できません。ディレクトリーのアクセス制御ルールを作成する方法は、18章アクセス制御の管理 を参照してください。

3.2.1. ルートエントリーの作成

新しいデータベースが作成されるたびに、データベースに保存される接尾辞に関連付けられます。その接尾辞を表すディレクトリーエントリーは自動的に作成されません。
データベースの root エントリーを作成するには、以下を実行します。
  1. Directory Server コンソールで、Configuration タブを選択します。
  2. 左側のメニューの Data エントリーを右クリックし、メニューから New Root Suffix を選択します。
  3. 新しい接尾辞およびデータベース情報を入力します。
  4. Directory タブで、Directory Server を表す最上位オブジェクトを右クリックし、New Root Object を選択します。
    New Root Object のセカンダリーメニューは、対応するディレクトリーエントリーのない新しい接尾辞を表示します。作成するエントリーに対応する接尾辞を選択します。
  5. New Object ウィンドウで、新規エントリーに対応するオブジェクトクラスを選択します。
    オブジェクトクラスには、接尾辞に名前を付けるために使用される属性が含まれている必要があります。たとえば、エントリーが ou=people,dc=example,dc=com の接尾辞に対応している場合は、または ou 属性を許可する別のオブジェクトクラスを選択します。
  6. New Object ウィンドウで OK をクリックします。
新しいエントリーの プロパティーエディターが開きます。「ディレクトリーエントリーの変更」 で説明されているように、OK をクリックして現在の値 を使用するか、エントリーを変更します。

3.2.2. ディレクトリーエントリーの作成

Directory Server コンソールは、新しいディレクトリーエントリー用に事前に設定したフォームとともに事前定義されたテンプレートを提供します。表3.1「エントリーテンプレートと対応するオブジェクトクラス」 は、各テンプレートに使用されるオブジェクトクラスのタイプを表示します。
表3.1 エントリーテンプレートと対応するオブジェクトクラス
Template オブジェクトクラス
ユーザー inetOrgPerson
グループ groupOfUniqueNames
組織単位 organizationalUnit
ロール nsRoleDefinition
サービスのクラス cosSuperDefinition
別のタイプ Other では、ユーザーが特定のオブジェクトクラスおよび属性を適用できるようにして、あらゆる種類のエントリーを作成できます。
  1. Directory Server コンソールで、Directory タブを選択します
  2. 左側のペインで、メインエントリーを右クリックして新しいエントリーを追加し、エントリーのタイプ( UserGroup、OrganizationalUnitRoleClass of Service、または Other )を選択します。
  3. 新しいエントリータイプが Other の場合、オブジェクトクラスの一覧が開きます。一覧からオブジェクトクラスを選択して新規エントリーを定義します。
  4. 一覧表示されているすべての属性の値を指定します。必要な属性にはアスタリスク(*)が付いています。
  5. オブジェクトクラス(エントリータイプ)で利用可能な属性の詳細一覧を表示するには、Advanced ボタンをクリックします。
    Property Editor で追加の属性を選択し、属性値を入力します。
  6. OK をクリックしてエントリーを保存します。新しいエントリーが右側のペインに表示されます。

3.2.3. ディレクトリーエントリーの変更

Directory Server コンソールのディレクトリーエントリーを変更するには、Property Editor と呼ばれるダイアログウィンドウを使用します。Property Editor には、エントリーに属するオブジェクトクラスおよび属性のリストが含まれ、オブジェクトクラス、属性、属性値、および属性サブタイプを追加および削除することで、そのエントリーに属するオブジェクトクラスおよび属性の編集に使用できます。
プロパティーエディターは、複数の方法で開くことができます。
  • Directory タブで、エントリーを右クリックし、ポップアップメニューから Advanced Properties を選択します。
  • Directory タブから、エントリーをダブルクリックして、詳細 ボタンをクリックします
  • Create... new entry フォームから Advanced ボタンをクリックします。
  • OKをクリックして、新規オブジェクト ウィンドウから
3.2.3.1. オブジェクトクラスのエントリーへの追加または削除
オブジェクトクラスをエントリーに追加するには、以下を実行します。
  1. Directory Server コンソールの Directory タブで、エントリーを右クリックし、ポップアップメニューから Advanced を選択します。
  2. オブジェクトクラスフィールドを選択し、Add Value をクリックします。
    Add Object Class ウィンドウが開きます。これは、エントリーに追加できるオブジェクトクラスの一覧を表示します。
  3. 追加するオブジェクトクラスを選択し、OK をクリックします。
エントリーからオブジェクトクラスを削除するには、削除するオブジェクトクラスのテキストボックスに、Delete Value をクリックします。
3.2.3.2. エントリーへの属性の追加
エントリーに属性を追加する前に、エントリーに属性を必要とするか、許可するオブジェクトクラスを含める必要があります。詳細は、「オブジェクトクラスのエントリーへの追加または削除」 および 12章ディレクトリースキーマの管理 を参照してください。
エントリーに属性を追加するには、以下を実行します。
  1. Directory Server コンソールの Directory タブで、エントリーを右クリックし、ポップアップメニューから Advanced を選択します。
  2. Add Attribute をクリックします。
  3. 一覧から追加する属性を選択し、OK をクリックします。
    注記
    追加する属性が一覧にない場合は、最初に属性が含まれるオブジェクトクラスを追加し、続いて属性を追加します。オブジェクトクラスの追加方法は、「オブジェクトクラスのエントリーへの追加または削除」 を参照してください。必要な属性を含むオブジェクトクラスが見つからない場合は、Red Hat Directory Server 10 Configuration, Command, and File Reference (この属性を使用するオブジェクトクラスの一覧)の属性を検索します。
  4. 属性名の右側にあるフィールドの新しい属性の値を入力します。
エントリーから属性とすべての値を削除するには、Edit メニューから Delete Attribute を選択します。
3.2.3.3. 大きな属性の追加
設定属性 nsslapd-maxbersize は LDAP 要求の最大サイズ制限を設定します。Directory Server のデフォルト設定では、この属性を 2 メガバイトに設定します。要求で 2 メガバイトより大きい非常に大きな属性を追加しようとすると、LDAP の追加または修正操作は失敗します。ただし、この制限はレプリケーションプロセスには適用されません。
非常に大きな属性を追加するには、まず nsslapd-maxbersize 設定属性の設定を、実行する最大の LDAP 要求よりも大きい値に変更します。
設定する値を決定する際には、1 つの属性だけでなく、属性を追加するのに使用される LDAP add および modify 操作 のすべての要素 を考慮してください。考慮すべき要因には、以下が含まれます。
  • リクエストの各属性名のサイズ
  • リクエストの各属性の値のサイズ
  • 要求内の DN のサイズ
  • オーバーヘッド(通常は 10 キロバイト)
nsslapd-maxbersize 設定を増やす必要がある一般的な問題の 1 つは、CRL 値( certificateRevocationListauthorityRevocationList、および deltaRevocationList など)を保持する属性を使用することです。
3.2.3.4. 属性値の追加
多値属性は、1 つの属性に対して複数の値をエントリーに追加できます。
  1. Directory Server コンソールの Directory タブで、エントリーを右クリックし、ポップアップメニューから Advanced を選択します。
  2. 値を追加する属性を選択し、値 の追加 をクリックします
  3. 新しい属性値を入力します。
エントリーから属性値を削除するには、削除する属性値のテキストボックスに、Delete Value をクリックします。
3.2.3.5. 属性サブタイプの追加
サブタイプでは、外部文字のセットバージョンを提供するなど、同じエントリー値をさまざまな方法で表すことができます。エントリーに追加できる属性には、言語、バイナリー、および発音の 3 種類のサブタイプがあります。
サブタイプをエントリーに追加するには、次のコマンドを実行します。
  1. Directory Server コンソールの Directory タブで、エントリーを右クリックし、ポップアップメニューから Properties を選択します。
  2. Add Attribute をクリックし、一覧から追加する属性を選択します。
  3. 言語 ドロップダウンリストから値を選択して、言語サブタイプを追加します。Subtype ドロップダウンリストから値を選択して、バイナリーまたはプローブのサブタイプを追加します。

言語サブタイプ

ユーザーの名前は、デフォルト言語以外の言語の文字でより正確に表現できる場合があります。たとえば、ユーザーである Noriko は日本語の名前を持ち、可能な限り日本語の文字で表現します。指定のname 属性の 言語サブタイプとして日本語を選択して、他のユーザーが日本語と英語で名前を検索できるようにします。以下に例を示します。

givenname;lang-ja
属性に言語サブタイプを指定するには、以下のようにサブタイプを属性名に追加します。
attribute;lang-subtype:attribute value
attribute はエントリーに追加される属性です。サブタイプ は、言語の略語の 2 文字です。サポートされる言語のサブタイプは、表D.1「サポートされる言語サブタイプ」 に記載されています。
エントリーの属性 インスタンスごとに 1 つの言語サブタイプのみを追加できます。複数の言語のサブタイプを割り当てるには、別の属性インスタンスをエントリーに追加してから、新しい言語のサブタイプを割り当てます。たとえば、以下は不正なものです。
cn;lang-ja;lang-en-GB:value
代わりに以下を使用します。
cn;lang-ja:ja-value
cn;lang-en-GB:value

バイナリーサブタイプ

バイナリーサブタイプを属性に割り当てると、ユーザー証明書(usercertificate;binary)などの属性値がバイナリーであることを示します。

バイナリーデータ はバイナリー サブタイプ(例: jpegphoto)を含まない属性に保存できますが、バイナリー サブタイプは、属性タイプの複数のバリアントが存在する可能性があるクライアントに対して指定します。

Pronunciation サブタイプ

属性に pronunciation サブタイプを割り当てると、属性値が電話番号であることを示します。サブタイプは、属性名に attribute;phonetic として追加されます。このサブタイプは、一般的に、複数のアルファベットを持つ言語サブタイプと組み合わせて使用されます。1 つは電話番号です。

このサブタイプは、cngivenname などのユーザー名が含まれることが想定される属性に便利です。たとえば、anyname;lang-ja;phonetic は、属性値がユーザーの日本語名の電話番号であることを示します。

3.2.4. ディレクトリーエントリーの削除

  1. Directory Server コンソールで、Directory タブを選択します
  2. エントリーを右クリックして削除するメニューから Delete を選択します。
警告
サーバーは、エントリーまたはエントリーを即座に削除します。削除操作を元に戻す方法はありません。

第4章 ディレクトリーエントリーの変更の追跡

これは、エントリーに変更が加えられるタイミングを追跡するのに役立ちます。Directory Server が追跡するエントリーの変更には、以下の 2 つの側面があります。
  • 変更シーケンス番号を使用してデータベースへの変更を追跡します。これは、レプリケーションおよび同期で使用されるシーケンス番号の変更に類似しています。通常のディレクトリー操作はすべて、シーケンス番号がトリガーされます。
  • 作成および変更の情報を割り当てます。これらの属性は、エントリーを作成して直近に変更したユーザーの名前と、エントリーの作成および修正時のタイムスタンプを記録します。
注記
エントリー USN、時間および名前の変更、および時間および作成はすべて操作属性であり、通常の ldapsearch では返されません。操作属性の検索実行に関する詳細は、「操作属性の検索」を参照してください。

4.1. 更新シーケンス番号でデータベースへの変更の追跡

USN プラグインは、LDAP クライアントがデータベース内のものが変更されたことを通知する方法を提供します。

4.1.1. エントリーシーケンス番号の概要

USN プラグインが有効な場合は、エントリーに対して書き込み操作を実行するたびに、エントリーに割り当てられるシーケンス番号 (USN) を更新します。書き込み操作には、add、modify、modrdn、および delete 操作が含まれます。エクスポート操作などの内部データベース操作は、更新シーケンスでカウントされません。 USN カウンターは、最近割り当てられた USN を追跡します。
4.1.1.1. ローカルおよびグローバルの USN
USN は、単一のエントリーではなく、データベース全体に対してグローバルに評価されます。USN は、データベースまたはディレクトリーの変更を追跡するために単に上向きにチェックするという点で、レプリケーションと同期の変更シーケンス番号に似ています。ただし、エントリー USN は CSN と別個に維持され、USN は複製されません。
このエントリーには、entryUSN オペレーション属性のエントリーへの最後の変更の変更番号が表示されます。(操作属性の検索実行に関する詳細は、「操作属性の検索」 を参照してください。)

例4.1 エントリー USN の例

 dn: uid=jsmith,ou=People,dc=example,dc=com
 mail: jsmith@example.com
 uid: jsmith
 givenName: John
 objectClass: top
 objectClass: person
 objectClass: organizationalPerson
 objectClass: inetorgperson
 sn: Smith
 cn: John Smith
 userPassword: {SSHA}EfhKCI4iKl/ipZMsWlITQatz7v2lUnptxwZ/pw==
 entryusn: 1122
USN プラグインには、ローカルモードとグローバルモードという 2 つのモードがあります。
  • ローカルモードでは、各バックエンドデータベースには、そのバックエンドデータベースに固有の USN カウンターを持つ USN プラグインのインスタンスがあります。これはデフォルト設定です。
  • グローバルモードでは、ディレクトリー全体に追加された変更に適用されるグローバル USN カウンターを使用する USN プラグインのグローバルインスタンスがあります。
USN プラグインをローカルモードに設定すると、結果はローカルのバックエンドデータベースに限定されます。USN プラグインをグローバルモードに設定すると、返される結果はディレクトリー全体に対して行われます。
ルート DSE は、lastusn 属性のデータベースのエントリーに割り当てられた最新の USN を表示します。USN プラグインがローカルモードに設定されているので、各データベースに独自のローカル USN カウンターがある場合、lastUSN は、USN が割り当てられているデータベースと、USN の両方を表示します。
lastusn;database_name:USN
以下に例を示します。
lastusn;example1: 2130
lastusn;example2: 2070
グローバルモードでは、データベースが共有 USN カウンターを使用する場合、lastUSN 属性は最新の USN のみを表示します。
lastusn: 4200
4.1.1.2. USN エントリーのインポート
エントリーがインポートされると、USN プラグインは nsslapd-entryusn-import-initval 属性を使用して、エントリーに USN が割り当てられているかどうかを確認します。nsslapd-entryusn-import-initval の値が数値である場合、インポートされたエントリーはこの数字をエントリーの USN として使用します。nsslapd-entryusn-import-initval の値が数値でない場合、USN プラグインは lastUSN 属性の値を使用して、インポートしたエントリーの USN で増やします。

4.1.2. USN プラグインの設定

「Directory Server コンソールでプラグインの有効化」 で説明されているように、USN プラグインをエントリーに記録するには有効にする必要があります。プラグインは、Directory Server Console またはコマンドラインを使用して有効にできます。以下に例を示します。
# ldapmodify -D "cn=Directory Manager" -W -x
dn: cn=USN,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on
次にサーバーを再起動して変更を適用します。

4.1.3. グローバル USN の有効化

デフォルト設定では、Directory Server は各バックエンドデータベースに一意の更新シーケンス番号 (USN) を使用します。すべてのバックエンドデータベースで一意の USN を有効にするには、以下を実行します。
  1. USN プラグインを有効にします。「USN プラグインの設定」 を参照してください。
  2. nsslapd-entryusn-global パラメーターを on に設定します。
    # ldapmodify -D "cn=Directory Manager" -W -x
    dn: cn=config
    changetype: modify
    replace: nsslapd-entryusn-global
    nsslapd-entryusn-global: on

4.1.4. USN Tombstone エントリーのクリーンアップ

エントリーが削除されると、USN プラグインは、エントリーを tombstone エントリーに移動します。レプリケーションが有効な場合は、USN および Replication プラグインによって個別の tombstone エントリーが保持されます。tombstone エントリーはレプリケーションプロセスで削除されますが、サーバーのパフォーマンスのために、サーバーをレプリカに変換するか、サーバーのメモリーを解放する前に USN tombstones を削除することが有益です。
usn-tombstone-cleanup.pl コマンドは、特定のデータベースバックエンドまたは特定の接尾辞の USN tombstone エントリーを削除します。必要に応じて、特定の USN までの tombstone エントリーをすべて削除できます。以下に例を示します。
# /usr/lib64/dirsrv/instance/usn-tombstone-cleanup.pl -D "cn=Directory Manager" -w secret -s "ou=people,dc=example,dc=com" -m 1100
バックエンドは、- s オプションを使用して、- n オプションまたは接尾辞を使用して指定する必要があります。両方を指定すると、- s オプション の接尾辞が使用されます。
usn-tombstone-cleanup.pl コマンドのオプションは、表4.1「USN-tombstone-cleanup.pl オプション」 に一覧表示されます。このツールの詳細は、設定、『コマンド、およびファイルリファレンス を参照してください』。
表4.1 USN-tombstone-cleanup.pl オプション
オプション 詳細
-D rootdn Directory Manager などの root 権限でユーザー DN を指定します。デフォルトは、Directory Manager の DN です。これは、cn=config 下の nsslapd-root 属性から読み取られます。
-m maximum_USN 削除するエントリーの上限を設定します。指定された最大値(inclusive)までの entryUSN 値を持つすべての tombstone エントリーは削除されますが、USN 値を超えると削除されます。最大 USN 値が設定されていない場合、すべてのバックエンド tombstone エントリーが削除されます。
-n backendInstance クリーニングするエントリーが含まれるデータベースの名前を指定します(削除)。
-s suffix クリーニングするエントリーを含む接尾辞の名前を指定します(削除)。
-w password ユーザー DN に関連付けられたパスワード。

4.2. 操作属性によるエントリー変更の追跡

デフォルト設定を使用すると、Directory Server は、全エントリーで以下の操作属性を追跡します。
  • creatorsName: エントリーを最初に作成したユーザーの識別名 (DN) です。
  • createTimestamp: エントリーの作成時にグリニッジ標準時 (GMT) 形式のタイムスタンプ。
  • modifiersName: エントリーを最後に変更したユーザーの識別名。
  • modifyTimestamp: エントリーが最後に修正された時点の GMT 形式のタイムスタンプ。
デフォルトの検索では操作属性が返されないことに注意してください。これらの属性はクエリーで明示的に要求する必要があります。詳細は 「操作属性の検索」を参照してください。
重要
これらの操作属性の追跡は、無効にしないことが推奨されます。無効にすると、エントリーは nsUniqueID 属性に割り当てられた一意の ID を取得しなくなり、レプリケーションは機能しません。

4.2.2. コマンドラインを使用した変更の追跡を有効にする方法

変更追跡はデフォルトで有効になっています。Red Hat は、この機能を無効にしないことを推奨します。コマンドラインでエントリー変更の追跡を再度有効にするには、次のコマンドを実行します。
  1. nsslapd-lastmodon に設定します。
    # ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
    
    dn: cn=config
    nsslapd-lastmod: on
  2. 必要に応じて、不足している nsUniqueID 属性を再生成するには、以下を実行します。
    1. データベースを LDAP データ交換形式(LDIF)ファイルにエクスポートします。「コマンドラインを使用した LDIF へのデータベースのエクスポート」 を参照してください。
    2. LDIF ファイルからデータベースをインポートします。「コマンドラインからのインポート」 を参照してください。

4.2.3. コンソールを使用した変更の追跡を有効にする方法

変更追跡はデフォルトで有効になっています。Red Hat は、この機能を無効にしないことを推奨します。コンソールを使用してエントリー変更の追跡を再度有効にするには、以下を実行します。
  1. Directory Server コンソールを開きます。「Directory Server コンソールを開く」 を参照してください。
  2. Configuration タブでサーバー名を選択します。
  3. Settings タブで Track Entry Modification Times チェックボックスを選択します。
  4. 必要に応じて、不足している nsUniqueID 属性を再生成するには、以下を実行します。
    1. データベースを LDAP データ交換形式(LDIF)ファイルにエクスポートします。「コマンドラインを使用した LDIF へのデータベースのエクスポート」 を参照してください。
    2. LDIF ファイルからデータベースをインポートします。「コマンドラインからのインポート」 を参照してください。

4.3. プラグイン開始更新のバインド DN の追跡

エントリーへの変更の 1 つで、ディレクトリーツリー全体で、他の自動変更をトリガーすることができます。たとえば、ユーザーが削除されると、そのユーザーは Referential Integrity Postoperation プラグインが属するグループから自動的に削除されます。
最初のアクションは、サーバーにバインドされているユーザーアカウントによって実行されているものとしてエントリーに表示されますが、関連するすべての更新 (デフォルト) はプラグインによって実行されているものとして表示され、どのユーザーがその更新を開始したかについての情報はありません。たとえば、MemberOf プラグインを使用してグループメンバーシップでユーザーエントリーを更新し、グループアカウントの更新はバインドされたユーザーが実行済みとして表示されますが、ユーザーエントリーの編集は MemberOf プラグインによって実行されると表示されます。
dn: cn=my_group,ou=groups,dc=example,dc=com
modifiersname: uid=jsmith,ou=people,dc=example,dc=com

dn: uid=bjensen,ou=people,dc=example,dc=com
modifiersname: cn=memberOf plugin,cn=plugins,cn=config
nsslapd-plugin-binddn-tracking 属性により、サーバーは更新操作を開始したユーザーと、実際に実行した内部プラグインを追跡できます。バインドされたユーザーは modifiersname 操作属性および creatorsname 操作属性に表示されますが、実行されたプラグインは internalModifiersname 操作属性および internalCreatorsname 操作属性に表示されます。以下に例を示します。
dn: uid=bjensen,ou=people,dc=example,dc=com
modifiersname: uid=jsmith,ou=people,dc=example,dc=com
internalModifiersname: cn=memberOf plugin,cn=plugins,cn=config
nsslapd-plugin-binddn-tracking 属性は、バインドされたユーザーと、その接続に対して実行される更新間の関係を追跡し、維持します。
注記
internalModifiersname 属性および internalCreatorsname 属性は、常にプラグインをアイデンティティーとして表示します。このプラグインは、MemberOf プラグインなどの追加のプラグインである可能性があります。コア Directory Server が変更を行うと、プラグインはデータベースプラグイン cn=ldbm database,cn=plugins,cn=config になります。
nsslapd-plugin-binddn-tracking 属性はデフォルトで無効になっています。サーバーがバインド DN に基づいて操作を追跡できるようにするには、ldapmodify を使用してその属性を有効にします。
# ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: cn=config
changetype: modify
replace: nsslapd-plugin-binddn-tracking
nsslapd-plugin-binddn-tracking: on

4.4. パスワード変更時間の追跡

パスワードの変更操作は、通常、エントリーに対するその他の変更として扱われるため、更新時間は lastModified 操作属性に記録されます。ただし、Active Directory 同期におけるパスワードの更新や、他の LDAP クライアントへの接続を容易にするため、パスワード変更の時間は別々に記録しないといけない場合があります。
パスワードポリシー内の passwordTrackUpdateTime 属性は、エントリーのパスワードが最後に更新された日時のタイムスタンプを記録するようサーバーに指示します。パスワードの変更時間は、pwdUpdateTime ( modifyTimestamp または lastModified の操作属性とは別の) ユーザーエントリーで操作属性として保存されます。
passwordTrackUpdateTime 属性は、パスワード変更時間にアクセスする必要があるクライアントに応じて、グローバルパスワードポリシー、サブツリー、またはユーザーレベルのポリシーの一部として設定できます。パスワードポリシーの設定は、「パスワードポリシーの管理」を参照してください。

第5章 参照整合性の維持

参照整合性 は、関連するエントリー間の関係を維持するデータベースメカニズムです。Directory Server では、参照整合性を使用して、ディレクトリー内の 1 つのエントリーへの更新が、更新されたエントリーを参照するその他のエントリーに適切に反映されるようにします。
たとえば、ユーザーのエントリーがディレクトリーから削除され、参照整合性が有効になると、サーバーはユーザーがメンバーとなるグループからユーザーも削除します。参照整合性が有効になっていないと、ユーザーは管理者が手動で削除するまでグループのメンバーのままになります。これは、ユーザーおよびグループの管理のディレクトリーに依存する他の製品と Directory Server を統合する場合に重要な機能です。

5.1. 参照整合性の仕組み

Referential Integrity Postoperation プラグインを有効にすると、削除または名前変更の操作直後に、指定した属性で整合性の更新を実行します。デフォルトでは、Referential Integrity Postoperation プラグインは無効になっています。
注記
プラグインによって生成された操作が複製されるため、マルチマスターレプリケーション環境の 1 つのサプライヤーレプリカでのみ Referential Integrity Postoperation プラグインを有効にします。複数のマスターでプラグインを有効にする場合は、サーバーですでに実行された操作を管理し、再適用する必要があります。
ユーザーエントリーまたはグループエントリーがディレクトリー内で削除、更新、名前変更、または移動すると、その操作は参照整合性ログファイルに記録されます。ログファイル内の識別名 (DN) の場合、Directory Server はプラグイン設定に設定された属性を定期的に検索および更新します。
  • エントリーの場合は、ログファイルで削除済みと表示され、ディレクトリーの対応する属性が削除されます。
  • エントリーの場合は、ログファイルで更新済みと表示され、ディレクトリーの対応する属性が更新されます。
  • エントリーの場合は、ログファイルで名前が変更または移動済みと表示され、ディレクトリーの対応する属性の名前が変わります。
デフォルトでは、Referential Integrity Postoperation プラグインが有効な場合は、削除または名前変更の操作直後に memberuniquememberowner、および seeAlso 属性で整合性の更新を実行します。ただし、Referential Integrity Postoperation プラグインの動作は、ディレクトリーのニーズに応じて複数の方法で設定できます。
  • レプリケーション変更ログに整合性の更新を記録します。
  • 更新間隔を変更します。
  • 参照整合性を適用する属性を選択します。
  • 参照整合性を無効にします。
参照整合性で使用される属性はすべて存在と等価性のためにインデックス化する 必要 があります。これらの属性をインデックス化しないと、変更操作および削除操作のためにサーバーのパフォーマンスが低下します。
nsIndexType: pres
nsIndexType: eq
nsIndexType: sub
インデックスの確認および作成に関する詳細は、「標準インデックスの作成」を参照してください。

5.2. レプリケーションによる参照整合性の使用

レプリケーション環境で Referential Integrity Postoperation プラグインを使用する場合は、特定の制限があります。
  • 専用のコンシューマーサーバー (読み取り専用レプリカのみが含まれるサーバー) では有効に しないでください
  • 読み書きレプリカと読み取り専用レプリカの組み合わせが含まれるサーバーで有効に しないでください
  • 読み書きレプリカのみが含まれるサプライヤーサーバーで有効にできます。
  • マルチマスターレプリケーションでは、1 つのサプライヤーでプラグインを有効にします。
レプリケーション環境がこれらのすべての条件を満たす場合は、Referential Integrity Postoperation プラグインを有効にすることができます。
  1. 「参照整合性の有効化および無効化」 の説明に従って、Referential Integrity Postoperation プラグインを有効にします。
  2. 変更ログに整合性の更新を記録するようにプラグインを設定します。
  3. すべてのコンシューマーサーバーで、Referential Integrity Postoperation プラグインが無効になっていることを確認します。
    注記
    サプライヤーサーバーが Referential Integrity Postoperation 整合性プラグインの変更をコンシューマーサーバーに送信するため、コンシューマーサーバーで Referential Integrity Postoperation プラグインを実行する必要はありません。

5.3. 参照整合性の有効化および無効化

5.3.1. コマンドラインから参照整合性の有効化および無効化

Referential Integrity Postoperation プラグインを有効または無効にするには、プラグインの設定エントリーに nsslapd-pluginEnabled パラメーターを設定します。
たとえば、プラグインを有効にするには、以下を実行します。
  1. nsslapd-pluginEnabled パラメーターを on に設定します。
    # ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x
    
    dn: cn=,cn=plugins,cn=config
    changetype: modify
    replace: nsslapd-pluginEnabled
    nsslapd-pluginEnabled: on
  2. インスタンスを再起動します。
    # systemctl restart dirsrv@instance_name

5.3.2. コンソールでの参照整合性の有効化および無効化

Referential Integrity Postoperation プラグインを有効にするには、「Directory Server コンソールでプラグインの有効化」 の手順に従います。

5.4. 更新間隔の変更

デフォルトでは、サーバーは、delete または modrdn の操作直後に参照整合性の更新を実行します。操作の量によっては、パフォーマンスに影響する可能性があります。パフォーマンスへの影響を軽減するために、更新間の時間を増やすことができます。
間隔を秒単位で設定します。あるいは、以下の値を設定できます。
  • 0: 参照整合性の確認は即座に実行されます。
  • -1: 参照整合性の確認は実行されません。
重要
更新間隔を 0 に設定すると、Referential Integrity Postoperation プラグインの更新間隔を 0 に設定する場合に限り、マルチマスターレプリケーション環境のすべてのマスターでプラグインを有効にすることができます。ただし、1 つのマスターに正の値を設定する場合は、レプリケーションループとディレクトリーの不整合を防ぐために、他のマスターでプラグインを有効にしないでください。
マルチマスターレプリケーション環境でプラグインを有効にする場合、Red Hat は更新間隔を 0 に設定し、すべてのマスターでプラグインを有効にすることを推奨します。

5.4.1. コマンドラインを使用した更新間隔の変更

たとえば、コマンドラインを使用して更新間隔を即座更新に設定するには、次を実行します。
  1. referint-update-delay パラメーターで間隔を秒単位で設定します。
    # ldapmodify -D "cn=Directory Manager" -W -x
    dn: cn=referential integrity postoperation,cn=plugins,cn=config
    changetype: modify
    replace: referint-update-delay
    referint-update-delay: 0
  2. Directory Server インスタンスを再起動します。
    # systemctl restart dirsrv@instance_name
参照整合性 は 1 つのマスターでのみ有効にできます。この間隔を 0 に設定すると、Directory Server は上記の変更をすべてのコンシューマーに即座に複製します。間隔を 0 よりも大きい値に設定し、Referential Integrity が有効なマスターがオフラインである場合は、このマスターが再び起動する前に参照はクリーンアップされません。

5.4.2. コンソールを使用した更新間隔の変更

コンソールを使用して更新間隔を設定するには、以下を行います。
  1. Referential Integrity Postoperation プラグインの設定で Property Editor を開きます。詳細は、「コンソールを使用したプラグインの設定」 を参照してください。
  2. referint-update-delay パラメーターで間隔を秒単位で設定します。
  3. Directory Server インスタンスを再起動します。「コンソールを使用した Directory Server インスタンスの起動および停止」 を参照してください。

5.5. 属性一覧の変更

デフォルトでは、参照整合性プラグインは member 属性、uniquemember 属性、owner 属性、および seeAlso 属性を確認し、更新します。コマンドラインまたはコンソールを使用して、更新する属性を追加または削除できます。
注記
Referential Integrity プラグインのパラメーターリストに設定される属性には、全データベースで等価インデックスが必要です。そうでない場合、プラグインは削除済みまたは変更された DN に一致するためにデータベースのすべてのエントリーをスキャンします。これにより、パフォーマンスに大きく影響する可能性があります。インデックスの確認および作成に関する詳細は、「標準インデックスの作成」を参照してください。

5.5.1. コンソールを使用した属性一覧の変更

  1. Referential Integrity Postoperation プラグインの設定で Property Editor を開きます。詳細は、「コンソールを使用したプラグインの設定」 を参照してください。
  2. referint-membership-attr 属性の属性を更新します。
    値の追加 およびの削除 ボタンを使用して、値を追加 したり、既存の値を削除したりできます。
  3. Directory Server インスタンスを再起動します。「コンソールを使用した Directory Server インスタンスの起動および停止」 を参照してください。

5.5.2. コマンドラインでの属性一覧の設定

  1. 属性リストを更新します。
    • プラグインが確認および更新される必要があるその他の属性を追加するには、以下を実行します。
      # ldapmodify -D "cn=Directory Manager" -W -x
      
      dn: cn=referential integrity postoperation,cn=plugins,cn=config
      add: referint-membership-attr
      referint-membership-attr: attribute_name
    • プラグインが確認および更新されなくなった属性を削除するには、以下を実行します。
      # ldapmodify -D "cn=Directory Manager" -W -x
      
      dn: cn=referential integrity postoperation,cn=plugins,cn=config
      delete: referint-membership-attr
      referint-membership-attr: attribute_name
  2. Directory Server インスタンスを再起動します。
    # systemctl restart dirsrv@instance_name

5.6. 参照整合性のためのスコープの設定

エントリーを削除すると、エントリーへの参照は削除または変更されます。この更新がすべてのエントリーおよびすべてのグループに適用されると、パフォーマンスに影響が及ぶ可能性があり、選択されたサブツリーに参照整合性を制限できなくなる可能性があります。この問題の スコープ アドレスを定義します。
たとえば、接尾辞 dc=example,dc=comou=active users,dc=example,dc=comou=deleted users,dc=example,dc=com の 2 つのサブツリーが含まれる場合があります。deleted users のエントリーは、参照整合性の確保のために処理しないでください。
Referential Integrity Postoperation プラグイン設定でスコープを定義するために、以下の 3 つの属性を使用できます。
nsslapd-pluginEntryScope 属性
この多値属性は、削除または名前変更のエントリーの範囲を制御します。これは、Referential Integrity Postoperation プラグインがユーザーエントリーの削除操作または名前変更操作を検索するサブツリーを定義します。定義されたサブツリーに存在しないユーザーを削除または名前変更した場合、プラグインは操作を無視します。この属性を使用すると、プラグインが操作を適用するデータベースのブランチを指定できます。
nsslapd-pluginEntryScope: dn
nsslapd-pluginExcludeEntryScope 属性
この属性は、削除または名前変更のエントリーの範囲も制御します。これは、Referential Integrity Postoperation プラグインがユーザーの削除や名前変更の操作を無視するサブツリーを定義します。
nsslapd-pluginExcludeEntryScope: dn
nsslapd-pluginContainerScope 属性
この属性は、参照を更新するグループの範囲を制御します。ユーザーの削除後、Referential Integrity Postoperation プラグインはユーザーが属するグループを検索し、それに応じて更新します。この属性は、プラグインがユーザーが属するグループを検索するブランチを指定します。Referential Integrity Postoperation プラグインは、指定のコンテナーブランチにあるグループのみを更新し、その他のグループは更新されないままにします。
nsslapd-pluginContainerScope: dn

第6章 Directory Database への入力

データベースには、Red Hat Directory Server が管理するディレクトリーデータが含まれます。

6.1. データのインポート

Directory Server には、データをインポートする(Directory Server Console またはインポートツールを使用)、またはレプリケーション用にデータベースを初期化することで、以下のいずれかの方法でデータベースにデータを作成できます。
表6.1「インポート方法の比較」では、インポートとデータベースの初期化の相違点を説明します。
表6.1 インポート方法の比較
動作 インポート データベースの初期化
データベースの上書き いいえ はい
LDAP 操作 追加、変更、削除 追加のみ
パフォーマンス より時間がかかる 速い
パーティション特長 すべてのパーティションで機能 ローカルパーティションのみ
サーバー障害への応答 ベストエフォート (障害が発生した時点までに行われたすべての変更が残る) アトミック (障害発生後にすべての変更が失われる)
LDIF ファイルの場所 コンソールへのローカル サーバーに対するコンソールまたはローカルへのローカル
設定情報 (cn=config) をインポートする Yes いいえ

6.1.1. インポート中の EntryUSN 初期値の設定

エントリーがサーバーからエクスポートされ、別のサーバーにインポートされた場合には、エントリーの更新シーケンス番号 (USN) が保持されません。「更新シーケンス番号でデータベースへの変更の追跡」で説明されているように、エントリー USN はローカルサーバーで発生する操作に割り当てられるため、これらの USN を別のサーバーにインポートすることは意味がありません。
ただし、データベースのインポート時やデータベースの初期化時にエントリーに USN 値を設定することが可能です (レプリカがレプリケーションに対して初期化される場合など)。これは、nsslapd-entryusn-import-initval 属性を設定して行います。これにより、インポートされたすべてのエントリーの USN が開始されます。
nsslapd-entryusn-import-initval には 2 つの値を指定することができます。
  • 整数。インポートされたすべてのエントリーに使用される明示的な開始番号です。
  • 次に、インポートされたすべてのエントリーは、インポート操作前にサーバー上の最も大きなエントリー USN 値を使用し、1 つずつ増分します。
nsslapd-entryusn-import-initval が設定されていない場合、すべてのエントリー USN はゼロで始まります。
たとえば、インポートまたは初期化操作の前にサーバーの最大値が 1000 で、nsslapd-entryusn-import-initval の値が next の場合、インポートされたすべてのエントリーには 1001 の USN が割り当てられます。
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -x "(cn=*)" entryusn

dn: dc=example,dc=com
entryusn: 1001
dn: ou=Accounting,dc=example,dc=com
entryusn: 1001
dn: ou=Product Development,dc=example,dc=com
entryusn: 1001
...
dn: uid=jsmith,ou=people,dc=example,dc=com
entryusn: 1001
...
エントリー USN の初期値を設定するには、データをインポートするサーバーまたは初期化を実行するマスターサーバーに nsslapd-entryusn-import-initval 属性を追加するだけです。
# ldapmodify -D "cn=Directory Manager" -W -x -D "cn=directory manager" -W -p 389 -h server.example.com -x

dn: cn=config
changetype: modify
add: nsslapd-entryusn-import-initval
nsslapd-entryusn-import-initval: next
注記
マルチマスターレプリケーションでは、nsslapd-entryusn-import-initval 属性はサーバー間で 複製されません。つまり、値は、レプリカの初期化に使用しているすべてのサプライヤーサーバーに対して設定する必要があります。
たとえば、Supplier1 に nsslapd-entryusn-import-initvalnext に設定され、レプリカの初期化に使用される場合は、インポートされたエントリーのエントリー USN は最も高い値に 1 が追加されます。Supplier2 に nsslapd-entryusn-import-initval が設定されておらず、レプリカの初期化に使用される場合は、Supplier1 および Supplier 2 にマルチマスターレプリカ合意がある場合でも、インポートされたエントリーのすべてのエントリー USN はゼロで始まります。

6.1.2. コンソールからのデータベースのインポート

Directory Server コンソールからインポート操作を実行すると、ldapmodify 操作はデータを追加し、エントリーの変更や削除を行います。この操作は、Directory Server が管理するすべてのデータベースと、Directory Server が設定したデータベースリンクを持つリモートデータベースで実行されます。
インポート操作は、Directory Server コンソールに対してローカルとなるサーバーインスタンスまたは別のホストマシン(リモートインポート操作)で実行できます。
インポートを実行するには、Directory Manager としてログインしている必要があります。
注記
インポート操作に使用される LDIF ファイルは、UTF-8 文字セットエンコーディングを使用する必要があります。インポート操作は、データをローカル文字セットエンコーディングから UTF-8 文字セットエンコーディングに変換しません。
警告
インポートされたすべての LDIF ファイルには、root 接尾辞も含まれている必要があります。
Directory Server コンソールからデータをインポートするには、以下を実行します。
  1. Tasks タブを選択します。画面の下部までスクロールし、Import Database を選択します。
    または、Configuration タブを開き、Console メニューから Import を選択します。
  2. Import Database ダイアログボックスで、LDIF ファイル フィールドでインポートする LDIF ファイルへの完全パスを入力するか、Browse をクリックしてインポートするファイルを選択します。
    コンソールがマシンのリモートで実行している場合、フィールド名は LDIF ファイルとして表示されます(コンソールを実行するマシン上)。ファイルを参照する場合、Directory Server ホストの現在のディレクトリーは参照されませんが、コンソールを実行しているマシンのファイルシステムも参照しません。
    リモートコンソールを使用してデータベースをインポートする場合 は、データベースへの相対パスを使用しないでください。リモートインポートでは、ファイルに相対パス が指定されている場合に Cannot write to file... というエラーで操作に失敗します。リモートインポート操作には常に絶対パスを使用します。
  3. オプション ボックスで、以下のオプションのいずれかまたは両方を選択します。
    • のみを追加します。LDIF ファイルには、デフォルトの追加手順に加えて、変更および削除手順を含めることができます。サーバーが add 以外の操作を無視するには、Add only チェックボックスを選択します。
    • Error に進みます。エラーが発生した場合でもインポートを続行するには、サーバーの Continue on error チェックボックスを選択します。たとえば、このオプションを使用して、新しいものに加えて、データベースにすでに存在するエントリーが含まれる LDIF ファイルをインポートします。サーバーノートでは、すべての新規エントリーの追加中に rejects ファイルの既存のエントリーがあります。
  4. File for Rejects フィールドに、サーバーがインポートできないすべてのエントリーを記録するファイルへの完全パスを入力するか、Browse をクリックして拒否が含まれるファイルを選択します。
    拒否は、データベースにインポートできないエントリーです。たとえば、サーバーは、データベースにすでに存在するエントリーや、親オブジェクトのないエントリーをインポートできません。コンソールは、サーバーによって送信されたエラーメッセージが rejects ファイルに書き込みます。
    このフィールドを空白のままにすると、サーバーは拒否されたエントリーを記録しません。
サーバーはインポートを実行し、インデックスも作成します。
注記
末尾のスペースは、リモートコンソールのインポート時に破棄されますが、ローカルコンソールまたは ldif2db インポート操作時に保持されます。

6.1.3. コンソールからのデータベースの初期化

データベース内の既存のデータは、データベースを初期化することで上書きできます。
Directory Manager (root DN)を除き、ルートエントリーが含まれる LDIF ファイルをデータベースにインポートできないため、データベースを初期化するために Directory Manager としてログインしている必要があります。Directory Manager のみが、dc =example,dc=com などのルートエントリーにアクセスできます。
警告
LDIF ファイルからデータベースを初期化する場合は、データを復元しない限り、o=NetscapeRoot 接尾辞を上書きしないように注意してください。それ以外の場合は、データベースの初期化により情報が削除され、Directory Server の再インストールが必要になる場合があります。
Directory Server コンソールを使用してデータベースを初期化するには、以下を実行します。
  1. Configuration タブを選択します。
  2. 左側のナビゲーションペインで Data tree を展開します。初期化するデータベースの接尾辞を展開し、データベース自体をクリックします。
  3. データベースを右クリックし、Initialize Database を選択します。
    または、Object メニューから Initialize Database を選択します。
  4. LDIF file フィールドにインポートする LDIF ファイルへの完全パスを入力するか、Browse をクリックします。
  5. コンソールが、インポートされているファイルのマシンから実行中の場合は、OK をクリックして、即座にインポートに進みます。Console がマシンリモートから LDIF ファイルを含むサーバーに実行している場合は、以下のオプションのいずれかを選択して OK をクリックします。
    • ローカルマシンからいる。LDIF ファイルがローカルマシンにあることを示します。
    • サーバーマシン から。LDIF ファイルがリモートサーバーにあることを示します。
    デフォルトの LDIF ディレクトリーは /var/lib/dirsrv/slapd-instance/ldif です。

6.1.4. コマンドラインからのインポート

コマンドラインでデータをインポートする方法は 4 つあります。
注記
インポート操作に使用される LDIF ファイルは、UTF-8 文字セットエンコーディングを使用する必要があります。インポート操作は、データをローカル文字セットエンコーディングから UTF-8 文字セットエンコーディングに変換しません。
警告
インポートされたすべての LDIF ファイルには、root 接尾辞も含まれている必要があります。
注記
暗号化したデータベースをインポートするには、スクリプトで -E オプションを使用します。詳細は、「暗号化したデータベースのエクスポートおよびインポート」 を参照してください。
6.1.4.1. ldif2db コマンドラインユーティリティーを使用したインポート
ldif2db スクリプトは、指定したデータベースのデータを上書きします。また、このスクリプトでは、インポートの開始時に Directory Server を停止する必要があります。
デフォルトでは、スクリプトは最初に保存してから、既存の o=NetscapeRoot 設定情報を、インポートするファイルの o=NetscapeRoot 設定情報とマージします。
警告
このスクリプトは、データベースのデータを上書きします。
LDIF をインポートするには、以下を行います。
  1. サーバーを停止します。
    # systemctl stop dirsrv@instance
  2. ldif2db コマンドラインスクリプトを実行します。
    # ldif2db -Z instance_name -n Database1 -i /var/lib/dirsrv/slapd-instance/ldif/demo.ldif -i /var/lib/dirsrv/slapd-instance/ldif/demo2.ldif
    警告
    -n オプションで指定したデータベースが LDIF ファイルに含まれる接尾辞と一致しない場合は、データベースに含まれるすべてのデータが削除され、インポートに失敗します。データベース名が間違っていることがないことを確認してください。
  3. サーバーを起動します。
    # systemctl start dirsrv@instance
6.1.4.2. ldif2db.pl Perl スクリプトを使用したインポート
ldif2db スクリプトと同様に、ldif2db.pl スクリプトは、指定されたデータベースのデータを上書きします。このスクリプトでは、インポートを実行するためにサーバーを実行する必要があります。
警告
このスクリプトは、データベースのデータを上書きします。
ldif2db.pl スクリプトを実行します。
# ldif2db.pl -Z instance_name -D "cn=Directory Manager" -w secret -i /var/lib/dirsrv/slapd-instance/ldif/demo.ldif -n Database1
注記
スクリプトを実行するには root 権限は必要ありませんが、Directory Manager として認証する必要があります。
6.1.4.3. ldif2ldap コマンドラインスクリプトを使用したインポート
ldif2ldap スクリプトは、LDAP を介して LDIF ファイルを追加します。このスクリプトを使用すると、データはすべてのディレクトリーデータベースに同時にインポートされます。ldif2ldap を使用してインポートするには、サーバーが稼働している必要があります。
ldif2ldap を使用して LDIF をインポートするには、以下を実行します。
[root@server ~]# ldif2ldap -Z instance_name -D "cn=Directory Manager" -w secretpwd /var/lib/dirsrv/slapd-instance/ldif/demo.ldif
ldif2ldap スクリプトでは、管理ユーザーの DN、管理ユーザーのパスワード、およびインポートする LDIF ファイルの絶対パスおよびファイル名が必要です。
6.1.4.4. cn=tasks エントリーを使用したインポート
Directory Server 設定の cn=tasks,cn=config エントリーは、サーバーがタスクの管理に使用する一時的なエントリーのコンテナーエントリーです。複数の共通ディレクトリータスクには、cn=tasks,cn=config の下にコンテナーエントリーがあります。一時タスクエントリーは、cn=import,cn=tasks,cn=config の下に作成し、インポート操作を開始できます。
ldif2db および ldif2db.pl スクリプトと同様に、cn=tasks のインポート操作はデータベースのすべての情報を上書きします。
このタスクエントリーには以下の 3 つの属性が必要です。
  • 一意の名前(cn)
  • インポートする LDIF ファイルのファイル名(nsFilename)
  • ファイルをインポートするデータベースの名前(nsInstance)
ldif2db および ldif2db.pl スクリプトで、- s オプションおよび -x オプションと同様に、インポートを包含または除外する接尾辞の DN を指定することもできます。
エントリーは、ldapmodify を使用したエントリーの追加」 で説明されているように ldapmodify を使用して追加されます。以下に例を示します。
# ldapmodify -a -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: cn=example import,cn=import,cn=tasks,cn=config
changetype: add
objectclass: extensibleObject
cn: example import
nsFilename: /home/files/example.ldif
nsInstance: userRoot
nsIncludeSuffix: ou=People,dc=example,dc=com
nsExcludeSuffix: ou=Groups,dc=example,dc=com
タスクが完了するとすぐに、エントリーはディレクトリー設定から削除されます。
この例で使用される属性と、このエントリーに設定できるその他の属性の詳細は、Red Hat Directory Server 設定、コマンド、およびファイルリファレンス の cn=import,cn=tasks,cn=config エントリーの説明を参照してください。

6.2. データのエクスポート

LDAP データ交換形式 (LDIF) ファイルは、Directory Server データベースからデータベースエントリーをエクスポートするために使用されます。LDIF は、RFC 2849, 『The LDAP Data Interchange Format(LDIF)- Technical Specification』 に記載されている標準形式です。
データのエクスポートは、以下の場合に役に立ちます。
  • データベースのデータのバックアップを作成します。
  • 別の Directory Server にデータをコピーします。
  • 別のアプリケーションへのデータのエクスポート。
  • ディレクトリートポロジーの変更後にデータベースを再作成します。
たとえば、ディレクトリーに 1 つのデータベースが含まれ、その内容が 2 つのデータベースに分割されている場合、2 つの新しいデータベースは、古いデータベースの内容をエクスポートし、これを 2 つの新しいデータベースにインポートして、これを 2 つの新しいデータベースにインポートします。図6.1「データベースコンテンツの 2 つのデータベースへの分割」
注記
エクスポート操作は、設定情報 (cn=config)、スキーマ情報 (cn=schema)、または監視情報 (cn=monitor) をエクスポートしません。

図6.1 データベースコンテンツの 2 つのデータベースへの分割

データベースコンテンツの 2 つのデータベースへの分割
Directory Server コンソールまたはコマンドラインユーティリティーを使用して、データをエクスポートすることができます。
警告
エクスポート操作中はサーバーを停止しないでください。

6.2.1. コンソールを使用したディレクトリーデータの LDIF へのエクスポート

最終的なエクスポートされたファイルの場所に応じて、一部またはすべてのディレクトリーデータを LDIF にエクスポートできます。LDIF ファイルがサーバーにある場合は、サーバーにローカルにあるデータベースに含まれるデータのみをエクスポートできます。LDIF ファイルがサーバーへのリモートである場合は、すべてのデータベースおよびデータベースリンクをエクスポートすることができます。
エクスポート操作を実行して、Directory Server Console または別のホストマシン(リモートエクスポート操作)にローカルとなるサーバーインスタンスからデータを取得できます。
サーバーの実行中に、Directory Server Console から LDIF にディレクトリーデータをエクスポートします。
  1. Tasks タブを選択します。画面の下部までスクロールし、Export Database(s) をクリックします。
    または、Configuration タブを選択して、Console メニューから Export をクリックします。
  2. LDIF File フィールドに LDIF ファイルの完全パスおよびファイル名を入力するか、Browse をクリックしてファイルを見つけます。
    コンソールがリモートサーバーで実行している場合、参照 は有効になりません。参照 ボタンが有効になっていないと、ファイルはデフォルトのディレクトリー /var/