- アップグレード時は、サードパーティリポジトリを無効化する
- アップグレードを禁止しているパッケージリストを初期化する
アップグレードは、公式サイトに書いてある手順に沿えば良いのだが、
実際にやってみたらアップグレード途中でエラーになる場合があった。それを踏まえて筆者のサーバでは、
『サードリポジトリ無効化 → アップデートロック解除 → パッケージアップグレード
→ リポジトリを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週間で完了させる事が出来たのだが、
バックアップが無かった場合を考えると、中々に怖い状況だったと思う…
「日々のバックアップと事前検証は重要」と身に染みた年始作業でした。
« 続きを隠す
