StatPress Reloaded

WordPress のプラグインで、アクセス解析というのがあったので入れてみた。名前は StatPress Reloaded。ただこれはあくまでも WordPress のアクセス解析なので、WordPress に来た分しか録れないが。まぁでも面白そうなので。ところがけっこう情報が古い。どういう情報かというと、OS やブラウザが 3 年ぐらい前で止まっている。あと日本の検索エンジンにまったく対応していない。
というわけで設定ファイルを書き換えて、Docomo や Sleipnir 、livedoor、Yahoo Japan、Rakuten などに対応させた。これは、seachengines.dat を書き換えればよい。

Yahoo|search.yahoo.|p|
Yahoo|search.yahoo.|submit|
Rakuten|websearch.rakuten.co.jp|qt|
Docomo|search.smt.docomo.ne.jp|MT|
Bing|www.bing.com|q|
Bing|bing.com|q|
Sleipnir|search.fenrir-inc.com|q|
Conduit|search.conduit.com|q|

Windows 7, 8 に対応したい場合はos.dat を

Windows 8|WindowsNT6.2|
Windows 7|WindowsNT6.1|

のようにすれば OK。
ただ、この StatPress、痒いところにはなかなか手が届かないようで、出す情報も少ない。この辺、もっといろいろ表示出来ると良いんだけど。まぁだいたいダイジェストって感じ。ただ、訪問者の追跡(どのページを最初に見て、その後どのページを見ていったかなど)がけっこう楽なのが面白い。ブログだとそういう遷移が解った方がイイのだろう。
stat_view

アリスソフトさんのアレ

2 月に起きたアリスソフトさんの件について、色々とこちらのサーバの構成を変えるべきかも知れないと思ったので日記に記す。例の事件の時もボクは大忙しで、この事件の詳細については調べる時間がなかった。ただおおむねざっと情報を横断したところ、納品先に渡すためのダウンロード・ディレクトリが洩れてしまったというのが原因の様だった。
これはどういうことかというと、ファイルをやりとりする際、こちらから一方的に送るだけの場合、利便性も考えてブラウザで落とせるようにするのが一番よい。そのため、ウェブサイトのどこかにそのデータを置き、そのデータのアドレスを相手に知らせて、ダウンロードしてくださいね、とやるのである。
この方法は実に便利で、この amatsukami.jp サーバにもある(爆)。こう言うことを書くのは非常によろしくないのだが、とは言え、まったく書かないと話が通じないので、バラしてしまった。とにかくあるのだ。主な用途は成果物の納品や、雑誌社さんに渡す素材などだ。しかも利便性を優先して、パスワードはかけていない。
そしてこの仕組みはもう 10 年以上、使ってきている。
バレないという保証はないが、いくつかのステップは必要である。

  1. ダウンロード・アドレスの特定
    どの URI からダウンロード出来るのか、知る必要がある。基本的に外部からは推測して当てるしかないが、おおむね想像がつくことも多い。たとえば、DL や Download っていう単語が入っていたり、アップローダ的な使い方をしていれば、Upload や UL、UP など。他にも Send とか To とか From とか、その手の単語は推測されやすいかも知れない。
  2. ファイル名の特定
    ダウンロード・アドレスが解っても、ファイル名が解らなければダウンロード出来ない。というのも、ダウンロード・アドレスを指定しただけでは、404 エラーなどでハネられてしまうからだ。但しここで注意が必要なのが、ファイル名ではなく、ディレクトリが指定されると、そのディレクトリにあるファイルを返してしまうという設定がある。これが ON になっていると、目も当てられない。ダウンロード・アドレスに置いてあるすべてのファイルが見えてしまうからだ。

というわけで、上の二つの名前が分からなければダウンロードはできない。そして基本的にこのダウンロード・アドレス+ファイル名の URI を知っているのは、ボクが「ここからダウンロードしてくださいね~」って教えた相手だけのはずなのだ。だからその人が漏らさない限り解らないし、Google などの検索エンジンに乗ることもない。

今回のアリスさんの場合、なんと Google で検索すると出てしまうらしい。
ここがボクはよく解ってないのだが、当事者同士のやりとりなだけのはずなのに、なんで Goolge に載ったんだろうってことだ。もう検証サイトとかできてるのかな。もし情報を持っている人がいたら教えて欲しいです。考えられることとしては、忘れないようにか、何かの理由で、URI をどこかに貼り付けておいたのが、Google に収拾されてしまったか、たまたま URI の推測に成功した人が、どこかの掲示板か何かに載せたか……でもそんなことってあるのかなぁ??

というわけでこのようなことが起きたため、ボクもダウンロードについてはどうしようか今も考え中である。まずは、一定期間経つと、そのダウンロード・アドレスに置いたファイルは削除する様にした。もともとダウンロード用のデータというのは自分の手元にマスターがあり、それを ZIP なり CAB なりで圧縮して渡しているので、ダウンロード・アドレスにあるファイルはなくなってもかまわないものだ。なので、ファイルの更新日付をチェックし、一定期間が過ぎたファイルについては自動的に削除するスクリプトを組んだ。
さらに今後対策していこうと思っているのは、以下の通りである。

  1. ダウンロード・アドレスをランダムに生成する
    ファイルを用意するたびに、ダウンロード・アドレスはランダムに生成する様にする。もしくは、相手先それぞれにダウンロード・アドレスを用意する。この際、ワイルドカード サブドメインも利用すると、より複雑になると思われる。
  2. ファイル名もランダム生成する
    ファイル名もランダム生成し、推測できないようにする。
  3. IP 制限をする
    提出する相手はだいたい会社が多いので、固定 IP を引いているところがほとんどだ。なのでそれ以外からはアクセス出来ない様に IP で制限してしまう。

1 と 2 についてはちょっとスクリプト(今なら PHP)を書く必要がある。
どちらにせよ、数ヶ月以内には対応しないとダメかなーと思っている。

WordPress あれこれ

某サイトをガリガリと作っていた。そのうち TAMA Networks でも挨拶する予定なんだけど、とりあえずサイトを紹介。

どれも WordPress で構築されている。
これらを組んだおかげで、WordPress で自由奔放にサイトを構築出来るようになった。Galette のサンタフル☆サマーのサイトも WordPress である。でも失敗しているところも実はあったりして、例えば GLacé のメニューはパーマリンクが失敗していて、カテゴリ ID が丸見えだったりとか(汗)。これは Windows Server だと rewrite がうまく動かなくなってしまった部分があって、仕方なくこうなっている(汗)。他にも相対・絶対ディレクトリの指定間違いとかがあったりして、そのたびに「あわわ」と慌てたり……いや、ちゃんとチェックしろよ(汗)。

スタッフ・ブログはいわゆる投稿ページで構成されているんだけど、サンタフル☆サマーはすべて固定ページで構成されている。スキンの方に PHP でページ名を判別して、レイアウトを変更している(現在の所、年齢認証、トップページ、その他の三つ)。GLacé 本体のサイトはトップページが固定ページで残りのページは投稿ページを使ってお知らせやダウンロードなんかを構築している。
スタッフ・ブログが一番 WordPress らしい使い方である。

なんでベタの HTML で組まなかったかというと、前の日記にも書いたような気はするけど、WordPress で構築しておけば、HTML が書けない人でもあとから更新出来るからってのが大きなメリットだったんだけど、実際に作ってみるとけっこう HTML の知識が必要だということが解った(爆)。特にサンタフル☆サマーのサイトはほとんど HTML ベタうちでつくってある(汗)。ただ、一応ボクが組んだヤツをコピペすればいいようにはしたんだけど……うーん、難しいなぁ。というのも、実は WordPress のエディタだけで作れないこともないんだけど、エディタ上で組むと、<div> や <span> を無視して改行されてしまったり、画像を挿入されてしまったりしてなかなか使いづらい。せめて <div> とか各段落ごとにうまく区分けして編集出来るようになってれば、WordPress のエディタでもいけそうなんだけどなぁ……。

ところで今回苦労したのが IE9 。とにかく IE9 だと、位置がずれるずれる。
基本 IE10 で作って、Google Chrome で確認してるんだけど、この二つはほとんど差はなく作れたんだけど、IE9 だと凄いずれる。主な原因は、Absolute。特にサンタフル☆サマーのトップページは重ねが多いため Absolute の嵐なのだが、right や left を設定してないと、親の ID(もしくはクラス)の text-align に左右されてしまうのね。本来座標を設定してないと、親の左上が起点になるはずなのだが、IE9 だと text-align で center とか設定されていると、親の真ん中の座標を起点に配置されてしまうのね……。もー。
あと CSS の座標指定を間違えて、 px じゃなくて x って書いてしまったところがあったんだけど、IE10 や Google Chrome ではそれを px として解釈して意図した位置に表示されたんだけど、IE9 では解釈してくれなかった。ところが HTML 側の表示順序を変えたら、意図した座標に表示されたりして、なんだこれw。
ただ IE9 は Windows 7 にデフォルトでついてくるブラウザなので、あんまり無視出来ないのよね。ちなみに IE8 や IE7 では確認してない(ぁ たぶん正しく表示されないような気がする。

まー、そんなこんなで、まだまだ WordPress、というか CMS を使ってサイトを簡単に構築する方法の模索は続きそうだ。
wp

拠点間 VPN

ボクの開発室は 9 月の末に引っ越した。これはいわゆる「開発分室」というヤツで、本社は今まで通りの場所にそのままあり、そして機能している。分室の方はボクがサーバをたて、いろいろ開発に使っているのだが、本社にはそこまで多機能なサーバはない。ただ、ボクがいる開発室は本社とは独立した部隊であり、あまり本社の業務内容に関わることはなかった。
が、いろいろと業務が進むにつれ、本社と連携をとらなければならない業務もあり、前々から VPN を貼りたくて仕方がなかった。でもそのためには、分室に置いてあるのと同じくらいのサーバを本社にも置く必要があった。う~ん、どうしようかなぁなんてここ数ヶ月悩んでいたんだけど、ふと本社も分室も同じルータを使っていることを思いだした。

「そうだ、ルータで VPN つなぎゃいいんだ」

って、なんで今までそのことに気付かなかったのか?
いや、実は気付いていたのだ。それでも VPN を積極的に張る気にならなかった。その理由は名前解決である。VPN を張った場合、当然 Windows ネットワークによるいわゆる共有フォルダのアクセスがメインの使い道になるわけだが、分室は DHCP を Windows Server が担っており、事細かに設定出来るため、本社側のマシンを分社の DNS に登録することにより、マシン名でアクセスすることができる。
一方、本社側の DHCP はルータ頼みになっており、分室側のマシンの名前解決ができない。また、ムリヤリ DNS サーバを VPN 先の分社側の DNS を参照するように設定は出来るが、万一 VPN が切れてしまったら、本社では名前解決ができなくなる(DNS を複数指定することはできるが、VPN が復活した後、自動的に分室の DNS を使ってくれるようにはなってくれない。DHCP に再度問い合わせる必要がある)。

そんなわけで、本社⇔分室の VPN 接続はここ数ヶ月、ずっと棚上げになっていたのだ(笑)。
が、様々なプロジェクトの進行上、さすがにそう言うワケにはいかなくなり、今日、ようやく重い腰を上げた。結局名前解決の問題は解決せず、単純に IP アドレスでアクセスすることにした。いわゆる「\\192.168.101.1」とかいう書き方である。

VPN 自体の接続はすぐにでき、あっという間に本社と分室でデータのやりとりができるようになった。VPN の確立が成功したら、分室側に本社の人のユーザを登録し、分室の Active Directory にアクセス出来るように設定した。さらに頻繁に使う人に対しては、hosts ファイルを書き換え、よく利用されるであろうマシンの IP を登録。原始的ではあるが、こうすることによってマシン名でアクセス出来るようにした。

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 のオープニングはこれのパクリオマージュである(ぁ