会社で利用していた専用サーバに収容されていたドメインを全て共用サーバへ引越しをした。
今年度の自分にとっての目玉事業。
会社の人達は「めんどくさい」「費用対効果は？」とかうるさかったけど、これで僕がいなくなってもなんとかまわせる状態になったと思う。
そういうの大事じゃない？

もうほとんど終りなので感想をば。

■移行した理由
・レンタルしていた専用サーバサービスが新規登録を終了した（縮小傾向にあった）
・セキュリティパッチが正しく当てられなくなっていた（原因不明のエラーになった）
・OSが古く、インストールされているアプリケーションが古かった（Redhat Linux 2.x ESとかだったかな）
・リソースが余り気味
・何か問題が起きると利用しているドメイン全てに影響が出る（電話が鳴る）
・サービスに対して料金が割高になってきた

4年～5年前に借りたサーバだったので、いろんなものが古臭くなって来てた。
なので交換時期は交換時期だったんだけど、ざーっと利用しているドメインを見て、別に専用サーバじゃなくても運用出来そうだったので、全てを共用サーバへ切り替えることにした。
自分への負担を軽減させたかったし。


■移行してみた結果
・管理しなくて良いって素晴らしい
・自由 < ノーリスク
・アプリケーションのアップデート等が迅速で感動（まあ、いきなりあるってのがちょっとアレだけど）
・費用は半分以下になった
・バックアップはこちらで簡易的なものを用意

とにかく何か問題が起きても「他人任せ」に出来るってのは、やはり楽だなー。
アプリケーション（PHPとか）のバージョンアップも自動でやってくれるし、助かりまくり。
SSH接続できるところを選んだので、簡単なものならインストールも出来ちゃうし、特に出来なくて不便ってことはないなー。
唯一の不満点はバックアップ。
以前は外部ストレージをレンタルサーバ側で用意してくれてたんだけど、共用サーバに限らず大概は「RAIDに対応してます、すごいでしょ」か「同じサーバ内に保存しといて」ぐらいしかやってくれないので、自前で取ることにした。
これはSSH接続を許してくれるところじゃないと厳しい。

あと、サーバ全体に関わるようなメールサーバの設定（25ポートのブロックとか）とか、ドキドキしながらやらなくてよくなったし、なんかあったとしても、サイト毎に切り離して対応出来るので、大分気楽。
というか、これが普通だよなー、管理が楽とか良くわからん理由で専用サーバ借りられて、痛い目にあったなー。
まあ、経験は積めたんだけど・・・。


■今後について
基本的には共用サーバで出来るものは、共用サーバに任せれば良いと思う。
気軽に専用サーバを借りると、夜中まで残ったり日曜日まで対応したり大変な時があるし。
専用サーバを借りなければいけない時は、ほぼ同じ環境のテストサーバも用意してくれないとごねる。
っつうか、それないと無理だわ、僕には。


サーバの管理は本当に奥が深いのです。
なので、個人的にはVPSの管理をしながら、多少の経験は積んでいきたいなー。
ということで、Linodeオススメです。
OSの再インストールとかも、コンパネ上から出来ちゃうし。

ということで、コツコツ頑張ります。

一番分かり易いところだと、
「IPで接続したら何が表示されるの？」
ってことなんだけど、デフォルトの状態だと一番最初に指定されたバーチャルドメインの設定が有効になる。
バーチャルホスト毎にhttpd.confを分けていると、そのファイル名順ってことになる。

参考サイト
デフォルトバーチャルホストを無効にする - WebOS Goodies

だからかー。
ってことで、参考サイトのように表示されないようにしても良いんだけど、なんだか勿体無いのでファイル名を以下のように変えたよ。

/etc/httpd/conf.d/_default.hogehoge.conf

まあ、なんでも良いからファイル名で一番上に来るようにすれば良いだけ。

■エラーの内容
こんなのが出ました。

$ ssh <ユーザー名>@<ユーザー名>.sakura.ne.jp

Received disconnect from : 2: Too many authentication failures for <ユーザー名>

なんじゃらほいと思って、違うIPアドレスのクライアントから接続したらうまくいった。
これは、何度もエラーしていると、IPアドレスで弾いちゃうソフトが入っているのかな？と問い合わせてみたら、IPで弾いてないんですけどとの返答。

さて、困った。
多分、僕の設定が悪い。

んで、いろいろ試しているうちになんとなくわかった！

■調査の流れ
接続に失敗するクライアントのユーザーのsshのconfigファイルが以下の様になってた。

# ~/.ssh/config

IdentityFile ~/.ssh/id_rsa.hogehoge1
IdentityFile ~/.ssh/id_rsa.hogehoge2
IdentityFile ~/.ssh/id_rsa.hogehoge3
IdentityFile ~/.ssh/id_rsa.hogehoge4
IdentityFile ~/.ssh/id_rsa.hogehoge5
IdentityFile ~/.ssh/id_rsa.hogehoge6
IdentityFile ~/.ssh/id_rsa.hogehoge7

id_rsa.hogehoge7だけが上手くいかないわけ。
んで、もしかしたらと思って、id_rsa.hogehoge7を一番上に持ってきて、再度チャレンジ。

# ~/.ssh/config

IdentityFile ~/.ssh/id_rsa.hogehoge7
IdentityFile ~/.ssh/id_rsa.hogehoge1
IdentityFile ~/.ssh/id_rsa.hogehoge2
IdentityFile ~/.ssh/id_rsa.hogehoge3
IdentityFile ~/.ssh/id_rsa.hogehoge4
IdentityFile ~/.ssh/id_rsa.hogehoge5
IdentityFile ~/.ssh/id_rsa.hogehoge6

これで、ちゃんと接続できた！
変わりに、id_rsa.hogehoge6が接続出来なくなったのだった。
これで謎が解けた！

■今回のエラーの全貌
・このようなconfigファイルの書き方だと、sshコマンドさんは上から何度もアクセスして試してみる
↓
・リモート側が6回までは失敗してもOKだけど、7回目からは無視
↓
・失敗し過ぎで切断エラー

■対策

# ~/.ssh/config

Host hogehoge1.sakura.ne.jp
    IdentityFile ~/.ssh/id_rsa.hogehoge1

Host hogehoge2.sakura.ne.jp
    IdentityFile ~/.ssh/id_rsa.hogehoge2

Host hogehoge3.sakura.ne.jp
    IdentityFile ~/.ssh/id_rsa.hogehoge3

Host hogehoge4.sakura.ne.jp
    IdentityFile ~/.ssh/id_rsa.hogehoge4

Host hogehoge5.sakura.ne.jp
    IdentityFile ~/.ssh/id_rsa.hogehoge5

Host hogehoge6.sakura.ne.jp
    IdentityFile ~/.ssh/id_rsa.hogehoge6

Host hogehoge7.sakura.ne.jp
    IdentityFile ~/.ssh/id_rsa.hogehoge7

まあ、ちゃんとホスト名と認証ファイルを紐付けしてやれってことね。
あんまりさくらとは関係ないけど、さくらだと6回までは我慢してくれるってことだな。

Linodeでのサーバ障害からの復旧をLinodeスタッフさんの手を借りて復旧したようなので、今後は自分で対応出来る様にメモ。
（まだ良くわかんないし）

■2009/10/28 9:30頃
Linodeで借りているサーバへアクセス出来なったことを確認。
ControlPanelからコンソールへアクセスしようとするが、出来ない為Rebootする。
→コンソールにはアクセス出来る様になる。

■2009/10/28 10:30頃
まだ繋がらないので再びRebootするも変わらず。

■2009/10/28 12:00頃
LinodeのTwitterアカウントから「障害が発生していることは認識しているので、しばしお待ちを」とお達しが。
なんと全サーバをリストラするという大事態らしい。
「一応リストラしたけど、また問題あるならチケット切って！」とコメントが。
チケットを切る。

■2009/10/28 13:00頃～
俺：サーバは動いているみたいだけど、ネットワークが通ってないみたいだよ！
Linode：一応リストアしたんだけど問題あるなら言って！
俺：だーかーら＝繋がらないんだよ！ping叩いても「そんなホスト知らんがな」って言われるよ！
Linode：もし出来るなら、ネットワークの設定ファイル調べてみて！間違ったMACアドレスが設定されているかもよ？
俺：見てみたけど、どんなMACアドレスが正しいかわからないよー。ifconfigコマンド叩いたから結果見てみて！
Linode：こっちで設定ファイルのMACアドレスの行を消してみたら上手くいったみたいだよ！他になんかある？
俺：おお！なおっとるがな！ありがとー、助かったー！
Linode：お役に立てて嬉しいよ！またねー！

みたいなやりとりをやる。
Linodeスタッフグッジョブ。

■2009/10/28 16:00頃
無事復旧。

多分、11時頃にはネットワーク以外についての問題はなかったみたいだが、自分のスキルの無さから復旧できず、Linodeスタッフさんが直してくれた。
復旧後と復旧前のMACアドレスが違っていたわけでも無いのに、なんでそれだけで動かなくなったのか謎。
DHCPサーバを使っているみたいだから、MACアドレスをクリアしないと再設定されないのかな？

おかしい状態のifconfigの結果。

eth0     Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
         BROADCAST MULTICAST  MTU:1500  Metric:1
         RX packets:0 errors:0 dropped:0 overruns:0 frame:0
         TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:1000
         RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

復旧後の状態のifconfigの結果。

eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          inet addr:xxx.xxx.xxx.xxx  Bcast:xxx.xxx.xxx.xxx  Mask:xxx.xxx.xxx.xxx
          inet6 addr: xxxx::xxxx:xxxx:xxxx:xxxx/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2016 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1903 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:235316 (229.8 KiB)  TX bytes:1644123 (1.5 MiB)

今気がついたんだけど、ネットワークインターフェースの状態を示すBROADCASTが正常起動していないことがわかる。

んーどういうカラクリでMACアドレスを削除（再取得？）したら動く様になったのか分からないなー。
けど、スタッフの人が直ぐに「MACアドレスあってる？」って聴いてきたところにヒントがあるんだろうか？

まあ、とりあえずメモしておくことにする。
すげー時間がかかった。

やっぱまだまだ僕にはサーバ管理は難しいな。
経験を積まねば。

Linodeは海外のサービスなので、基本的にこの辺は海外仕様のままです。
んで、日本仕様に合わせて居たつもりだったんだけど、調べてみたら合っていなかったので対応することに、そのメモ。

■タイムゾーンを日本時間へ

cp -p /usr/share/zoneinfo/Japan /etc/localtime

こんだけで、その場でdateすれば値が変わっているのがわかる。

■文字コードを日本語へ

vi /etc/sysconfig/i18n

-LANG="en_US.UTF-8"
+LANG="ja_JP.UTF-8"

一旦ログアウトして、ログインし直せば変わってる。

こんだけー。
楽だー。