破壊的変更を行ったCentOSのファイルシステムを復旧する

はじめに

VALU Advent Calendar 2018 の15日目です。

いきなりの私事ですが、私はまだVALU社の社員ではなく、2019年1月1日より正式な社員としてjoinすることとなっております。
そこでアドベントカレンダーという西洋の文化と掛けまして、今年現職で犯した最も大きな罪を懺悔し、償いのプロセスを公開することで、現職チーム・VALUチームからの赦しを与えられんことを願うこととします。

懺悔

時代背景

現職では数年前に契約したさくらVPSを使用し、コーポレートサイトやその他静的サイトを一部運用していました。
契約開始以降移管等を一度も行っていなかったためか、ディストリビューションは **CentOS 5系¹**を指していました。

GitHubが使えなくなる、その日

とある日、サイトの更新をしようとgit pullしたところ、以下のエラーが発生。

fatal: unable to access 'https://github.com/{自社リポジトリ}/': 
error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

SSL関連のエラーです。
gitコマンドで参照されているOpenSSLのバージョンが古いことが原因のようです。

[root@ ~]# openssl version
OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008

禁断の果実

httpdやphpはソースコードからビルドすることで、SSLのpathが指定できた(はず)ですが、gitはうまくいきませんでした。
ということで、 yumで管理されているOpenSSLのバージョンをなんとか1.0.1系へとメジャーバージョンアップデートさせることを試みました。

破滅への第一歩です。

yum update openssl では、メジャーバージョンアップデートがされないため、いよいよ禁断の果実へと手を出します。

yum remove openssl

.
.
.
.
.

神ハデスが私に尋ねます。

上記の処理を行います。よろしいでしょうか？ [y/N]

.
.
.
.
.

こうしてこのサーバーへの最後の審判は降りました。

yumやcurl等直感的に通信が必要そうなコマンドは愚か、cdを含むめちゃくちゃ基本的なシェルコマンドさえもすべて削除され、挙句SSHセッションが切れサーバーへのログインもできなくなったのです。

償い

さくらVPS カスタマーセンター

さくらVPSのサポートにどうにか復元の方法がないか問い合わせてみるが答えはNO。

お問い合わせをいただき恐縮ではございますが、「さくらのVPS」はバックアップなども含めてお客様に管理をしていただくサービスでございます。
弊社にてお客様のサーバの戻し作業やsnasphotの作成なども行ないません。
ご了承くださいますようお願いいたします。

しかしなんとか方法がないか、血眼でググったり電話で泣きついてみたりしたところ、さくらVPSのコンパネが提供しているリモートコンソールから、レスキューモードでの起動が可能とのこと。

光明が差し込んだ瞬間でした。

レスキューモード

OSの再インストールということで、1つ間違えばデータが飛ぶ。
そんな状況下では頭真っ白、顔真っ青、目は真っ黒な極限状態に陥るので、ここからは丁寧にスクショを貼って復元手順を説明します。
同志へ届きますように。

1. 対象のサーバーにカスタムOSをインストール

CentOS 5系がなかったので6系を選択。
なんか怖いアラートがたくさん出ますが、私は大丈夫でした。

そしてVNCコンソール画面へのログイン案内が出るので、開く。

2. CentOSの初回起動画面で Rescue installed system を選択

3. 言語、キーボードの選択

English us を選択。

4. ネットワーク設定の確認画面で No を選択

ネットワークの設定は必要なのですが、なぜかGUI上ではうまくできないので後ほどCLI上で設定します。

5. 既存データを /mnt/sysimage にマウントするよ！ に Continue を選択

6. Shell Start を選択後、 Ok でレスキューモードシェルへとログイン

7. /mnt/sysimage に既存のファイルシステムが復旧されていることを確認！

無事、復活です。

ネットワークの設定

データにアクセスできたので、あとは /mnt/sysimage 配下の必要なデータを他サーバーへと移すのみでした。
前述の通りレスキューモードの起動ではネットワーク設定、またルーティングテーブルが未設定の状態で、外部への通信ができません。

ネットワーク設定方法はググるとたくさん情報が出てきたので、細かい説明は割愛します。
さくらVPSのコンパネ上の情報とのマッピングだけご紹介。

ネットワーク設定(前）

ネットワーク、ルーティングテーブル設定

ifconfig eth0 ${addr_ip} netmask ${netmask_ip}
route add default gw ${gateway_ip} eth0

ネットワーク設定(後）

そして外部通信が可能になりました！！

その後scpなりrsyncなりで、必要なデータを移管することができました。(割愛)

まとめ

yum remove openssl により、破壊的変更を行ったファイルシステムをレスキューモードにより復元後、ネットワーク設定をし外部サーバーへ逃がすことができました。

反省点として、GitHubの警告が出た時に調べた公式のアナウンスをもっと注意深く読むべきでした。

We advise that users of Red Hat 5 upgrade to a newer version of the operating system.

RedHatに対する説明はあったものの、CentOSに対する説明がなかったので他の方法を考えてしまいましたが、CentOSはRHELのクローンなので立ち止まるべきでした。
[CentOS バージョン] (https://ja.wikipedia.org/wiki/CentOS#%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3)
[RedHat リリースバージョン]
(https://ja.wikipedia.org/wiki/Red_Hat_Enterprise_Linux)

そもそも、OSにプリインストールされているようなパッケージは容易に削除²などしてはいけません。
もっとそもそも、サポートが切れているようなOSバージョンをそのまま運用するという選択を取るべきではありません。

さて、いかがでしたでしょうか。
無事、2018年最大の失敗を清めることができたかと思います。
来年からのVALU社へのjoinが楽しみです。

アーメン。

参考

[CentOS5 以前ではもう github に接続できない] (https://donbulinux.hatenablog.jp/entry/2018/06/11/160950)
OpenSSL バージョンアップ TLS1.1以降に対応

1. CentOS 5系は2017.03.31にサポート切れしています。 ↩

2. パッケージの削除を保護する方法がCentOS 6系からは実装されているみたいです。デフォルトでつけてくれると世の中平和なのにね〜。 ↩