OpenLDAPのslapd.d形式の設定ディレクトリへエントリを追加する ― 2017/04/06

初回構築で、slaptestを用いてslapd.confからslapd.dを生成する手順は山ほど検索にひっかかるけど、その後の修正については公式ドキュメントぐらいしか見当たらなかったので明日の自分のためのメモ。 既存の設定内容の変更は ldapvi を使うと良い。

やりたかったこと

初回起動時にmonitor databaseを上げていなかったのでこれを追加したい。 ldifを一から手書きしたくない

手順

とりあえず、初回構築に使用したslapd.confに必要な記述を追加する。 

# echo 'database monitor' >> slapd.conf

slaptestでslapd.dの形式に変換する。稼働しているディレクトリに重ねないようディレクトリ名は変更する。 

# slaptest -f slapd.conf -F test.d

先程追加した行に対応するldifファイルを探す。 今回の場合だと 

test.d/cn=config/olcDatabase={2}monitor.ldif

だった。

こいつを適当な場所にコピーして編集 

test.d/cn=config/olcDatabase={2}monitor.ldif
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 9dea67ca
dn: olcDatabase={2}monitor
objectClass: olcDatabaseConfig
olcDatabase: {2}monitor
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: 42048058-aece-1036-8a7a-a1cdfe3cc878
creatorsName: cn=config
createTimestamp: 20170406043551Z
entryCSN: 20170406043551.138208Z#000000#001#000000
modifiersName: cn=config
modifyTimestamp: 20170406043551Z

monitor.ldif
dn: olcDatabase=monitor,cn=config
objectClass: olcDatabaseConfig
olcDatabase: monitor
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
  • {2}は挿入される際に採番される連番なので削除する。
  • dnはちゃんとcn=configから全部書く
  • structuralObjectClass以降の行は管理情報なので挿入時のldifには必要ない

できたファイルをldapaddで挿入する。 

# ldapadd -x -W -D "cn=admin,cn=config" -f /etc/openldap/monitor.ldif

over.

by ひーくん [UNIX] [コメント(0)｜トラックバック(0)]

Phusion Passengerのログローテート設定 ― 2017/04/12

logrotateでファイルがmvされてもPassengerは以前のファイルを掴んだままなので、これを手放させる必要がある。 方針は2つ？

logrotateをcopytruncateモードで動かす。

  • 旧ログをmvではなくcpした上で旧ログの内容をクリアする。
  • 処理時間がかかるのでログの取り零しが発生しうる。 
# /etc/logrotate.d/passenger.log
/path/to/app/shared/log/*log {
  weekly
  missingok
  rotate 1000
  create 0644 user group
  copytruncate
  dateext
}

logrotateのpostrotateでPassengerにアプリを再読み込みさせる。

  • ログの取り零しは発生しない。
  • 次回のアクセス時にRailsの起動コストがかかる。 
# /etc/logrotate.d/passenger.log
/path/to/app/shared/log/*log {
  weekly
  missingok
  rotate 1000
  create 0644 user group
  dateext
  sharedscripts
  postrotate
    touch /path/to/app/current/tmp/restart.txt
  endscript
}

うちは緩いサービスなのでcopytruncateで良いけど、copytruncateで取り零しが発生するようなサービスだと、Railsの起動コストはもっと耐えられないような気がするけど……。

by ひーくん [Rails] [コメント(0)｜トラックバック(0)]