DigiLoog

フィルタリングを集中管理する為に便利なので、sieveプラグインを利用しているが、
sieveプラグインを同梱している”dovecot-pigeonhole”のパッケージがCentOS8に無く、
ネットの海を右往左往したのでその備忘録。

原因は、RHEL8.0をリリースする際にdovecot-pigeonholeパッケージが削除された影響。
CentOS8はRHEL8を元にリビルドしている都合上、
大元となるRHEL8.0に含まれていないパッケージは含まない傾向がある。

ただ、至る所からブーイングが出たのか、
Red Hat Bugzillaで『次期RHEL8には”dovecot-pigeonhole”を含める』とアナウンスがあった。
実際、MBOX Kojiにもdovecot-pigeonholeパッケージが準備されている事を確認。
ただし、何かしらの理由があるのか、まだ403の状態になっていた。

という事で更に調査を進めると、独自ビルドした謎RPMを配布していたり、
自力でビルドしてdovecotと連携させる回避策が出てきた。

今回、メール鯖を刷新するにあたりdovecotが使えないのは致命的過ぎるので、
筆者はdovecot含めて全部独自ビルドする事に。
日頃からソースビルドは良く実行しているので特に苦も無く起動までこぎ着ける事が出来た。
ビルドオプションは次の通り。他にはsystemd.serviceファイルも作成したが、
全部書くとそれなりの量になるので、サーバ刷新が一段落したタイミングで書こうと思う。

◇dovecot ./configure –prefix=/usr/local/dovecot \ –with-pam –with-ldap=yes –with-mysql \ –with-lz4 –with-libcap –with-zlib \ –with-bzlib –with-lzma make && make install ◇Pigeonhole ./configure –prefix=/usr/local/dovecot \ –with-dovecot=/usr/local/dovecot/lib/dovecot \ –with-ldap=plugin make && make install

これで、残るは起動テストのクリアとメールデータの移行＆切り替えになる。
残る作業が一番の山場なので、自鯖と言えども丁寧に切り替えを実施したい。

DB用ロードバランサにhaproxyを使うかmaxscaleを使うか最後まで迷ったが、
今回はmaxscaleを採用する事に。
決め手になったのは、レプリケーション構成を取っている時に自動昇格などが出来る点。
とは言っても、haproxyを長く使っている事もあり慣れているので、
他の使い方が出来ないかテストも継続中。

maxscaleを使う上でキモになるのはVirtual IPによる冗長化だが、
今回からデュアルスタック化する予定なので、如何にコンフィグを短くするかに四苦八苦中。
恐らく、vrrp_sync_groupを用いてヘルスチェック指定をまとめるの方法で行けそうだが、
新自鯖のコアになるサーバ・機能なので入念にチェックし、
情報が纏まったらそのうちブログに載せたい。…はよ、構築を進めねば

現行の自鯖機ではそれぞれのサーバ毎にDBを構築しているが、
今回の自鯖刷新を機にDBの集約化と構成変更も計る事にした。

パターンは色々あるが、今テストを行っているのは下記の通り

1. MariaDB + Replication + mysqlfailover
2. MariaDB + Replication + MaxScale
3. MariaDB Galera Cluster + Galera Arbitrator

現行維持で行くならば、レプリケーションを元にした構成になるが、
Galera Clusterを元にした構成も技術的に面白いので調査中。

ただし、クラスタ構成は3台以上の奇数構成を取らないと安定しない為、
“ns-lab BB”のサーバ構成になっているActive/Standbyとすると台数が足りなくなる。
その為、Arbitratorを何処かに構築して疑似的に奇数台数にする手があるのだが、
Arbitratorを使った構成例が極端に少なかったり、
そもそもドキュメントもお粗末な状況なので踏み切っていい物か手探り状態だったりする。

その為、MaxScaleを使った疑似リバプロ構成もテスト中。
久々に構成を大きく変更する事もあり、技術調査をしながら構築している為、
構成変更をブログに書くのは1ヶ月以上先になりそうだが何時か纏めようと思う。