2017年10月18日水曜日

db2bak.pl の結果を知りたい

389 Directory Server の db2bak.pl の中身を見る限り、どうやらこれは
 "cn=backup, cn=tasks, cn=config" にエントリを追加するだけで、後は task プラグイン
にお任せのようだ。

エントリの追加後タスクの実行を待っていたりしないので非同期で、その結果は db2bak.pl
だけでは得ることができない。同期モードを作るべきな気がするが。
# 自分で作れってw

ちなみに db2bak.pl の終了コードは perl の DSUtil:ldapmod() の返り値と同じなので、
エントリ追加が出来たかどうかしか取れない。

じゃぁ終了判断やその結果をどうやって知るかってことになるが、errors ログファイル
を見るのが一番確実ではあるが行parseするのが面倒。

db2bak.pl を実行すると以下のように標準出力にエントリの DN が表示される。

# db2bak.pl -Z testinst -D "cn=Directory Manager" -w password
Back up directory: /var/lib/dirsrv/slapd-testinst/bak/rhds1-2017_10_18_2_15_12
Successfully added task entry "cn=backup_2017_10_18_2_15_12, cn=backup, cn=tasks, cn=config"

そのエントリを参照すると以下のよう。


dn: cn=backup_2017_10_18_2_20_7,cn=backup,cn=tasks,cn=config
objectClass: top
objectClass: extensibleObject
cn: backup_2017_10_18_2_20_7
nsarchivedir: /var/lib/dirsrv/slapd-testinst/bak/hoge
nsdatabasetype: ldbm database
nstaskcurrentitem: 0
nstasktotalitems: 1
nstasklog:: xxxxxx
  :
nstaskstatus: Backup finished.
nstaskexitcode: 0

nstasklog 属性に base64 で詳細ログが記録されてる。終了したか否かの判断は
nstaskstatus と nstaskexitcode ですれば良いっぽい。ただ、このエントリは終了後
その結果にかかわらず 2 分で消える。2 分という設定がどこにあるかわからないが、
以下で 2 分と言っている人がいた。cn=config にはそれらしき設定は無かった。

http://www.databaseusers.com/article/7985099/backup+monitor

Once a task has finished (good or bad), the entry will stay visible for 2 minutes. By viewing the nstaskstatus and nstaskexitcode attributes you can find out how far it has gone and if the task has finished successfully or with an error.
Here is an example using a persistent search filtering on nstaskexitcode so you only get a response back once the job has completed:

これをぐるぐる回して同期なスクリプトを作るか。終了後 2 分で消えるということは、
db2bak.pl 実行後にぐるぐる回す間隔を 2 分以内にすればとりあえずはなんとか消える
前に結果が取れるってことかな。

めんどくさっ
今から python で作り変えてみる。

2017年10月10日火曜日

389 Directory MemberOf Plugin は refint 不要ぽい

389 Directory の MemberOf プラグインは、あるメンバーの実エントリの DN を modrdn して書き換えると、
何もしなくても(refint overlay 使わなくても)ちゃんと groupOfNames 側の member を書き換えてくれる。

その逆の、ある groupOfNames のグループの実エントリで、グループの DN を modrdn で書き換えても
ちゃんとユーザエントリ側の memberOf を書き換えてくれた。

しかしながら groupOfNames の owner 属性は対象外っぽい。こちらは refint するしかないかも。

2017年10月7日土曜日

389 Directory Server リストア失敗 → 成功

くだらないミスだったんだけど、同じことでハマる人がいるかもしれないので役に立てばのメモ。

まぁ、タイトルは 389 Directory にしたけど本当は RHDS なんだけどね。おそらく同じだろうからまぁいいかな(違ってたらコメントで教えて下さい)。

bak2db.pl を使って、db2back.pl で取得したバックアップディレクトリからリストアを試みたが、/var/log/dirsrv/slapd-<instance>/errors には以下のエラーが。

ERR - ldbm_back_archive2ldbm - No back up "/home/ryo/rhds1-2017_10_7_3_20_46" exists.
ERR - task_restore_thread - Restore failed (error -1)

ぐぐっても情報が無いので、ソースから上記箇所を grep。すると servers/slapd/back-ldbm/archive.c に以下の箇所あり。

   48     return_value = dbversion_read(li, directory, &dbversion, &dataversion);
   49     if (return_value) {
   50         if (ENOENT == return_value) {
   51             slapi_log_err(SLAPI_LOG_ERR, "ldbm_back_archive2ldbm", "No back up \"%s\" exists.\n",
   52                           directory);
   53             return -1;
   54         }

どうも DB のバージョンを確認するファイルが無いと(ENOENT)。バックアップディレクトリ内のファイル名から考えると
DBVERSION ってのがあるんだけど... うーーん permission も問題なし... あ、SELinux ?バックアプファイルの context を見てみる。

# ls -Z
-rw-------. dirsrv dirsrv unconfined_u:object_r:user_home_t:s0 DBVERSION
-rw-------. dirsrv dirsrv unconfined_u:object_r:user_home_t:s0 dse_index.ldif
-rw-------. dirsrv dirsrv unconfined_u:object_r:user_home_t:s0 dse_instance.ldif
-rw-------. dirsrv dirsrv unconfined_u:object_r:user_home_t:s0 dse.ldif
   :

あぁぁ... てことで

# chcon -R system_u:object_r:dirsrv_var_lib_t:s0 rhds1-2017_10_7_3_20_46/

これで解決しますた。

2017年10月4日水曜日

389-consle (redhat-idm-console)が ssh の X Forward で動かん→動いた

redhat-idm-console (389-console)をリモート越しに起動して手元の X で表示しようと、
試みたところ以下のエラーで起動できない。

Exception in thread "main" java.awt.HeadlessException
        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)
Headless というのがようわからんが、/etc/java/とredhat-389-console.conf で以下の
ようにとにかくこれを外してみた。


$ diff -u /etc/java/redhat-389-console.conf.dist /etc/java/redhat-389-console.conf
--- /etc/java/redhat-389-console.conf.dist      2016-10-10 01:45:11.000000000 +0000
+++ /etc/java/redhat-389-console.conf   2017-10-04 01:44:55.026633680 +0000
@@ -1,3 +1,3 @@
 mylang=${mylang:-en}
 ADDITIONAL_JARS=${ADDITIONAL_JARS:-redhat-idm-console_$mylang.jar}
-ADDITIONAL_OPTIONS=${ADDITIONAL_OPTIONS:-"-Dprogram.name=redhat-idm-console -Djava.util.prefs.systemRoot=$HOME/.redhat-idm-console -Djava.util.prefs.userRoot=$HOME/.redhat-idm-console"}
+ADDITIONAL_OPTIONS=${ADDITIONAL_OPTIONS:-"-Dprogram.name=redhat-idm-console -Djava.util.prefs.systemRoot=$HOME/.redhat-idm-console -Djava.util.prefs.userRoot=$HOME/.redhat-idm-console -Djava.awt.headless=false"}

すると、libawt_xawt.so が無いぞと怒られ調べたらこれは Headless でない
java-1.8.0-openjdk パッケージに含まれる模様

# yum install java-1.8.0-openjdk 

しかしなんで単なる設定をいじるのにこんなに重い GUI を起動せにゃあかんのか。しかも
激重な Java。Java は Windows 以上に嫌いだわ。どの OS とも相性が悪い。当初のコンセ
プトとは大違い。クソ言語。問題なのはプログラマが多いこと。だから糞システムが量産
される。Java の世界だけで OS 作って勝手にやってりゃいいのに。こっちくんな。