古いサーバを新しくリプレースした際の失敗談

何年も前に作成し、動作させていたサーバを新規に作成したサーバに移行させる作業を行う事となった。
その際に、既存のシステムを新サーバにどうやって実装するか調べ、新サーバの方に移させた。
そして、いざ、新サーバとの切替の動作確認中に問題が生じ、同僚の協力を仰いだ所、同僚より「○○○のシステムはどうなってるの？」と聞かれ「はっ！」と思い出す。
完全にそのシステムの事を失念しており、「完全に忘れてた」という感じで急遽、それも実装・動作確認を行った。
幸いにもそれは設定を追加・変更するだけで、特に問題なく動作したので事なきを得た。
サーバの移行などは多人数のチェックや確認をしないとこのような思い込みによる抜けや間違いが発生するので、チェック等をなるべく多人数で行うことが望ましい。

AWSのEC2にログイン出来ない

EC2に最新バージョンのubuntuサーバを選択しサーバを作成し、初期インストール時に設定されているログイン名にてSSH接続でログインしようとするが出来ない。
サポートにログインIDが変わったとかを聞くも特に変わりがない。
同じバージョンのサーバはVM上でも作成した事があり、その時はこのような症状は発生しなかった。
試しに、違うSSHクライアントで接続を試すと、問題なくログイン出来た。
そこでいろいろ調べた結果、いつも使用しているSSHクライアントだけに発生する事案だという事が判明。
尚、同時にログインを可能にする方法もあったので、それも実施。
同バージョンのサーバを違う環境で作っていて特に問題がなかったのが原因がわかるまでの時間を遅らせた。
この辺り、ダメなら他の方法をという時に、他のSSHクライアントで試すという考えが出なかったのが問題だと考える。
柔軟な思考が要求される場面で、あっちがOKならこっちもOKという思考膠着がより解決の時間を経過させる要因だと痛感した。

「Tera Term」というWindows用SSHクライアントソフトで発生。最新版ubuntuではSSHサーバでのRSA暗号化が入らなくなり、RSA暗号化でログインするTera Termでログイン出来なくなった。
サーバー側のsshd_configでRSA暗号化を使えるようにすればログイン出来るようになりました。

アプリの設定の勘違い（思い込み）

最近はいろんなサーバ用アプリもパッケージで提供され、コマンドで簡単にインストール出来るようになったが、自社で使う機能上、提供されていない物を使いたい場合は自分でソースファイルからコンパイルして作成という昔からの方法を取らざるおえない場合がある。
こうしてインストールした物を他のパッケージ提供された物と組み合わせて使う場合、安易にドキュメントや検索した設定例とかに頼ると正常に動作しない場合が発生する。
今回は設定ファイルの場所が間違っていた為に、設定した内容が読み込まれなくて動作しないという状況になった。
これはソースファイルからコンパイルで作成の過程でデフォルトの設定ファイルの場所が通常とは違う場所が指定されていた為に発生した事案となります。
該当アプリ作成時に指定された場所に置いたら、問題なく動作した。
実際にこれに気がつくまでの時間がかなりかかってしまった。
パッケージ提供と自分で入れた物を混合させて使う場合は注意が必要と痛感しました。

ミスや失敗はないにこした事はないのですが、そうはうまくいきません。
基本的に複数人でのチェックは必須な感じですが、人手不足とかひとり情シスとかの場合それも難しいです。
なので、同じミス（失敗）を繰り返さない為に、「何故？（原因）」「解決策」という感じで、原因とそれの解決策をハッキリとさせ、今後に活かせるように出来れば良いと思っています。