WordPress とスタッドレス・タイヤ(何

相変わらず WordPress をいじっている。
テーマ(デザイン)さえ作っておけば、あとは HTML が解らなくても更新出来るのはよい。しかも WordPress には様々な関数が用意されているので、テーマの中にそれを仕込んでおけば色んなことが出来る。
とまぁ、ほとんど WordPress については理解したんだが、rewrite で変な現象が起きてしまった。それは、URI に必ず index.php というのが入ってしまうことだ。WordPress は rewrite と言う機能を使って、アドレスを自由に設定出来る。
本来、ブログのシステムというのはシステムに引数を渡して動く。例えば、2013 年 2 月 4 日の記事を見たかったら、amatsukami.jp/index.php?20130204 なんてアドレスになる。でもそれだとウェブページっぽくないので、amatsukami.jp/2013/02/04/ なんていう風に設定出来るのだ。amatsukami.jp/2013/02/04/ ってアクセスが来たら、サーバの方でこっそり amatsukami.jp/index.php?20130204 に書き換えているのだ。それが rewrite の機能である(ちなみに TAMA Networks では rewrite を動かしていない)。

事の発端は IIS で日本語の URI が通らないことだった。これが実は後に IIS のバグというのが判明するのだが、それと解らず、WordPress の方の rewrite の設定を変えてしまったのだ。ところがそれ以降、元の設定に戻しても index.php が必ずつくようになってしまった……orz。amatsukami.jp/2013/02/04/ ですむところが、amatsukami.jp/index.php/2013/02/04/ となってしまうのだ。
ネットで検索すると原因はいろいろあるようで、いろいろ試してみたんだけど今のところ解決出来ず。うーん、なんだこれ? ただ IIS はテスト用のサーバで、本番サーバは Linux の apache で動いているから特に問題はないのだが、テスト・サーバと本番サーバでURI が異なるという状態になってしまった。うーん、これは困った。これでは、テストで作ったコンテンツをそのまま本番にコピーすれば動くという環境じゃ無くなってしまうではないか。
まぁ IIS の方は合間合間に調べるしかないかなー。

BCQX6jQCYAACMUY
会社に着いたらスタッドレス・タイヤが届いていた。苦節一ヶ月。ようやくである。
スタッドレス・タイヤを買うことになったのは去年の 12 月、親父の PC の調子が悪いと言うことで呼ばれていたのだが、草津はすでに雪であり、スタッドレス・タイヤが必要だったからだ。そこで買いに行ったのだが、どこも売り切れだった。で、通販で買うことにし、12 月の終わりに注文したのだが、年明けになって「そのタイヤ、エスティマじゃ合わないかも」って連絡があり、選び直しになってしまい、さらにボクが自分が担当するブランドのウェブサイトとかで忙しくなってしまい、1 月の下旬に注文し直し、ようやく届いたと言うわけである。

今冬はこれで勝る!!!

ところでなんで前の車の時はスタッドレス・タイヤを持っていなかったかというと、走り屋仕様のスタッドレス・タイヤはすっげーたかくて、そのうち買おうなんて思っていたら車そのものを乗り換えてしまったでござる。いやー、エスティマのいい所ってとにかく大衆車ってことだよね。色んなパーツが安い。前の車なんて、車検でも毎回すごい金額だったので、エスティマになってからは(燃費以外)財布に優しい車だなーと思っている。

雑談色々

今日は特に大きなトピックがないので、箇条書きっぽく綴ります。
深夜、ちょっと作業の合間に amatsukami.jp サーバの FTP のログを見てたら、けっこう辞書アタックが来ててびっくりした。下手したら 24 時間やってることも。まぁ BOT だから時間なんて関係ないか。とりあえず 1 単語のパスワードがないかチェックした。最近は回線が速くなってるし、辞書アタックしやすいよね。
パスワードはランダム文字を使うようにしているんだけど、amatsukami.jp を使っている他の人たちは大丈夫かなぁと思いつつ……。

あとサーバの話ついでに、amatsukami.jp のバックアップ用 HDD が一つ逝った。この HDD でバックアップしていた内容は、別のもっと容量の大きな HDD にバックアップをとるようになったので、言わば使っていないに等しい HDD なんだけど……うーむ。まぁこれを機に捨てるかー。
ただバックアップ HDD は今、いろんな HDD に分散しちゃってるから、まとめたいんだよねー。4TB を 4 個ぐらいかってきて。でも、今、お金ないよー。

messenger
Windows Live Messenger が今年の 3 月でサービス終了する。で、Messenger を起動していると新しいバージョンがありますって表示されるのね。え、もうサービス終了するのに、バージョン・アップするんだ? ってクリックしたら、Skype 6.1 が落ちてきたwww ちょwww バージョンアップ違うしwww もうちょっと表現変えた方が(汗)。

temp
そして、気温がすごかった。なんと 4 月並みの陽気だそうで、天気予報では最高気温 20 ℃とか出ていた。すげー。汗ばむくらいの陽気だったよ。

いろはサントラ
最後に、久々に「いろは」のサントラがヤフオクに出ていた。さすがに万は越えなかったが、売値の 3 倍で落札されていた。 すごいなぁ……。

WordPress のテーマとか

カリカリと WordPress のテーマ用の PHP 書いたりしてた。
ボクが担当しているブランドのウェブサイト公開が近づいている。今までは HTML を書いていたんだけど、今回のブランドでは各プロジェクト・リーダーに更新させようと思っている。プロジェクト・リーダーは HTML や CSS に明るいわけではないので、更新のシステムに CMS を導入することにしたのだ。それが WordPress だ。 で、WordPress でブランド用のサイトのデザインを作っておき、ディレクタは WordPress を更新するだけでよいという方法を試すつもりだ。

ただ、うまく行くかどうかは解らない。と言うのも、エロゲ・ブランドのサイトを WordPress だけで作れるかどうか疑問な点がけっこうあるからだ。バナーだけのページとか作れるのかなぁ……?? 実はよく解っていない。

もう一つの懸念点はまったく違うテーマ(デザイン)をページごとに適用したい場合だ。WordPress では特定の記事のテーマを切り変えることが出来るがしかし、これは単純に今あるテーマにそのページ用のデザインを作るという方法をとっていて、まるごとテーマそのものを切り替えることができない。
エロゲではプロジェクトごとにオリジナル・サイトを用意することが多く、プロジェクトごとにデザインも何もかもが異なる。で、色々調べていると、どうやら WordPress はマルチサイト機能というのがあって、そもそも複数のサイトを一つの WordPress で構築出来るらしい。
モードは二つで、サブディレクトリ・モードとサブドメイン・モードだ。
サブディレクトリ・モードというのは、例えば、 amatsukami.jp が親だとしたら、amatsukami.jp/products/ とか amatsukami.jp/developments/ とかサブディレクトリで別のサイトを構築するモード。
サブドメイン・モードは、blog.amatsukami.jp とか tamaki.amatsukami.jp とかサブドメインで別のサイトを構築するモード。
このマルチサイト機能を使うと、各サイトごとにテーマが 0 から設定出来る。なので、まったく違うページも、一つの WordPress で出来てしまうのだ。これは便利!!
というわけで、本ちゃんのサーバはすぐに設定が完了した。それは本ちゃんのサーバが Apache だからだ。WordPress でマルチサイト機能を ON にすると Apache の設定ファイルも生成してくれる。だから、それをそのままサーバに設定すればよい。
ところが更新前のテストに使っているサーバは Windows Server で、そこに WordPress を入れている。マルチサイト機能を使うには rewrite という機能が必要だ。これはどういう機能かというと、URI を色々と内部で書き換えてくれる機能なのだ。例えばサイトを引っ越ししたときに、旧サイトから新サイトへアドレスをサーバ側で書き換えたり、CGI の引数をあたかも HTML の静的ページに見せたりとかそういうときに使う。
IIS には rewrite 機能があるものの、設定の方法が Apache と違う。で、結論から言ってしまうと、Apache の設定をそのまま IIS に設定する方法があるのだが、ボクはそれを知らずに一生懸命 WordPress の rewite の仕様を探してしまった……orz
rewite の仕様を読み、それから WordPress の書き換え後の URI を調べようとしたのだが、とにかくこの WordPress の書き換え後の URI について解説しているページが見つからなくて、あーでもないこーでもないと色々試行錯誤しつつ、だめだー 404 エラーになるーって途方に暮れていたのだ。
で、ふと IIS の rewrite の設定を見てたら、インポートって言うのがあった。よく見ると、.htaccess に書く Apache の設定をそのまま書けばそれがそのまま IIS の設定になるらしい。イヤン、もっと早く言ってよ!!!<お前の目が節穴なだけだ

ということで、無事、テスト・サーバでもマルチサイト機能が動くようになった。
で、まぁ色々とスキンもとりあえずトップページ用は完成したので、更新準備完了。
これから WordPress とは長いつきあいになりそうである。
紹介する曲は、アランフェス協奏曲。ギター協奏曲というクラシックではけっこう珍しい協奏曲。もっともこれをクラシックを認めない人も多いけど(笑)。その昔 Falcom の Brandish っていう RPG のオープニングはこれのパクリオマージュである(ぁ

たまきんは、正月に何をしていたか?

新年最初の更新です。が、まだ明けましておめでとうは言いません(汗)。
とりあえず年末年始の動きをざさっと。
マスターアップが一件近いので、基本的に仕事してました。スクリプト、プロット、他。親が帰省したので、ちょうど良いというか、一人で静かになれたので。でも考える時間が多くて、振り返ると進みが悪い。プロットの作成はひたすら資料集めとアイデア出しなので、思うように行かない。
他にも仕事用のサーバ周りをいくつか。というわけで今日はサーバの話です。たぶん長いです(ぁ

Hyper-V の仮想ネットワークとNAT

今 amatsukami.jp サーバは VPN を貼るのに仮想サーバを使っているんだけど、その理由は Hyper-V で構築した仮想ネットワークでは NAT をしていけないようで、仮想ネットワークに NAT を設定すると極端に転送速度が遅くなる(この辺とか、この辺とか、この辺とか、この辺)。なので、VPN を仮想サーバ上に構築し、そこで NAT を実現している。
でも考えてみれば、amatsukami.jp サーバには NIC が 2 枚刺さっている(Intel の NIC ともともとマザボについていたカニの NIC)。しかもカニの方を殺している。そこで、カニの NIC を復活させ、そこに仮想ネットワークを構築し、Intel の NIC をファイル転送用&外向きにした。仮想マシンでは主にメールや LDAP のやりとりが主なので、まーカニでいいでしょうと。
で、NAT とか VPN とかの設定をしようかなーと思ったんだけど、とりあえず NIC を二個使う設定をしたところで満足してやめてしまった(マテ

Redmine のデータベース移行

amatsukami.jp で運営している Redmine が不安定だというのは以前日記に書いた。結局それは解消されておらず、一日に一回 Redmine を再起動することで回避しているのだが、そもそもこの回避方法が気に入らない。結局原因は何なんだ? と言った所で、さすがにこれは他の人も困っているはずだろうと色々ネットをあさって調べて見たら(この調べるのに時間がかかる。しかもほとんど英語だし)、どうも最近は起きないらしい。それはつまりどういうこと? 最新の Redmine を入れれば起きないってこと?
というわけで、実は去年末から新しい仮想サーバを立ち上げ、そこに Redmine 2.2.0 を入れて試験運用してみていたのだ。で、とりあえず数日たっても落ちずに動き続けていることを確認。そこで古い Redmine からデータベースを移行して動かしてみた。

それからまた数日問題なく動いている。おぉ、これは成功かもしれん。いや、ただ単にバージョン・アップしただけだけどね!

さらにまた数日、データベースを移行しても動き続けていたので、本格的に事務所のサーバに Redmine を構築することにする。実は 20 時間ほどで飛んでしまうという現象のおかげで、勤め先のサーバには Redmine をセットアップしていなかったのである(この飛ぶ現象が解決できたら、入れようと考えていた)。
というわけで、勤め先のサーバに仮想マシンを立ち上げ、そこに Redmine をセットアップ。そしてデータベースを移行。これまた数日様子を見る。
そして数日後、無事、事務所の Redmine も動き続けていた。これが 1/1 の AM8:00 であった。
苦節 2 週間くらいであろうか。去年の 12 月の下旬頃からあれやこれやと実験を繰り返し、ようやく事務所サーバでの Redmine 運用にこぎ着けた。あー、めんどくさかった。もっとちゃんと英語が出来れば、たぶんもっと根本的な解決出来た(バージョン・アップせずに原因をつぶせた)と思うんだけど……結局バージョン・アップという形でなんとか解決できたようだ。

サーバの完全移行

実は Redmine は amatsukami.jp サーバに残っていた最後のサービスであった。
どういうことかというと、ボクの勤め先のサーバ機能は、最初 amatsukami.jp サーバを利用していたんだけど、去年の 10 月にサーバを用意してもらって、それから 1 ヶ月ほどかけて amatsukami.jp サーバから新しいサーバに移していた。でもこの Redmine だけは解決できず、ずっと amatsukami.jp サーバで運用していたんだけど、この 1/1 の朝 8 時を持って、amatsukami.jp サーバのすべての機能が、新サーバへと移行した。長かった~~~。ようやっと新サーバですべてが完結できるようになった。
amatsukami.jp サーバは今後、ボク個人の同人とかのサーバとして利用される予定である……っていうか、同人ソフト作る時間をください……orz

WordPress の spam 状況

相変わらず、WordPress への spam 書き込みがひどい。まぁ、すでに TAMA Networks が  spammer に周知されてしまったので、もうどうしようもないのだけれど。更新 ping は海外のブログ・サービスには送らないようにした。その辺の話題は、12/12 の日記に詳しい。まぁとはいえ、spam を書き込まれたからと言って、ボクが認証するまでは表には出ないので、このページを見にきてくれた人たちには何の影響もないと思う。

それにしても一日に何通も来るので(WordPress に書き込みをすると、ボクにメールが送られてくる)、ついでに数を調べて見たのだが、実に 75.7% が spam であった。残りの 24.3% がボクが承認した書き込み。いやはや、spam 率が高いですな。

でね、12/12 の日記で更新 ping を海外のものから、日本のものに送るようにしたと書いたんだけど、そしたら日本語での spam が多くなった(爆)。うひー、わたしが浅はかでした! まったくもー!! とりあえずメール通知やめちゃおうかなぁ……。

sakura VPS

bs_ryok01b
このところ、色んなサイトやネトゲに関わっているというか手伝っていて、その中でサーバの手配ってのがある。けっこう大きなネトゲだと amazon EC2 を使うんだけど、予算もないしあんまり人も来ないんじゃね的な場合は、sakura VPS を使ってみている。ところで Windows Azure や amazon EC2 と VPS サービスは似ているようで実は全然違う。もちろん用途によるが、Azure や amazon EC2 の方が圧倒的に楽である。ただこれもあくまでも大規模なサーバ群を構築するに当たって、という条件が付くが。
そんなわけで、ひりついたプロジェクトにはもっぱら sakura VPS を使っている(ぁ
コイツのいいところはとにかくなんでも自由に使えることなのだが(OS も自分でセットアップするし、どんなサーバ・プログラムを使うかも全部自分で設計して自分でインストールする)、いかんせんボクは UNIX が解らない(マテ。なので、設定は UNIX が解っているエンジニアがやる。

近々実験してみたいのが、VPS 上にエロゲの体験版やムービーなどを置くとどうなるか。
たかだか 3000 本出るか出ないかのソフトでも、体験版を公開すると一日の転送量がテラバイトを余裕で越える。なので、オフィシャル・サイト用の VPS とダウンロード用の VPS に分け、さらにデータセンターの場所も変えて、例えばオフィシャル・サイトが大阪、ダウンロード・サイトを石狩に置けば、ダウンロードがどんなに集中しようがオフィシャル・サイトは重くならないようにできるかなと……。そんなことを夢想している。
あと初っぱなからオフィシャル・サイトが IPv6 対応だだだ! ボクが設定したんじゃないけど(ぁ
というわけで、IPv6 でもつながるエロサイトになりそうだ。

ところで Windows サーバの VPS ってあるのかなと思ったら、一応あるんだけど、やっぱ高いねー。まぁ OS のライセンスが必要だからしようがないんだけど。こっちならボクでも 0 から設定できるんだけどなー。まぁ、コスト削減のためということで、もっぱら Linux 系の VPS を使うことが多い。
ボクも Windows の VPS を一台借りて、ミラーリングとかいろいろやってみようかなぁ……と思い始めている。
写真は、夜行った温野菜の写真。なんか面白い出汁だったので、写真に撮ってしまった。
いやー、最近ストレス太りしてしまった。もー、ストレスから逃げるために食べちゃうんだよね……やばいー。

1212190437

WordPress 3.5 アレコレ

bs_ruri01f
TAMA Networks で使っている CMSWordPress)がバージョン・アップして、3.5 になった。特に何の気もなく、バージョンアップしてしまった(マテ)。そしたら予想以上にいろいろ変わっていたので、ちょっとびっくり。今度からはちゃんとリリース・ノート読もう!<サーバ管理者としてあるまじき行為
なんと言っても一番変わったのは画像などを貼り付ける画面。今までと全然違う。今まではアップロードが前提となっていて、画像を貼り付けるたびにアップロード画面になって面倒だった。何故面倒かというと、日記で毎日使われているキャラクタの顔は、既にアップロードされているデータであるため、既にあるデータを選ぶ画面(ライブラリ)に切り替えてなくちゃいけなかった。っていうのと、アップロードされたファイルは新しい順に表示されるので、古い方に切り替えなくちゃいけなかったし。それに、写真などをアップロードしたときも、まとめてアップロードしたあとはアップロード画面ではなく、ライブラリ画面から選ぶわけで、アップロード画面なんていうのは、最初だけしか使わないのである。
3.5 になってから、ライブラリ画面がデフォルトとなった。さらに複数の画像が一度に貼り付けられるようになった。今までは一枚貼ってはメディア画面を開き、ライブラリ画面に遷移し、画像を選んでいたのだが、3.5 からは貼り付けたい画面を CTRL や Shift キーで選べば OK。あとはどばーっと並べて貼っ付けてくれる。

トラブルと言えば、アップデート機能が動かなくなったこと。エラー・メッセージを見てみると、C:\Windows\Temp にアーカイブ・ファイルがねーよと出ていた。そこで原因はすぐに分かった。そのフォルダはそもそも PHP などで書き込みできるようにはしていない。CGI でアクセス出来る場所は別に用意してある。今までのバージョンでは php.ini に書かれているテンポラリ・フォルダを見に行っていたようだが、3.5 では Windows の環境変数を見に行ってしまうようだ。
そこであれこれ色々調べて見ると、どうやら WordPress には WP_TEMP_DIR という定数があるっぽい。ここに、CGI 用のパスを設定すればよいのだろうと勝手に推測<ソースを見んかい! wp-config.php に勝手に以下の一行を追加。

> define(‘WP_TEMP_DIR’, ‘テンポラリ・フォルダへのパス’);

無事に更新機能が動くようになった。めでたし、めでたし。