WordPress のタイムアウト問題を解決する

この TAMA Networks は WordPress というシステムで動いている。
で、この WordPress がバージョンアップしたのでウチでもバージョンアップしようとしたのだが、バージョンアップ中にタイムアウトしてしまう……。

あれー? なんだこれ。

いや、まぁ前からなかったわけではないのよね。特に最近はテレワークで昼間もネットが重い。
その辺が関係あるのかなと思い、PHPset_time_limit(); 関数を使って、サーバの応答を待つ時間を長くしてみたんだけど……そもそもこの関数で設定した時間よりも先に HTTP 500 エラーになってしまった。

なんだなんだ?

じゃぁサーバ側の問題か……と思い、いろいろと設定を漁った結果、サーバ側には三つのタイムアウト時間を設定する場所があった。

  1. アプリケーション プール
    1. アプリケーション プールの生存確認を行う ping 応答時間
    2. アプリケーション プールのアイドル状態をシャットダウンする時間
  2. サイトそのものの接続タイムアウト設定
  3. FastCGI のアイドル タイムアウト

このどれが直接関わっているのかはようわからんっていうか、多分全部だろうと言うことでとりあえず全部の時間を 10 分にしてみたところ、無事に WordPress が更新されるようになった。

ところが、とあるプラグインを更新しようとしたらタイムアウトしてしまった!
マジか!? 設定が悪いのか!? って思って、試しにブラウザで普通にそのプラグインをダウンロードしようとしたら、そもそも 10 分経ってもダウンロードが終わらなかったwwww
ツイートで 10 分と言っているのは、タイムアウトの設定値が 10 分だからなわけですな。

だめだこりゃ_(:3 」∠ )_

ようやくサイトを SSL 化する

新サーバ移行の話、続き。
昨日、ウェブ サービスを新サーバに移した。昨日の作業は古いサーバで動いていたものをそのまま新しいサーバで動かすというものだ。なので変わった所は一つも無い。とにかく今まで通り動かすのが目的だ。
もっとも一つだけちゃんと動かないサイトがあるが(汗)。

さて、移植が終わったら今度は各サイトの SSL 化である。
今あなたが見ているこの amatsukami.jp サーバは、あなたの端末とつながっているから見られるわけだが、その間にはプロバイダIX など様々なサーバや回線を通してつながっている。
なので amatsukami.jp サーバとあなたの端末がやりとりしているデータは、間に入っているプロバイダなどがのぞき見ることが出来てしまうのだ。ただボクはあまりそれは問題視していない。というのも別にクレジットカードを扱うようなサイトでもないし、見られて困るようなサイトでも無いからだ。

ところが最近はのぞき見が出来てしまうようなサイトは、ブラウザで「信頼できないサイト」って表示されたり、検索の順番を下げられたりするようになってしまった。

そこで SSL 化である。amatsukami.jp サーバとあなたの端末との通信を暗号化してしまうのだ。こうすることによってたとえ途中でデータが抜かれたとしても、暗号を解かない限り、内容を知ることは出来ない。

ではなぜ今までの amatsukami.jp サーバは暗号化してこなかったかというと、今までの amatsukami.jp サーバはウェブ サービスを提供するプログラム(IIS という)が古くて、一つのサイトしか暗号化できなかったのだ(汗)。

というわけで amatsukami.jp サーバで運営している 21 サイト全部暗号化しよう! と言いたいところなのだが、そうは問屋が卸さない。というのも暗号化することによって今まで表示されていたサイトが表示されなくなったり、動かなくなったりする場合もあるからだ。不具合の出たサイトの運営者がボクなら別にボクが治せばいいので問題ないのだが、他の人が運営しているサイトはその人じゃないと変更などは加えられない。
なのでとりあえず、ボクが直接管理・更新しているサイトについて暗号化した。

手始めに TAMA Networks、汐碕市のサイトcaitisithskysphere などを SSL に対応させた。今の所、ちゃんと動いていると思われる。
しかし油断は出来ない。この暗号化はインターネットの世界で信頼されている組織から暗号化のためのキーをもらって実現している。そのキーの寿命は三ヶ月しかない。三ヶ月経つとキーは効力を失い、使えなくなるのだ。そのためキーの更新を三ヶ月おきにしなければならないのだが……それが正常に出来るかどうかは三ヶ月後である(汗)。
三ヶ月後の日記でいろいろ慌ててないといいなぁ……。下のスクリーンショットはこの TAMA Networks の暗号キーの有効期限を表示したもの。11/4 に切れることが確認できる(そしてちゃんと更新されてました)。

さて、今日はめっちゃ久しぶりに横田基地の近くにあるお気に入りの中華料理屋さん『紅満園』に行った。ここは早い・安い・美味いが揃った割とジャンクなって言い方は失礼かもしれないが、気軽にばくばくっと行けるお店なのだ。
二人で行ったんだけど、とりあえず好きなおかずとそしてご飯モノを頼んだ。おかずは麻婆豆腐とエビチリ、ご飯は高菜炒飯と牛肉炒飯。三番目の写真は海老が中に巻いてある細い春巻き。

予想外だったのが鶏の唐揚げ。4 番目と 5 番目の写真。

いやね、ちょっとつまむ程度っていうかさ、4, 5 個入ってるくらいのを想像するじゃん?
写真もそんな風に見えたの!
そしたら超巨大なのが 5 枚も……。いわゆる一枚肉ってヤツ??
しかもおばさんがニッコニコで持って来てさ。
いやー、食うの大変だったwww

でも中、すげージューシーでやわらかくて、うまかったわー。

PHP の恥ずかしい話と TV で見た分福

ついに WordPress から PHP のバージョンが古いと警告されるようになった。amatsukami.jp サーバは PHP 5.3 で動いている。こいつはセキュリティ ホールとかもあって本当は使っちゃいけないバージョンだ。
しかも 2 年前に PHP5 系でしか動かないものは、別のサーバに追い出している。
なのでさっさと PHP のバージョンをアップしないといけないのだ。また、上の別サーバに追い出したときにも書いているが、アップデートしないと WordPress そのものが動かなくなるというのも予想していた(そして今年の 4 月に動かなくなるらしい)。

じゃぁアップデートすりゃいいじゃん。

いや、まったくその通りなんだけど、実は過去に何度か PHP のアップデートを試みて失敗しているのだ。入れるのは 7 系と言われているバージョン。ところが amatsukami.jp サーバに 7 系を入れてもなぜか従来ある 5 系が呼び出されてしまうという現象がおきるのだ。
7 が入っているディレクトリ(フォルダ)から直接 php.exe を叩いても、5 系が呼び出される。しかもその場合、exe は 7 なんだけどその他の全てが 5 なため、PHP が起動すらしないという状況になるのだ。
これがもーわからなくてわからなくて、何度やってもこうなる……orz

という経緯があった。しかしさすがに WordPress から「もう動かなくなるよ」って言われてしまったらなんとかしてアップデートするしかない。そこで今日も設定してみたんだけどやっぱり動かない。まぁそうだよなー、もう何度も試してるしなぁ……もう Windows Server 自体がおかしくなってるのかなぁ……とか思い始める。

PHP は php.exe というプログラム本体以外に、さまざまな機能を実現するためのプログラム群(Extension)がある。そいつらを読み込むためには MS-DOS 時代からある PATH という環境変数にそのプログラム群が入っているディレクトリを定義したりするのだが、それは php.ini という定義ファイルに書いておくことも出来るので amatsukami.jp サーバの PATH にはその設定はない。
なければ定義ファイルを見に行くはずだよなーなんて思いながら、環境変数をぼけーっと眺めていたら、「PHPRC」っていう環境変数を見つける。そしてそこには PHP5 系のディレクトリが設定されている。

これかぁぁぁぁぁぁぁぁぁぁ!!!

この環境変数はまさにその php.ini がある場所を設定する環境変数なのだが、これがあるために PHP7 系を起動しても 5 系のプログラム群を読みに行っていたのであるorz
すっかり見落としていたというか、忘れてた!!!
あほやなぁ……。

というわけでこの環境変数を消し、PHP のバージョンごとに PHPRC を設定して無事 PHP7 系が動くようになった。この数年の失敗はなんだったんだ……。

ところが問題はそれだけでは終わらなかった。WordPress が動かないのだ。
もちろん動くサイトもある。ということは PHP 自体のアップデートには成功しているのだろうととりあえず判断し、WordPress 本体をあれやこれやといじる。WordPress そのものはけっこう規模の大きなソフトウェアな上に、ボクがかってにいじくってる部分もあるので何かが引っかかってるんだろうと調べるも、そもそも自分が WordPress のどこをいじったのかも憶えてないwww

とりあえず一つの WordPress でいくつものサイトを運営できる「マルチサイト機能」が問題なのかなと思ったのだが、マルチサイトが ON になっているサイトも動くことが判明

結果的に古いプラグインが原因だと解った。そのプラグインを外すことによって、ほぼ全ての WordPress が動くようになった。ところが GLacé というエロゲ ブランドのサイトがあるのだが、ここだけは動かなかった(汗)。なんだろうなー。
でも、このサイトを管理する義務もないし、しらなーいってなった(ぁ
でもなー、古い PHP で動かし続けるのは問題があるわけで、さてどうしたもんか……。

さて、今日行ったランチはね、楽しかったというか何というか。
お店の名前は『分福』。なんか入り口がけっこう凝ってる(7 番目の写真)のでちょっと入るのに躊躇してたんだけど、入ってビックリ。あ!って思った。中はお風呂屋さんなのだ! そしてテレビで見たことある!! ワールドビジネスサテライトだったかガイアの夜明けだったかまぁなんかその手の番組で居抜き物件とかリノベーション物件でがんばってるお店を特集してたときに出てきたあの店だ!
そうかー、まさか田町にあったとは。

写真は鳥煮定食と、ミルフィーユ豚カツ定食とハムカツ定食。
お値段は 800 円 ~ 1000 円。ご飯お代わり自由だったかな?
鳥はかなりゴロゴロ入ってるし、ミルフィーユ カツはやわらかくて衣サクサクだし、ハムカツは分厚くて中にチーズが挟んであって食べ応え充分。いやー、イイ店でした。ここは常連になりたいと思った店でした。

まぁでもハムカツとかミルフィーユカツとか鳥肉とか、なんていうんだろうね安いもので美味しくしようっていう感じなのかな……と<失礼

天津神本舗を SSL 化する話

今日はわりと遅めに食事に出たため、お店はだいたいどこも昼休み(?)に入ってしまっていた。個人経営の飲食店は、14 時頃から 17 時頃まで閉まってしまうことが多いのだ。その時間帯にやっているのはチェーン店かラーメン屋くらいなものである。

というわけでとんこつラーメン屋さんに入ってみた。
一瑞亭
食べログの店数が妙に高いが、とりたててこれはという感じではない。普通(ぁ
スープは真っ白ではなく、濁り系。博多ラーメンらしいあっさりした感じはでてて食べやすいと思った。
炒飯がしょっぱかったー。

ちなみにこの一瑞亭、前に食べた由丸と同じ並びにある。由丸は白くてミルキー系(北九州系なんだろうか?)で特色は全然違うので、その二つが味わえるのはいいなと思った。

ところで同人の方で使っている amatsukami.infoSSLHTTPS)化をしてみた。
世間はなんでもかんでも SSL 化である。Google Chrome に至っては SSL 化していないサイトにアクセスすると警告を出す始末。えー、たかが個人サイトに SSL 化って必要なの?? っていう思いは未だに変わらないものの、世の中がそういう流れになっていくので仕方なく(ぉ

といっても自分のサーバでやったのではない。
実は自分の所でやらない大きな理由がある。それはウチのウェブサーバである IIS7.5 が SNI にちゃんと対応してないのだ。暗号化されたウェブページを取り扱う HTTPS は、何もかも暗号化するため、amatsukami.info と言うようなドメイン名まで隠蔽してしまう。となると一つのサーバでいくつものドメインを運営しているサイトにはアクセスできなくなってしまうのだ(なんのドメインでアクセスしに来たのか解らなくなるため)。
そこで HTTPS で通信を確立する前に平文でドメイン名だけをやりとりする規格が SNI なのだが、ウチのサーバにはその機能が無い(正確にはないわけではないが、対応が中途半端)。
そのため、amatsukami.jp や amatsukami.info、他にも様々なサイトを動かしているウチのサーバは SSL 化ができないでいた。

まぁそもそもサーバ自体を更新しなくちゃいけないんだけどね。こっちは裏で少しずつ進行中。

とりあえず練習も兼ねてテキトーなホスティング サービスを契約した。月 300 円(ぁ
ファイル容量は 100GB、DB は三つまで。DB の容量は 100 MB まで。
DB の制限がきつすぎるなぁ、と思いつつ……。

まず一回目は失敗。どうしても WordPress が動かなかった。
DB の問題か? それとも WordPress のスクリプトの問題か??

それから一日おいて、もう一度試してみた
すると ASCII モードで転送していたのが問題だったようだ。とりあえず動いてエラーを吐くところまではきた(前回はウンともスンとも言わなかった)。そのエラーを見ると、今度は memcached 関連のところで動かなくなっていたことが解った。それらを取り外すと動き始めた。

次に萌え時計だ。これが動かないんだwww
原因はファイル名に日本語を使っているからというのは何となく推測できたのだが、それの何がいけないのかさっぱりわからない。ファイル名の文字コードソースファイル側の文字コードを合わせたりしたのだが、まったくダメ。

結局これはソースコードの UTF8 から EUC にコンバートすることによって動いた。

もっとも時間がかかったのがファイルのアップロードだ。FTPS でアップロードしたのだが、とにかく途中で止まるのだ。天津神本舗は 1.16GiB ほどのデータが有り、ファイル数は 6174 個。とまりまくってそのたびに再接続してまたアップするファイルを指定して……とかやってたんだけど、6 時間ぐらいかかった。
あほらしい……orz

これ、どうも NextFTP というソフトだとなるらしい。確かに一回目の時は CyberDuck というソフトを使ったのだけど、そちらだと三回ぐらいしか止まらなかった。もー、なんなの?? じゃぁなんで二回目も CyberDuck を使わなかったのかというと、同じファイルがあった場合にちゃんとした比較がなかったのと、バイナリ モードだけでアップする方法がよく解らなかったため。たぶんどっちもないわけじゃないとは思うんだけどね……設定を見つけられなかった。

ちなみに萌え時計はもっとデータがデカくて、7GiB オーバー。こっちもアップするのが大変だった~。

なんだかんだで Windows Server と Linux はけっこう違うなぁと実感した作業であった。

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 ポート番号を分けることによって使い分けていた。
たとえば、https://amatsukami.jp:9999/ なんて感じだ。でもこれはデフォルトの動作じゃないし、見た目もよろしくない。

リバースプロキシを使えば、https://amatsukami.jp/redmine/ ってやると https://amatsukami.jp:9999/ にアクセスするように設定できる。こうすることによって、全て https://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 サーバが怪しいんだなぁ……(実は PHP の設定が不味かった)。

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

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

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