after (33301B)
1 弊部での 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 内折り返しが一切制限されておらず、誰でも当該ルータにパケットを 271 投げることができるような状態ですが、FortiVPN 等の待ち受けを行っておら 272 ず、管理画面も MGMT ポート及びサーバからのみ接続出来るような構成にな 273 っ て い る た め 、 問 題 は 起 こ り づ ら い 環 境 で あ る と 考 え て い ま す 。 最 近 の 274 FortiGate は保守無しで運用していると、勝手にファームウェアアップデート 275 をするとのことなので、次のシステム更新では、こちらも更新してもよいかも 276 しれません。さすがに FortiGate 100D は骨董品がすぎます。 277 FortiGate とサーバ間は/30 の IPv4 で接続しています。これは、サーバの L2 278 ネットワークに侵入者が接続しようとした際に、必ずゲートウェイかサーバの 279 280 TLP:CLEAR 281 TLP:CLEAR 282 どちらかをオフラインにしなければならないようにし、発見を早めたいという 283 意図と、サーバ間通信を FortiGate のポリシーで管理したいため、横着して同 284 一 L2 につなぐ馬鹿をシス管チームで最もがさつな私が行わないようにするた 285 めです。また、IPv6 に関しては、そもそも学内ネットが対応していないため、 286 弊部では導入していません。 287 過去 1 度起こった問題として、FortiGate の設定値が異常な値になっており、 288 緊急メンテナンスを行う際に、サーバと Cloudflare との接続は問題無かったた 289 め、Cloudflare Tunnel により管理画面へのアクセスを Cloudflare Access 付きで 290 許可し、遠隔メンテナンスしたことがあります。セキュリティレベルが大きく 291 下がりますが、サーバネットワークから管理画面に入れるようにしておくと幸 292 せになれるかもしれません。もちろん、ベストはコンソールサーバを導入する 293 ことだとは思います。 294 なんちゃって IaC の導入 295 IaC とは、インフラをコードで掛けるようにする便利技術です。K8s などが 296 有名な IaC を可能にするツールですが、これらは YAML 等で書かれた定義フ 297 ァイル通りにインフラを構築します。そういう意味では Docker Compose も IaC 298 みたいなものですから、最初から IaC は対応しているようなものです。 299 弊部ではより安全な運用のため、Compose ファイルを Git 管理することにし 300 ました。弊部では GitHub に全幅の信頼を置いているため、シークレットを含 301 むファイルを大量に GitHub のプライベートリポジトリにアップロードしてい 302 ます。これにより、更新作業等で失敗が起こった場合でも、git revert を行うだ 303 けで、ミスをなかったことにできます。ただし、データベースが侵害された場 304 合にはどうしようもないですから、もちろん作業前バックアップはこれまで通 305 り行います。 306 なお、Renovate や K8s、ArgoCD 等を導入しようかと思いましたが、LDAP 307 サーバなどとは比べものにならない管理コストが発生するため、ひとりごとチ 308 ャンネルにぼそっと書いた瞬間にシスアドチームメンバーから NG のリアクシ 309 ョンが飛んできました。さすがに K8s はマネジメントコスト高すぎるのでそ 310 れはそうです。GitHub か 311 ら Pull してくる手間が丸 312 々 無く なる ので 、便 利か 313 な と思 いま した が、 さす 314 がに無理です。 315 また、Grafana に存在するダッシュボードを Git 管理する機能なども利用し 316 ています。全体的に Git 連携機能のあるソフトウェアは当該機能をオンにする 317 と大抵使いやすくなるため便利です。 318 サーバのメンテナンス 319 ソフトウェア更新などのサーバメンテナンスは、主に Mattermost の新リリ 320 ースに合わせる形で行っています。弊部では ESR にとどめることはせず、率 321 先して最新版を適用していますので、ほぼ毎月更新作業があります。 322 サーバのシェルには、サーバに接続している KVM か、Cloudflare Tunnel お 323 よび Access を使ったブラウザでのシェル接続を行います。自宅では Teleport 324 等を利用していますが、ログが残らない点以外は Cloudflare Tunnel の SSH ア 325 326 実際のチャットログ 327 328 TLP:CLEAR 329 TLP:CLEAR 330 プリケーションで十分です。エラーログを最悪録画で見れるようにと作業中は 331 画面共有を Teams で行ってほしいと考えチャンネルを作りましたが、こちら 332 は現在運用されていません。さすがに不便すぎるため、使わない理由も分かり 333 ますが。 334 サーバではシス管 1 人 1 人にユーザを払い出しており、Access により認証が 335 通ると、それぞれのアカウントに自動的にログインされるようになります。ま 336 た、Access の認証は Microsoft Entra ID 及び Google Cloud Identity Free を利用し 337 ています。一応 GitHub OAuth も対応させてはいますが、使っている人は見た 338 ことがありません。 339 本来なら各ユーザ毎に実行できるコマンドを厳格に制限したり、history を 340 収集すべきだとは思いますが、さすがに数名でボランティア的に運用している 341 サーバでこれらの設定を行うのは大変で、おまけに運用が無駄に複雑化するた 342 め、これらのセキュリティはほぼ設定されていません。サーバに設定されてい 343 るセキュリティ機能といえば、ClamAV の定期実行と UFW くらいです。 344 また、メンテナンス前には一応マニュアルを作ったり、前述したなんちゃっ 345 て IaC にて複数名で投入するコンフィグをレビューしたりしています。現状、 346 マニュアルにないエラーが出たことはありましたが、操作ミスによるトラブル 347 は発生していません。 348 この運用も後輩が出来てからより安全になっていきました。ワンオペはやは 349 り危険な現場猫運用になりますね。 350 作業マニュアル 351 作業マニュアルは Redmine 及び YouTrack Cloud で管理しています。Redmine 352 は同じサーバで運用されているため、YouTrack Cloud にバックアップのように 353 設置している形です。また、タスク管理は Redmine で行っていますが、口頭 354 でお願いする場面がそれなりにあるため、常に Redmine が正しいという訳で 355 はないというかなり問題のある運用になっています。 356 しかし、Redmine に助けられたケースはかなり多く、過去起こった問題、解 357 決に掛かった時間、問題の原因、投入したコマンド等を事細かに記述していま 358 すから、本来は別で用意すべきではありますが、チケット一覧が簡易的なナレ 359 ッジベースになっています。例えば、2025 年 7 月に起こった Grafana Cloud の 360 Log 保存が 50GB を超えてしまう問題について、Postfix から大量の送信エラー 361 が出ており、原因としては root ユーザによる Cronjob の 送信元アドレスが 362 MAIL_FROM を設定していても Enverope From が root@のままであることに起 363 因する、送信元アドレス不明エラーであり、本来は設定投入時に検証すべき所 364 が検証漏れしていたのか、一度運用で root@のメールアドレスがさくらのメー 365 ルボックスから消されたかのどちらかが原因かと思われますが、これについて、 366 実際の変更した設定値とその意味について書いているため、もし誰かが間違え 367 て root@のメールアドレスを吹き飛ばしても、過去のチケットから原因究明出 368 来るはずです。 369 また、初期の頃は作業マニュアルは Word 製のコピペがまともに出来ない恐 370 ろしいマニュアルでしたが、Redmine 導入後には Markdown になり、コピペし 371 やすくなりました。その代わり、これまでマニュアルにあった、警告色で重要 372 な箇所をマークする等のアノテーションが効かなくなったのですが、今のとこ 373 ろ問題は起こっていません。 374 375 TLP:CLEAR 376 TLP:CLEAR 377 もし許可が下りれば、過去利用していた Mattermost 更新資料を添付しよう 378 と思います。 379 さらば、Mattermost 380 Mattermost は と て も よ い ソ リ ュ ー シ ョ ン で す 。 弊 部 で 適 当 に 聞 い て も 、 381 Mattermost に対する不満は、よくあるアプリとは別で Mattermost とか言う聞 382 きなじみのない謎のアメリカ産アプリをインストールしなければならないだっ 383 たり、ID 管理が追加で必要というものですが、少なくとも一般の平均的な学 384 生にして見れば Slack だって同じなわけです。 385 少なくとも、弊学では Slack を使う授業は存在するものの、圧倒的に少数で、 386 大体は Moodle 及び Teams で相互にやりとりを行い、Slack などというものを 387 知らずに卒業する人がほとんどでしょう。 388 弊部で Mattermost を運用停止する理由はただ一つで、先日のポリシー変更 389 に よ り 、 250 名 を 超 え る テ ナ ン ト で 利 用 で き な く な っ た か ら で す 。 元 々 390 Mattermost には 1,000 ユーザまでの制限がありました。実はこれすら知らなか 391 ったのですが、さすがに 250 人に行くまでは簡単に道筋が浮かんでしまいます。 392 そして、Mattermost から移行をするのであれば、DB や API が大きく変わら 393 ないうちに移行をしなければなりません。現在であれば Mattermost からの移 394 行スクリプトはいくらでもありますが、これが Mattermost 11 になった後や、 395 それ以降のマイナーバージョンアップで利用し続けられる保証がないため、当 396 該プレス公開後、すぐに対策を考え、今年度末に Matrix ベースのチャットシ 397 ステムに移行することにしました。つまり、最初から Element + Synapse の構 398 成に移行すればよかったわけです。導入コストの高さから採用を見送ったこと 399 を軽く恨みたくなります。Slack からの移行と異なり、Mattermost から Synapse 400 の移行は、プライベートチャンネルでも、かなり頑張れば移行できそうである 401 ため、既存のチャットログを捨てなくてもよいのが救いです。最悪移行できな 402 くても、データベースに元データがあるため、これらのチャットログは HTML 403 等にダンプできます。何とすばらしいことでしょう。 404 もしまた部誌を書く機会があれば、「Synapse 導入から n か月、現状の様子 405 報 告 」 の よ う な タ イ ト ル に な る でし ょ う 。「 Synapse に は 勝 てな か っ たよ 。 406 Mattermost 君これからもよろしくね」というタイトルにはならない、はず。 407 また、GitLab SSO も今回終了するらしく、最悪延命することになった時に、 408 GitLab SSO が足を引っ張らなくてよかったと思っております。ちなみに、自 409 宅で導入していた家族向けチャットは GitLab SSO を利用して自宅内 Active 410 Directory および Entra ID と連携していたため、今回の件で 90 日以上前のメッ 411 セージにアクセス出来ないことを伝え、Mattermost から Slack に移行しました。 412 元々 Slack を使っていた時期はあったので、最初からそのままにしておけばよ 413 かったと深く後悔しております。もともと自宅は実験的な環境としてつくって 414 いたこともあり、障害発生時に家族からの連絡が来ない問題もあったため、ち 415 ょうどよかったと思うことにします。家族内では、某総務省案件常連のチャッ 416 トサービスを利用していないため、おそらくこの方法が最も便利で確実かつ安 417 心だと考えています。Salesforce がさらなる Slack の改悪を行わなければですが。