リバース プロキシと WordPress

昨日Apache 上で PHP を動かすのに苦労したという記事を書いた。まぁ普段から Linux を使ってる人間にとってはなんてことない設定だ。Windows Server 側のボクからしても、振り返れば大したことではない。
さて、次は Windows Server でも Linux でもない、別の問題だ。

この仕事は WordPress を使う仕事だった。といってもボクはそちらには踏み入れない。ボクの仕事はフロント部分で、デザイナーさんがあげてきたウェブ デザインを CSS + HTML + JavaScript + PHP で WordPress のテーマに落とし込む仕事である。
とはいえサーバを用意するようには言われたので、昨日用意した仮想サーバに WordPress をインストールして動くようになるまではやらなければならない。

昨日も説明したが、仮想サーバはこの amatsukami.jp サーバ上にある。
インターネットからこの仮想サーバにアクセスするには、グローバル IP アドレス(インターネットの世界で重複しないユニークなアドレス)を最低でも一つ割り当てなければならないのだが、amatsukami.jp にはグローバル IP アドレスが一つしかないので、仮想サーバに割り当てることは出来ない。
そこでリバース プロキシApplication Request Routing)という仕組みを使って、仮想サーバにアクセスしに来たデータは amatsukami.jp サーバが素通しして仮想サーバに通すようにする。こうすることによって、外からはあたかも仮想サーバがインターネット上にいるかのように見えるわけである。

これ自体の設定は、とても簡単で、素通しの設定をすればいいのである。

問題は HTTPS だ。とはいえ、実はこれ自体も設定は簡単である。リバース プロキシが暗号化の処理をしてあげればいいのだ。リバース プロキシの向こう側にいる仮想サーバは別に暗号化の処理をしなくても良いのだ。
ところがここで大きな問題が生じる。それは「リンク」だ。

仮想サーバは暗号化の処理をしない。ということはどういうことになるかというと、WordPress は、自身のリンクにすべて「http://」という暗号化なしのアドレスを貼ってしまうのだ。

暗号化してある場合、ここは「https://」で始まらなければならない。でも WordPress 自身というか、仮想サーバそのものが暗号化の処理を必要としていないわけだから、https のリンクを張るわけがない。

さーて、こまった……これはどうすればいいんだ??

で、いろいろ試行錯誤した結果、WordPress が実行される一番最初のところで、ムリヤリ、HTTPS だという嘘の情報を書き込むと動くことが判明したwwww

$_SERVER['HTTPS'] = 'on';

この一行を書き加えるだけですべて解決(汗)。え、ほんとにいいのかなぁ??
たぶん解決方法としては正しくないとは思うんだけど、とりあえず動いているし、特に問題も起きてないのでよしとしよう(ぁ
プラグインとかの更新もちゃんとできるし……(^^;

2020 年最初の台風が発生した。去年より 3 ヶ月以上遅れての発生だ。というのも去年は 2/20 の段階ですでに二号が生まれているからだ。とはいえツイートで一月に発生していたというのは調査不足だ。じっさい 2029 年の台風一号がいつ発生したかは調べてない(汗

さてこの 2019 年との台風発生の違いは現れるだろうか? 去年は妙に台風の数が多かったが……今年は果たして?

やっとウェブサービスに手をつける

新サーバを組み立てて 4 ヶ月近くが過ぎようとしている……(汗)。
いつの間にか 8 月である。
やばい、いいかげんやばい……。

Web サービス以外はすでに新サーバで動いている。

今はウェブ周りが旧サーバで動き、メールや仮想マシンなどはすべて新サーバで動いている状況だ。さっさとウェブ周りを新サーバに移さないと、そもそも電気代がもったいない(汗)。電力消費量が全然違うのだ(大汗)。
たぶん、月 1000 円くらい違うと思う。ちゃんと測ってないけど(ぁ

さて、ウェブである。amatsukami.jp サーバはとにかく色んなウェブ サービスをしている。何がめんどくさいって、まずどのサービスがストレージ上のどこにアタッチされているのか、さらにその中にも他のストレージがアタッチされてたりとかする。
あとリバース プロキシ。こいつが何をしているのか、もう知らんwww

7 年間成長を続けたウェブサービスを移植するなんて、めんどくさいwww

個人で動かしているサーバでさえこの為体である。これが業務となるともっと大変なんだろうなぁなんて遠い目をする。

とはいえサーバを見つめているだけでは一向に状況は進まない。
というわけで、重い腰をあげてやることにした。

amatsukami.jp サーバで運営しているサイトは 21 個。さらに Redmine、Aipo、SVN、MantisBT というウェブサービスがあってそれらは開発者用のサイトにリバース プロキシを使って接続されている。って今書いてて思いだしたけど、SVN の移植してないことに気付いたwww

まー、地道にこれらを一つ一つ新サーバに移植していく。
DB を使っている場合は DB も移植せんといかん。

15:30 頃始めた移植作業は、途中いやになって不貞寝したりはしたんだけど(マテ)、日付変わって 2:00 頃に一通りの終了を見た。ルータの設定も旧サーバから新サーバにルートを変更。念のため旧サーバは何かあったときのために動かし続けて寝た。

新サーバに移行して、某ブランドのサイトが動かなくなったwww
あれー?? 古い PHP もちゃんと残してあるのになぁ……なんか知らんがトップページが動かん。なんだこれ?? まぁとりあえず見えてるからいいか<マテ

他にもちらほら動かないものも……。特に Perl がほぼ全滅。
しかしなんで動かんのかよくわからんなー……。最近の Perl は動くんだけどね。古い Perl がサッパリ動かん。かといって古い Perl 入れたくないなぁ……。おかげで昔の日記が見られなくなってしまった……。つーか、スクリプトは動いてるみたいなんだけど、過去の日記がきれいさっぱり無くなってしまったのだ。ストレージ上にデータはあるのだがそれを認識してくれないのだ。う~む……。

まぁとりあえず今日はここまで。まだやることは残っている。それはサイトの SSL 化だ。旧サーバである IIS 7.5 は SNI という機能に完全に対応していなかった。そのため証明書を一つしか持てなかったのだ。なので 21 もサイトがあるのにその中のどれか一つしか SSL 化できなかったのだ(正確には SAN には対応していたので、サブドメインでの複数のサイトの SSL 化はできた)。

まだまだ新サーバへの移行は遠い。

下の写真は今日の気温と、マックの辛いものシリーズチキンナゲットに続き、バーガーも辛くなったと言うので買ってみた。カレーの方はマイルドと言っているので案の定たいしたことはなかった。スパイシービーフも……う~ん、これはソースはスパイシーチキンマックナゲットのソースと同じっぽい。

本気で辛くすると子供とか食べれないからなぁ……。やっぱりこういう老若男女が来る店で辛いものは期待しちゃだめだなぁ……。

天津神本舗を 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 はけっこう違うなぁと実感した作業であった。

iPhone の動画とか西武池袋線とか萌え時計とか

iPhone で撮影した動画を Premiere で読み込ませると、映像と音声が同期しないという記事は以前にも書いた。原因はわからないまま、現在も動画を編集するときは 60 分 あたり 2 秒ほど音声を短くするという対処方法をとっている。
でもこれをやるのはけっこうめんどくさかった。

上のツイートでは Premiere が直してくれたようにつぶやいているが、実はこれ、iPhone 7 だと問題なく、iPhone 6 ではやっぱり音と映像がずれていた。というのも Premiere 2017 でも iPhone 6 で撮ったデータは相変わらずズレているからだ。
どうやら Premiere が悪いのではなく、iPhone 側のデータに問題があるようだ。

そしてこれは iPhone 7 で解決したわけでもなかった。
2 ヶ月後の話になるが、iPhone 7 でも 60fps のデータは音ズレが発生することが判明。やはり iPhone 側に問題があるようだ。だが、ネットで検索してもこの現象に悩んでる人がいないみたいなんだよねぇ? iPhone はプロが映像作品を作る時にも使われているらしいのでこの問題にぶち当たってる人はいそうなんだけどなぁ。

もちろん気付かれていない(問題視されてない)可能性もある。そもそも音は別マイクで録っているだろうし、ズレも 60 分に 2 秒程度だ。プロの映像作品だと細切れにして撮っていることが多い。5 分や 10 分程度ではズレに気付かない(問題ない)かもしれない。

電車は 5 分くらい遅れたのでは運行情報には出ないようだ。
遅刻したけどな!

萌え時計を自分のサーバに設置せずに使う場合、amatsukami.info サーバを使うことになるのだが、コイツは HTTP で通信しているため、HTTPS なサイトに萌え時計を貼ると表示されなくなる。
う~む、最近は何でもないサイトでも HTTPS を使う傾向にあるし、そもそも Google 検索の検索結果は HTTPS を優先させる措置を執ったため、どうでもいいサイトでもどんどん HTTPS 化している。
ウチも HTTPS にすればいいじゃんと言われるとそれまでなんだけど、IIS 7.5 ではバーチャルホストのどれか一つしか HTTPS のサイトが作れないという欠点があるのだ。現在、ウチのサーバは開発者用のサイトがあるのだが、そいつが HTTPS を使っているため、他のサイトは HTTPS 化できないのである。
IIS 8.0 以降では出来ることは確認しているので、サーバを刷新してからかなぁと思っている。