| Home | 次のページ »    [Movabletype ]

2012.02.17

Movabletypeを別サーバーに移動/コピー

Movable typeの最新版は、MT-5.xだが、今でも3.35を使っている。
理由は、MT-3.xの時代に散々カスタマイズを施し、TextのFormatterなどもこのブログの記事のようにコマンドラインの記述に都合が良いように書き直して、Pluginとして使っているからである。さらには、数人の友人がブログページを開いているので、MMIが変わると戸惑うことを恐れるからである。
さて、自宅内で運用しているサーバーが壊れたことを考え、別の予備サーバーを立ち上げ色々なサービスの設定を行っているが、ブログを移設するのに手間取ったので、下記にその顛末を書いておく。

1. ディレクトリーのコピー

(1) mt.cgiの入っているディレクトリーならびにブログの公開ディレクトリーをrsyncなどを使って全て
予備サーバーにコピーする。
(2) CGIPathの変更
mt-config.cgiに書かれているCGIPathを予備サーバーのURLに変更する。

例: CGIPath http://abc.myhome.jp  → CGIPath http://xyz.myhome.jp

2. 元のサーバーでブログのDBをdump

# mysqldump --default-character-set=binary -u USER -pPASS BLOGDB > abcblogdb

USER, PASS, BLOGDBは、設定した正しい値を入れること。

  • 予備サーバーでリストア
  •  (1) 元のサーバーでdumpしたDBデーターをftpなどで予備サーバーにコピーする。
     (2) sedを使ってURL名を変更

  • 10MB近いデーター量で、数分要した。
  • # sed -e "s/abc.myhome.jp/xyz.myhome.jp/g" abcblogdb > xyzblogdb

    (3) DBのリストア

    # mysql -u USER -pPASS BLOGDB <  xyzbogdb

    ERROR 2006 (HY000) at line 66: MySQL server has gone awayとエラーになる。
    66行目でエラーというので66行目を見ると、
    LOCK TABLES `mt_author` WRITE; となっている。
    ここで、LOCK TABLESとなっているのが悪いのかと思って、UNLOCK TABLESにsedを使って書き換えてみたが、今度は別のエラーになって、構文のエラーなのでマニュアルをよく読めと言ってくる。
    ここでお手上げかと思ったが、Netで色々調べたら、mysqlの転送の最大パケット数が不足していることが分かった。
    エラーになった行に、たまたまLOCK TABLESの語句があったので、これが原因かと思って混乱してしまった。ともかく、以下のようにpacket数を修正した。

    # vi /etc/my.cnf
    ・
    [mysqld]
    ・
    max_allowed_packet = 1M → 32Mに修正した

    ちなみに、[mysqldump]のセクションでは、max_allowed_packet = 16M となっていた。
    mysqlを再スタート

    # /usr/local/etc/rc.d/mysql-server restart

    ここで、再度DBのリストア

    # mysql -u USER -pPASS BLOGDB <  xyzbogdb

    今度はエラーなく無事終了した。

    3.ブログの再構築

    mt.cgiをブラウザで開いて、ユーザー名。パスワードを元のサーバーで用いていたのを使いログインし、複数のブログを順次開いて、公開パスが予備サーバに対応したものになっていることを確認し、サイトの再構築を行う。
    blogurl.jpg
    これで、無事終了である。書くと複雑のようだが、分かってしまうと沢山のページを有するブログであっても短時間で引越しができる。

    2010.12.05

    MTのエントリーの編集画面(2)

    以前に、MTのエントリーの編集画面で、編集画面で表示されるタイトルの長さが短すぎるのを修正した。
    しかし、MTのバージョンを3.35にしたら編集方法が違っていたので、以下にその方法を書いておく。/mt/lib/MT/Appに移動してCMS.pmを編集する。

    # cd ・・・/mt/lib/MT/App
    # vi CMS.pm

    修正場所はの6343行目あたりで、下記の赤字部である。すなわち、my title_max_lenを32の固定値にする。

        my %blogs;
    require MT::Blog;
    #    my $title_max_len = const('DISPLAY_LENGTH_EDIT_ENTRY_TITLE');
    my $title_max_len = 32;
    my $excerpt_max_len = const('DISPLAY_LENGTH_EDIT_ENTRY_T ・・・

    ついでに、最近のエントリーのタイトル表示も長くしておく。1906行あたりである。

          $row->{status_text} = MT::Entry::status_text($entry->status);
    #      my $max_len = const('DISPLAY_LENGTH_MENU_TITLE');
    my $max_len = 32;
    if (defined($row->{entry_title}) && ($row->{entry_title}・・・

    タイトルが長い場合は2行にわたるようになるが、通常は1行に納まる場合が多く、不都合はない。むしろ、良い感じになった。

    2010.08.31

    PageButeでMT-3.35のページ分割

    以前、MTPagenateというプラグインを使ってメインページの分割を行った。
    しかし、このためにはphpが動く環境を構築して、index.htmlをphp化してindex.phpとして、index.htmlにアクセスしてきたのをindex.phpに振り向けるRedirectの設定を.htaccessで行う必要もあった。

    ところが、その後PageButeと言うプラグインが提供されて、php化することなく簡単にページ分割ができるようになった。以下は、本ブログでメインページを分割した内容である。
    ただし、本ブログはMTのVersionが3.35であり、MT4あるいはMT5の場合は、些か異なるのでネットで他の記事を参照されたい。

    なお、カテゴリーのページも同様に分割できる。(適用ブログ例)

    (1) まず、PageButeをダウンロードして解凍する。

    (2) 解凍したPageBute.plをmt/pluginsディレクトリーに入れる。
    (3) 設定内容(メインページに赤字部を挿入)

             <div id="pagebody">
                <div id="pagebody-inner" class="pkg">
                   <div id="alpha">
    <div class="content-nav">
    <MTIfPageBefore>
    <span><$MTPageBefore delim="前の5件"$></span>
    </MTIfPageBefore>
    <$MTPageLists$>
    <MTIfPageNext>
    <span><$MTPageNext delim="次の5件"$></span>
    </MTIfPageNext>
    (全エントリー数:<$MTBlogEntryCount$>)
    </div>
                      <div id="alpha-inner" class="pkg">
    <MTPageContents count="5">
                         <MTEntries lastn="500">
    
    <$MTPageSeparator$>
                         </MTEntries>
    </MTPageContents>
                 </div>
    <div class="split">
    <MTIfPageBefore>
    <span><$MTPageBefore delim="前の5件"$></span>
    </MTIfPageBefore>
    <$MTPageLists$>
    <MTIfPageNext>
    <span><$MTPageNext delim="次の5件"$></span>
    </MTIfPageNext>
    (全エントリー数:<$MTBlogEntryCount$>)
    <br><br><br></div>
              </div>
    

    2008.01.22

    Movabletypeの3.25から3.35へのUpdate

    MovabletypeはMT4が出て賑やかだが、大幅なUpdateで従来細工していた内容を入れ込むのは大変だし、デザインなども用意されているのを選んで使う場合は便利であるが、自分でデザインするのはかえって不便にも感じられた。もちろん慣れの問題であろうが。
    3.25に加えて、修正したのはMT/tmpl/cms/upload.tmplで、アップロードしたときに格納するデフォルトのディレクトリーを入れたことぐらいである。

    <input name="extra_path" id="extra_path" value="archives"/>
    

    value=”archives”を追加した。

    2007.02.10

    コメントスパム攻撃

    攻撃、そう正に攻撃です。

    昨年暮れに、HDDがおかしくなり、大急ぎで新しいHDDでサーバを立て直し、やれやれと安心していたら、年が明けてしばらくしてから、どうも調子が悪い。
    日に2~3回、外からWebページにアクセスしても無応答で、サーバがダウンしたかと思っていると1時間ぐらいで回復することが繰り返されていた。 最初のうちは、外からアクセスするばあいのproxy serverがbusyかなにかだろうと思っていたが、どうもそうでは無いらしいと気づいた。 が、しばらくすると回復するので忙しさにもかまけて放っておいたが、終に我慢の限界に達して、本格的に調べる決心をして待ち構えていた。

    そして、それは起こった。 HDDのアクセスランプは点きっぱなしでなにやら激しくアクセスしている音が聞こえる。
    早速、ログインしてtopでプロセスを見ようとしたが、ログインも出来ない。 pingには応答する。
    以前にDOS攻撃やられたこともあり、とにかく、何かの攻撃らしいとみて、LANケーブルを抜いて、Localでログインしようとするが、一向に回復しない。 30分ぐらい経過して何とかログインできてtopコマンドを打って驚いた。
    wwwが起動するperlプロセスのオンパレードで、まだキューに350ほど溜まっている。
    もちろん、メモリーは全部食いつぶされて、HDDのswapを使って必死に実行しようとしているのだ。

    1. 対策

    ここで、ブログに対するコメントスパムの攻撃だろうと気づいたが、どう対策するか考える必要に迫られた。
    MTに対するコメントスパムに対する対策はネットで調べると、沢山引っかかり、日本語文字の含まれていないコメントはリジェクトするとか、コメントの投稿formにhidden属性でキーワードを仕込んでおき、それをチェックすることで、ちゃんと投稿欄に書き込んだかをみるなどの方法が書かれている。

    これらは有効な方法で過去には見事にスパムを撃退することも出来たが、今回はこれらは役に立たない。
    何故なら、以前に取った対策は有効に機能していて、まったくコメントの投稿を防いでいるのだが、あまりのも激しい攻撃で、コメントの妥当性をチェックするに要する時間より短い間隔での攻撃だからだ。
    ログを見ると1秒間に30回ぐらいの攻撃が延々と続く。

    最初に思いつくのはコメント処理のcgiのファイル名を変えることであるが、ネットで調べると1週間ぐらいしか持たないらしい。 たしかにブログページを解析すれば、直ぐにcgiの新しいファイル名は知れるのだから、そうかも知れない。 1週間に1回の割合でファイル名を変え、mt-config.cgiのScript名を、それに直してすべてのブログを再構築するなどやっていられないですよね。

    ここで、見つけたのが、
    Junk Slowdownというページです。
    mt-comment.cgiの名前を変えると同時にmt-comment.cgiにアクセスしてきたら.htaccessのredirect機能で別のところに飛ばし、受け付けない旨のメッセージを返し、また30秒のDelayを入れることだ。

    具体的に方法は、
    (1) Movabletypeがインストールされているディレクトリーの.htaccessに次の2行を追加

    RewriteEngine on
    RewriteRule ^(mt-comments|mt-tb|mt-comcom|mt-tbtb)\.cgi$ /xyz/sand-trap.php [LAST]

    /xyz/sand-trap.phpは、飛ばし先である。
    (2) comments.cgiとmt-tb.cgiの名前を変更
    ここでは、comments.cgi → mt-koment.cgi, mt-tb.cgi → mt-back.cgi として例示する。
    mt-config.cgiのコメントとトラックバックのScriptを変更。 もし、コメントとトラックバックに関するScript指定の記述がmt-config.cgiに無ければ、下記の2行を追加する。

    CommentScript mt-koment.cgi
    TrackbackScript mt-back.cgi

    そして、全てのブログページを再構築
    (3) sand-trap.phpを作って /xyz/ディレクトリーに入れる。 もちろん、phpの実行環境がない場合は、perlで記述してもよい。 下記はphpの例である。

    <body>
    
    <div style="font-size:200%;
                text-align:center;
                background:#822;
                color:white;
                border:2px solid red;
                padding:1ex;
                margin-bottom:1ex;
                ">
    Sand Trap
    </div>
    
    <p style="border:2px solid red;
              padding:1ex;
              ">
    You have been redirected to this script because
    you have used an obsolete resource to which
    no references exist on this website. This makes
    you presumably a junker, and therefore your
    session has been bogged down with this webpage.
    </p>
    
    <?php
    ob_flush();
    flush();
    sleep(30);
    ?>
    
    <p style="text-align:center;
              border:2px solid red;
              padding:1ex;
              margin-top:1ex;
              ">
    If you are going to abuse me, I will abuse you right back.
    </p>
    
    </body>

    適用したら、効果テキメン。 やっとサーバを安定稼動状態に保つことができた。
    どうも、スパム対策は、妥当性のチェックの精度を上げることに血道をあげてもダメで、DOS攻撃ライクの集中攻撃に対する対策を考える必要の段階にきたようだ。
    今回の方法も破られる時がくるのではと心配である。 次の対策もいまから策を練っておく必要がありそうだ。

    Next »