DigiLoog

続きを読む »

• アップグレード時は、サードパーティリポジトリを無効化する
• アップグレードを禁止しているパッケージリストを初期化する

アップグレードは、公式サイトに書いてある手順に沿えば良いのだが、
実際にやってみたらアップグレード途中でエラーになる場合があった。それを踏まえて筆者のサーバでは、
『サードリポジトリ無効化 → アップデートロック解除 → パッケージアップグレード
　→ リポジトリを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を下記コマンドで再生成すれば良い。

他に”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週間で完了させる事が出来たのだが、
バックアップが無かった場合を考えると、中々に怖い状況だったと思う…
「日々のバックアップと事前検証は重要」と身に染みた年始作業でした。

« 続きを隠す

続きを読む »

構築手順は何時も通りのwikiに纏めたのでそちらを参照。
ちなみに、今回は権威DNSサーバ(PowerDNS Authoritative Server)のみ構築してみた。

• nowsky system-lab memo : Linux/Source/PowerDNS

構成としてはこんな感じにしてみた。

ポイントとしては、ゾーン管理をPowerDNS+PDNS Managerに任せておき、
実際のユーザクエリに応答するフロントエンドは従来のBINDを利用してみた。
本来なら一番危険なのがフロントエンドなので、この箇所をNSD・Knot DNS辺りにしておくのがベスト。
ただし、今回はPowerDNSとGUIツールの使用感をテストしたかったので、
フロントエンドは手抜きして使い慣れたBINDにしてみた。

構成図はシンプル。ゾーン転送でBIND(slave)にデータを送る。
アプリケーションは違うだろうが、同様の構成は『Hidden Primary』として商用でもやる事が多い。

………

PowerDNSのGUIツールは色々な物をテストしてみたが、最終的にPDNS Managerに落ち着いた。
PDNS Managerは実装がシンプルなのと、PHP+JSで作られているので既存のWEBサーバと親和性が高く、
1台のサーバに色々詰め込んでいる自鯖用途に合致した。

当初、PowerDNS-Adminを使おうと思っていたのだが、
PIPの構築やらPython依存関係の解消など色々と面倒な中、
TCP:443でアクセスさせるには、リバースプロキシを噛ませる必要も出てきたので諦めた。
ただ、PowerDNS-Adminは機能が豊富で、ユーザ認証をAD連携(LDAP)する事も出来るらしいので、
エンタープライズで利用するなら、このツールが筆頭候補になると思う。

PDNS Managerの良い所は、余分な機能が無いので直感的にゾーン情報を弄れる。
その割に、ユーザ認証はローカルDBでちゃんと出来たり、
レコードタイプにALIAS等のニッチな物が揃っているので、十分な機能を持っている。
レコードで使うとしても、大多数は『A / AAAA / NS / MX / CNAME / TXT』辺りだと思うのと、
そこまで細かい制御やるなら、GUIよりもゾーン情報を直書きした方が意図した設定になると思う。

………

使ってみた感じだと、PDNS Managerは動作が軽く、ゾーン転送にも影響は無かった。
簡単にPowerDNSを使ってみたい場合には、良い選択肢になりそうだった。
そんな中でも気になったのは、レコードを編集する度にゾーン情報のシリアルが上がる為、
利用者が多い環境ではシリアルの『YYYYMMDD』と実際の日付が合わなくなりそうだった。

ただ、シリアル自体は数が相当数確保されているので、シリアルを気にしないなら問題無さそう。
そもそも、GUIを使う様な環境ではシリアル管理もGUI任せの方が良いので、希有な心配かもしれない。
…まぁ、シリアルを戻す事はDBを直接弄れば出来そうだったが (｀・ω・´)

“ns-lab BB”のインターネット向けDNSサーバは従来通りの構成を取っているが、
色々とテストして、本番利用が出来そうならばこちらの権威DNSも載せ替えようと思う。

« 続きを隠す