QA@IT
«回答へ戻る

更新だと曖昧なので「パスワード更新」に変更

760
 > テスト時にうまくいって、今上手くいかない理由としては、更新時のエントリー検索に時間がかかり、ldappasswdの処理が完了する前にldapmodifyを実行しているため、ldapへの更新ができてないものかと思ってます。
 > 考え方としていかがでしょうか?
 
-考え方はわかります。ただ「ldappasswdの処理が完了する前に」の箇所は、すっきりしませんよね?もしそうだとすると、ldappasswdの実行が終わって、いったん呼び出し側のプロセスに制御が返ってきて、次にldapmodifyの実行を開始したとき、その時点ではLDAPの更新はまだできておらず、後の時点ではじめてLDAPの更新が(非同期に)完了することになると思いますが、自分にはそういった状況は考えにくいです(「ない」ともいいきれませんが)。
+考え方はわかります。ただ「ldappasswdの処理が完了する前に」の箇所は、すっきりしませんよね?もしそうだとすると、ldappasswdの実行が終わって、いったん呼び出し側のプロセスに制御が返ってきて、次にldapmodifyの実行を開始したとき、その時点ではLDAPのパスワード更新はまだできておらず、後の時点ではじめてLDAPのパスワード更新が(非同期に)完了することになると思いますが、自分にはそういった状況は考えにくいです(「ない」ともいいきれませんが)。
 
 他の可能性として、例えばldappasswdがエラーになって、その結果ldapmodifyが失敗する場合もあると思います。その場合は2回目のldapmodifyが成功するのは、LDAPのレプリケーションにより、対向側のサーバーから新しいパスワードがコピーされたと考えられるのではないかと思います。もちろんこれもあくまで推測の域をでません。
 

あと、コマンドだけで実行した場合は再現しません。
FreeRADIUSのlocal_cpwとの連携も関係してたりしますでしょうか。

とするとシェルスクリプトの書き方が関係するかもしれません。

ldapmodifyの入力は下のようにヒアドキュメントを使って標準入力から食わせているのでしょうか?

ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 << EOS
dn: uid=ldapuser,ou=People,dc=nodomain
changetype: modify
replace: shadowLastChange
shadowLastChange: 20000
EOS

それとも下のようにldifファイルを作ってそれを食わせているのでしょうか?

echo "dn: uid=ldapuser,ou=People,dc=nodomain" > modify.ldif
echo "changetype: modify"                     >> modify.ldif
echo "replace: shadowLastChange"              >> modify.ldif
echo "shadowLastChange: 20000"                >> modify.ldif
ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 -f modify.ldif

テスト時にうまくいって、今上手くいかない理由としては、更新時のエントリー検索に時間がかかり、
ldappasswdの処理が完了する前にldapmodifyを実行しているため、ldapへの更新ができてないものかと思ってます。

更新に時間がかかると、NASからRADIUSサーバーに対するリトライが発生しうるので、シェルスクリプトが二重起動されることもあるのではないかと思います。

例えば一つの可能性として、もしldifファイルを作っていて、かつファイル名がユニークでない場合は、タイミングによってはldifファイルが壊れる可能性もあるのではないかと思います。

実際の原因はもう少し情報がないとわかりませんが、とりあえず思いついたのはこんなところですかね。

追記
いい忘れてましたが、あともう一つ気になるのはやはりシェルスクリプトの書き方で、下記のどちらなんだろうかということです。

  • サーバーAのスクリプトはLDAPの更新をAのLDAPサーバーに対してかけ、サーバーBのスクリプトはLDAPの更新をBのLDAPサーバーに対してかけるようになっている。
  • サーバーAのスクリプトもサーバーBのスクリプトも通常はLDAPの更新をAのLDAPサーバーに対してだけかけるようにし、サーバーAが落ちた時はサーバーBのスクリプトが更新先をAからBに切り替えるようになっている。

一般的には後者だろうと思います。ただ前者がNGかというとはっきりわかりませんが。

NASにプライマリーRADIUSサーバーとセカンダリーRADIUSサーバーを設定しているのではないかと思いますが、更新に時間がかかると、両方のRADIUSサーバーにリクエストが飛んでいくと思います。

その場合2台のサーバー上でシェルスクリプトが起動されると思いますが、そのこととOpenLDAPの「相互にレプリケーションする」構成の関係はとても気になります。

プロバイダ(マスタ)が2台いるわけですが、スクリプトの書き方が前者のケースだったとき、同時に2台のプロバイダ(マスタ)に更新をかけたときに好ましくない副作用がおきないかといったことです。

追記(2018/09/24)

今回の不具合の原因として推測していることは、ldappasswdとldapmodifyを連続して実行しているため、ldappasswdの処理が 完了する前にldapmodifyを実行しているためだと考えています。
テスト時にうまくいって、今上手くいかない理由としては、更新時のエントリー検索に時間がかかり、ldappasswdの処理が完了する前にldapmodifyを実行しているため、ldapへの更新ができてないものかと思ってます。
考え方としていかがでしょうか?

考え方はわかります。ただ「ldappasswdの処理が完了する前に」の箇所は、すっきりしませんよね?もしそうだとすると、ldappasswdの実行が終わって、いったん呼び出し側のプロセスに制御が返ってきて、次にldapmodifyの実行を開始したとき、その時点ではLDAPのパスワード更新はまだできておらず、後の時点ではじめてLDAPのパスワード更新が(非同期に)完了することになると思いますが、自分にはそういった状況は考えにくいです(「ない」ともいいきれませんが)。

他の可能性として、例えばldappasswdがエラーになって、その結果ldapmodifyが失敗する場合もあると思います。その場合は2回目のldapmodifyが成功するのは、LDAPのレプリケーションにより、対向側のサーバーから新しいパスワードがコピーされたと考えられるのではないかと思います。もちろんこれもあくまで推測の域をでません。

繰り返しになりますが、実際の原因はもう少し情報がないとわからないです。

> あと、コマンドだけで実行した場合は再現しません。
> FreeRADIUSのlocal_cpwとの連携も関係してたりしますでしょうか。

とするとシェルスクリプトの書き方が関係するかもしれません。

ldapmodifyの入力は下のようにヒアドキュメントを使って標準入力から食わせているのでしょうか?

```sh
ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 << EOS
dn: uid=ldapuser,ou=People,dc=nodomain
changetype: modify
replace: shadowLastChange
shadowLastChange: 20000
EOS
```

それとも下のようにldifファイルを作ってそれを食わせているのでしょうか?

```sh
echo "dn: uid=ldapuser,ou=People,dc=nodomain" > modify.ldif
echo "changetype: modify"                     >> modify.ldif
echo "replace: shadowLastChange"              >> modify.ldif
echo "shadowLastChange: 20000"                >> modify.ldif
ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 -f modify.ldif
```

> テスト時にうまくいって、今上手くいかない理由としては、更新時のエントリー検索に時間がかかり、
> ldappasswdの処理が完了する前にldapmodifyを実行しているため、ldapへの更新ができてないものかと思ってます。

更新に時間がかかると、NASからRADIUSサーバーに対するリトライが発生しうるので、シェルスクリプトが二重起動されることもあるのではないかと思います。

例えば一つの可能性として、もしldifファイルを作っていて、かつファイル名がユニークでない場合は、タイミングによってはldifファイルが壊れる可能性もあるのではないかと思います。

実際の原因はもう少し情報がないとわかりませんが、とりあえず思いついたのはこんなところですかね。

**追記**
いい忘れてましたが、あともう一つ気になるのはやはりシェルスクリプトの書き方で、下記のどちらなんだろうかということです。

- サーバーAのスクリプトはLDAPの更新をAのLDAPサーバーに対してかけ、サーバーBのスクリプトはLDAPの更新をBのLDAPサーバーに対してかけるようになっている。
- サーバーAのスクリプトもサーバーBのスクリプトも通常はLDAPの更新をAのLDAPサーバーに対してだけかけるようにし、サーバーAが落ちた時はサーバーBのスクリプトが更新先をAからBに切り替えるようになっている。

一般的には後者だろうと思います。ただ前者がNGかというとはっきりわかりませんが。

NASにプライマリーRADIUSサーバーとセカンダリーRADIUSサーバーを設定しているのではないかと思いますが、更新に時間がかかると、両方のRADIUSサーバーにリクエストが飛んでいくと思います。

その場合2台のサーバー上でシェルスクリプトが起動されると思いますが、そのこととOpenLDAPの「相互にレプリケーションする」構成の関係はとても気になります。

プロバイダ(マスタ)が2台いるわけですが、スクリプトの書き方が前者のケースだったとき、同時に2台のプロバイダ(マスタ)に更新をかけたときに好ましくない副作用がおきないかといったことです。

**追記(2018/09/24)**
> 今回の不具合の原因として推測していることは、ldappasswdとldapmodifyを連続して実行しているため、ldappasswdの処理が 完了する前にldapmodifyを実行しているためだと考えています。
> テスト時にうまくいって、今上手くいかない理由としては、更新時のエントリー検索に時間がかかり、ldappasswdの処理が完了する前にldapmodifyを実行しているため、ldapへの更新ができてないものかと思ってます。
> 考え方としていかがでしょうか?

考え方はわかります。ただ「ldappasswdの処理が完了する前に」の箇所は、すっきりしませんよね?もしそうだとすると、ldappasswdの実行が終わって、いったん呼び出し側のプロセスに制御が返ってきて、次にldapmodifyの実行を開始したとき、その時点ではLDAPのパスワード更新はまだできておらず、後の時点ではじめてLDAPのパスワード更新が(非同期に)完了することになると思いますが、自分にはそういった状況は考えにくいです(「ない」ともいいきれませんが)。

他の可能性として、例えばldappasswdがエラーになって、その結果ldapmodifyが失敗する場合もあると思います。その場合は2回目のldapmodifyが成功するのは、LDAPのレプリケーションにより、対向側のサーバーから新しいパスワードがコピーされたと考えられるのではないかと思います。もちろんこれもあくまで推測の域をでません。

繰り返しになりますが、実際の原因はもう少し情報がないとわからないです。

追記(2018/09/24)

760
 
 プロバイダ(マスタ)が2台いるわけですが、スクリプトの書き方が前者のケースだったとき、同時に2台のプロバイダ(マスタ)に更新をかけたときに好ましくない副作用がおきないかといったことです。
 
+**追記(2018/09/24)**
+> 今回の不具合の原因として推測していることは、ldappasswdとldapmodifyを連続して実行しているため、ldappasswdの処理が 完了する前にldapmodifyを実行しているためだと考えています。
+> テスト時にうまくいって、今上手くいかない理由としては、更新時のエントリー検索に時間がかかり、ldappasswdの処理が完了する前にldapmodifyを実行しているため、ldapへの更新ができてないものかと思ってます。
+> 考え方としていかがでしょうか?
+
+考え方はわかります。ただ「ldappasswdの処理が完了する前に」の箇所は、すっきりしませんよね?もしそうだとすると、ldappasswdの実行が終わって、いったん呼び出し側のプロセスに制御が返ってきて、次にldapmodifyの実行を開始したとき、その時点ではLDAPの更新はまだできておらず、後の時点ではじめてLDAPの更新が(非同期に)完了することになると思いますが、自分にはそういった状況は考えにくいです(「ない」ともいいきれませんが)。
+
+他の可能性として、例えばldappasswdがエラーになって、その結果ldapmodifyが失敗する場合もあると思います。その場合は2回目のldapmodifyが成功するのは、LDAPのレプリケーションにより、対向側のサーバーから新しいパスワードがコピーされたと考えられるのではないかと思います。もちろんこれもあくまで推測の域をでません。
+
+繰り返しになりますが、実際の原因はもう少し情報がないとわからないです。

あと、コマンドだけで実行した場合は再現しません。
FreeRADIUSのlocal_cpwとの連携も関係してたりしますでしょうか。

とするとシェルスクリプトの書き方が関係するかもしれません。

ldapmodifyの入力は下のようにヒアドキュメントを使って標準入力から食わせているのでしょうか?

ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 << EOS
dn: uid=ldapuser,ou=People,dc=nodomain
changetype: modify
replace: shadowLastChange
shadowLastChange: 20000
EOS

それとも下のようにldifファイルを作ってそれを食わせているのでしょうか?

echo "dn: uid=ldapuser,ou=People,dc=nodomain" > modify.ldif
echo "changetype: modify"                     >> modify.ldif
echo "replace: shadowLastChange"              >> modify.ldif
echo "shadowLastChange: 20000"                >> modify.ldif
ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 -f modify.ldif

テスト時にうまくいって、今上手くいかない理由としては、更新時のエントリー検索に時間がかかり、
ldappasswdの処理が完了する前にldapmodifyを実行しているため、ldapへの更新ができてないものかと思ってます。

更新に時間がかかると、NASからRADIUSサーバーに対するリトライが発生しうるので、シェルスクリプトが二重起動されることもあるのではないかと思います。

例えば一つの可能性として、もしldifファイルを作っていて、かつファイル名がユニークでない場合は、タイミングによってはldifファイルが壊れる可能性もあるのではないかと思います。

実際の原因はもう少し情報がないとわかりませんが、とりあえず思いついたのはこんなところですかね。

追記
いい忘れてましたが、あともう一つ気になるのはやはりシェルスクリプトの書き方で、下記のどちらなんだろうかということです。

  • サーバーAのスクリプトはLDAPの更新をAのLDAPサーバーに対してかけ、サーバーBのスクリプトはLDAPの更新をBのLDAPサーバーに対してかけるようになっている。
  • サーバーAのスクリプトもサーバーBのスクリプトも通常はLDAPの更新をAのLDAPサーバーに対してだけかけるようにし、サーバーAが落ちた時はサーバーBのスクリプトが更新先をAからBに切り替えるようになっている。

一般的には後者だろうと思います。ただ前者がNGかというとはっきりわかりませんが。

NASにプライマリーRADIUSサーバーとセカンダリーRADIUSサーバーを設定しているのではないかと思いますが、更新に時間がかかると、両方のRADIUSサーバーにリクエストが飛んでいくと思います。

その場合2台のサーバー上でシェルスクリプトが起動されると思いますが、そのこととOpenLDAPの「相互にレプリケーションする」構成の関係はとても気になります。

プロバイダ(マスタ)が2台いるわけですが、スクリプトの書き方が前者のケースだったとき、同時に2台のプロバイダ(マスタ)に更新をかけたときに好ましくない副作用がおきないかといったことです。

追記(2018/09/24)

今回の不具合の原因として推測していることは、ldappasswdとldapmodifyを連続して実行しているため、ldappasswdの処理が 完了する前にldapmodifyを実行しているためだと考えています。
テスト時にうまくいって、今上手くいかない理由としては、更新時のエントリー検索に時間がかかり、ldappasswdの処理が完了する前にldapmodifyを実行しているため、ldapへの更新ができてないものかと思ってます。
考え方としていかがでしょうか?

考え方はわかります。ただ「ldappasswdの処理が完了する前に」の箇所は、すっきりしませんよね?もしそうだとすると、ldappasswdの実行が終わって、いったん呼び出し側のプロセスに制御が返ってきて、次にldapmodifyの実行を開始したとき、その時点ではLDAPの更新はまだできておらず、後の時点ではじめてLDAPの更新が(非同期に)完了することになると思いますが、自分にはそういった状況は考えにくいです(「ない」ともいいきれませんが)。

他の可能性として、例えばldappasswdがエラーになって、その結果ldapmodifyが失敗する場合もあると思います。その場合は2回目のldapmodifyが成功するのは、LDAPのレプリケーションにより、対向側のサーバーから新しいパスワードがコピーされたと考えられるのではないかと思います。もちろんこれもあくまで推測の域をでません。

繰り返しになりますが、実際の原因はもう少し情報がないとわからないです。

> あと、コマンドだけで実行した場合は再現しません。
> FreeRADIUSのlocal_cpwとの連携も関係してたりしますでしょうか。

とするとシェルスクリプトの書き方が関係するかもしれません。

ldapmodifyの入力は下のようにヒアドキュメントを使って標準入力から食わせているのでしょうか?

```sh
ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 << EOS
dn: uid=ldapuser,ou=People,dc=nodomain
changetype: modify
replace: shadowLastChange
shadowLastChange: 20000
EOS
```

それとも下のようにldifファイルを作ってそれを食わせているのでしょうか?

```sh
echo "dn: uid=ldapuser,ou=People,dc=nodomain" > modify.ldif
echo "changetype: modify"                     >> modify.ldif
echo "replace: shadowLastChange"              >> modify.ldif
echo "shadowLastChange: 20000"                >> modify.ldif
ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 -f modify.ldif
```

> テスト時にうまくいって、今上手くいかない理由としては、更新時のエントリー検索に時間がかかり、
> ldappasswdの処理が完了する前にldapmodifyを実行しているため、ldapへの更新ができてないものかと思ってます。

更新に時間がかかると、NASからRADIUSサーバーに対するリトライが発生しうるので、シェルスクリプトが二重起動されることもあるのではないかと思います。

例えば一つの可能性として、もしldifファイルを作っていて、かつファイル名がユニークでない場合は、タイミングによってはldifファイルが壊れる可能性もあるのではないかと思います。

実際の原因はもう少し情報がないとわかりませんが、とりあえず思いついたのはこんなところですかね。

**追記**
いい忘れてましたが、あともう一つ気になるのはやはりシェルスクリプトの書き方で、下記のどちらなんだろうかということです。

- サーバーAのスクリプトはLDAPの更新をAのLDAPサーバーに対してかけ、サーバーBのスクリプトはLDAPの更新をBのLDAPサーバーに対してかけるようになっている。
- サーバーAのスクリプトもサーバーBのスクリプトも通常はLDAPの更新をAのLDAPサーバーに対してだけかけるようにし、サーバーAが落ちた時はサーバーBのスクリプトが更新先をAからBに切り替えるようになっている。

一般的には後者だろうと思います。ただ前者がNGかというとはっきりわかりませんが。

NASにプライマリーRADIUSサーバーとセカンダリーRADIUSサーバーを設定しているのではないかと思いますが、更新に時間がかかると、両方のRADIUSサーバーにリクエストが飛んでいくと思います。

その場合2台のサーバー上でシェルスクリプトが起動されると思いますが、そのこととOpenLDAPの「相互にレプリケーションする」構成の関係はとても気になります。

プロバイダ(マスタ)が2台いるわけですが、スクリプトの書き方が前者のケースだったとき、同時に2台のプロバイダ(マスタ)に更新をかけたときに好ましくない副作用がおきないかといったことです。

**追記(2018/09/24)**
> 今回の不具合の原因として推測していることは、ldappasswdとldapmodifyを連続して実行しているため、ldappasswdの処理が 完了する前にldapmodifyを実行しているためだと考えています。
> テスト時にうまくいって、今上手くいかない理由としては、更新時のエントリー検索に時間がかかり、ldappasswdの処理が完了する前にldapmodifyを実行しているため、ldapへの更新ができてないものかと思ってます。
> 考え方としていかがでしょうか?

考え方はわかります。ただ「ldappasswdの処理が完了する前に」の箇所は、すっきりしませんよね?もしそうだとすると、ldappasswdの実行が終わって、いったん呼び出し側のプロセスに制御が返ってきて、次にldapmodifyの実行を開始したとき、その時点ではLDAPの更新はまだできておらず、後の時点ではじめてLDAPの更新が(非同期に)完了することになると思いますが、自分にはそういった状況は考えにくいです(「ない」ともいいきれませんが)。

他の可能性として、例えばldappasswdがエラーになって、その結果ldapmodifyが失敗する場合もあると思います。その場合は2回目のldapmodifyが成功するのは、LDAPのレプリケーションにより、対向側のサーバーから新しいパスワードがコピーされたと考えられるのではないかと思います。もちろんこれもあくまで推測の域をでません。

繰り返しになりますが、実際の原因はもう少し情報がないとわからないです。

スペルミス修正

760
 
 一般的には後者だろうと思います。ただ前者がNGかというとはっきりわかりませんが。
 
-NASにプライマリーRADIUSサーバーとセカンダリーRADIUSサーバーを設定しているのではないかと思いますが、更新に時間がかかると、両方のRAIUSサーバーにリクエストが飛んでいくと思います。
+NASにプライマリーRADIUSサーバーとセカンダリーRADIUSサーバーを設定しているのではないかと思いますが、更新に時間がかかると、両方のRADIUSサーバーにリクエストが飛んでいくと思います。
 
 その場合2台のサーバー上でシェルスクリプトが起動されると思いますが、そのこととOpenLDAPの「相互にレプリケーションする」構成の関係はとても気になります。
 

あと、コマンドだけで実行した場合は再現しません。
FreeRADIUSのlocal_cpwとの連携も関係してたりしますでしょうか。

とするとシェルスクリプトの書き方が関係するかもしれません。

ldapmodifyの入力は下のようにヒアドキュメントを使って標準入力から食わせているのでしょうか?

ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 << EOS
dn: uid=ldapuser,ou=People,dc=nodomain
changetype: modify
replace: shadowLastChange
shadowLastChange: 20000
EOS

それとも下のようにldifファイルを作ってそれを食わせているのでしょうか?

echo "dn: uid=ldapuser,ou=People,dc=nodomain" > modify.ldif
echo "changetype: modify"                     >> modify.ldif
echo "replace: shadowLastChange"              >> modify.ldif
echo "shadowLastChange: 20000"                >> modify.ldif
ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 -f modify.ldif

テスト時にうまくいって、今上手くいかない理由としては、更新時のエントリー検索に時間がかかり、
ldappasswdの処理が完了する前にldapmodifyを実行しているため、ldapへの更新ができてないものかと思ってます。

更新に時間がかかると、NASからRADIUSサーバーに対するリトライが発生しうるので、シェルスクリプトが二重起動されることもあるのではないかと思います。

例えば一つの可能性として、もしldifファイルを作っていて、かつファイル名がユニークでない場合は、タイミングによってはldifファイルが壊れる可能性もあるのではないかと思います。

実際の原因はもう少し情報がないとわかりませんが、とりあえず思いついたのはこんなところですかね。

追記
いい忘れてましたが、あともう一つ気になるのはやはりシェルスクリプトの書き方で、下記のどちらなんだろうかということです。

  • サーバーAのスクリプトはLDAPの更新をAのLDAPサーバーに対してかけ、サーバーBのスクリプトはLDAPの更新をBのLDAPサーバーに対してかけるようになっている。
  • サーバーAのスクリプトもサーバーBのスクリプトも通常はLDAPの更新をAのLDAPサーバーに対してだけかけるようにし、サーバーAが落ちた時はサーバーBのスクリプトが更新先をAからBに切り替えるようになっている。

一般的には後者だろうと思います。ただ前者がNGかというとはっきりわかりませんが。

NASにプライマリーRADIUSサーバーとセカンダリーRADIUSサーバーを設定しているのではないかと思いますが、更新に時間がかかると、両方のRADIUSサーバーにリクエストが飛んでいくと思います。

その場合2台のサーバー上でシェルスクリプトが起動されると思いますが、そのこととOpenLDAPの「相互にレプリケーションする」構成の関係はとても気になります。

プロバイダ(マスタ)が2台いるわけですが、スクリプトの書き方が前者のケースだったとき、同時に2台のプロバイダ(マスタ)に更新をかけたときに好ましくない副作用がおきないかといったことです。

> あと、コマンドだけで実行した場合は再現しません。
> FreeRADIUSのlocal_cpwとの連携も関係してたりしますでしょうか。

とするとシェルスクリプトの書き方が関係するかもしれません。

ldapmodifyの入力は下のようにヒアドキュメントを使って標準入力から食わせているのでしょうか?

```sh
ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 << EOS
dn: uid=ldapuser,ou=People,dc=nodomain
changetype: modify
replace: shadowLastChange
shadowLastChange: 20000
EOS
```

それとも下のようにldifファイルを作ってそれを食わせているのでしょうか?

```sh
echo "dn: uid=ldapuser,ou=People,dc=nodomain" > modify.ldif
echo "changetype: modify"                     >> modify.ldif
echo "replace: shadowLastChange"              >> modify.ldif
echo "shadowLastChange: 20000"                >> modify.ldif
ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 -f modify.ldif
```

> テスト時にうまくいって、今上手くいかない理由としては、更新時のエントリー検索に時間がかかり、
> ldappasswdの処理が完了する前にldapmodifyを実行しているため、ldapへの更新ができてないものかと思ってます。

更新に時間がかかると、NASからRADIUSサーバーに対するリトライが発生しうるので、シェルスクリプトが二重起動されることもあるのではないかと思います。

例えば一つの可能性として、もしldifファイルを作っていて、かつファイル名がユニークでない場合は、タイミングによってはldifファイルが壊れる可能性もあるのではないかと思います。

実際の原因はもう少し情報がないとわかりませんが、とりあえず思いついたのはこんなところですかね。

**追記**
いい忘れてましたが、あともう一つ気になるのはやはりシェルスクリプトの書き方で、下記のどちらなんだろうかということです。

- サーバーAのスクリプトはLDAPの更新をAのLDAPサーバーに対してかけ、サーバーBのスクリプトはLDAPの更新をBのLDAPサーバーに対してかけるようになっている。
- サーバーAのスクリプトもサーバーBのスクリプトも通常はLDAPの更新をAのLDAPサーバーに対してだけかけるようにし、サーバーAが落ちた時はサーバーBのスクリプトが更新先をAからBに切り替えるようになっている。

一般的には後者だろうと思います。ただ前者がNGかというとはっきりわかりませんが。

NASにプライマリーRADIUSサーバーとセカンダリーRADIUSサーバーを設定しているのではないかと思いますが、更新に時間がかかると、両方のRADIUSサーバーにリクエストが飛んでいくと思います。

その場合2台のサーバー上でシェルスクリプトが起動されると思いますが、そのこととOpenLDAPの「相互にレプリケーションする」構成の関係はとても気になります。

プロバイダ(マスタ)が2台いるわけですが、スクリプトの書き方が前者のケースだったとき、同時に2台のプロバイダ(マスタ)に更新をかけたときに好ましくない副作用がおきないかといったことです。

追記

760
 例えば一つの可能性として、もしldifファイルを作っていて、かつファイル名がユニークでない場合は、タイミングによってはldifファイルが壊れる可能性もあるのではないかと思います。
 
 実際の原因はもう少し情報がないとわかりませんが、とりあえず思いついたのはこんなところですかね。
+
+**追記**
+いい忘れてましたが、あともう一つ気になるのはやはりシェルスクリプトの書き方で、下記のどちらなんだろうかということです。
+
+- サーバーAのスクリプトはLDAPの更新をAのLDAPサーバーに対してかけ、サーバーBのスクリプトはLDAPの更新をBのLDAPサーバーに対してかけるようになっている。
+- サーバーAのスクリプトもサーバーBのスクリプトも通常はLDAPの更新をAのLDAPサーバーに対してだけかけるようにし、サーバーAが落ちた時はサーバーBのスクリプトが更新先をAからBに切り替えるようになっている。
+
+一般的には後者だろうと思います。ただ前者がNGかというとはっきりわかりませんが。
+
+NASにプライマリーRADIUSサーバーとセカンダリーRADIUSサーバーを設定しているのではないかと思いますが、更新に時間がかかると、両方のRAIUSサーバーにリクエストが飛んでいくと思います。
+
+その場合2台のサーバー上でシェルスクリプトが起動されると思いますが、そのこととOpenLDAPの「相互にレプリケーションする」構成の関係はとても気になります。
+
+プロバイダ(マスタ)が2台いるわけですが、スクリプトの書き方が前者のケースだったとき、同時に2台のプロバイダ(マスタ)に更新をかけたときに好ましくない副作用がおきないかといったことです。
+

あと、コマンドだけで実行した場合は再現しません。
FreeRADIUSのlocal_cpwとの連携も関係してたりしますでしょうか。

とするとシェルスクリプトの書き方が関係するかもしれません。

ldapmodifyの入力は下のようにヒアドキュメントを使って標準入力から食わせているのでしょうか?

ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 << EOS
dn: uid=ldapuser,ou=People,dc=nodomain
changetype: modify
replace: shadowLastChange
shadowLastChange: 20000
EOS

それとも下のようにldifファイルを作ってそれを食わせているのでしょうか?

echo "dn: uid=ldapuser,ou=People,dc=nodomain" > modify.ldif
echo "changetype: modify"                     >> modify.ldif
echo "replace: shadowLastChange"              >> modify.ldif
echo "shadowLastChange: 20000"                >> modify.ldif
ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 -f modify.ldif

テスト時にうまくいって、今上手くいかない理由としては、更新時のエントリー検索に時間がかかり、
ldappasswdの処理が完了する前にldapmodifyを実行しているため、ldapへの更新ができてないものかと思ってます。

更新に時間がかかると、NASからRADIUSサーバーに対するリトライが発生しうるので、シェルスクリプトが二重起動されることもあるのではないかと思います。

例えば一つの可能性として、もしldifファイルを作っていて、かつファイル名がユニークでない場合は、タイミングによってはldifファイルが壊れる可能性もあるのではないかと思います。

実際の原因はもう少し情報がないとわかりませんが、とりあえず思いついたのはこんなところですかね。

追記
いい忘れてましたが、あともう一つ気になるのはやはりシェルスクリプトの書き方で、下記のどちらなんだろうかということです。

  • サーバーAのスクリプトはLDAPの更新をAのLDAPサーバーに対してかけ、サーバーBのスクリプトはLDAPの更新をBのLDAPサーバーに対してかけるようになっている。
  • サーバーAのスクリプトもサーバーBのスクリプトも通常はLDAPの更新をAのLDAPサーバーに対してだけかけるようにし、サーバーAが落ちた時はサーバーBのスクリプトが更新先をAからBに切り替えるようになっている。

一般的には後者だろうと思います。ただ前者がNGかというとはっきりわかりませんが。

NASにプライマリーRADIUSサーバーとセカンダリーRADIUSサーバーを設定しているのではないかと思いますが、更新に時間がかかると、両方のRAIUSサーバーにリクエストが飛んでいくと思います。

その場合2台のサーバー上でシェルスクリプトが起動されると思いますが、そのこととOpenLDAPの「相互にレプリケーションする」構成の関係はとても気になります。

プロバイダ(マスタ)が2台いるわけですが、スクリプトの書き方が前者のケースだったとき、同時に2台のプロバイダ(マスタ)に更新をかけたときに好ましくない副作用がおきないかといったことです。

> あと、コマンドだけで実行した場合は再現しません。
> FreeRADIUSのlocal_cpwとの連携も関係してたりしますでしょうか。

とするとシェルスクリプトの書き方が関係するかもしれません。

ldapmodifyの入力は下のようにヒアドキュメントを使って標準入力から食わせているのでしょうか?

```sh
ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 << EOS
dn: uid=ldapuser,ou=People,dc=nodomain
changetype: modify
replace: shadowLastChange
shadowLastChange: 20000
EOS
```

それとも下のようにldifファイルを作ってそれを食わせているのでしょうか?

```sh
echo "dn: uid=ldapuser,ou=People,dc=nodomain" > modify.ldif
echo "changetype: modify"                     >> modify.ldif
echo "replace: shadowLastChange"              >> modify.ldif
echo "shadowLastChange: 20000"                >> modify.ldif
ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 -f modify.ldif
```

> テスト時にうまくいって、今上手くいかない理由としては、更新時のエントリー検索に時間がかかり、
> ldappasswdの処理が完了する前にldapmodifyを実行しているため、ldapへの更新ができてないものかと思ってます。

更新に時間がかかると、NASからRADIUSサーバーに対するリトライが発生しうるので、シェルスクリプトが二重起動されることもあるのではないかと思います。

例えば一つの可能性として、もしldifファイルを作っていて、かつファイル名がユニークでない場合は、タイミングによってはldifファイルが壊れる可能性もあるのではないかと思います。

実際の原因はもう少し情報がないとわかりませんが、とりあえず思いついたのはこんなところですかね。

**追記**
いい忘れてましたが、あともう一つ気になるのはやはりシェルスクリプトの書き方で、下記のどちらなんだろうかということです。

- サーバーAのスクリプトはLDAPの更新をAのLDAPサーバーに対してかけ、サーバーBのスクリプトはLDAPの更新をBのLDAPサーバーに対してかけるようになっている。
- サーバーAのスクリプトもサーバーBのスクリプトも通常はLDAPの更新をAのLDAPサーバーに対してだけかけるようにし、サーバーAが落ちた時はサーバーBのスクリプトが更新先をAからBに切り替えるようになっている。

一般的には後者だろうと思います。ただ前者がNGかというとはっきりわかりませんが。

NASにプライマリーRADIUSサーバーとセカンダリーRADIUSサーバーを設定しているのではないかと思いますが、更新に時間がかかると、両方のRAIUSサーバーにリクエストが飛んでいくと思います。

その場合2台のサーバー上でシェルスクリプトが起動されると思いますが、そのこととOpenLDAPの「相互にレプリケーションする」構成の関係はとても気になります。

プロバイダ(マスタ)が2台いるわけですが、スクリプトの書き方が前者のケースだったとき、同時に2台のプロバイダ(マスタ)に更新をかけたときに好ましくない副作用がおきないかといったことです。

改行追加

760
 ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 -f modify.ldif
 ```
 
-> テスト時にうまくいって、今上手くいかない理由としては、更新時のエントリー検索に時間がかかり、> ldappasswdの処理が完了する前にldapmodifyを実行しているため、ldapへの更新ができてないものかと思ってます。
+> テスト時にうまくいって、今上手くいかない理由としては、更新時のエントリー検索に時間がかかり、
+> ldappasswdの処理が完了する前にldapmodifyを実行しているため、ldapへの更新ができてないものかと思ってます。
 
 更新に時間がかかると、NASからRADIUSサーバーに対するリトライが発生しうるので、シェルスクリプトが二重起動されることもあるのではないかと思います。
 

あと、コマンドだけで実行した場合は再現しません。
FreeRADIUSのlocal_cpwとの連携も関係してたりしますでしょうか。

とするとシェルスクリプトの書き方が関係するかもしれません。

ldapmodifyの入力は下のようにヒアドキュメントを使って標準入力から食わせているのでしょうか?

ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 << EOS
dn: uid=ldapuser,ou=People,dc=nodomain
changetype: modify
replace: shadowLastChange
shadowLastChange: 20000
EOS

それとも下のようにldifファイルを作ってそれを食わせているのでしょうか?

echo "dn: uid=ldapuser,ou=People,dc=nodomain" > modify.ldif
echo "changetype: modify"                     >> modify.ldif
echo "replace: shadowLastChange"              >> modify.ldif
echo "shadowLastChange: 20000"                >> modify.ldif
ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 -f modify.ldif

テスト時にうまくいって、今上手くいかない理由としては、更新時のエントリー検索に時間がかかり、
ldappasswdの処理が完了する前にldapmodifyを実行しているため、ldapへの更新ができてないものかと思ってます。

更新に時間がかかると、NASからRADIUSサーバーに対するリトライが発生しうるので、シェルスクリプトが二重起動されることもあるのではないかと思います。

例えば一つの可能性として、もしldifファイルを作っていて、かつファイル名がユニークでない場合は、タイミングによってはldifファイルが壊れる可能性もあるのではないかと思います。

実際の原因はもう少し情報がないとわかりませんが、とりあえず思いついたのはこんなところですかね。

> あと、コマンドだけで実行した場合は再現しません。
> FreeRADIUSのlocal_cpwとの連携も関係してたりしますでしょうか。

とするとシェルスクリプトの書き方が関係するかもしれません。

ldapmodifyの入力は下のようにヒアドキュメントを使って標準入力から食わせているのでしょうか?

```sh
ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 << EOS
dn: uid=ldapuser,ou=People,dc=nodomain
changetype: modify
replace: shadowLastChange
shadowLastChange: 20000
EOS
```

それとも下のようにldifファイルを作ってそれを食わせているのでしょうか?

```sh
echo "dn: uid=ldapuser,ou=People,dc=nodomain" > modify.ldif
echo "changetype: modify"                     >> modify.ldif
echo "replace: shadowLastChange"              >> modify.ldif
echo "shadowLastChange: 20000"                >> modify.ldif
ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 -f modify.ldif
```

> テスト時にうまくいって、今上手くいかない理由としては、更新時のエントリー検索に時間がかかり、
> ldappasswdの処理が完了する前にldapmodifyを実行しているため、ldapへの更新ができてないものかと思ってます。

更新に時間がかかると、NASからRADIUSサーバーに対するリトライが発生しうるので、シェルスクリプトが二重起動されることもあるのではないかと思います。

例えば一つの可能性として、もしldifファイルを作っていて、かつファイル名がユニークでない場合は、タイミングによってはldifファイルが壊れる可能性もあるのではないかと思います。

実際の原因はもう少し情報がないとわかりませんが、とりあえず思いついたのはこんなところですかね。

回答を投稿

あと、コマンドだけで実行した場合は再現しません。
FreeRADIUSのlocal_cpwとの連携も関係してたりしますでしょうか。

とするとシェルスクリプトの書き方が関係するかもしれません。

ldapmodifyの入力は下のようにヒアドキュメントを使って標準入力から食わせているのでしょうか?

ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 << EOS
dn: uid=ldapuser,ou=People,dc=nodomain
changetype: modify
replace: shadowLastChange
shadowLastChange: 20000
EOS

それとも下のようにldifファイルを作ってそれを食わせているのでしょうか?

echo "dn: uid=ldapuser,ou=People,dc=nodomain" > modify.ldif
echo "changetype: modify"                     >> modify.ldif
echo "replace: shadowLastChange"              >> modify.ldif
echo "shadowLastChange: 20000"                >> modify.ldif
ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 -f modify.ldif

テスト時にうまくいって、今上手くいかない理由としては、更新時のエントリー検索に時間がかかり、> ldappasswdの処理が完了する前にldapmodifyを実行しているため、ldapへの更新ができてないものかと思ってます。

更新に時間がかかると、NASからRADIUSサーバーに対するリトライが発生しうるので、シェルスクリプトが二重起動されることもあるのではないかと思います。

例えば一つの可能性として、もしldifファイルを作っていて、かつファイル名がユニークでない場合は、タイミングによってはldifファイルが壊れる可能性もあるのではないかと思います。

実際の原因はもう少し情報がないとわかりませんが、とりあえず思いついたのはこんなところですかね。

> あと、コマンドだけで実行した場合は再現しません。
> FreeRADIUSのlocal_cpwとの連携も関係してたりしますでしょうか。

とするとシェルスクリプトの書き方が関係するかもしれません。

ldapmodifyの入力は下のようにヒアドキュメントを使って標準入力から食わせているのでしょうか?

```sh
ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 << EOS
dn: uid=ldapuser,ou=People,dc=nodomain
changetype: modify
replace: shadowLastChange
shadowLastChange: 20000
EOS
```

それとも下のようにldifファイルを作ってそれを食わせているのでしょうか?

```sh
echo "dn: uid=ldapuser,ou=People,dc=nodomain" > modify.ldif
echo "changetype: modify"                     >> modify.ldif
echo "replace: shadowLastChange"              >> modify.ldif
echo "shadowLastChange: 20000"                >> modify.ldif
ldapmodify -x -D "uid=ldapuser,ou=People,dc=nodomain" -w password123 -f modify.ldif
```

> テスト時にうまくいって、今上手くいかない理由としては、更新時のエントリー検索に時間がかかり、> ldappasswdの処理が完了する前にldapmodifyを実行しているため、ldapへの更新ができてないものかと思ってます。

更新に時間がかかると、NASからRADIUSサーバーに対するリトライが発生しうるので、シェルスクリプトが二重起動されることもあるのではないかと思います。

例えば一つの可能性として、もしldifファイルを作っていて、かつファイル名がユニークでない場合は、タイミングによってはldifファイルが壊れる可能性もあるのではないかと思います。

実際の原因はもう少し情報がないとわかりませんが、とりあえず思いついたのはこんなところですかね。