Azureに389 Directory Server の検証機を作ってみた

先日、Red Hat 社から、「将来的にはOpenLDAPがREALのパッケージから外されるかもよ、、」というアナウンスがありました。

参考: Red Hat Enterprise Linux7.4 Release Notes Chapter 53. Deprecated Functionality

参考: What is the support status of the LDAP-server shipped with Red Hat Enterprise Linux?

OpenLDAPには、大変お世話になっておりましたが、サポートの範囲外になってしまうかも、と考えると代用手段を用意せねばということで、
RedHat が販売している「Red Hat Directory Server」を検証しようとしましたが、ライセンス料が、、、。
そこでOSS版である「389 Directory Server」なら無料の検証機をつくれますのでAzure上に構築してみました。

「389 Directory Server」、「Red Hat Directory Server」とは

元々は「Fedora Directory Server 」(Fedora DS)と呼ばれていました。
また、発展の経緯から「Sun Java System Directory Server」と「iPlanet Directory Server」は親戚と言えます。

コマンドに関しては今まで用いてきた ldapserach,ldapadd,ldapdelete,ldapmodfiy は問題なく使えます。
ですが、slapcatなどのOpenLDAP系のコマンドは実行できません。

「Red Hat Directory Server」はこの商用版になります。「389 Directory Server」にできることはすべてできるようです。

実際に構築してみる。

今回の記事では主設定を以下のように設定していきます。

まず、CentOSのインスタンスを作成します。サイズは最小サイズでも構いませんが、負荷テストなどを行いたい場合などは、大きめに作っておくといいと思います。
（参考：Azureに仮想マシン(CentOS)を構築する）

作成が終了しましたら、yumコマンドで 389DS をインストールします。

# yum install 389-ds

インストール完了しましたら、次にインスタンスの作成に入りますが、その前に /etc/hosts に使用するサフィックスとインスタンス名を記載しておく必要があるので、記載しましょう。
IPアドレスはマシン自身のIPアドレスで構いませんが、パブリックIPアドレスを記載してしまうと再起動のたび、変えなきゃいけなくなってしまうのでローカルIPアドレスを記載します。

# cat /etc/hosts
   ~
  10.0.1.0 example.test.com
   ~

また、389DS を使用するには、デフォルト設定より多くのファイルを開く必要がありますので、設定しましょう。
以下の内容で/etc/security/limits.d/90-test.com (ファイル名は任意) を作成します。

# cat /etc/security/limits.d/90-test.com
   
*	soft	nofile	8192
*	hard	nofile	8192

では、389インスタンス作成を行います。「389」にはインストールスクリプトが同梱されているのでそちらを実行します。
設定は各自異なると思いますが、特にこだわりがない場合は、「Computer name」のみ hosts に記載したものを使用し、ほかはデフォルト設定で構いません。

# setup-ds-admin.pl

設定例

インストールが完了した場合、dirsrv@インスタンス名とdirsrv-adminというサービスが立ち上がっているはずです。
今後の設定は、コンソールごしにGUIを用いてdirsrv-adminを介して行うことになります。
以下のコマンドでコンソールを起動できます。

# 389-console

AzureでGUI？

設定はGUIで行うと書きましたが、公式マニュアルは基本GUIでの作業を前提に書かれています。
しかし、Azureをはじめとするクラウド上のCentOSでGUIを実行することは難しいです。
（Azureに仮想マシン(CentOS)を構築する 通りですと、実行できません。）

$ 389-console
Exception in thread "main" java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an operation which requires it.
        at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:204)
        at java.awt.Window.(Window.java:536)
        at java.awt.Frame.(Frame.java:420)
        at java.awt.Frame.(Frame.java:385)
        at javax.swing.JFrame.(JFrame.java:189)
        at com.netscape.management.client.console.Console.(Unknown Source)
        at com.netscape.management.client.console.Console.main(Unknown Source)

こんな風になってしまいます。

ではどうするか、、、いろいろ考えました。
私が使った手段の紹介をしたいと思います。（これが最善ではないです。絶対に）

ローカルにもう一台CentOSを作ります。私はVirtualBox内に一台作成しました。
バージョンはなるべく389DSサーバに近い方がいいでしょう。

作成が終了しましたら、ローカル、389サーバ共にXサーバ関連のパッケージをインストールします。

# yum groupinstall "GNOME Desktop"

ローカルの構築の際に、GUIも一緒にインストールしてもいいでしょう。
その後GUIを起動します。

# startx

その後、ローカルマシンでターミナルを開き、389サーバにSSH接続をします。その際に -X をつけGUIを手元に転送するようにします。

# ssh -X ＜389DSサーバのユーザ＞＠＜389DSサーバのパブリックIPアドレス＞

接続できましたら、コンソールを起動します。今度は起動できるはずです。

あとは、公式ドキュメントに従っていろいろ試すだけです。

GUIは嫌いだ

GUIを開くまでが非常にメンドクサイ、、
それ以前に、クライアント先にGUIがない可能性も捨てきれない、、
その場合は、ldapmodfiyとldifファイルを使用して設定することもできます。
SSL化、レプリケーションの作成、ログのローテーション設定などができることを確認しています。
また、設定ldifである/etc/dirsrv/インスタンス名/dse.ldifを直接編集でも設定できるそうですが、
私は怖くて編集できませんでした。

でも、結局うまく設定できているかを確認するためには、GUIのコンソールがあった方がいいので、検証機では、GUIがあった方がいいと思っています。

最後に

今回は、これから構築することが増えていきそうなRHDS及び、389DSの検証環境を構築してみました。
OpenLDAPとは機能に大きな差異は今のところ見つけられていないですが、設定方法に大きな違いがあるように感じました。
やっぱり、実際に触れてみないとわからないこと多いです。
皆さんも、ぜひ検証してみてください。