dscreate コマンドを使用することで、 389 Directory Server のインスタンスを作成したりきれいに削除したりすることができます。

インスタンスの作成方法には 2 つの種類があります。 1 つめは設定ファイルを使用する方法、もう 1 つは自動生成されたテンプレート (雛型) ファイルを使用する方法です。なお、自動生成されたテンプレートファイルを使用して本番環境を作成する場合は、内容をよく読んで注意深く設定してください。

インスタンスを作成したら、あとは管理者用のアカウントを作成して、必要なユーザとグループを管理してサービスを動作させてください。

389 Directory Server は主に 3 つのコマンドで制御します:

下記の手順を実施することで、いくつかのサンプル用エントリを含むテスト目的や開発目的のインスタンスを構築することができます。

シンプルな設定ファイルを使用することで、新しい 389 Directory Server インスタンスを作成することができます。このファイルは INF と呼ばれる形式でなければなりませんが、ファイル名に関しては任意の名前を使用することができます。

既定のインスタンス名は localhost です。インスタンス名は作成後に変更することができませんので、混乱を避けるとともに、動作を良く理解できるよう、既定値ではなく独自の名前を指定しておくことをお勧めします。なお、下記の例では LDAP1 というインスタンス名で、サフィックス (LDAP での既定のドメイン名) が dc= LDAP1 ,dc= COM である場合の例を示しています。

例 5.2 には新しい 389 Directory Server インスタンスを作成する際の設定ファイルの例が示されています。この内容を修正せずそのまま利用してもかまいません。

インスタンス名を忘れてしまった場合は、 dsctl コマンドを実行して全てのインスタンスを表示させてください:

> sudo dsctl -l
slapd-LDAP1

dscreate コマンドを使用することで、新しい 389 Directory Server インスタンスを作成するためのテンプレート (雛型) を自動生成することができます。このコマンドでは、そのまま使用できる形でテンプレートが作成されますので、あとは必要に応じて様々な箇所を修正するだけでインスタンスを作成することができます。ただし、そのまま使用するのはテスト用途に留めるものとし、本番環境の場合は要件に合わせて適切に変更してください。なお、既定値はテンプレートファイル内のコメントとして書かれています (英語) 。設定を変更する場合は既定値のコメント文字を外して、必要な値を記入していってください。いずれのオプションに対しても詳しく説明が書かれています。

下記のコマンドを入力して実行すると、設定例を標準出力に出力することができます:

> sudo dscreate create-template

上記のコマンドを実行すると標準出力にテンプレートが出力されますが、このままでは使用できません。下記のようにして任意のファイル名を指定して、そのファイル内にテンプレートを出力してください:

> sudo dscreate create-template TEMPLATE.txt

下記は出力されたテンプレートの抜粋です:

# full_machine_name (str)
# Description: Sets the fully qualified hostname (FQDN) of this system. When
# installing this instance with GSSAPI authentication behind a load balancer, set
# this parameter to the FQDN of the load balancer and, additionally, set
# "strict_host_checking" to "false".
# Default value: ldapserver1.test.net
;full_machine_name = ldapserver1.test.net

# selinux (bool)
# Description: Enables SELinux detection and integration during the installation
# of this instance. If set to "True", dscreate auto-detects whether SELinux is
# enabled. Set this parameter only to "False" in a development environment.
# Default value: True
;selinux = True

システムの完全修飾ドメイン名 (テンプレート内の full_machine_name) など、既存の環境からの既定値を自動的に設定している様子がわかるかと思います。あとはこのファイルを何も変更せずそのまま利用して、新しいインスタンスを作成してみます:

> sudo dscreate from-file TEMPLATE.txt

これにより、 localhost という名前の新しいインスタンスが作成され、作成が完了すると自動的に開始されます:

> sudo dsctl localhost status
Instance "localhost" is running

既定値のままインスタンスを作成しても問題なく動作しますが、いくつかの設定値を変更しておくことで、より本番に近い環境を作成することができます。

インスタンス名は作成後に変更することができませんので、混乱を避けるとともに、動作を良く理解できるよう、既定値ではなく独自の名前を指定しておくことをお勧めします。インスタンス名を変更するには、 ;instance_name = localhost の行のコメント文字 (;) を外して、 localhost を任意の名前に変更してください。ここでは LDAP1 という名前を使用しています。

また、もう 1 つ変更すべき箇所として、ユーザとグループのサンプルを作成する機能があります。必要であれば ;sample_entries = no の箇所のコメント文字を外して、 no を yes にしてください。サンプル作成を指定すると、 demo_user (ユーザ) と demo_group (グループ) がそれぞれ作成されます。

このほか ;root_password の行のコメント文字 (;) を外して、設定したいパスワードを入力してもかまいません。

また、テンプレート内には既定のサフィックス (LDAP での既定のドメイン名) を指定していませんので、下記のようにして suffix 行で指定を行うことができます:

suffix = dc=LDAP1,dc=COM

作成したインスタンスをきれいに削除してやり直すには、 dsctl で下記のようなコマンドを入力して実行します:

> sudo dsctl LDAP1 remove --do-it

389 Directory Server のインスタンスを管理するには、 systemd を使用します。まずはサービスの状態を表示するには、下記のように入力して実行します (下記はインスタンス名が LDAP1 である場合の例です):

> systemctl status --no-pager --full dirsrv@LDAP1.service
   ● dirsrv@LDAP1.service - 389 Directory Server LDAP1.
     Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled)
     Active: active (running) since Thu 2021-03-11 08:55:28 PST; 2h 7min ago
    Process: 4451 ExecStartPre=/usr/lib/dirsrv/ds_systemd_ask_password_acl
       /etc/dirsrv/slapd-LDAP1/dse.ldif (code=exited, status=0/SUCCESS)
   Main PID: 4456 (ns-slapd)
     Status: "slapd started: Ready to process requests"
      Tasks: 26
     CGroup: /system.slice/system-dirsrv.slice/dirsrv@LDAP1.service
             └─4456 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-LDAP1 -i /run/dirsrv/slapd-LDAP1.pid

LDAP サーバの起動／停止／再起動を行うには、それぞれ下記のように入力して実行します:

> sudo systemctl start dirsrv@LDAP1.service
> sudo systemctl stop dirsrv@LDAP1.service
> sudo systemctl restart dirsrv@LDAP1.service

systemctl の使用方法について、詳しくは 第10章 「systemd デーモン」 をお読みください。

なお、 dsctl コマンドでもサービスの起動と停止を行うことができます:

> sudo dsctl LDAP1 status
> sudo dsctl LDAP1 stop
> sudo dsctl LDAP1 restart
> sudo dsctl LDAP1 start

389 Directory Server のローカル管理を行う目的で、 /root ディレクトリ内に .dsrc 設定ファイルを作成することができます。これにより、管理者 (root) や sudo 経由で管理権限を取得したユーザが、わざわざ 389 Directory Server の管理者情報を入力したりすることなく管理できるようになります。 例 5.3 には、サーバをローカル管理する場合の例が示されています。ここではインスタンス名が LDAP1 、ベース DN が com である場合を示しています。

/root/.dsrc ファイルを作成したら、あとは新しいユーザを作成していきます (詳しくは 5.6項 「LDAP でのユーザとグループの管理」 をお読みください) 。

# LDAP1 インスタンスを管理するための /root/.dsrc ファイルの例

[LDAP1] 1

uri = ldapi://%%2fvar%%2frun%%2fslapd-LDAP1.socket 2
basedn = dc=LDAP1,dc=COM
binddn = cn=Directory Manager

重要: sudoers.ldap の次世代新機能について

sudo 1.9.9 以前のバージョンでは、 sudoers.ldap のうち sudoUser , sudoRunAsUser , sudoRunAsGroup の各属性で否定表現が正しく動作しませんでした。たとえば下記のようになっていました:

 # joe 以外の全員にマッチさせるつもりが、
# 全員を対象外としてしまう例
sudoUser: !joe

# 同様に joe 以外の全員にマッチさせるつもりが、
# joe を含む全員を対象としてしまう例
sudoUser: ALL
sudoUser: !joe

sudo のバージョン 1.9.9 およびそれ以降では、 sudoUser における否定表現が動作するようになっています。詳しくは man 5 sudoers.ldap をお読みください。

LDAP のサーバ設定は /etc/dirsrv/slapd-インスタンス名 のディレクトリ内に存在しています。このディレクトリ内には証明書や鍵のほか、 dse.ldif ファイルが含まれています。これらは tar コマンドを利用して圧縮しながらバックアップすることができます:

> sudo tar caf \
config_slapd-インスタンス名-$(date +%Y-%m-%d_%H-%M-%S).tar.gz \
/etc/dirsrv/slapd-インスタンス名/

注記: tar で出力される無害なメッセージについて

なお、上記のような tar コマンドを実行すると、 tar: メンバ名から先頭の `/' を取り除きます のようなメッセージが表示されますが、無視してかまいません。

設定を復元したい場合は、上記で採取したバックアップを同じディレクトリ内に展開します:

dsctl コマンドを利用することで、オフラインバックアップを採取することができます。まずはサーバを停止します:

> sudo dsctl インスタンス名 stop
Instance "インスタンス名" has been stopped

下記の例のとおりに実行すると、 /var/lib/dirsrv/slapd-LDAP1/bak/インスタンス名-日付 のようなディレクトリ内にバックアップが作成されます。

> sudo dsctl インスタンス名 db2bak
db2bak successful

たとえばテスト用に作成した ldap1 インスタンスの場合、下記のようなディレクトリになります:

/var/lib/dirsrv/slapd-ldap1/bak/ldap1-2021_10_25_13_03_17

バックアップから復元したい場合は、下記のようにしてバックアップを含むディレクトリを指定します:

> sudo dsctl インスタンス名 bak2db \
/var/lib/dirsrv/slapd-インスタンス名/bak/インスタンス名-日付/
bak2db successful

あとはサーバを起動します:

> sudo dsctl インスタンス名 start
Instance "インスタンス名" has been started

なお、 LDIF 形式でのバックアップを採取することもできます:

> sudo dsctl インスタンス名 db2ldif --replication userRoot
ldiffile: /var/lib/dirsrv/slapd-インスタンス名/ldif/インスタンス名-userRoot-日付.ldif
db2ldif successful

LDIF 形式のバックアップから復元したい場合も同様に、ファイル名を指定して復元し、サーバを起動するだけです:

> sudo dsctl ldif2db userRoot \
/var/lib/dirsrv/slapd-インスタンス名/ldif/インスタンス名-userRoot-日付.ldif
> sudo dsctl インスタンス名 start

dsconf コマンドを利用することで、 LDAP データベースのオンラインバックアップを採取することができます:

> sudo dsconf インスタンス名 backup create
The backup create task has finished successfully

上記を実行すると、 /var/lib/dirsrv/slapd-インスタンス名/bak/インスタンス名-日付 のようなディレクトリ内にバックアップが作成されます。

復元は下記のようにして行います:

> sudo dsconf インスタンス名 backup restore \
/var/lib/dirsrv/slapd-インスタンス名/bak/インスタンス名-日付

下記では、既存のユーザとグループを一覧表示する例を示しています。なお、インスタンス名は LDAP1 であるものとします。実際に実行する際には、お使いのインスタンス名に置き換えて実行してください。

> sudo dsidm LDAP1 user list
> sudo dsidm LDAP1 group list

特定のユーザに対する全ての情報を表示させるには、下記のように入力して実行します:

> sudo dsidm LDAP1 user get ユーザ名

特定のグループに対する全ての情報を表示させるには、下記のように入力して実行します:

> sudo dsidm LDAP1 group get グループ名

グループのメンバー一覧を表示するには、下記のように入力して実行します:

> sudo dsidm LDAP1 group members グループ名

下記の例では 1 人のユーザ wilber を作成しています。このとき、サーバインスタンスは LDAP1 、サフィックスは dc=LDAP1,dc=COM であるものとします。

ユーザを作成したあとは、グループを作成してユーザを割り当てます。下記の手順では server_admins という名前のグループを作成し、そのグループに wilber ユーザを所属させます。このとき、インスタンス名は LDAP1 、サフィックスは dc=LDAP1,dc=COM であるものとします。

ユーザの削除やグループからのユーザ脱退、そしてグループそのものの削除についても、 dsidm コマンドで行います。下記の例では、 server_admins グループから wilber ユーザを脱退させています:

> sudo dsidm LDAP1 group remove_member SERVER_ADMINS \
uid=wilber,ou=people,dc=LDAP1,dc=COM

次にユーザを削除します:

> sudo dsidm LDAP1 user delete \
uid=wilber,ou=people,dc=LDAP1,dc=COM

さらにグループを削除します:

> sudo dsidm LDAP1 group delete SERVER_ADMINS

下記のプラグインは 389 Directory Server において公式にはサポートされておりません:

nsslapd-rootpwstoragescheme や passwordStorageScheme の設定値として、もしくはアカウントポリシーオブジェクト内での passwordStorageScheme の値としては、下記の値はサポート対象外となっております:

注記

なお、これらの値を含むデータベースからのインポートに関しては、 nsslapd-enable-upgrade-hash が on (デフォルト値: on) になっていればサポート対象内となります。

OpenLDAP と 389 Directory Server との間にはそれなりの差異が存在することから、移行を行うにあたっても事前のテストと調整を繰り返し実施する必要があります。そのため、手早く移行テストを実施して、必要な追加手順を素早く洗い出すことが肝心です。

あらかじめ用意しておくべきもの:

slapd の設定が動的な ldif 形式ではない場合、まずは slaptest を利用して動的なコピーを作成します。 /root/slapd.d/ のような slapd.d ディレクトリを作成して、下記のコマンドを実行します:

> sudo slaptest -f /etc/openldap/slapd.conf -F /root/slapd.d

上記を実行すると、下記のようにいくつかのファイルが作成されるはずです:

> sudo ls /root/slapd.d/*

/root/slapd.d/cn=config.ldif

/root/slapd.d/cn=config:
cn=module{0}.ldif  cn=schema.ldif                 olcDatabase={0}config.ldif
cn=schema          olcDatabase={-1}frontend.ldif  olcDatabase={1}mdb.ldif

サフィックスごとに 1 つの ldif ファイルが作成されます。以降の例ではサフィックスが dc= LDAP1 ,dc= COM であるものとします。また、 /etc/openldap/slapd.conf 形式を使用している場合は、下記のようなコマンドを実行することで、 ldif のバックアップファイルを作成することができます:

> sudo slapcat -f /etc/openldap/slapd.conf -b dc=LDAP1,dc=COM \
-l /root/LDAP1-COM.ldif

あとは openldap_to_ds ユーティリティを利用して設定とファイルを分析させ、移行プランを表示させます (この時点では何も変更は行われません):

> sudo openldap_to_ds LDAP1\
/root/slapd.d /root/LDAP1-COM.ldif.ldif

前述のとおり上記では何も変更されませんが、下記のような出力が現れるはずです:

Examining OpenLDAP Configuration ...
Completed OpenLDAP Configuration Parsing.
Examining Ldifs ...
Completed Ldif Metadata Parsing.
The following migration steps will be performed:
 * Schema Skip Unsupported Attribute -> otherMailbox (0.9.2342.19200300.100.1.22)
 * Schema Skip Unsupported Attribute -> dSAQuality (0.9.2342.19200300.100.1.49)
 * Schema Skip Unsupported Attribute -> singleLevelQuality (0.9.2342.19200300.100.1.50)
 * Schema Skip Unsupported Attribute -> subtreeMinimumQuality (0.9.2342.19200300.100.1.51)
 * Schema Skip Unsupported Attribute -> subtreeMaximumQuality (0.9.2342.19200300.100.1.52)
 * Schema Create Attribute -> suseDefaultBase (SUSE.YaST.ModuleConfig.Attr:2)
 * Schema Create Attribute -> suseNextUniqueId (SUSE.YaST.ModuleConfig.Attr:3)
[...]
 * Schema Create ObjectClass -> suseDhcpConfiguration (SUSE.YaST.ModuleConfig.OC:10)
 * Schema Create ObjectClass -> suseMailConfiguration (SUSE.YaST.ModuleConfig.OC:11)
 * Database Reindex -> dc=example,dc=com
 * Database Import Ldif -> dc=example,dc=com from example.ldif -
excluding entry attributes = [{'structuralobjectclass', 'entrycsn'}]
No actions taken. To apply migration plan, use '--confirm'

あとは下記のように実行することで、実際の移行を行うことができます。変更しない場合とは出力が異なることに注意してください:

  > sudo openldap_to_ds LDAP1 /root/slapd.d /root/LDAP1-COM.ldif --confirm
Starting Migration ... This may take some time ...
migration: 1 / 40 complete ...
migration: 2 / 40 complete ...
migration: 3 / 40 complete ...
[...]
Index task index_all_05252021_120216 completed successfully
post: 39 / 40 complete ...
post: 40 / 40 complete ...
🎉 Migration complete!
----------------------
You should now review your instance configuration and data:
 * [ ] - Create/Migrate Database Access Controls (ACI)
 * [ ] - Enable and Verify TLS (LDAPS) Operation
 * [ ] - Schedule Automatic Backups
 * [ ] - Verify Accounts Can Bind Correctly
 * [ ] - Review Schema Inconistent ObjectClass -> pilotOrganization (0.9.2342.19200300.100.4.20)
 * [ ] - Review Database Imported Content is Correct -> dc=ldap1,dc=com

移行が完了すると openldap_to_ds は、実施しておかなければならない移行後のチェック作業の一覧を表示します。この作業はいずれも移行を最適に行うために必要な手順ですので、本番環境でも同じようにしておくことをお勧めします。あとはテストクライアントとアプリケーションを、移行後の 389 Directory Server インスタンスに向けてテストを行ってください。

重要: ロールバックプランの策定

移行時、もしくは移行後に何らかの問題に直面することを想定して、ロールバックプラン (手戻りのための手順) と移行の成功判断基準を策定しておくことが重要です。具体的には、動作させなければならないクライアントやアプリケーションは何か、後から移行しても問題のないクライアントやアプリケーションは何か、それらでテストしておくべきことは何か、どのようにして手戻りの被害を最小限にするのか、巻き込むべきチームはどこなのかを事前に決めておく必要があります。

用途や範囲などが環境によって様々に異なることから、画一的な移行プラン／手戻りプランを策定することは難しいモノです。まずは移行処理をおおまかにテストしてみて、そこから少しずつ問題点を洗い出していくのがよいでしょう。また、下記のような一般的な手法も役に立つはずです:

OpenLDAP 環境の場合、パススルー型のユーザ認証を行うのに saslauthd を使用することがあります。この場合、認証処理では下記のようなコンポーネントが関わってきます:

 ┌─────────────────┐
 │                 │
 │LDAP クライアント│
 │                 │
 └─────────────────┘
          │
      バインド
          │
          ▼
 ┌─────────────────┐
 │    OpenLDAP     │
 │     サーバ      │
 │                 │
 └─────────────────┘
          │
          │
          ▼
 ┌─────────────────┐
 │                 │
 │    saslauthd    │
 │                 │
 └─────────────────┘
          │
          │
          ▼
 ┌─────────────────┐
 │                 │
 │     外部認証    │
 │                 │
 └─────────────────┘

設定が正しいことを確認したり、そこから先のトラブルシューティングを実施したりする場合は、下記のような情報が必要となります:

OpenLDAP でのパススルー認証に関する詳細については、公式文書である OpenLDAP Admin Guide (英語) をお読みください。

  ┌─────────────────┐
  │                 │
  │LDAP クライアント│
  │                 │
  └─────────────────┘
           │
       バインド
           │
           ▼
  ┌─────────────────┐
  │     389-DS      │
  │     サーバ      │
  │                 │
  └─────────────────┘
           │
           ▼
  ┌─────────────────┐
  │                 │
  │  pam saslauthd  │
  │                 │
  └─────────────────┘
           │
           ▼
  ┌─────────────────┐
  │                 │
  │    saslauthd    │
  │                 │
  └─────────────────┘
           │
           │
           ▼
  ┌─────────────────┐
  │                 │
  │     外部認証    │
  │                 │
  └─────────────────┘

OpenLDAP は 「様々な部品から構成されるソフトウエアパッケージ」 であり、様々なカスタマイズを実施できることから、 「画一的な手順」 で移行ができるものではありません。まずは OpenLDAP の環境と設定、そして使用範囲をよく調査してください。調査の対象としては、下記のようなものがあります (下記だけであるとも限りません):

最終的に 389 Directory Server をどのように配置するのかについても、よく計画しておく必要があります。これはオーバーレイをプラグインで置き換えること以外の、サーバの配置やインストールに関する内容です。現在の環境をよく調査し、 389 Directory Server の配置計画を立てたら、あとは移行プランの策定になります。 OpenLDAP の環境と並行して 389 Directory Server の環境を動作させて、お互いに切り替えることができるようにしても良いでしょう。

OpenLDAP から 389 Directory Server への移行は一方通行です。相互運用の意味でもこれらの間には十分な差異がありますし、逆方向 (389 Directory Server から OpenLDAP へ) の移行は提供されていませんので、よく注意しておく必要があります。下記には、様々な類似性と差異の一覧を示しています。

389 DS は他のデータベースとは異なるレプリケーション管理を行います。レプリケーションは非同期でありながらも、結果整合性を持つ仕組みになっています。つまり、下記のような動作になります:

一般的に LDAP は、 「書き込みの少ない」 データベースであるため、これらの特徴を考慮しても、サーバが一貫性のない状態にはならず、常に既知の安定状態に居続けることができます。また、この安定状態からの変更は少しずつしか行われないため、日々の運用ではこのような欠点に気付くようなことはありません。

レプリケーションの構成 (トポロジ) を設計するにあたっては、下記のような要素を決めておく必要があります。

これらの要素はいずれも構成そのものに影響します (詳しい構成例については 5.11.3項 「レプリケーションの設計例」 をお読みください) 。

下記の章では、 2 ノードから 6 ノードまでの 389 Directory Server ノードを使用する、いくつかのレプリケーション構成例を示しています。なお、レプリケーションを構成する際の最大サプライヤ数は 20 ノードまでです。実際の運用経験からすると、レプリケーション効率を高めるための最適なノード数は最大でも 8 ノードまでと考えられています。

5.11.3.1 2 つのレプリカ #Edit source

例 5.4: 2 つのサプライヤレプリカ #

┌────┐       ┌────┐
│ S1 │◀─────▶│ S2 │
└────┘       └────┘

例5.4「2 つのサプライヤレプリカ」 には S1 と S2 という 2 つのレプリカが示されています。これらは双方向レプリケーションとして構成する場合の例で、これらのノードはいずれもサプライヤとコンシューマの両方を兼ね備えた存在となります。 S1 と S2 は別々のデータセンター内であっても、同じデータセンター内であってもかまいません。 LDAP URI や負荷分散装置、 DNS SRV レコードのいずれかでクライアント側からのアクセスを分散させることができます。また、これは高可用性を提供する際の最もシンプルな構成でもあります。ただし、一方のサーバで障害が発生してオフラインになった場合、他方のサーバでは全てのクライアントからの処理を受け付ける必要があることに注意してください。また、 2 ノードのレプリケーションでは一方のノードがオフラインになった場合、残った 1 つのノードのみで全ての処理を行わなければならないことから、水平分散としては不適切です。

注記: 既定の構成

2 ノードの構成は最も簡単に管理できることから、既定の構成と考えられます。この構成を初期構成として、必要に応じて構成を広げていってもかまいません。

┌────┐       ┌────┐
│ S1 │◀─────▶│ S2 │
└────┘       └────┘
   ▲            ▲
   │            │
   ▼            ▼
┌────┐       ┌────┐
│ S3 │◀─────▶│ S4 │
└────┘       └────┘

                  ┌────┐       ┌────┐
                  │ S1 │◀─────▶│ S2 │
                  └────┘       └────┘
                     ▲            ▲
                     │            │
   ┌────────────┬────┴────────────┴─────┬────────────┐
   │            │                       │            │
   ▼            ▼                       ▼            ▼
┌────┐       ┌────┐                  ┌────┐       ┌────┐
│ S3 │◀─────▶│ S4 │                  │ S5 │◀─────▶│ S6 │
└────┘       └────┘                  └────┘       └────┘

             ┌────┐       ┌────┐
             │ S1 │◀─────▶│ S2 │
             └────┘       └────┘
                │            │
                │            │
   ┌────────────┼────────────┼────────────┐
   │            │            │            │
   ▼            ▼            ▼            ▼
┌────┐       ┌────┐       ┌────┐       ┌────┐
│ S3 │       │ S4 │       │ S5 │       │ S6 │
└────┘       └────┘       └────┘       └────┘

ここまでに説明してきた 389 DS の構成例やこの後の説明では、様々な用語を使用しています。下記ではそれら用語に対する説明を示しています。

最小構成例として、まずは 2 ノードの双方向レプリケーションと 1 ノードの読み込み専用サーバを構成してみます。下記の例では、読み書き可能なレプリカのサーバ名は RW1, RW2 とし、読み込み専用のレプリカのサーバ名は RO1 とします (もちろん必要に応じて自由な名前を設定してかまいません) 。

この構成内にあるサーバには、全て同じサフィックスを設定する必要があります。また、初期状態では RW1 にのみデータが存在するものとします。

5.11.5.1 2 ノードレプリケーションの設定 #Edit source

下記のコマンドは 2 ノード構成 ( 例5.4「2 つのサプライヤレプリカ」 ) の場合のコマンド例で、ホスト名を RW1, RW2 にしています (実際には独自の名前でかまいません) 。

警告: 強力なレプリケーションマネージャパスワードの作成について

レプリケーションマネージャのアカウントはディレクトリマネージャのアカウントと同等の権限を持つことから、セキュリティを確保するために強力なパスワードを設定しておくことを強くお勧めします。

各サーバで異なるレプリケーションマネージャのパスワードを設定する場合は、それぞれのサーバが使用するアカウントをよく覚えておいてください。たとえば RW1 側のレプリケーション同意を設定する場合、パスワードとして設定すべきなのは RW2 側のレプリケーションマネージャのパスワードとなります。

まずは RW1 側を設定します:

> sudo dsconf インスタンス名 replication create-manager
> sudo dsconf インスタンス名 replication enable \
--suffix dc=example,dc=com \
--role supplier --replica-id 1 --bind-dn "cn=replication manager,cn=config"

RW2 側の設定は下記のようになります:

> sudo dsconf インスタンス名 replication create-manager
> sudo dsconf インスタンス名 replication enable \
--suffix dc=example,dc=com \
--role supplier --replica-id 2 --bind-dn "cn=replication manager,cn=config"

上記のコマンドを実行することで、 RW1, RW2 の両方にレプリケーション用のデータを設定することができます。なお、 RW1 と RW2 では replica-id の値が異なっていることに注意してください。また、このコマンドを実行すると、レプリケーションマネージャのアカウントを作成することになります。このアカウントは、 2 つのノードが互いに認証する際に使用するアカウントとなります。

これで RW1 と RW2 の間でレプリケーションを行う準備ができました。あとは RW1 から RW2 に対して、データを発信するための最初の合意を作成します。

> sudo dsconf インスタンス名 repl-agmt create \
--suffix dc=example,dc=com \
--host=RW2 --port=636 --conn-protocol LDAPS --bind-dn "cn=replication manager,cn=config" \
--bind-passwd パスワード --bind-method SIMPLE RW1_to_RW2

上記のコマンドだけではデータベースの同期が始まりません。同期を始めるには、初期化または再初期化と呼ばれる完全同期が必要となります。初期化または再初期化を行うと、 RW2 側の全てのデータがリセットされ、 RW1 と全く同じデータになります。これを行うには、下記のように入力して実行します:

> sudo dsconf インスタンス名 repl-agmt init \
--suffix dc=example,dc=com RW1_to_RW2

あとは RW1 側で下記のようなコマンドを入力して実行し、状況を確認します:

> sudo dsconf インスタンス名 repl-agmt init-status \
--suffix dc=example,dc=com RW1_to_RW2

同期が完了すると、 Agreement successfully initialized というメッセージが表示されるはずです。それ以外のエラーメッセージが表示された場合は、エラーログを調べてみてください。エラーが表示されなければ、 RW1 と RW2 は全く同じデータになっているはずです。

あとはデータを双方向に複製するため、 RW2 から RW1 に対するレプリケーション合意も設定します:

> sudo dsconf インスタンス名 repl-agmt create \
--suffix dc=example,dc=com \
--host=RW1 --port=636 --conn-protocol LDAPS \
--bind-dn "cn=replication manager,cn=config" --bind-passwd パスワード \
--bind-method SIMPLE RW2_to_RW1

これで RW1 と RW2 の双方向レプリケーションが完成し、一方での変更が他方にも反映されるようになっています。いずれかのサーバで下記のようなコマンドを入力して実行し、状態を確認してください:

> sudo dsconf インスタンス名 repl-agmt status \
--suffix dc=example,dc=com \
--bind-dn "cn=replication manager,cn=config" \
--bind-passwd パスワード RW2_to_RW1

5.11.5.2 読み込み専用ノードの設定 #Edit source

読み込み専用ノードを作成するには、まずレプリケーションマネージャのアカウントとメタデータを作成するところから始めます。ここでのサーバ名は RO3 とします:

警告: 強力なレプリケーションマネージャパスワードの作成について

レプリケーションマネージャのアカウントはディレクトリマネージャのアカウントと同等の権限を持つことから、セキュリティを確保するために強力なパスワードを設定しておくことを強くお勧めします。

各サーバで異なるレプリケーションマネージャのパスワードを設定する場合は、それぞれのサーバが使用するアカウントをよく覚えておいてください。たとえば RW1 側のレプリケーション同意を設定する場合、パスワードとして設定すべきなのは RW2 側のレプリケーションマネージャのパスワードとなります。

> sudo dsconf インスタンス名 replication create-manager
> sudo  dsconf インスタンス名 \
replication enable --suffix dc=EXAMPLE,dc=COM \
--role consumer --bind-dn "cn=replication manager,cn=config"

なお、読み込み専用のレプリカに対しては、レプリカ ID の指定は不要であるほか、役割の指定を consumer にします。これにより、特殊な読み込み専用のレプリカ ID が割り当てられます。読み込み専用のレプリカを作成したら、あとは RW1, RW2 のそれぞれに対してレプリケーション同意を追加します。下記は RW1 側での実行例です:

> sudo dsconf インスタンス名 \
repl-agmt create --suffix dc=EXAMPLE,dc=COM \
--host=RO3 --port=636 --conn-protocol LDAPS \
--bind-dn "cn=replication manager,cn=config" --bind-passwd パスワード
--bind-method SIMPLE RW1_to_RO3

下記の例は、 RW2 と RO3 との間でのレプリケーション同意を RW2 側で設定する場合の例です:

> sudo dsconf インスタンス名 repl-agmt create \
--suffix dc=EXAMPLE,dc=COM \
--host=RO3 --port=636 --conn-protocol LDAPS \
--bind-dn "cn=replication manager,cn=config" --bind-passwd パスワード \
--bind-method SIMPLE RW2_to_RO3

これらの作業が完了したら、あとは RW1, RW2 から RO3 へデータベースの初期化を行います。下記の例では、 RW2 から RO3 に初期化を行っています:

> sudo dsconf インスタンス名 repl-agmt init
--suffix dc=EXAMPLE,dc=COM RW2_to_RO3

dsconf コマンドには監視オプションが用意されています。このコマンドを実行することで、レプリカ内で直接状態を確認することができるほか、他のホストからでも実行することができます。下記の例は RW1 内での実行例で、 2 つのレプリカに対する状態の確認と、自分自身の確認をそれぞれ行っています:

> sudo dsconf -D "cn=Directory Manager" ldap://RW2 replication monitor
> sudo dsconf -D "cn=Directory Manager" ldap://RO3 replication monitor
> sudo dsconf -D "cn=Directory Manager" ldap://RW1 replication monitor

また、 dsctl コマンドには healthcheck というオプションもあります。下記ではローカルの 389 DS インスタンスに対して、レプリケーションの状態確認を行っています:

> sudo dsctl インスタンス名 healthcheck --check replication

-v オプションを追加すると、 healthcheck で行っていることの詳細を表示することができます:

> sudo dsctl -v インスタンス名 healthcheck --check replication

オプション無しで dsctl インスタンス名 healthcheck を実行すると、一般的な状態確認のみを行います。

下記のようなコマンドを実行することで、 healthcheck を実行した際に行われる処理の内容を調べることもできます:

> sudo dsctl インスタンス名 healthcheck --list-checks
config:hr_timestamp
config:passwordscheme
backends:userroot:cl_trimming
backends:userroot:mappingtree
backends:userroot:search
backends:userroot:virt_attrs
encryption:check_tls_version
fschecks:file_perms
[...]

個別のチェックのみを実行したい場合は、下記のように入力して実行します:

> sudo dsctl インスタンス名 healthcheck \
--check monitor-disk-space:disk_space tls:certificate_expiration

レプリケーションを有効化した場合は、 389 Directory Server のバックアップについてもいくつかの調整を行う必要があります (一般的なバックアップ方法については 5.5項 「389 Directory Server でのバックアップと復元」 をお読みください) 。具体的には、バックアップ時に db2ldif コマンドを実行している場合、 --replication フラグを指定して、レプリケーションのメタデータを最初にバックアップするようにしてください。また、バックアップは構成内の全てのサーバに対して行うものとし、バックアップからの復元に際しては、構成内の 1 ノードでのみ実施して、残りのノードは再初期化を行ってデータを複製してください。

メンテナンスやその他の運用上の理由で、レプリケーションを一時的に停止することができます。なお、一時停止は変更履歴の保持日数で示された期間 (詳しくは 5.11.9項 「Changelog max-age」 をお読みください) まで続けることができます。

レプリケーションを一時停止するには、 repl-agmt コマンドを使用します。 RW2 で一時停止する場合は、下記のように入力して実行します:

> sudo dsconf インスタンス名 repl-agmt disable \
--suffix dc=EXAMPLE,dc=COM RW2_to_RW1

再開する場合は、下記のように入力して実行します:

> sudo dsconf インスタンス名 repl-agmt enable \
--suffix dc=EXAMPLE,dc=COM RW2_to_RW1

レプリカを何らかの理由でしばらくオフラインにする場合には、最大で changelog max-age で指定した時間までが許容されます。 max-age オプションは過去の変更履歴を持つ長さを時間で指定するための値で、ここで指定したよりも過去の履歴は自動的に削除されます。

しばらくオフラインになっていたレプリカが復帰すると、通常のレプリケーションと同様に、他のレプリカとの間で同期が行われます。 max-age で指定したよりも長い時間オフラインであった場合は、一貫性を失うことから、他のノードからの変更を拒否したり、他のノードへの変更の送信を拒否したりするようになります。下記の例では、 max-age を 7 日間に設定しています:

> sudo dsconf インスタンス名 \
replication set-changelog --max-age 7d \
--suffix dc=EXAMPLE,dc=COM

レプリカを削除するには、まず他のノードに対して変更点の送信を停止する必要があります。あとは削除するノードで受け付けていたレプリケーション合意を削除します。下記の例では、 RW2 を削除する場合の例を示しています。まずは RW1 での発信側レプリケーション合意を削除します:

> sudo dsconf インスタンス名 repl-agmt delete \
--suffix dc=EXAMPLE,dc=COM RW1_to_RW2

あとは削除対象のレプリカ (この例では RW2) で、全ての送信側レプリケーション合意を削除します:

> sudo dsconf インスタンス名 repl-agmt delete \
--suffix dc=EXAMPLE,dc=COM RW2_to_RW1
> sudo dsconf インスタンス名 repl-agmt delete \
--suffix dc=EXAMPLE,dc=COM RW2_to_RO3

あとは RW2 インスタンスを停止します:

> sudo systemctl stop dirsrv@INSTANCE_NAME.service

最後に構成内に書かれているレプリカ ID を削除するため、 cleanallruv コマンドを実行します。下記は RW1 で実行した場合の例です:

> sudo dsconf インスタンス名 repl-tasks cleanallruv \
--suffix dc=EXAMPLE,dc=COM --replica-id 2
> sudo dsconf インスタンス名 repl-tasks list-cleanruv-tasks

389 Directory Server でレプリケーションを使用する場合、公式には下記のサポート制限があります:

同期の形態にもよりますが、最小構成では 1 台の 389 Directory Server と 1 台の Active Directory サーバで同期を構築することができます。ただし、 Active Directory は完全なドメインコントローラでなければならず、読み込み専用のドメインコントローラ (RODC) であってはなりません。なお、 389 DS はドメイン内の単一のフォレストの内容のみを複製するため、グローバルカタログは不要です。

まずはデータの流通方向を選択します。 AD から 389 DS だけでなく、 389 DS から AD や、その両方を指定することもできます。

注記: パスワード同期について

389 DS と Active Directory との間では、パスワードの同期を行うことができません。将来的には Active Directory から 389 DS に対してパスワードを同期できるようになる予定です。

同期の構成を図に表すと、下記のようになります。 389 Directory Server 内や Active Directory 内の構成が異なる場合もありますが、 389 DS と Active Directory は 1 つの接続のみで賄われる点が最も重要です。また、これによって発生しうる、 389 DS と AD の災害対策やバックアップ計画の策定も非常に重要です。これらを計画しておくことで、単一のレプリケーション接続であっても、正しく復元できるように構成できるからです。

┌────────┐     ┌────────┐         ┌────────┐     ┌────────┐
│        │     │        │         │        │     │        │
│ 389-ds │◀───▶│ 389-ds │◀ ─ ─ ─ ▶│   AD   │◀───▶│   AD   │
│        │     │        │         │        │     │        │
└────────┘     └────────┘         └────────┘     └────────┘
    ▲               ▲                  ▲             ▲
    │               │                  │             │
    ▼               ▼                  ▼             ▼
┌────────┐     ┌────────┐         ┌────────┐     ┌────────┐
│        │     │        │         │        │     │        │
│ 389-ds │◀───▶│ 389-ds │         │   AD   │◀───▶│   AD   │
│        │     │        │         │        │     │        │
└────────┘     └────────┘         └────────┘     └────────┘

Replicating Directory Changes (ディレクトリ変更のレプリケート) の権限を持つセキュリティグループが必要となります。たとえば Directory Server Sync という名前のグループを作成します。具体的には、 Microsoft Metadirectory Services ADMA サービス アカウントの 'ディレクトリ変更のレプリケート' アクセス許可を付与する方法 ( https://docs.microsoft.com/ja-JP/troubleshoot/windows-server/windows-security/grant-replicating-directory-changes-permission-adma-service ) をお読みのうえ、手順に従って設定してください。

警告: 強力なセキュリティの必要性について

このグループ内のメンバーを設定する際は、ドメイン管理者と同等の注意を払うようにしてください。このグループのメンバーは Active Directory 環境内の機密情報を読み込むことができるため、ユーザに対しては乱数から生成された強力なパスワードを設定するとともに、グループ内のメンバー追加や削除が不適切に行われないよう注意してください。

また、このグループに所属するサービスアカウントも作成する必要があります。

また、 389 DS と AD との通信を暗号化 (LDAPS) するため、 Active Directory 環境には証明書の設定もしなければなりません。なお、 Generic Security Services API/Kerberos (GSSAPI/KRB) は使用できません。

389 Directory Server 側ではバックエンドデータベースを設定し、組織単位 (OU) の各項目を同期できるように設定する必要があります。

また、 389 Directory Server 側ではレプリカ ID を設定して、読み込みと書き込みの両方ができるように設定する必要があります (レプリケーションの設定について、詳しくは 5.11項 「レプリケーションの設定」 をお読みください) 。

下記は 389 Directory Server 側で実行すべきコマンドで、 Active Directory から 389 Directory Server への同期合意を作成しています:

> sudo dsconf インスタンス名 repl-winsync-agmt create --suffix dc=example,dc=com \
  --host AD-ホスト名 --port 636 --conn-protocol LDAPS \
  --bind-dn "cn=サービスアカウント名,cn=USERS,dc=AD,dc=EXAMPLE,dc=COM" \
  --bind-passwd "パスワード" --win-subtree "cn=USERS,dc=AD,dc=EXAMPLE,dc=COM" \
  --ds-subtree ou=AD,dc=EXAMPLE,dc=COM --one-way-sync fromWindows \
  --sync-users=on --sync-groups=on --move-action delete \
  --win-domain AD-ドメイン adsync_agreement

合意を作成したあとは、初回の同期を実行します:

> sudo dsconf インスタンス名 repl-winsync-agmt init --suffix dc=example,dc=com adsync_agreement

下記のコマンドを使用することで、同期の状況を確認することができます:

> sudo dsconf インスタンス名 repl-winsync-agmt init-status --suffix dc=example,dc=com adsync_agreement

注記: 項目によっては同期されない問題について

初期の同期が成功していても、場合によっては同期されない項目が現れる場合があります。詳しくは /var/log/dirsrv/slapd-インスタンス名/errors 内にある 389 DS のログファイルをご覧ください。

下記のコマンドを入力して実行し、合意の状態を確認します:

> sudo dsconf インスタンス名 repl-winsync-agmt status --suffix dc=example,dc=com adsync_agreement

Active Directory と 389 Directory Server のトポロジ内でメンテナンスを実行する場合は、下記のようなコマンドを入力して実行し、合意を一時的に停止します:

> sudo dsconf インスタンス名 repl-winsync-agmt disable --suffix dc=example,dc=com adsync_agreement

一時停止した合意は、下記のように入力して実行することで再開できます:

> sudo dsconf インスタンス名 repl-winsync-agmt enable --suffix dc=example,dc=com adsync_agreement