タグ「xrea」が付けられているエントリー

s333からのエクソダス

| s333からのエクソダス

このブログの収容先であるxreaのs333サーバが頻繁に高負荷状態で,エントリの投稿が大変困難な状態が続いていました.どのような状態かって,こんな感じです.

100621_s333_01.jpg

スクショは負荷観測から頂きました.サーバのCPUがCore2 Duo T7200なのに,LoadAverageが30超えてるとか,常識的に考えて可笑しいだろ.というわけで,移転先を探したところ,s370が確保できたので,ささーっと移動してみた.移行方法は前回の失敗を活かして,ちゃんとした方法で.

  1. 新サーバ(s370)をレンタルし,無料7日間を行使してPlus化する
  2. 旧サーバ(s333)からデータをバックアップする
  3. s370がPlusになったら,s370の管理画面に入り,サーバ間コピーを行う
  4. 具体的には,s333の/public_htmlを/public_htmlにミラー(削除なし)する
  5. s370にMySQLのDBを作る
  6. バックアップ(ダンプ)したDBをFTPでs370に置く
  7. データベースの復元をする
  8. それっぽく動いていそうなことを確認する
  9. VALUE DOMAINのDNSレコードをs370用に書き直す
  10. しばらく待って,切り替わっていることを確認する
  11. s333からs370にPlusの利用権を移す
  12. s333を閉鎖する

今回は無料7日間の権利を行使したことと,サーバ間コピーを使ったことです.おかげさまで,サクッと終わりました.この程度のコストなら,サーバに嫌気がさしたらすぐに移転できそうです.楽ちん!

関連:
s319からのエクソダス - 4403 is written

4月末からトラックバックスパムが再び激化し始めた.記録によれば,4/28から5/6までの9日間で227発ほど,.htaccessの拒否リストを通過して,MT側のTBスパムに引っかかっている.易々とすり抜けられているのが許せないので,なんですり抜けているのかをログで確認してみた.

WordPress/2.7

こんなUAのやつがすり抜けていやがる.これは・・・拒否すると影響範囲が広そうだなぁ.どうするかなぁ.てか,そもそも正規のWP2.7ってTB打つ時のUAはこれなんだろうか?それを調べた方がいいかな.

短時間に連続じゃないし,エントリに順番に打ち込んでくるわけじゃないし,異なるIPアドレスから打ってくるし・・・.これは巧妙化するボットのポートスキャンと同じですね.ちと困ったなっと.ボットの場合はどうやってフィルタを書くんだろう?

200905061448追記:

「WordPress/2.7」を詐称するスパムウェアを確認しています。

本物の WordPress は、すでに2カ月以上前に 2.7.1 が提供されています(4月29日時点での最新版)。 2.7 は事実上 obsolete とみなしてよいと思います。

芳立五蘊 | WordPress/2.7

とのことなので,アグレッシブに排除の方向で.

夜分遅く,こんばんは.突然,403Forbiddenになったので,夜逃げしかたかと思われたかもしれませんが,似たようなものです.

このブログはxreaのs319サーバで運用されていたのですが,ここのところ,サーバの負荷が高く,頻繁にエラーが出る状況でした.特に,MT4.1はAJAXグリグリの管理画面で,記事を書いているときに画像を挿入しようと思って接続エラーが出たときのショックは異常.どのぐらい異常かって,記事が消えるくらい.そのため,ブログの更新意欲が減退気味でした.

閑話休題.サーバの負荷がuptimeによれば,30とか40とかザラ.こんな不健全なサーバはよろしくない.そこにきて本日,ついに決別に至ったトラブルが発生.MTの管理画面であるmt.cgiにアクセスすると,403になってしまうのだ.なんということだ!これはやばいと思った.何といってもMTの管理画面に入れなければ,バックアップが取れない!まぁ.結局はうまくいったわけだが.では,どのように移行したのかを手順を追って説明.

  1. xreaの管理画面(s319)から「データベースの保存」を利用してDBのバックアップを作成する
  2. SSHでログインし,~をtarでガチ固め
  3. FTPでtarをダウンロード
  4. xreaから新しい無料サーバをレンタル
  5. s333を獲得
  6. value-domainの管理画面からxrea+のサービス利用権をs319からs333に移動する
  7. ドメインの設定もs333に向ける
  8. s333のFTPが有効になったら,tarをガチアップして展開
  9. xreaの管理画面(s333)から「データベースの復元」でDBを元に戻す
  10. 上手くいっていることを確認してs319を閉じる

主にはこのような流れになります.実際には,サービス利用権をs333に移動したんですが,ディスク容量の増量はすぐに適用されないようで,50MBしかアップロードできませんでした.そのため,このブログの画像類はアップロードされていません.だから,実はtarの展開はサーバ上では出来ずに,ローカルで展開して,個別にアップロードしました.なので,まだ完全移行は出来ていません.一応,動いています.

というわけで,ご覧の皆様には全く関係のない話でした.s333の感想ですが,至って良好で,快適です.負荷も1以下なので,良好です.今後とも,4403をよろしくお願いいたします.

んなバカな!っていうタイトルが付いてますが,事実です.XREAは普通にSSHで入るとrbashという制限モードで繋がります.どのぐらい制限されているかって?

yocchan440@s319:~> ls
rbash: /bin/ls: restricted: cannot specify `/' in command names
yocchan440@s319:~> cd /
rbash: cd: restricted
yocchan440@s319:~>

正にガッカリな状態である.そこで,bash化を行うわけです.やり方は簡単で,参考サイトをそのまま.これでSSHでの作業時も安心ですねっ!

Movabletypeの最新ベータである4.1b2を導入してみた.導入に当たった参考サイトはこちら.ただし,mt-config.cgiを設置しない状態で,mt-wizard.cgiを使った方が初期設定は楽だと思う.DBにはSQLiteを採用したかったのだが,上手く動作しなかったので,MySQLを利用している.それ以外のmt-config.cgiの設定項目は以下.

DefaultLanguage ja
MailEncoding ISO-2022-JP
ExportEncoding Shift_JIS
DefaultTimezone 9
ShowIPInformation 1
DBUmask 0022
HTMLUmask 0072
UploadUmask 0072
DirUmask 0072
PublishCharset utf-8
HelpURL http://www.movabletype.jp/documentation/

至って簡単だ.

Google Sitemapsを使うわけだが,設置してみたところ,以下のエラーが表示された.

404 (ファイルが見つかりません) エラー ページのヘッダーで 200 (OK) のステータスが返されました。

そんなこと言われてもなぁ・・・XREAをレンタルしているわけで,ボクにそんなことを言われても・・・

というわけで,調べてみました!簡単なことで,.htaccessを使って,404は独自の404なページに飛ばしてやればよいようです.

ErrorDocument 401 /error/401.html
ErrorDocument 403 /error/403.html
ErrorDocument 404 /error/404.html
ErrorDocument 500 /error/500.html

こうして,問題は解決したのです.

プロフィール

e-m@il @ddress