一部のサービスで利用しているサーバーですが、そろそろ稼働させつづけるのも限界が見えてきたようなので移設を計画しておりました。
が、しかし、計画より半年ほど早くあれこれと不具合が出てきたため（私の余計な操作が原因の多くを占めていると思いますが）、当初は２週間かけて行うはずであった移設作業を先週末から昨日まで実施しておりました。およそ半分の期間、かつ日中は他の仕事がわんさか入っている中での作業なので当初の計画は破棄して「突貫移設計画」での作業です。
先に書いておきますがこの記事には技術的な内容は全く含まれていません（だって詳しく書くわけにいかない）。なのでトラブルシュートのために解決策を検索されている方々がもし居たとしたら何の参考にもならない記事だということを先に述べておきます。
■さて何が変わったでしょう？
まず大きく変わったのが、東京リージョンから大阪リージョンへ物理的に設置場所が変わりました。と言っても場所もハードも借り物なわけですが（総務省への提出書類に「東京」とか余計なことを書いてなくってよかった）
そしてCentOSからUbuntuへとOSも変わりました。CentOSにする前はDebianだったので単純にもとの系統に戻っただけという見方もありますが・・・なにせ６～７年前にCentOSに頑張って移した時はもうディストリビューションを変えることは無いだろうという気持ちだったのです、が・・・情報が多いであろう多勢主流に乗ったつもりが世の中の移ろいはとても速く非情なものでして。
同じLinuxなんだから大差なくて簡単でしょ、と思われがちなのですが似て異なるものってのはずいぶんと厄介なものです。しかも稼働しはじめてから６～７年も経過していればなおさら。
ずっと日常的にLinuxの様々なディストリビューションに触れている猛者な方々にとっては小さな差異なのだろうけれど、そりゃ私だってWindows3.1以降Windows11に至るまで４桁回に迫るほどＯＳのインストールやトラブルシュートをしてきましたからWindows系ならそれなりに痒い所に勘が働きますが、そういった勘がLinuxに対してはまったく働かないもどかしさがあるものです。
というわけで細かいところまで完璧に移してくることは最初から放棄して、表面上のサービスだけいくつか見た目をそのままにすることだけを考えようというのが突貫移設計画の１項目目。
■いつもなぜか悩むBIND
外部公開用という側面より内部処理用にBINDを使っていて、いいかげん自前で上げるのやめたいなと思っていたのですが、突貫計画では何も考えずにサーバー移行。
でも、なぜかいつもBINDの設定はスムーズにいかないのですよ。
私の圧倒的な経験不足。
お名前ドットコムさんのセカンダリーDNSを使わせてもらっているんですが、なんかWEB設定画面でしつこく別メニューに飛ばそうとしてくる構成に戸惑うことが多いような。
何年か前に弄ったときもまずセカンダリに反映されず、あれこれ触っていたものの単純にゾーン設定のシリアル値をカウントアップしてなかっただけというオチだったのですが。
今回も同様にセカンダリに反映されず、ちゃんとシリアル値をカウントアップしているのになぁ、まさか「ミスタイプかなにかで桁違いに大きな値を転送してしまっていた」のかなあ・・・そうなると(1)符号なし整数が溢れるような値を転送して(2)その値が浸透するのを待って(3)再び正常な値を転送・・・とかやってたら７２時間ｘ２テイクというぞっとする時間がかかってしまうじゃないか、とか思っていたのですが。
なんのことはない、複数のconfファイルでrecursionの設定がダブってしまい、recursion no;と指定しているつもりが yes;で上書きされていたためオープンリゾルバ対策の一環なのか転送が拒否られていたというオチでした、たぶん（confが複数ファイルに細分化されていくとどうも見落としがちで苦手）
■Postfixというハードルも
いつでも悩ましいPostfixでも、SASL認証ファイルのPermissionが無いとかそもそもファイルが存在しないとかいろいろとログにサーバーからの文句が書かれています。
なにも考えずにCentOSから設定をもってくるとどうもUbuntuとの相性が悪いのか違いが大きくなりがちなところなのかもしれないですね。
ある程度の設定ができたところで外部への送信がうまくいかない。
なぜだろうと調べてみるとOP25Bというハードルが。そうだサーバー契約完了してから７２時間くらいは送信できないという制限があるのだった。突貫計画以前の計画では７２時間なんか余裕で過ぎてからの作業だったはずなので失念しておりました。ひたすら待つだけ。
その待っている間にも他のサーバーのメールキューにひたすら溜まり続けているのは一体なぜ？と思ったら、オープンリレー対策にと厳しくしすぎたあおり。あれこれPATHが変わったらそりゃPermission deniedやらFile not foundが多発するのを想定すべきところが抜けていたりと反省。ログ見て「あれー権限つけてるのになんでだろう？」とか悩んであれこれ試している暇があったら参照している位置が違っていることに早く気づけ自分と言ってあげたい。
■nginxもApacheもサクサク動く
旧サーバーも新サーバーもストレージやメモリ容量などの外形的なスペックは同じなのですが、やはりハードウェアの進化なのかCUIで操作していても速さを感じますね。
おかげで従来はApacheだけでも重さを感じるシーンがあったのが、すっかり解消されてnginxと併存してくれています。これは初期設定作業をしていても気持ちがいい。
というわけで調子にのって、物理的に２台に分散していたサービスを１台に集約してさらにスッキリしました（と言っても内部的なお話なので外から見れば何も変わっていないはずですが）
ただここでもやはりpathが変更になっている影響に悩まされ・・・内部で絶対パスで書くのは極力控えようと猛省。
■綺麗にできなかった部分も残るが
唯一心残りなのはWordPressのサイト構成が従来のまま。気分一新してシンプルに作り直したかったのだけれど、そんな時間的余裕は無いということでHTMLとSQLをまるごとごっそり持ってきて展開しただけ。
ただHTMLのパスが変わったのでSQLを流し込む前にSQL文中のパス文字列を書き換えて、ついでにデータベースとしてlatin1なんて設定が残っていた文字コードもごっそりUTF-8に置き換えるという強引な手を使っていますが。
文字コードの違いにはいつも忘れたころに悩まされますよね。
今回もデータベースのデフォルト値が変わっていたおかげで「取り込んだデータがなんか化けてるなー」と気づいて変換するきっかけができたわけですが、手元のCUI環境で化けないように整形して満足していたらそのデータベースから文字列を提供するAPIの出力が化けていて、わざわざAPI内でlatin1からUTF-8へ変換していた処理を無効化してあげる余計な作業が発生しました（たぶんまだ見逃している部分があるに違いない）
というわけで作業待ち時間の間にサイトの動作確認を兼ねてだらだらと書き連ねてみたわけですが、この記事のアップも突貫計画の１６０ステップ目の項目だったりします。
—
消えちゃった動画や写真データの復元は
安心安全な『株式会社パソコントラブル救助隊』へ。
https://hqsecure.net/
