WordPress じゃなくて IIS の設定だったでござる

amatsukami.jp サーバはボクのサイトだけでなくいくつかのサイトを運営しているのだが、その中には TAMA Networks と同じ WordPress を使っているサイトもある。そのサイトの管理者から 60MB のファイルがアップロードできないと連絡があった。

試しに TAMA Networks で 60MB のファイルをアップロードしようとするとするとすんなりアップロードできてしまった。んー? なんだこれ? 同じ amatsukam.jp サーバ上で動く WordPress なのに差なんてあるのか?

と思って、コンフィグ ファイルを見たり php.ini を見たりしたんだけど、よく解らない。
というか 30MB 以上アップロードできるようになっているように見える。

で、「Windows Server 30MB アップロードできない」とかで検索したら、Microsoft のウェブサーバIIS)はデフォルト設定では 30MB のファイルサイズ制限がかけられているらしい。っていうかたぶん TAMA Networks はそれを外していたようだ。

というわけで、それを設定したら無事ファイルはアップロードできるようになりましたとさ。

リバースプロキシの基本がわかってない(ぁ

さて、昨日は古い PHP で動く旧コンテンツを、リバースプロキシApplication Request Routing)を使って別のサーバに追い出すことに成功した。ということはだ、今別サーバで色々動いているものが、少なくとも見た目上は一つに集約できるのではないかということに気づく。

今、Redmine(プロジェクト管理)やグループウェア(Aipo)なんかが動いてはいるんだけど、それらは全部 HTTP でやりとりするのね。しかも Windows で動かすと全部独立したサービスで動くため、これらを一つの HTTP で動かすわけにはいかないという状況だ。

そこでどうしているかというと、不特定多数の人がアクセスするサービスはデフォルトに割り当て、ボク一人で使っている Redmine やグループウェアは TCP ポート番号を分けることによって使い分けていた。
たとえば、http://amatsukami.jp:9999/ なんて感じだ。でもこれはデフォルトの動作じゃないし、見た目もよろしくない。

リバースプロキシを使えば、http://amatsukami.jp/redmine/ ってやると http://amatsukami.jp:9999/ にアクセスするように設定できる。こうすることによって、全て http://amatsukami.jp/ で完結できる。

というわけでさっそく一番使用頻度が高いグループウェアで設定してみようとするんだが、これがうまくいかない。ホスト名が一致しないのだ。
どういうことかというと、リバースプロキシ経由になるということは、グループウェアにアクセスしに来るのはリバースプロキシと言うことになる(アクセス経路は以下の通り)。

ユーザ → リバースプロキシ → グループウェア

リバースプロキシとグループウェアは LAN 内で結ばれていて、お互い LAN 内の名前(ホスト名という)で呼び合っている。この LAN 内のホスト名はインターネットの世界では通用しない。でもグループウェアは呼ばれたホスト名で応答するように作られており、リバースプロキシは LAN 内でしか有効でないホスト名をそのままユーザに返してしまうため、インターネット網にいるユーザは結局アクセス出来ないのだ。

じゃぁ旧コンテンツはどうしているのかというと、旧コンテンツのエンジンである Pukiwiki Plus ! は返すホスト名を固定できるのだ。このホスト名をインターネットで通じる名前にしておけば問題ないというわけである。
ところがボクが使っているグループウェアにはこの機能が無い。
ただこの時、ボクはグループウェアの方に着目してしまったのよね……これが遠回りの原因になってしまった。グループウェアはオープンソースなもんだから、ソースとかを見始めちゃったのよね……orz
結局、この日は解決することができなかった
(正解はリバースプロキシ側に、ユーザがアクセスしてきた時のホスト名のままでアクセスするという設定があるのだった)

下の写真は浅草橋で一番美味しい(とボクが思い込んでいる)、ろく月の豚白湯麺とチャーシュー丼。うまいー!

リバースプロキシって便利!

TAMA Networks の急コンテンツは Pukiwiki Plus ! というシステムで動いている。コイツは PHP 5.2 じゃないと動かない。5.3 以降では動かないのだ(どうも動くらしいのだが、IIS ではセキュリティ関連の機能がまったく働かない)。そのおかげで、amatsukami.jp サーバはずっと PHP を更新できないでいる。そうこうしているうちに PHP は 7 になってしまった。

一方、現在の TAMA Networks は WordPress というシステムで動いていて、これは現役のシステムであり、バージョンアップもされている。
そしていつかは WordPress が PHP5.2 では動かなくなるはずだ。現に WordPress のプラグインなどは 5.2 で動かないものもチラホラ出始めている。
しかし、先の Pukiwiki Plus ! のおかげで、こちらは PHP のバージョンを上げられない。
何かいい方法はないものか? と、色々考えたあげく、二つの方法を思いついた。

  1. amatsukami.jp サーバで複数のバージョンの PHP が動くようにする
  2. リバースプロキシを使って、Pukiwiki Plus ! を amatsukami.jp サーバから追い出す

と言うわけで①を試そうとしたんだが、IIS7.5 ではこれがどうもうまくいかない。
いや、7.5 でもできると思うんだけどなぁ……。結果的に旧コンテンツが動かなくなるw
そこでやる気を失って放置してたら、ウェブサーバが落ちたwww
どうやら旧コンテンツの実行にものすごく時間がかかるようになってしまったためで、旧コンテンツそのものにアクセス出来ないようにしたら、復活した。

これが 9/11 頃である。

その後も①に色々挑戦するも、何故かうまく動かない。まぁ amatsukami.jp サーバは 6 年も稼働し続けているし、その間、いろんな設定ミスだのなんだのをしてきたから内部がけっこうヤバいことになっているのかもしれない。
さっさと新しいサーバに移行しなければ……という結論には達するものの、技術的な勉強も兼ねて仮想サーバ(こちらは IIS8.0)に PHP を 2 バージョン(5.2 と 7)をセットアップした。するとすんなり両バージョンで PHP が動くではないか。なのでこの設定をそっくりそのまま amatsukami.jp サーバに持ってくると……やっぱり動かないorz
う~む、やはり amatsukami.jp サーバが怪しいんだなぁ……。

そこで amatsukami.jp サーバにリバースプロキシを設定する。そして http://amatsukami.jp/scripts/pukiwiki/ 及び http://amatsukami.jp/pukiwiki/ にアクセスしに来たら、それは仮想サーバの Pukiwiki を呼び出すように設定した。
と言うわけで上のメニューにある「今は昔」のリンク先は amatsukami.jp サーバではなく、仮想サーバで動いているコンテンツだったりする。

将来的にサーバを新調したら、どっちの方法でやるかは悩むな。サーバを新しくしたら当然そっちでは複数のバージョンの PHP が動かせるはずだ。となれば別にリバース プロキシに頼らなくてもよい。
ただ将来的な設計で、ロードバランサなどを置く場合は、そもそも全てのサイトがリバース プロキシでの運用になるだろうし……。まぁそれはその時になったら考えよう。

下の写真はシャンブラとボクが勝手に呼んでいる『上海ブラッセリー』の塩やきそばと半チャーハン。ここのチャーハンは紅生姜が入っているのが特徴だ。半チャーハンの写真がフタルあるのは、ここ、半チャーハンはお代わり自由だったんだけど、それがなくなり、「普通」「大盛り」「特盛り」が選べるようになった。その大盛りと特盛りの比較写真が、チャーハンが二つ並んでる写真だw
あくまでも半チャーハンの大盛りと特盛りなので、大盛りが普通のチャーハンくらいの量だと思ってもらえれば間違いないと思われる。ただし、残っているチャーハンの量に影響されるのか解らないが、けっこう日によって量は違ったりするw

glace.me と galette.me を amatsukami.jp で引き受ける

GLacé / Galette のサイトを amatsukami.jp で受け持つことになったので、引っ越し作業をした。もともとボクが立てたサーバだから、まぁそんなに面倒なことはないのだが、GLacé / Galette のサイトというのは WordPress と実 HTML が混在していたり、LinuxDebian)で動いてたりしていたので、そのままコピーしたのでは動かないところがちらほら。
実 HTML 部分と WordPress を切り替える処理はボクがテキトーに組んだんだけど、ApacheIIS で返値が異なると言うことを突き止めるまで、さっぱり原因がわからず、頭を悩ませることにw

とりあえず引っ越し作業は終わり、amatsukami.jp 上で見られるようになった。
元の Linux の方は今月いっぱい残しておいて、様子を見る予定。

たぐり庵

今日のお昼は門前仲町駅のすぐ近くにある『たぐり庵』という蕎麦屋さん。入るとすでに満席で、相席となった。
天麩羅丼セットを注文。

味がすごかった。びっくりした。
まずまったくしょっぱくないの。つゆも、そして天麩羅丼にかかっているつゆも。
これ、すごいよ。
で、出汁の味も別に強いわけでもない。
どういうことなの?
どうやってつくっているの?
で、けっこううまい。
昨日の『なごみ』といい、なんだか不思議である。
ただ若い人や濃い味が好きな人からすると、味がないって言われてしまうかもしれない。けど、蕎麦の味を楽しむならこのつゆがすごくいい気がする。
はへー、びっくりした。

1511127409 1511127403 1511127406 1511127404

会社から戻ったら、職場で BGM を聞く方法の続き。
DLNA は他のソフトを試すべきかとか色々考えた結果、余計なソフトはインストールせず WebDAV を試してみることにした。こいつなら HTTP だけ喋れれば良い。職場のルータが何かいろいろ制限がかかっていても、比較的使いやすいだろう。
ただ SSL にはしたい。
で、これがちょっとくせ者で、WebDAV で SSL を利用したいとき、IIS(バージョンは 7.5)にある「ドメイン証明書の作成」ではダメで、ちゃんと Active Directory の証明書サービスから発行したドメイン証明書じゃないと動かなかった。
まぁこの辺、ボクがちゃんと理解していないからかも……。

で、WebDAV は SSL 付きでうまく動いた。次にこれをどうやって読み出すかだ。通常 WebDAV でファイルをやりとりする場合、https://amatsukami.jp ほにゃららって感じになる。この方法だとソフトによっては対応していない場合がある。
そこであれこれ捜していると、WebDAV をドライブに割り当てられることが解った。
つまり https:// で始まるのではなく、普通の HDD みたいに W:\ って感じでアクセス出来るのだ。設定する方法は簡単で、コマンドプロンプトから「net use [ドライブにしたいアルファベット]: https://サーバホスト名」で OK。
するとユーザ名とパスワードを聞いてくるので、この WebDAV にアクセスするためのユーザ名とパスワードを入れればあとは普通にドライブ名でアクセスできるようになった。

ただこの方法では問題が一つ残る。それはプレイリスト。
プレイリストはすべて LAN 経由でアクセスすることを前提に作ってしまっているので、「\\サーバ名\音楽データのあるフォルダ名\アーティスト名\曲名.flac」みたいな感じになってしまっている。
これを「X:\音楽データのあるフォルダ名\アーティスト名\曲名.flac」っていう風にしないといけない(この例の場合、WebDAV は X ドライブとなっている)。
で、まぁこれは grep で一気に置換した。プレイリストが二種類になってしまうが、これは仕方がない。出向中の 4 ヶ月の間だけのことだし。

さて、あとは出向先に行ってみなければ、うまく行くかどうかは解らない。
一番の懸念点は証明書のインストールである。ドライブに WebDAV を割り当てる場合で SSL 通信をしたいとき、どうもその通信した相手のサーバの証明書を、使う側の PC にインストールしておかなければいけないらしい。今回の場合の証明書はボクが勝手に発行した証明書であり、世間的には信用できない代物である。そのため、PC にこの証明書をインストールし、信用できる証明書ですよって設定しないといけないんだけど、こういった信用できない証明書を勝手にはインストール出来ないようにしている可能性があるのよね。
まぁそればかりは出社してみないと解らない。あとは明日に持ち越しである。

rewrite 導入

ブラウザのブックマーク(お気に入り)に入れるほどでもないけど、何となくこれは取っておこうと思うアドレスをどうしようか悩んでいた。あとで見返すかもしれない、そしてほとんど見返すことではないであろうアドレスである。 こんなのをいちいちブックマークに登録していたらキリがない。 で、思いついたのが「はてなブックマーク」って自前で運営できないのかな、といういことだった。
それで色々捜した結果、Scuttle という CGI に出会った。
これはソーシャル・ブックマークを自前で運営できるシステムだ。
設置自体はすぐにできた。登録すると、ちゃんとスクリーン・ショットも表示してくれる。イイ感じじゃないか!
ところが、日本語が通らない。いや、正確に言うと、「検索」と「タグ」に日本語を使うとちゃんと表示されないのだ。
設定とかを見直すも、特に問題ない……。困ったなぁ……とりあえず半角だけで運用するかぁ、ということでこの時は日本語の使用を諦めた。

さて、それから数時間経って、ちょっと頼まれた仕事があり、WordPress でサイトを構築していた。でね、こっちでは Rewrite を使うことにした。WoredPress っていうのは CGI なので基本的にサイトを表示するときは、アドレスが「プログラムのファイル名+表示したい記事のパラメータ」と言うことになる。 プログラムのファイル名は、index.php だ。この後ろに ? をつけて表示したいカテゴリや記事の番号なんかを指定していく。でもそれだとウェブページのアドレスっぽくない。そこでそれらしくさせる方法がある。
Rewrite といってウェブページっぽくなってるアドレスを、プログラムのファイル名+パラメータに書き換え(Rewrite)てくれる機能だ。
たとえば TAMA Networks のエロゲの記事は、http://amatsukami.jp/eroge/ でアクセス出来るが、これの実体は http://amatsukami.jp/?page_id=3385 である。 ボクは「プログラムのファイル名+パラメータ」でいいやって思ってたので、Rewrite 機能を使ってなかったんだけど、その頼まれごとで使う必要が出てきたので、じゃぁついでに TAMA Networks でも仕掛けておくかーと思って設定してみたのである。

ところが、これがまともに動かない。 なんだこれー!? で、色々実験してみると、日本語のページ名だと動かないことがわかった。 あれ? これってひょっとして、上の Scuttle と同じ原因?

と言うわけで、検索したらすぐに関連記事をみつけた。

パッチを当てると直るらしい……ということはバグ?(ぁ
あとレジストリもいじる必要があるようだ。
この設定をしたら、ばっちり Scuttle でも日本語が通るようになった。 いえーい!
そんなわけで、ボクが日頃気になったネタとか笑ったサイトとかを「お気に入り」に公開しました。また、TAMA Networks 自体もプログラムの名前+パラメータから、普通のサイトっぽくなりました(ぁ

 

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