before (33374B)
1 Pim での Mattermost 運用 2 3 システム管理チーム 荒木 優和 4 Pim では、Slack が 90 日以上前に送信されたメッセージが閲覧できなくする 5 という発表を受け、異なるチャットシステムを採用することにしました。当時 6 から VC 目的で運用していた Discord への移行や、Zulip という Discord のよう 7 なチャットシステム、Element 及び Matrix という分散型チャットプロトコルへ 8 の移行も考えました。弊部では他社の利用実績及び Docker を使った構築の容 9 易さから、Mattermost を採用することにしました。 10 2022 年 8 月から本格的に移行を開始し、現在、単一サーバで 115 ユーザを 11 収容し、3 年弱で 8 万件近いメッセージがやりとりされています。 12 初期のサーバシステム 13 初期のサーバは、個人宅に設置していました。当時はサーバ運用知識があま 14 りなかった上、他のサーバソフトウェアと共存させており、他のソフトウェア 15 が Load Average や Disk IO を食い尽くしたり、コアスイッチやボーダールータ 16 の再起動をよくしていたため、利用者に不便を強いてしまっていました。部と 17 しても 1 個人の自宅に大量のチャットデータが入っているマシンが存在するこ 18 とは問題であると考え、同年 9 月 9 日に部の保有するサーバへの移行を行い、 19 11 月 21 日に学内への移設作業を行いました。 20 21 導入当時は、島根県内の OCN の個人向け回線を利用し、nginx のリバース 22 プロキシをかませた状態で提供していましたが、学内に設置するに当たり、ポ 23 ート開放ができないため、Cloudflare Tunnel を利用することにしました。最初 24 はアクティブメンバーであった情報科学生の研究室に設置する予定でしたが、 25 情報科では独自のネットワークで DNS と DHCP 以外の UDP トラヒックが外 26 部に出ていかないなどという、すばらしいネットワー 27 クであったため、学内ネットが利用できる活動部屋に 28 設置することになりました。 29 また、構築当初はメールを自宅内のメール送信シス 30 テムを経由させ、Mailjet のようなサービスを利用し通 31 知メールを送信していましたが、1 日で 100 件を超え 32 るメールを送っていたため、Vultr を個人で契約して 33 SMTP サーバを運用していましたが、学内への移設に 34 伴い、当時部員にメールアドレスを付与するために導 35 入していた、さくらのメールボックスから送信するよ 初期のサーバ(右) 36 37 当時の障害報履歴の一部 38 39 TLP:CLEAR 40 TLP:CLEAR 41 42 う に し 、 送 信 元 ア ド レ ス も 「 noreply@chat.<base domain>」 か ら 43 「noreply.chat@<base domain>」 に変更しました。さくらのメールボックスは 44 当 時 DKIM に 対 応 し て お ら ず 、 SPF と 45 DMARC の み を 設 定 し て い た 状 態 で し た 46 が、特にメール不着のクレームなどもなく、 47 スムーズに移行できました。 48 当時の Mattermost 運用は今よりも遙か 49 にずさんでした。学内に移行した後は当時 50 よりまともになりますが、システム管理チ 51 ー ム に 新入 生 を 迎え る ま で 、 こ の 大 味 な 52 2000 年代初期を感じるサーバ運用は続き 53 ます。設置先の部屋の管理担当が勝手にサ 54 ーバを強制終了したりとか。また、当時の 55 管理者は大学からバスで 40 分の場所に住 56 んでいたため、迅速な障害対応ができず、 57 おまけに担当者の所属学部ではない建屋に 58 存在したため、深夜や土日などには対応が 59 できない等の致命的な問題もありました。 60 サーバの監視 61 個人宅に設置していた際は上記のスクリーンショットにあるように Zabbix 62 で監視していました。学内に移行した際にもこのシステムは使い続けており、 63 Zabbix Agent 2 を利用して Docker 監視などを行っていました。この監視では、 64 WireGuard で WebARENA Indigo 上の監視システムと接続し、Zabbix による監 65 視を入れていた他、後に島根の OCN 回線からも Uptime Kuma を利用し、接続 66 性確認とエラー通知を行っていました。その後、Pim 側で管理運用するサーバ 67 として、Grafana Cloud とオンプレの Grafana を同一サーバに設置しました。 68 Grafana Cloud では、サーバ本体の死活監視及びリソース使用率の監視とログ 69 収集を当初行っており、後に Grafana Pyroscope を活用した、Mattermost サー 70 バのプロファイリング情報を確認できるようにしています。2025 年 5 月に実 71 施した Grafana Cloud の利用状況調査では、シリーズ数は約 5,000 件と、無料 72 枠の 1/4 程度利用しており、ログは 2.5 GB 程度消 73 費し、プロファイリングも 13 GB 程度と、100 人 74 越えのインスタンスは Grafana Cloud の無料枠で特 75 に問題なく監視できていました。シスアドチーム 76 は4名ですので、どちらかと言うと、3 ユーザ制 77 限のほうがキツいです。 78 オ ン プ レ の Grafana で は 、 Loki を 使 っ た 79 Mattermost のログ監視を Grafana Cloud と冗長化し 80 ておこなっている他、Mattermost の PostgreSQL に 81 直接接続し、Mattermost 内の統計を取っています。 82 2025 年の後半に部員宅の Uptime Kuma が DB の 83 破損の影響でサービスを終了したため、Phare を 84 導入し、シス管チームが監視システムを直接扱え 85 るようにしたほか、Discord への自動通報機能や、 86 87 自宅内メールサーバの pflogsumm 88 89 Phare のステータス 90 TLP:CLEAR 91 TLP:CLEAR 92 93 *1https://github.com/mkaraki/mattermost-image-compression-plugin 94 シス管チームホームページから監視画面が見られるようになりました。 95 ドメイン変更 96 現在、弊部では「pim.gr.jp」ドメインを利用していますが、当時は異なるド 97 メインを利用していました。企業と連絡を取ることが増えたのと、ドメインレ 98 ピュテーションを少しでも高くする目的で、2023 年 9 月に部で利用するドメ 99 インを完全に変更しました。この影響で、Mattermost で利用しているドメイン 100 も 変 更 と な り ま し た 。 Mattermost の ド メ イ ン 変 更 は 、「 .env」 フ ァ イ ル の 101 「DOMAIN」を変更するだけで完結しましたが、古い Mattermost のメッセー 102 ジリンクが一部 Mattermost 内に存在する影響で、これらのエンドポイントに 103 接続しようとし、失敗するエラーが発生しましたが、「Disable website link 104 previews from these domain」の設定に旧ドメインを設定することで、強引に対 105 処しました。 106 ドメイン変更時には旧 URL でアクセスする部員がいる等のトラブルも起き 107 ましたが、特に大規模な障害もなく移行できました。ただ、予算の問題で古い 108 ドメインは更新していないため、ドロップキャッチ被害が起こる可能性と今後 109 永久に向き合う必要があります。ドメイン取得は本当に覚悟が必要ですね。 110 ちなみに、Pim のサーバ内では、旧ドメインのディレクトリが大量に残った 111 ままになっています。完全に歴史的経緯案件ですね。 112 データ量対策 113 Open Source Conference 2023 Shimane に て、弊部での Mattermost 利用状況に 114 ついて発表しましたが、その際に大量の添付ファイルがやりとりされているこ 115 とに気がつきました。インストール当初はそれこそファイル容量制限をデフォ 116 ルト値にしており、動画などを貼り付けられ、それの対応として Discord と同 117 じ 8 MB 制限を導入して対応していましたが、とはいえ 8 MB も十分重く、主 118 な添付ファイルが画像であることも影響し、多くのストレージを消費する事態 119 となりました。 120 そのため、アップロードされた画像を小さいサービスにリサイズし、WebP 121 のクオリティを限りなく下げた上で保存する Mattermost のプラグインを作成 122 しました。現在、GitHub で公開しています*1。また、当時は WebP のプレビュ 123 ー が で き な か っ た た め 、 WebP プ レ ビ ュ ー を 可 能 に す る パ ッ チ を 作 成 し 、 124 Mattermost 本体にプルリクエストを送りました。元々なぜかモバイル版ではプ 125 レビューができていたため Web 版のみの対応であり、おまけに数行編集する 126 だけで対応できたのが幸いでした。テストコードの方が長かったです。 127 このプラグインはよく働いてくれました。実際の環境では、2/3 もの画像が 128 読み込みエラーで圧縮されないなどという訳の分からない謎バグもありました 129 が、適当に 6 か月分の添付ファイルのサイズ情報を見ますと、未圧縮の JPEG、 130 PNG ファイルは 436 件で 776MiB あるのに対し、圧縮済み WebP ファイルは 131 253 件で 7.2MiB と、作者本人も絶賛する性能です。 132 また、Docker 版の Mattermost では内蔵されている画像処理ライブラリが少 133 なく、これが画像の読み込みに失敗する理由だと考えていますが、現在はこの 134 135 TLP:CLEAR 136 TLP:CLEAR 137 138 *1https://sysadmin.pim.gr.jp/contents/2025/05_mattermost_stats/ 139 140 TLP:CLEAR 141 TLP:CLEAR 142 プラグインはメンテナンスしておらず、後述の理由から今後メンテナンスをす 143 ることもないでしょう。 144 学内でのサーバ引っ越し 145 実は学内でのサーバの場所は 1 度変わっています。元々サーバを設置してい 146 た部屋では、先に記述したように、サーバの電源が第三者に切られていた問題 147 などがあり、はっきり言って安全な環境ではありませんでした。 148 部の顧問をしている教員の所属するセンターでサーバラックを導入したが、 149 そこに空きスペースがあるとのことで、そちらの空きスペースを一部お借りし、 150 弊部のサーバを置かせていただけることになったため、そちらに引っ越しを行 151 いました。ちなみに、前述したドメイン変更もこのタイミングで行っています。 152 また、同時に PostgreSQL のバージョン更新を行いました。特に Mattermost 153 の要求バージョンギリギリになっていた訳ではないですが、当時の最新版であ 154 る Postgres 15 にバックアップ復元訓練をかねる形でアップグレードを行いま 155 した。Postgres はメジャーバージョンが変わると DB に互換性がなくなるため、 156 一度 pg_dump でデータベースをエクスポートした後にまっさらな状態の DB 157 にインポートをしなければならず、バックアップの復元と全く同じ手順が要求 158 されるため、とても有用な訓練になりました。また、作業数日後に PostgreSQL 159 16.0 がリリースされたため、ギリギリのタイミングで少し古い Postgres 系統を 160 採用してしまった形になります。 161 この部屋も学部が違うため、土日や深夜時間での対応はできませんが、移行 162 時にはシス管チームにも優秀な後輩がいたため、平日の昼であれば最悪後輩が 163 代わりに対応をしてもらえるようになりました。また、この後輩はかなり慎重 164 派で、取りあえずバックアップ無しで適当に更新をかける私と違い、適切な手 165 順に従い更新をしてくれるため、重大な問題を発生させることもなく、とても 166 頼りになる存在です。 167 最近の利用状況・リソース情報 168 2025 年 5 月に実施した調査結果が、シス管チームホームページに掲載され 169 ています 170 *1。Mattermost サーバは世代遅れの 6th gen Core i7 サーバで動いてい 171 ますが、CPU 性能は申し分ないです。ごくまれに OOM Killer の おかげで 172 Mattermost が殺されていますので、16 GB メモリだと少し厳しいかもしれませ 173 んが、Docker で運用しているため、Restart Policy で勝手に復旧してくれるの 174 が便利です。もし構築する際は Restart Policy が設定できる Docker か systemd 175 を利用することをおすすめします。 176 過去 4 日間のプロファイルを見る限り、たまにスパイクもありますが、そこ 177 まで大きなものではなく、安定して稼働していると言っても良いでしょう。 178 また、初期の Mattermost サーバは Core i3 + 16 GB RAM で他のサービスと 179 共存させていました。そのため、Mattermost 自体はかなり軽量なソフトウェア 180 と言って良いでしょう。どちらかというとセキュリティソリューションである 181 ClamAV のメモリ使用率のほうが高く、おまけに現システムでは主に歴史的経 182 緯から apt 版の Clamd と Docker 版の Clamd が同時に立ち上がっているため、 183 184 TLP:CLEAR 185 TLP:CLEAR 186 187 平常時よりも多くのメモリを消費しています。 188 ■ClamAV の利活用 189 弊部ではセキュリティソリューションに ClamAV を利用しています。セキュ 190 リティソリューションとして個人的に利用しているのは ESET ですが、さすが 191 に Linux 向け ESET は高額であり、Sophos の無料版もすでに存在しておらず、 192 実質てきに利用できる唯一のソリューションでした。まあ、Cisco Systems の 193 プロダクトではあるので、無いよりは絶対によいだろうというノリで採用して 194 います。マルウェアスキャンは定期実行していますが、特にリアルタイムスキ 195 ャンは行っていません。現状検知されたことも無く、多分侵害は起こっていな 196 いでしょう。 197 また、後述しますが、Mattermost の ClamAV プラグインを利用しているため、 198 悪意のあるユーザや、アカウントの乗っ取り被害に遭ったユーザが WannaCry 199 等をアップロードしようとしても防がれるはずです。多分。 200 実際のシステム構成 201 Mattermost Docker の システム構成は当初からあまり変わっていません。 202 PostgreSQL と Mattermost Community Edition、 そして Watchtower でパッチバー 203 ジョンの自動更新を入れています。Watchtower は containrrr の提供する物を使 204 っていましたが、Docker のバージョンアップのため利用できなくなり、現在 205 は Nick Fedor 氏の Fork 版を利用しています。Mattermost のバージョン指定を 206 マイナーバージョンまでにとどめておきますと、自動で更新されるため、ヒュ 207 ーマンリソースが足りていない弊部ではかなり助かっています。 208 また、2023 年 1 月に ClamAV を同一 Compose にインストールし、ClamAV 209 プラグインからウイルススキャンを掛けられるようにしました。ClamAV はか 210 なりメモリを食いますが、新サーバに切り替わった後でメモリも 16GB あった 211 ため、特に問題なく動いています。試しに EICAR を置いてみたこともありま 212 すが、元気よくブロックしてくれています。 213 オンプレ監視システムとして、Grafana と Loki、Promtail(後に Alloy に移行) 214 を導入しました。Grafana が Postgres に接続できる必要があるため、本来はあ 215 まりよくないのでしょうが、これらも同じ Compose で定義されています。 216 また、Zabbix や Grafana Cloud からの監視用に nginx 217 を導入しています。これらは nginx の stub_status 及 218 び JSON で出力されるログを参照し、Mattermost への 219 接続状況を出力してくれます。こちらの機能に関し 220 ては、弊部で提供しているもうひとつのサービスで 221 ある Redmine にも導入したいと考えているほど有用 222 で、例えば古いバージョンの Mattermost Client が使 223 い続けられている等のセキュリティ上の問題になり 224 得そうな状況の監視も可能です。また、弊部では特 225 に導入していませんが、Crowdsec 等と連携し、悪意 226 のある接続の試行者を IP BAN することもできるでし 227 ょう。 228 サーバのホストには Ubuntu Server を利用しています。最初に導入した際は 229 自宅サーバの Proxmox 上にダイレクトに Docker をインストールするという、 230 ロックな手法で構築していましたが、部のサーバになってからは Ubuntu Server 231 nginx の監視画面 232 233 TLP:CLEAR 234 TLP:CLEAR 235 を利用しています。Docker のホストにある程度高機能で重たい Ubuntu Server 236 を利用している理由として、apt ベースのアプリケーションをインストールし 237 て使う用途があったというのと、Debian と比べ、商用向けにも作られている OS 238 だけあって、Ubuntu では脆弱性が独自のパッチで修正されている場合が多か 239 ったためです。それぞれの脆弱性は Low や Medium 等のあまり気にする必要 240 のないものではありますが、あるよりない方が精神的にも幸せになれますから、 241 こちらを選択しています。 242 とはいえ、最初に Ubuntu を選択した理由は純粋に当時は Debian をあまり 243 使ったことがなかっただけで、その後に Debian と Ubuntu をそれぞれ利用す 244 るようになったのち、Wazuh からの脆弱性アラートの数が大きく異なること 245 に気づいたという時系列が正しいため、最終的にはすばらしい選択ではありま 246 したが、これはただの偶然です。昔から Ubuntu しか使ったことがなかったた 247 め、必然的に Ubuntu Server が選ばれました。 248 また、リリースから 1 年半遅れにはなりましたが、つい最近時間があって暇 249 だったため、部のサーバを Ubuntu Server 24.04 LTS にアップグレードしまし 250 た。do-release-upgrade 君 が勝手にソースを吹っ飛ばしたため、かなり焦りま 251 した。そういう所を見ると Debian Trixie のアップグレードは楽でしたが、さ 252 すがに手軽さがないのと、どうでも良いレベルとはいえ脆弱性のあるパッケー 253 ジが stable のリポジトリにそれなりの数存在するため。弊部で導入することは 254 しばらくはないのかなと思います。Canonical が Ubuntu Server を完全有料化し 255 ないことを祈っています。RedHat のようなことをする会社は 1 社で間に合っ 256 ていますので。もちろん、タダで使わせてもらっている立場ですから甘んじて 257 受け入れますが。 258 また、LDAP の導入は直前まで悩みましたが、結局導入しませんでした。 259 GitLab SSO から LDAP を実質的にプロキシ出来るのですが、そもそも GitLab 260 内部の認証以外が非推奨であるのと、LDAP の管理コストを考えるとさすがに 261 導入を躊躇しました。しかし、現状は Redmine 等の他のサービスもできたこ 262 とから、導入しておけばよかったとも感じています。ただし、後輩の育成項目 263 が増えるため、一長一短ですが。 264 ネットワーク構成 265 学内の LAN を利用しているため、通信は SINET から出る形になります。意 266 味があるかは微妙ですが、上流に FortiGate を設置し、IDS 掛けている他、フ 267 ァイアウォールポリシーにより、起こりえない通信をブロックしています。た 268 だし、FortiGate はもちろん保守や AV パッケージの購入ができる予算はないた 269 め、かなり古いバージョンの FortiOS と IDS 定義で運用しています。学内では 270 LAN 内折り返しが一切制限されておらず、誰かが WannaCry 等に感染した場 271 合、学内有線 LAN 及び Wi-Fi に接続しているかなりの数のホストが危険にさ 272 らされるような構成ではありますが、FortiVPN 等の待ち受けを行っておらず、 273 管理画面も MGMT ポート及びサーバからのみ接続出来るような構成になって 274 いるため、問題は起こりづらい環境であるとは考えています。最近の FortiGate 275 は保守無しで運用していると、勝手にファームウェアアップデートをするとの 276 ことなので、次のシステム更新では、こちらも更新してもよいかもしれません。 277 さすがに FortiGate 100D は骨董品がすぎます。 278 FortiGate とサーバ間は/30 の IPv4 で接続しています。これは、サーバの L2 279 280 TLP:CLEAR 281 TLP:CLEAR 282 ネットワークに侵入者が接続しようとした際に、必ずゲートウェイかサーバの 283 どちらかをオフラインにしなければならないようにし、発見を早めたいという 284 意図と、サーバ間通信を FortiGate のポリシーで管理したいため、横着して同 285 一 L2 につなぐ馬鹿をシス管チームで最もがさつな私が行わないようにするた 286 めです。また、IPv6 に関しては、そもそも学内ネットが対応していないため、 287 弊部では導入していません。 288 過去 1 度起こった問題として、FortiGate の設定値が異常な値になっており、 289 緊急メンテナンスを行う際に、サーバと Cloudflare との接続は問題無かったた 290 め、Cloudflare Tunnel により管理画面へのアクセスを Cloudflare Access 付きで 291 許可し遠隔メンテナンスしたことがあるため、セキュリティレベルが大きく下 292 がりますが、サーバネットワークから管理画面に入れるようにしておくと幸せ 293 になれるかもしれません。もちろん、ベストはコンソールサーバを導入するこ 294 とだとは思います。 295 なんちゃって IaC の導入 296 IaC とは、インフラをコードで掛けるようにする便利技術です。K8s などが 297 有名な IaC を可能にするツールですが、これらは YAML 等で書かれた定義フ 298 ァイル通りにインフラを構築します。そういう意味では Docker Compose も IaC 299 みたいなものですから、最初から IaC は対応しているようなものです。 300 弊部ではより安全な運用のため、Compose ファイルを Git 管理することにし 301 ました。弊部では GitHub に全幅の信頼を置いているため、シークレットを含 302 むファイルを大量に GitHub のプライベートリポジトリにアップロードしてい 303 ます。これにより、更新作業等で失敗が起こった場合でも、git revert を行うだ 304 けで、ミスをなかったことにできます。ただし、データベースが侵害された場 305 合にはどうしようもないですから、もちろん作業前バックアップはこれまで通 306 り行います。 307 なお、Renovate や K8s、ArgoCD 等を導入しようかと思いましたが、LDAP 308 サーバなどとは比べものにならない管理コストが発生するため、ひとりごとチ 309 ャンネルにぼそっと書いた瞬間にシスアドチームメンバーから NG のリアクシ 310 ョンが飛んできました。さすがに K8s はマネジメントコスト高すぎるのでそ 311 れはそうです。GitHub か 312 ら Pull してくる手間が丸 313 々 無く なる ので 、便 利か 314 な と思 いま した が、 さす 315 がに無理です。 316 また、Grafana に存在するダッシュボードを Git 管理する機能なども利用し 317 ています。全体的に Git 連携機能のあるソフトウェアは当該機能をオンにする 318 と大抵使いやすくなるため便利です。 319 サーバのメンテナンス 320 ソフトウェア更新などのサーバメンテナンスは、主に Mattermost の新リリ 321 ースに合わせる形で行っています。弊部では ESR にとどめることはせず、率 322 先して最新版を適用していますので、ほぼ毎月更新作業があります。 323 サーバのシェルには、サーバに接続している KVM か、Cloudflare Tunnel お 324 よび Access を使ったブラウザでのシェル接続を行います。自宅では Teleport 325 326 実際のチャットログ 327 328 TLP:CLEAR 329 TLP:CLEAR 330 等を利用していますが、ログが残らない点以外は Cloudflare Tunnel の SSH ア 331 プリケーションで十分です。エラーログを最悪録画で見れるようにと作業中は 332 画面共有を Teams で行ってほしいと考えチャンネルを作りましたが、こちら 333 は現在運用されていません。さすがに不便すぎるため、使わない理由も分かり 334 ますが。 335 サーバではシス管 1 人 1 人にユーザを払い出しており、Access により認証が 336 通ると、それぞれのアカウントに自動的にログインされるようになります。ま 337 た、Access の認証は Microsoft Entra ID 及び Google Cloud Identity Free を利用し 338 ています。一応 GitHub OAuth も対応させてはいますが、使っている人は見た 339 ことがありません。 340 本来なら各ユーザ毎に実行できるコマンドを厳格に制限したり、history を 341 収集すべきだとは思いますが、さすがに数名でボランティア的に運用している 342 サーバでこれらの設定を行うのは大変で、おまけに運用が無駄に複雑化するた 343 め、これらのセキュリティはほぼ設定されていません。サーバに設定されてい 344 るセキュリティ機能といえば、ClamAV の定期実行と UFW くらいです。 345 また、メンテナンス前には一応マニュアルを作ったり、前述したなんちゃっ 346 て IaC にて複数名で投入するコンフィグをレビューしたりしています。現状、 347 マニュアルにないエラーが出たことはありましたが、操作ミスによるトラブル 348 は発生していません。 349 この運用も後輩が出来てからより安全になっていきました。ワンオペはやは 350 り危険な現場猫運用になりますね。 351 作業マニュアル 352 作業マニュアルは Redmine 及び YouTrack Cloud で管理しています。Redmine 353 は同じサーバで運用されているため、YouTrack Cloud にバックアップのように 354 設置している形です。また、タスク管理は Redmine で行っていますが、口頭 355 でお願いする場面がそれなりにあるため、常に Redmine が正しいという訳で 356 はないというかなり問題のある運用になっています。 357 しかし、Redmine に助けられたケースはかなり多く、過去起こった問題、解 358 決に掛かった時間、問題の原因、投入したコマンド等を事細かに記述していま 359 すから、本来は別で用意すべきではありますが、チケット一覧が簡易的なナレ 360 ッジベースになっています。例えば、2025 年 7 月に起こった Grafana Cloud の 361 Log 保存が 50GB を超えてしまう問題について、Postfix から大量の送信エラー 362 が出ており、原因としては root ユーザによる Cronjob の 送信元アドレスが 363 MAIL_FROM を設定していても Enverope From が root@のままであることに起 364 因する、送信元アドレス不明エラーであり、本来は設定投入時に検証すべき所 365 が検証漏れしていたのか、一度運用で root@のメールアドレスがさくらのメー 366 ルボックスから消されたかのどちらかが原因かと思われますが、これについて、 367 実際の変更した設定値とその意味について書いているため、もし誰かが間違え 368 て root@のメールアドレスを吹き飛ばしても、過去のチケットから原因究明出 369 来るはずです。 370 また、初期の頃は作業マニュアルは Word 製のコピペがまともに出来ない恐 371 ろしいマニュアルでしたが、Redmine 導入後には Markdown になり、コピペし 372 やすくなりました。その代わり、これまでマニュアルにあった、警告色で重要 373 な箇所をマークする等のアノテーションが効かなくなったのですが、今のとこ 374 375 TLP:CLEAR 376 TLP:CLEAR 377 378 ろ問題は起こっていません。 379 もし許可が下りれば、過去利用していた Mattermost 更新資料を添付しよう 380 と思います。 381 さらば、Mattermost 382 Mattermost は と て も よ い ソ リ ュ ー シ ョ ン で す 。 弊 部 で 適 当 に 聞 い て も 、 383 Mattermost に対する不満は、よくあるアプリとは別で Mattermost とか言う聞 384 きなじみのない謎のアメリカ産アプリをインストールしなければならないだっ 385 たり、ID 管理が追加で必要というものですが、少なくとも一般の平均的な学 386 生にして見れば Slack だって同じなわけです。 387 少なくとも、弊学では Slack を使う授業は存在するものの、圧倒的に少数で、 388 大体は Moodle 及び Teams で相互にやりとりを行い、Slack などというものを 389 知らずに卒業する人がほとんどでしょう。 390 弊部で Mattermost を運用停止する理由はただ一つで、先日のポリシー変更 391 に よ り 、 250 名 を 超 え る テ ナ ン ト で 利 用 で き な く な っ た か ら で す 。 元 々 392 Mattermost には 1,000 ユーザまでの制限がありました。実はこれすら知らなか 393 ったのですが、さすがに 250 人に行くまでは簡単に道筋が浮かんでしまいます。 394 そして、Mattermost から移行をするのであれば、DB や API が大きく変わら 395 ないうちに移行をしなければなりません。現在であれば Mattermost からの移 396 行スクリプトはいくらでもありますが、これが Mattermost 11 になった後や、 397 それ以降のマイナーバージョンアップで利用し続けられる保証がないため、当 398 該プレス公開後、すぐに対策を考え、今年度末に Matrix ベースのチャットシ 399 ステムに移行することにしました。つまり、最初から Element + Synapse の構 400 成に移行すればよかったわけです。導入コストの高さから採用を見送ったこと 401 を軽く恨みたくなります。Slack からの移行と異なり、Mattermost から Synapse 402 の移行は、プライベートチャンネルでも、かなり頑張れば移行できそうである 403 ため、既存のチャットログを捨てなくてもよいのが救いです。最悪移行できな 404 くても、データベースに元データがあるため、これらのチャットログは HTML 405 等にダンプできます。何とすばらしいことでしょう。 406 もしまた部誌を書く機会があれば、「Synapse 導入から n か月、現状の様子 407 報 告 」 の よ う な タ イ ト ル に な る でし ょ う 。「 Synapse に は 勝 てな か っ たよ 。 408 Mattermost 君これからもよろしくね」というタイトルにはならない、はず。 409 また、GitLab SSO も今回終了するらしく、最悪延命することになった時に、 410 GitLab SSO が足を引っ張らなくてよかったと思っております。ちなみに、自 411 宅で導入していた家族向けチャットは GitLab SSO を利用して自宅内 Active 412 Directory および Entra ID と連携していたため、今回の件で 90 日以上前のメッ 413 セージにアクセス出来ないことを伝え、Mattermost から Slack に移行しました。 414 元々 Slack を使っていた時期はあったので、最初からそのままにしておけばよ 415 かったと深く後悔しております。もともと自宅は実験的な環境としてつくって 416 いたこともあり、障害発生時に家族からの連絡が来ない問題もあったため、ち 417 ょうどよかったと思うことにします。家族内では、某総務省案件常連のチャッ 418 トサービスを利用していないため、おそらくこの方法が最も便利で確実かつ安 419 心だと考えています。Salesforce がさらなる Slack の改悪を行わなければですが。