2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable
1
複数Redmine環境における
ユーザ管理作業の効率化
2020/11/14
redmine.tokyo 第19回勉強会
@y503unavailable

2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable
2
自己紹介
• 名前：奈良 裕記 ( y503unavailable <- httpエラーコード503)
– 製造業で開発部署のadminしてます。
• RedmineTokyoスタッフ
unofficialcooking カスタマイズ情報サイト担当
– https://redmine.tokyo/projects/unofficialcooking
• Kindle本やYoutube動画も作成、unofficial-redmine.org
– https://www.slideshare.net/y503unavailable/unofficial-redmine-japan2020
• ６年前にRedmineサーバ統合を実施
(この時のDB構造知見が今回役に立った)
– https://www.slideshare.net/y503unavailable/redmine-42182169

2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable
3
お断りと連絡先
• 本LTの内容はPoC段階であり無保証です。（普段よりも）
• 実施時は自己責任でお願いします。
ご意見・ご提案などは
Redmine.Tokyoのunofficialcookingまでお願いします。
https://redmine.tokyo/issues/1188
画面デモなど希望あれば、ユーザディスカッションの＃１か懇
親会で声掛けてください。

2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable
4
Redmineは1台で足りますか？
• 大規模運用で数百人/複数部署/複数用途で利用する場合、
1台のRedmine内に無理やり押し込んで運用するより、
複数のRedmineサーバに分割する方が運用し易い。
– 1台のRedmineの中でシステムレベル設定項目の使い分けは困
難。ユーザ間調整も面倒。
– Redmineの利用状況、利用者間の関係、admin間の関係、現場
差異、現場モチベーション
–無理に統合 ＜＜ 分割＋統合管理仕組

2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable
5
Redmineの設定項目分類
区分 設定者 内容
システム単位の設定 Redmine管理者 トラッカー、ロール、ワークフロー、ステータス、カ
スタムフィールド定義、用語定義、ユーザグループ定
義、その他システムレベル設定
Project単位の設定 ＰJ管理者 プロジェクト階層毎設定、バージョン、カテゴリ、メ
ンバー
ユーザ設定 各ユーザ 名前、パスワード、管理者権限、言語設定など
システム単位の設定項目は、Redmine管理者のみが設定できる。
つまり、サーバの統合により、Redmine管理者の権限が無くなると、従来
行えていたシステムレベルの管理作業が行えなくなる。
（本表の対象は設定項目のみ、チケット/変更記録/活動は除外した。）

2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable
6
複数Redmine運用時の課題と改善案
• 単に複数Redmineを運用するだけなら苦労しない。
• しかしRedmine間で内容を連携し活用、組織単位などで集計したい場合、
運用負荷がｎ倍になる。
• 課題例
– 人事異動対応/各サーバ毎実行必要（人事異動/新人/退職）
– 組織/ユーザ単位の利用状況集計作業が面倒
（ユーザＩＤ/組織グループがサーバ毎に異なるため、余計な変換作業が発生）
• 改善案
– サーバ間でユーザとグループの定義内容の同一性を確保する。
– 変更内容を自動反映する（名前、パスワード変更、無効化、所属変更)
– Redmine自体の機能で実現する必然性は無い。データはDB上だからDBの機能で実現すれば良い。

2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable
7
実現手法
下記手順により対応した（DBのテーブル単位複製）
1. Redmineをprimary/secondary(複数可)に分ける。
2. ユーザ/グループ定義の変更作業はprimaryのRedmineでのみ実施
（各個人またはシステム管理者の設定）
3. secondary側は、ユーザIDを追加不可の設定にする。
管理/設定/認証/ユーザーによるアカウント登録-無効
4. DBのテーブル単位複製機能を利用
– primary上のユーザ定義/グループ定義情報の変更のみを、secondaryに複製する。（DB設定）
– （usersと users-groupsテーブル)
– secondary側のreadonly指定は実施しない
primary
secondary
users,users-groupsのみ複製

2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable
8
一応動いた
・動作確認内容
ユーザ/グループ定義が正しく反映されることを確認した
1. primary側のユーザ名を変更、secondary側を再表示し反映済確認
2. secondary側ユーザ名を変更、primary側を再表示し反映無確認
3. primary側ユーザ名を再度変更、secondary側を再表示し反映済確認
4. primary側グループ登録内容を変更、 secondary側を再表示し反映済確認
• 試行環境
– CentOS7,MariaDB10,Redmine4.1-trunk(unofficial-redmine版)
– DB設定手順は本資料末尾の参考資料を参照
users,users-groupsのみ複製
primary
secondary

2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable
9
ご利益と落とし穴
• 本設定による利点
– Redmineのユーザ/グループ定義作業箇所を一か所に集約した。
（人事異動対応作業効率化）
– Redmineサーバ間のデータ分析、連携が容易になった。
• 問題点と対応
– 単にDBで設定内容を一元管理しただけなので、
問題点(+対策案)は勿論ある。 (次頁以降)
users,users-groupsのみ複製

2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable
10
問題点と対策1
primaryへのログイン時、secondaryの最終ログイ
ン日時が変更される。ユーザ使用状況把握困難
対策
・primary側のソースを変更し更新させない
– models/user.rb: def update_last_login_on!
パスワード/名前変更時には変更されてしまうが、
大規模環境ならAD利用で直接変更しないのでは？
原因 users.last_login_on (最終ログイン日時)も複製されるため

2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable
11
問題点と対策2
各secondaryのみのシステム管理者権限を設定できない
secondary管理者へのprimary管理者権限設定は不可
対策案(未検証)
• secondary内でDBのレプリケーショントリガーを利用し、
usersテーブル更新時に、特定IDにadminを強制設定する
• 定期的にsqlでupdateする。（頻繁な変更は無い筈）
システム管理者権限のフラグは、users.adminであり、
primaryの内容が当然複製される。

2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable
12
問題点と対策3
secondary側で、ユーザ情報・グループ定義情報の
変更/追加/削除操作が可能だが
primary側更新で,ユーザ情報上書/グループ定義破損する。
対策
 運用で対処（危険)
 secondary側のソース変更し更新操作させない
 Viewcustomizeでメニューから項目削除
 特定ユーザに対して一部管理者メニューを非表示にする
 https://github.com/onozaty/redmine-view-customize-scripts/blob/master/hide_part_of_admin_menu.js
原因 グループ定義は、グループ定義中ユーザ単位のレコードのため

2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable
13
問題点と対策4
他にも問題点あるかもしれない(未検証)
二要素認証のusers.twofa_totp_last_used_at など心配
各環境で検証お願いします。本LTはPoC段階の提案です。
原因 usersテーブル内に、定義情報とサー
バ内動的情報が同居している以上不可避

2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable
14
追加対応1
特定グループ定義の編集権限のみ移譲したい
– 一部のグループ定義が、頻繁に変更される。
(特定secondaryのみ利用)
– SEC＆作業負荷面から、当該グループ定義の変更権限
のみをsecondary管理者に委譲したい。
対策
– 下記手法で外部の専用コマンドを作成する。
（特定グループIDのみ変更可能にする）
– 【Redmine】Python で Redmine CLI ツールを作ってみる！
https://mlog.wlaboratory.com/entry/category/tools/redmine/python-redmine-cli

2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable
15
追加対応2
ユーザ・グループ定義以外の、
他のシステムレベル定義項目も共通化したい
参考資料（DB設計)
• RedmineのDB設計参考資料(サーバ統合事例）https://www.slideshare.net/y503unavailable/redmine-42182169
• Redmineデータベースのテーブル構造を紐解いてみるhttps://docs.google.com/presentation/d/e/2PACX-
1vSGC3DEnLZqAEs4zRmkCsrEz4m3Uj0qo0fiMHi2JexyVYUdV6wjoUftoIhhVTc1C-
r_6lJDDOBuafvu/pub?start=false&loop=false&delayms=3000&slide=id.p
対策
システムレベル項目の各テーブルも、テーブル単位で複製すれば良い。
（トラッカー,ステータス,ロール,ワークフロー,カスタムフィールド）
trackers, issue_statuses , roles,roles_managed_roles, workflows,
custom_fields,custom_fields_roles,custom_fields_trackers,

2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable
16
参考文献（DB複製関連)
具体的なDB設定手順は、下記など参照してください。
• [MySQL][MariaDB] DBのレプリケーション構築手順
– https://qiita.com/suzutsuki0220/items/e5be03ea8f44ad2f6533
• Replication Filters
– https://mariadb.com/kb/en/replication-filters/
• スレーブのレプリケーションフィルターについて
– https://gihyo.jp/dev/serial/01/mysql-road-construction-news/0088
• mariadbのスレーブトリガーを試してみる。(slave_run_triggers)
– https://qiita.com/sand_bash/items/b6169757e7d32df88467
• postgresql-10以降でテーブル単位の複製が可能（ロジカルレプリケーション）
– https://oss-db.jp/dojo/dojo_column_01
• 論理レプリケーション
– https://www.postgresql.jp/document/11/html/logical-replication.html
今回の/etc/my.cnf 追加内容（参考）
複製元Redmine
[mysqld]
log-bin
server-id=1
expire_logs_days=5
replicate-do-table=redmine.user
replicate-do-table=redmine.groups_users
複製先Redmine
[mysqld]
server-id=2
replicate-do-table=redmine.users
replicate-do-table=redmine.groups_users
接続状況確認
show slave status;
show master status;

2020/11/14 第19回redmine.tokyo 勉強会 複数Redmine環境におけるユーザ管理作業の効率化 @y503unavailable
17
御清聴ありがとうございました
• 各自のRedmine運用に、多少なりとも役に立て
ば幸いです。
• Redmineはオープンソースソフトです。
–協力して育成＆利用していきましょう。
ユーザ会はそのための場所です。
• ご意見、内容指摘の連絡先
redmine.Tokyo UnofficialCooking
unofficial-redmine.org
y503unavailable@ twitter, slack