「openSUSE Leap 15.0」に上書きアップグレードした失敗談と注意点
“ns-lab BB”のサーバ群は「CentOS:openSUSE:Debian = 5:4:1』程度の比率で稼働中なのだが、
その中でもメール系はメインにopenSUSEを採用し続けている。
だが、時間が取れずずっとLeap 42.3状態で稼働していたので、休みを使ってアップグレードしてみた。
が、そうは簡単に行かず躓きそうな地雷を色々と踏み抜いたので、
後世に残す為にも備忘録化しようと思う _(:3」∠)_
まず、openSUSEサポートは公式サイトに纏まっているのだが、
当初は2019年1月末までだったLeap 42.3のサポートが、何時の間にか2019年6月まで延長となった。
なので、従来の知識を持っている人だと『早くアップグレードせねば!』と焦るかもしれないが、
まだ半年弱の猶予があるので、下記も読みつつ日本openSUSEユーザ会とかで情報収集をしてから、
計画的にアップグレードするのでも遅くはない。 …というより強く推奨する。
というのも、テストもした上で「行けるだろ」とアップグレードしたら、
サーバが1台吹っ飛で再構築した ヽ(´ー`)ノ
ちなみに、下記の備忘録はwikiに追記済なので、
該当しそうな項目があったらそっちも見て貰えるとありがたいです (´・ω・`)
- アップグレード時は、サードパーティリポジトリを無効化する
- アップグレードを禁止しているパッケージリストを初期化する
アップグレードは、公式サイトに書いてある手順に沿えば良いのだが、
実際にやってみたらアップグレード途中でエラーになる場合があった。それを踏まえて筆者のサーバでは、
『サードリポジトリ無効化 → アップデートロック解除 → パッケージアップグレード
→ リポジトリを15.0に切り替え → OSアップグレード → 色々と元に戻す』
の手順で上手くいった。その中で最初に書いたサードパーティーリポジトリ無効化がキモで、
コレをやらなかったら、OSが起動しなくなったりアップグレード後のパッケージが不完全でエラーが頻発した。
なので、アップグレード前にはリポジトリ整理とロック制御見直しを強く推奨する。
………
- SuSEfirewall2がfirewalldに変わった
コレは有名は話なので、openSUSE使いなら知っている人も多い筈。
上書きアップグレードではSuSEfirewall2の設定も残っているのだが、
Leap 15.0でインストールされるfirewalldも入って居る状況になるので、
SuSEfirewall2とfirewalldが両方インストールされてしまい微妙に不安定になった。
この問題は、どちらかのパッケージをアンインストールすれば解決出来るので、
慣れたSuSEfirewall2を続投するか、firewalldへの移行を行えば良いと思う。
ちなみに”ns-lab BB”では、自動生成したポリシーを食わすスクリプトもあるのでSuSEfirewall2を続投した。
………
- Dovecot2.2がDovecot 2.3になった
Dovecotはメジャーバージョンアップにより、dhパラメータの記述方法が微妙に変化した。
なので、そのままだと起動しなくなる。
具体的にはコチラにも書いてある通り、dh.pemを下記コマンドで再生成すれば良い。
dd if=/var/lib/dovecot/ssl-parameters.dat bs=1 skip=88 | openssl dhparam -inform der > dh.pem |
他に”ns-lab BB”で発生した問題として、Dovecot 2.3からSQLを叩く箇所にバグがあるらしく、
ユーザ認証にSQLを噛ましている場合にユーザ取得・認証処理が出来なくなる問題が発生した。
こちらは絶賛修正中と何処かに書いてあったので、今回はDovecot 2.2にダウングレードして使う事にした。
………
- SSLライブラリがOpenSSL v1.1.0になった
OpenSSLは古いパッケージを使っている環境でハマる可能性が高いと思う。というよりハマった (´;ω;`)
現在はメンテナンスが停滞気味の「枯れた」アプリの場合、最近のOpenSSLには対応していないケースがある。
“ns-lab BB”ではこの問題がOpenDKIMで発生した。
通常ならば、zypperでインストール出来るOpenDKIMをそのまま使うのだが、
そのパッケージの改修が間に合って折らず、OpenSSL v1.1.0に対応出来ていない状況だった。
しかし、Leap 15.0ではOpenSSL v1.1.0がデフォルトとなった為、
SSLのバージョンが高すぎてOpenDKIMを起動出来なくなった。
コレを解決出来ないとメールサーバとして大問題なので、
自力でパッチを書いたりGitHubのパッチを適用したが、最終的にはEPELのsrcrpmを自力ビルドした。
当初、エラーが出ずに起動出来なくなり原因究明が難航したが、
『起動は出来るがSSL系の処理を行うとバグる』時、OpenSSL v1.1.0に対応しているか確認しつつ、
出来るならばダウングレード・ソースビルドなどをすると良いという知見を得た。
………
- ロケールがバグる
コレは”ns-lab BB”が特殊な気もするが、今回アップグレードした全てのサーバで起きた。
微妙に困ったのは、コンソール設定と実際のロケール設定がズレる事で、
テキストを表示した時に変な制御コードが追加されていたり、ファイルの先頭1文字が消えていたりした。
結果、コンフィグに謎の1文字が追加される事となり、編集したファイルで構文エラーが出まくった。
恐らく、2バイト文字が原因だと思うが最近はUTF-8な英語のみ使っていたので原因追及はあまり行わずに、
全サーバのロケールを”en_US.UTF-8″に統一して終わらせた。
ちなみに、新規インストールした場合はこの問題が起きなかった。
………
- GlusterFSのアップグレードによって後方互換が無くなった
コレもメール領域にGlusterFSを採用している”ns-lab BB”特有問題だが、
GlusterFSクラスタを組んで居るサーバを1台ずつアップグレードしていったら、
新・旧サーバの間でクラスタが張れなくなった。
クラスタ作成し直したり、Firewallの設定を変更したり色々とやってみたのだが、
最終的に同バージョンのGlusterFSならばクラスタを張れる事がわかったので、
アップグレード後に全クラスタを解除し、バックアップデータとBrickから差分を取りつつリストアした。
どちらかというとGlusterFSの問題であると思うが、
似たような構成を組んで居る人は注意した方が良いと思う。
他にも、Perlで実験採用されていた構文が無くなったり、
gettyが存在しないデバイスを握ろうとして暴走したりするのだが、イレギュラー要素が強いので割愛。
どちらにしても、アップグレードは危険な作業に違いは無いので、事前のアップグレードテストを強く推奨する。
筆者の場合は自宅にあるHyperVでスナップショット取りつつアップグレードテストを2回行った上で、
本番環境のアップグレードを行った。が、そこまでやっても全サーバで何かしらの問題が出た。
一番クリティカルなのは、ブートローダが壊れてサーバが起動しなくなったのがVPS上で1台発生し、
急遽、ベンダーを買えてKAGOYA CLOUDで再構築し直した。
ちなみに、このサーバが以前で話題に出した「メールゲートウェイ4号機」だったり。
この再構築も事前にバックアップをちゃんと取っていたので、
平日の合間を縫って1週間で完了させる事が出来たのだが、
バックアップが無かった場合を考えると、中々に怖い状況だったと思う…
「日々のバックアップと事前検証は重要」と身に染みた年始作業でした。