2021年11月28日(日) - 19:25 | カテゴリ:
Linux
CentOS 8のサポートが2021年末で終了すると発表され紆余曲折あったLinux界隈。
筆者も自宅サーバでCentOS 8を利用しているので、年末迄に方針を固める必要があった。
色々な環境を動かしているので、CentOS Streamが適切な検証環境もあったり、
Web・DNS・Mail・DBと安定稼働させたい本番系があるのも事実だった。
当初は全台をCentOS Streamに移行予定だったのだが、
以前試した時に謎の挙動をしたので、本番系は他のディストリビューションへ移行する事に。
AlmaLinuxとRockyLinuxの二つが候補となったが今回はRockyLinuxを採用する事にした。
という事で、RockyLinuxを選んだ経緯とアップグレードした結果を書こうと思う。
RockyLinuxへツールで引っ越したサーバのバージョンがこちら。標記もRockyに変わっていた。
移行には公式が準備しているツールを利用した。
そのままのコマンドだが、筆者が撃ち込んだ実際のコマンドは次の通り。
# curl https://raw.githubusercontent.com/rocky-linux/ \
rocky-tools/main/migrate2rocky/migrate2rocky.sh -o migrate2rocky.sh
# chmod u+x migrate2rocky.sh
# ./migrate2rocky.sh -r
# reboot
|
CentOS・AlmaLinux・RockyLinuxはRHEL 8と互換性があるので、
結果として3つのディストリビューションも相互に互換性がある。
そんな中で移行ツールも各ディストリビューションで公開されており、
万が一、開発停止になっても別の物に移行出来るのもRockyLinuxを選んだ理由となる。
ちなみに、OracleLinuxはJavaサポート切れとSolarisの恨みがあるのと、
MiracleLinuxは原資がコロコロ変わっている印象があり、不安要素が大きかったので没にした。
他の選定理由はCentOSと同じ構築体制を取っているのかあたりだが、
決定打はソフトウェアのアップグレードは比較的簡単だけどダウングレードは困難である点だった。
後ろ向きな意見となるが、殆どの場合でダウングレードは面倒臭いのが常なので、
万が一の時に移行先へアップグレードで引っ越し出来るかが重要になりそうと踏んだ。
RockyLinuxの方が数日レベルでリリースが遅いので、
今後開発が危うくなった時もAlmaLinuxへ引っ越しが出来るので、初回はRockyLinuxにした。
でも実際に引っ越した結果、問題は全く起きず正常稼働してくれているので継続利用しようと思う。
………
ちなみに、RHELの追従速度は次の通り。SecureBootもちゃんと対応していた。
| |
RHEL 8 |
AlmaLinux 8 |
RockyLinux 8 |
| v8.3 |
2020/11/03 |
2021/03/30 |
N/A |
| v8.4 |
2021/05/18 |
2021/05/26 |
2021/06/21 |
| v8.5 |
2021/11/09 |
2021/11/12 |
2021/11/15 |
| SecureBoot |
○ (v8.1) |
○ (v8.4) |
○ (v8.5) |
RockyLinuxが発足した直後は開発遅延も大きかったが、
体制が整ったらしく他と遜色ないリリース速度を出すまでになっている。
SecureBootも対応済で機能面で大きな差がが無い上、
コントリビューターも揃ってきている様なので、今後はリリース日の差が更に埋まると思う。
………
このWebサーバも既にRockyLinuxで稼働しているのだが、
バグ含めた100%の移植率を誇るだけあり問題なく稼働している。
ソースビルドしたアプリは勿論の事、自作したスクリプトや管理プログラムもそのまま動いている。
EPEL等のサードパーティリポジトリも使えており、本当の意味で移行コマンドを実行して完了した。
自鯖で本番利用している環境はRockyLinuxへ移行したが、
開発環境ではCentOS Streamを利用する上、KVMホストはCentOS 7を使い続けているので、
当面の間はCentOSを引き続き利用する事になりそう。
今回の騒動をマイナスに捉える人も多いが、
コミュニティが活発になり選択肢が増えるのはメリットと捉えているので、
今後もLinux界隈をウォッチしながら様々なディストリビューションを試していきたい。
« 続きを隠す
2021年10月03日(日) - 21:34 | カテゴリ:
Linux
自宅サーバのメールゲートウェイでは、OpenDMARCを使ってDMARCレポートを生成しているのだが、
OpenDMARCをv1.3からv1.4にアップグレードしたら、レポート生成時にエラーが出力される様になった。
実際に出力されたエラーログのサマリは次の通り。最初はDBが壊れたと思った (´・ω・｀)
opendmarc-reports: can't extract report for domain example.com: Unknown column 'messages.arc' in 'field list'
opendmarc-expire: DELETE failed: Table 'opendmarc.arcauthresults' doesn't exist
|
DBにカラムが足りなそうだったので、リリースノートと公式ドキュメントを確認した所、
OpenDMARC v1.4.0でARC(Authenticated Received Chain)にも対応した影響で、
生成するレポート用データのフォーマットとDBカラムが変更になった様だった。
1.4.0 Add ARC support ... Update SQL schema to support new porting functionality for DKIM selectors
|
OpenDMARC v1.3以下はARCに対応していないので、当然ながらデータベースもARCを想定していない。
その為、v1.3.X以下を利用している環境をアップグレードした場合は追加されたARCカラムが存在しないので、
レポート生成データを格納するデータベースに情報をinsert出来ずエラーとなる。
比較的簡単なテーブル構造なので人力でカラムを追加しても解決出来るのだが、
今回はデータを格納しているデータベースを一度初期化してデータを作り直す事に。
生成したDMARCレポートは別の方法でバックアップしているので、
カラムを弄って整合性を崩すよりも一から作り直した方が安全と判断した。
作り直した後はエラーも発生せずにレポートを生成が出来ており従来通りの機能を使えている。
当面は自宅サーバでメール送受信をし続けるので、
コア機能のコンポーネントアップグレードには気を付けねばと改めて実感する出来事だった。
2021年09月11日(土) - 23:54 | カテゴリ:
Linux
ns-lab BBでは色んなLinuxディストリビューションを使う事でシステムが偏らないようにしている。
バックボーン設備も例に漏れずマルチディストリビューション構成なのだが、
その中でもDHCP兼バックボーン管理サーバを兼ねているopenSUSE 15.2をそのままにしていた。
冗長化していると言ってもDHCPサーバが止まるとPCや無線接続スマホが通信出来なくなるので、
慎重にアップグレードする必要があったのと、
自作プログラムも動いているので慎重にアップグレードする必要があった。
最近は毎週末がバタバタしていたのだが今日だけはなんとか時間を確保出来たので、
DHCP兼バックボーン管理サーバを、openSUSE 15.2からopenSUSE 15.3にアップグレードしてみた。
os-releaseも15.3に切り替わっていた。
今回も公式が公開しているopenSUSE15.3アップグレード手順に沿って作業。
ディストリビューションのアップグレード自体は問題無く完了したのだが、
メール関係でハマりポイントが出てきたのでメモしておく。
1. Postfixがhashをサポートしなくなる
題の通りだが、最近のPostfixはハッシュDB(hash)をサポートしていないので、
Postfixのaliase設定にhashを使っていると次の様なエラーを吐いて落ちてしまう。
error: unsupported dictionary type: hash
warning: transport_maps is unavailable. unsupported dictionary type: hash
|
サードパーティのプラグインを入れればhashを使えるらしいが、折角なのでlmdbに切り替えた。
lmdbに切り替えた場合、postmapも再実行してDBを再生成する必要がある。
そのままpostmapを実行しただけではダメなので “postmap lmdb:transport_maps” の様に接頭辞を付ける。
2. Dovecotでdh.pemが必要になる
コレはCentOS8でも起きたので知っている人がいるかもしれないが、
openSUSEのDovecotでdh.pemを設定していない場合、コマンド実行もエラーになる場合がある。
コマンドでもエラーを吐くのがネックで、APIにも影響が出てしまい見事にエラーを踏み抜いた。
対応するのは簡単で “openssl dhparam -out /etc/dovecot/dh.pem 4096” を叩いた後に、
dovecotのコンフィグに “ssl_dh = </etc/dovecot/dh.pem” を追加すれば動くようになる。
コマンドやAPIのみを使う場合、dovecotをdaemonとして起動させる必要は無いのだが、
コンフィグに追記しないと動かないので注意する。
………
久々にサーバを弄ったので思い出しながらになったので時間がかかったが面白かった。
技術屋たる者、やはり手を動かしてなんぼだと再認識した土曜日でした。
« 続きを隠す
