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’, ‘テンポラリ・フォルダへのパス’);

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

サーバが大変なことに!

rural_sy00e
Microsoft の定例パッチが降ってきた。あれだよね、なんかこれって神託みたいな感覚だよな(笑)。振り回されたりするし。で、amatsukami.jp サーバは物理サーバを含めると 4 台のサーバで構成されている。これら 4 台にパッチを当てるわけだが、当てる順番はトラブルを起こしても良い(あまり重要ではない)サーバから順に当てられる。
で、パッチ当てそのものはすべて正常に終了したのよ。案の定再起動を要求され、再起動してみたあとが、大変なことに。
まず、メール・サーバに接続できなくなった。そして、リモート・デスクトップも不通に……。慌てて Hyper-V マネージャから接続し直すも、イマイチ原因が分からない。イベント ログを見てみると、「時間がなんかずれてるんじゃボケ! 」って書いてあった。

しまった!!

amatsukami.jp サーバは PDC(Primary Domain Controller)に相当するマシンが Hyper-V 上に構築されているんだけど、そいつがプロバイダが提供する NTP サーバから時刻を取得し、他のサーバはこの PDC から時間を得ている。11/25 にプロバイダを変更したのだが、参照先の NTP は古いプロバイダのままだった。通常、プロバイダの NTP というのは自社で提供するネットワーク内からしかアクセス出来ないようになっている。
そのため、サーバはずっと同期を取れないままになっており、少しずつ amatsukami.jp の全サーバの時計が狂っていたのである。で、メールを受信したとき、もしくは中継したとき、サーバの時間を使うわけだが、サーバの時間が狂っていると未来からメールが来たりして、いろいろと問題が起こる(爆)。
ちょいと勉強不足なのだが、昨今のメール・サーバというのはどうもサーバの時間も見るのだが、外部にも参照しに行っているのか、それともメールのヘッダを見て、時間をチェックしているのか、サーバの時間が GMT とずれているといろいろとエラーを通知してくるのである。
そんなわけで、PDC の NTP サーバを設定し直し、同期が取れることも確認。そしてその後、他の三台も PDC と同期をとらせ、無事解決した。

しかし原因を究明するのに少し手間取ってしまい、せっかく 3 時には寝られると思ったのに、寝たのは 5 時だった……orz
曲は Pillows 。なんとなく今回のトラブルを表してみました(謎)。

WordPress への spam がひどい

朝、っていうか昼頃か(ヲイ)、目を覚ましてメールをチェックしたら、未読メールが 20 通くらいたまってた。

何事!?

仕事関連は寝る前(朝 7 時頃)までに片付けたはずだが、その間に何か問題事でも起きたのかと戦々恐々としながらメールを開いてみると、TAMA Networks への書き込みであった。しかもいずれも spam だった。
さらに、そうやってメールをチェックしているそばから、新たな spam 書き込みが!
TAMA Networks は WordPress に移行してから、日記へのコメント書き込みは管理者の承認が必要となった。そのおかげで前と違って、spam 書き込みが表示されることはなくなったのだが、それにしてもこう頻繁に書き込まれてくるとは……。
1 時間に 5 通ぐらいやってくるときもある。うう~む、これはひどい。
原因はおそらく、Wordpress にデフォルトで設定されている更新 ping のせいであろう。コイツはブログサイトやブログ系のポータルサイトなどに対して自分の更新を伝える機能で、更新 ping をそういったサイトに送ることにより、自分のサイトの情報をそれらのサイトにも掲載してもらえるのである。

いや、そもそも更新 ping を送っていることを、この spam が来て初めて知った(というか、予測した)。案の定 TAMA Networks の WordPress の設定を見てみると、しっかりと設定されていた。迂闊だった。
とはいえ、これはこれで便利だって言うか、日本のサイトに設定しちゃえってことで、とりあえず yahoo などの有名どころのサイトに更新 ping を送るように設定しておいた(マテ)。

まぁこんなんで来訪者が増えるとは思えないが……。
とは言えもうすでにボクのサイトは spam 業者に知られるところとなったので、この更新 ping をやめたからといって、spam がなくなるわけではない。これからしばらく(ずっと?)、spam 書き込みが続くことだろう。
ただ面白いことが一つだけあって、spam が書き込まれるページというのが、エヴァのレビューなのよね。他のページにも来てるんだけど、全 spam 書き込みのウチ、42% がこのエヴァの記事に投稿されている。なんでだろうねぇ……。

曲は最近かぶりがちなのだが、Jazztronik から守破離。

hotmail にメールが出せなくなった。

ふと外注さんにメールを出したら、エラーで戻ってきた。
Hotmail からのエラー。
ヘッダをみると、以下のリンクが埋め込まれていた。

どうやらプロバイダを変更したことによって、「おめーの IP は勝手サーバで安全かどうかわからんから拒否する」(意訳)ということらしい。勝手サーバというのは運営する側のポリシーによって定義が異なるのだが、hotnamail の場合、プロバイダが振り出す動的 IP で運営されているメール・サーバのことをとりあえずは指しているようだ。これはマイッタ。OCN から WAKWAK へ移行した弊害のようだ。Hotmail は他のフリーメールに比べてこの辺が非常にきついイメージがある。
実は前も、Hotmail が使っている spam フィルタが勝手サーバをはじくようになっていて、いちいちそのサイトに自サバの IP を登録しないといけなかった。

  • 550 DY-001
    ポリシーを理由にメールが Hotmail によって拒否されました。通常、動的 IP から送信された電子メールは受信拒否されます。一般に動的 IP は、認証されない SMTP メールをインターネット メール サーバーに配信するためには使用されないからです。電子メール管理者またはネットワーク管理者のどちらでもない場合は、電子メールまたはインターネットのサービス プロバイダーに連絡して支援を依頼してください。動的 IP アドレスおよび固定 IP アドレスの一覧については、http://www.spamhaus.org を参照してください。

今回も同じで、spamhaus というところで蹴られているようだ。
調べて見ると、PBL というところに、WAKWAK の動的 IP がしっかりと載っていた。
とりあえず手順に従って、amatsukami.jp サーバの IP アドレスをこのリストから削除するように申請しておいたが……果たしてうまく行くか、行くとイイのだが……。ちなみに WAKWAK からウチへは amaterasu.as.wakwak.ne.jp というホスト名を割り当てられている。

とりあえずこれを早急に解いてもらわないと、外注さんとコンタクトとれない~~。
曲は Jazztronik から Beautiful Flow。

プロバイダと回線


11/25 に amatsukami.jp サーバのプロバイダを OCN から WAKWAK に切り替えた(その時の日記)。一週間が経ち、回線の違いが見えてきたので何となく公開してみようと思う。今回使われている図は知人のサーバからボクのサーバを監視してもらった結果である。
まず、24 時間の ping の反応グラフ。見ると解るように、だいたい 21 時頃から反応が鈍くなっているのが解る。これはつまりこの WAKWAK 回線のユーザが企業ではなく個人が多いことを示していると思う。会社から戻ってきて、食事も終わり、寝るまでの時間であると予測できる。それは週のグラフを見ると、より鮮明になる。

週のグラフで見ると、土日も同じように夜、反応が遅くなっているが、土日に関してはさらに昼間もいくつか反応が遅くなっている。これはつまり、WAKWAK ユーザが土日の場合、昼間も活発であることを示している。

最後に 1 ヶ月のグラフを示す。グラフが途中なくなっている部分がプロバイダを切り替えた部分で左側が WAKWAK、右側が OCN である。OCN の 24 時間グラフはもう過ぎ去ってしまって保存していないのだが、OCN では WAKWAK と違い、平日の昼間の反応が遅くなっていることが解る。そして土曜日もそこそこビジーだ。これはつまり OCN のユーザが企業が多いことを示していると思う。
最初はウチのサーバにアクセスに来る人たちがこういう行動を示しているのかなと思っていたのだが、こうしてプロバイダを変えてみると、回線のクセであると言うことがよく解る。

WAKWAK に変えて、今のところこれといった不具合というか不満は起きてない。ただボクのサーバの使い方も、実は変わりつつある。と言うのも今までボクが抱えていたプロダクトはすべてこの amatsukami.jp がインフラを担ってきた。FTP、SVN などなど大容量のファイルをやりとりするサービスをずっと提供してきた。しかしここに来て、自分の事務所で新しいサーバが立ち、大容量なやりとりはそちらで行われるようになった。今後、増々 amatsukami.jp サーバの役割は、新サーバへと移行していくことだろう。なので、個人ユーザの多い WAKWAK へ移行したのもなんとなく良いタイミングなのかも知れないと思っている。

下に貼り付けた曲は Terry Callier という人の Dancing Girl。1972 年の曲だけれども、ただのダンスっていうわけじゃなくて何となくもの悲しいメロディがすごく気に入っている。冬の夜に、心落ち着かせながら聞いて見てください。

Perl が動かない

今日こそは PHP を動かす!
というわけで、色々悪戦苦闘。0 から入れ直してみたりとか……でも、そもそもあんまりやることもない。
仕方がないので手がかりを見つけるために、PHP HTTP エラー 500(内部サーバエラー)で検索しまくった。
そもそもエラー 500 というのは漠然としたエラーというか、「なんか CGI がこけてんぞ」っていうようなことを表す程度のもので、CGI が動かなかったらだいたいこのエラーが返ってくる。だから HTTP エラー 500 なんかで検索しても、様々な原因がヒットするわけで……もはやこれを一つ一つしらみつぶしに見ていって、心当たりのありそうなものを探すしかない。
まさにローラー作戦である。

が、思いの外、原因はすぐに特定できた。
php.ini にTIMEZONE を設定する項目があるのだが、そこが何も書かれていないとエラーになるらしい。
そんなの今まで設定したことありませんけどー<マテ
とおもって、amatsukami.jp の方の php.ini を見たんだけど、特に TIMEZONE の設定はされてなかった。
んー、違うんじゃないかなぁと思いつつも、Asia/Tokyo を php.ini に設定してみる。
すると、動いた……orz

うが─────!!!!

この二日間はなんだったんだ……orz
まぁそんなこんなで PHP は動くようになったのだが、5.4.4 を入れたため、Pukiwiki Plus! は動かなかった……。
どうしようかなぁ、これが動かないといろいろ困るんだよなぁ。

で、新しい社屋には会議室が二つある。
で、本社にも一つある。
本社の人がこちらの会議室を使うこともある。
誰がどの会議室をいつ予約しているのかというのをウェブ上で見られるようにすればよいかなと思い、テキトーな会議予約システムを設定してみたのだが……今度は Perl が動かない!! うぎゃー、なんでじゃ!? と思って、サーバ インストール時に仕掛けた Perl で作られたシステムは動く。どういうことだ??

調べて見ると、Perl.exe では CGI としてちゃんと動くことが判明。
ところがこの Perl.exe は相対パスとかその辺に  UNIX と互換性がなく、Windows 版の Perl.exe で動かすことを考えて作られているプログラムなら問題ないが、それを考慮してないものは、ISAPI 版を使わないと行けないんだけど、この ISAPI 版の Perl が動かない。なんか、無許可の動詞を実行しようとしたといってエラる。そもそもすべての動詞を許可していますけどー。
その後、色々調べるも、IIS で POST(動詞の一つ)を受け付けなくなるというところにはたどり着いたんだけど……うーん、なんか違うような、あっているような??

というわけで Perl と悪戦苦闘するハメに……うもー、なんなんだ。
しようがないので Perl はおいておいて、会議室の予約システムを PHP のものを設置してみた。
phpScheduleIt というシステムで、なんでもこの手の予約システムでは定番のシステムらしい。で、設置はすんなりいったんだが、これが重い!! なんでこんなに重いんだ!? というわけで、ボクの感触としては設置に失敗しているような気がするんだよなぁ。だって 3GHz オーバーの最新の CPU のサーバだし、それでこんなに重いのはおかしい……。
実際に使ってみた人からも「重いんですが」という苦情が……うーん、PHP そのものの設置に失敗しているのか、それとも MySQL の設定が不味いのか、それとも phpScheduleIt の設置そのものが悪いのか……しっかしこんなにサーバ設定で苦労するのも久しぶりだなぁ……orz

そんなわけで、サーバの設定はまだまだ続きます。
だいたい、VPN とか証明書回りとかもぜんぜんできてないし(T_T)

PHP が動かない

開発機が安定したのでやっとこさ、サーバの設定に戻る。
まずは PHP の続き。
とにかく動かない。
HTTP500 エラー出っぱなし。出しっぱなし。困った。
ログを色々見てみるのだが(Windows イベント、IIS のログ、PHP のエラー出力 ON、localhost で実行)、まったく手がかりナシ。仕方ないので VPN とか証明書関係とかそういうのをやりつつ、時々「PHP、動くようになってないかなー」とか思ってテストしてみたり(動くようになっているワケがない)。
そうして一日が終わっていった<バカ
ちなみに直接コマンドラインから PHP を叩くと動くんだよねー。

いやー、こんなこと初めてだわー。
ちなみに Perl はあっさりと動いた(ただし、後日事件が起きるのだが)。

閑話休題。
引っ越し先の事務所のすぐ近くにあるつけ麺屋「来吉」に行ってきた。
基本、大勝軒などでおなじみの魚出汁のスープなんだけど、柚か何か柑橘系のモノが入っていて、後味がちょっとスッキリ。チャーシューは炙りチャーシュー。普通に美味しかったけど、麺が乾きすぎて、箸で麺を取ろうとすると、ボソッと全部取れてしまうw カウンターを見るとごま油が置いてあって「麺が取りにくいときはこれでほぐしてください」って、いやー、もうちょっと水分多くてもいいんじゃなかろうか(汗)。
 
ところで建物が民家を改造したモノなのかな? 外は雰囲気イイナーって思って入ると、中は普通のカウンターという(汗)。まぁいいんだけれども。なおカメラは iPhone ではなく Android 機(N-05D)。