リバース プロキシと 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 年との台風発生の違いは現れるだろうか? 去年は妙に台風の数が多かったが……今年は果たして?

ようやくサイトを 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

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

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

新サーバを組み立てて 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 はけっこう違うなぁと実感した作業であった。

Aipo と PC & モバイル環境

Aipo っていうグループウェアがある。
で、これをボクは一人で使っている(笑)。
備忘録とかスケジュールとかを前はテキスト エディタでメモってたんだけど、今ボクの情報端末環境がけっこう変わったって言うか無節操って言うか、なんていうか、場所によって色々機器が変わるので、スケジュールの確認等をすべて Web 上でやる必要が出てきた。
ちなみにボクを取り巻く情報端末は以下の通り。

  • 自宅開発機(Windows 10)
  • 会社開発機(Windows 10)
  • ゴロ寝用 ThinkPad X200(Windows 10)
  • いつも持ち歩いている iPhone 6(iOS)
  • いつも持ち歩いている VAIO Duo 11(Windows 10)
  • 自室以外で使ってる ASUS Vivo Tab Note 8(Windows 10)

外出先での打ち合わせなどは主に VAIO Duo 11。VAIO を持ち出すのを忘れた場合 iPhone でメモを取っている。
会社では会社の開発機でメモを取る。
わりと複雑なのが自宅で、自分のデスクに座っているときは自宅開発機、ベッドとか床でゴロゴロしている時は ThinkPad X200、自分以外の部屋にいるときは ASUS の Vivo Tab Note 8 を持ち歩いているというような状況である。

これら 6 つの機械から、スケジュールやらメモやら ToDo やらをすべてテキスト エディタでやってて、自宅サーバにあるメモ ファイルを入れるフォルダにどんどん入れてた。けどね、これ、あとで見返さないのよねww メモ取ったっきり。で、〆切とかやることとか忘れることが多かった。

ので、ボク一人しか使わないけど Aipo を入れているのだが、それが 7.0.1 だったので 8.1.1 にアップグレードした。といってもこれは簡単で、EXE を叩くだけである。そうすると勝手にアップグレードしてくれる。

次に SSL である。ウチはオレオレ証明書で運用しているのだが、自分で使う機械にはウチのサーバの認証局を信用する認証局として登録してあるので、ブラウザなどでエラーが出ることはない。しかし、Aipo の SSL は独自設定のため、アクセスするたびに「信頼できない証明書」って表示されていた。この Aipo 独自の証明書をウチのサーバの認証局で認証するようにした。
これは Aipo に入っている Keystore というコマンドラインを使って csr ファイルを作成し、そいつをウチのサーバの認証局で認証させるという方法でできた。
こんな感じで今はメモやスケジュール、ToDo なんかを全部 Aipo に任せて、どの端末からでも参照できるようにした。

疑心暗鬼な人々

NSAHTTPS を解読できるという話は、確かスノーデン氏のリーク情報が最初だったと思う。その後、NSA 長官も同じような発言があったと思うのだが、ざっと検索した限りでは明言しているところは見つけられなかった(関連記事)。

さて、何のことやらと思ってる人も多いと思うので、まずはちゃんとした説明からしておこう。
皆さんが IEGoogle Chrome などのウェブ ブラウザを使ってウェブサイトを見るとき(いわゆる、インターネットをするとき)、サーバとブラウザは HTTP という取り決めに従って見たいデータをやりとり(通信)している。
インターネットというのは色んなサーバがつながって成り立っていて、例えば、今見ている TAMA Networks のサーバから様々なサーバを経由して、あなたのパソコン(スマフォかもしれないが)に送られている。
なので、その経由しているサーバの管理者は、その内容を見ることができる。
これはウェブサイトに限らず、メールでも同じだ。

そこで、HTTPS という取り決めがある。コイツは TAMA Networks 上で暗号化しておき、あなたのパソコンにむかって情報を流す。そして受け取ったあなたのパソコンがその暗号を復号して、画面に表示する。
こうすることによって、経由しているサーバにデータは流れるものの、なんのデータかは解らなくなるわけだ。
この暗号は素数と素因数分解を用いるもので、途方もない計算量が必要なため、現在のコンピュータでは簡単に解読にできない(何百年もかかる)というのが「担保」になっている。

ところがスノーデンや NSA 曰く、すでに HTTPS については問題になってないらしい。
本当なのか!?

ボクが予想したのは、アメリカの認証局(その暗号と暗号の発信元が同一で有り、誰がその暗号を発行したのかを証明する機関)とすでに密約が交わされており、そこから秘密鍵を得て、HTTPS の通信を全て復号できるのではないかというものだ。
ただそれにしても、認証局は証明書を発行するだけで有り、秘密鍵まで知るわけではないはずだ。

ということは、NSA は暗号を解くことができるのだろうか?

実はもう一つ、暗号を回避する方法がある。それは中継されるサーバの間に簡単に言うとブラウザをかますのだ。例えばボクが Amazon で買い物をしたとする。ボクは Amazon に接続しようとするわけだが、ボクのパソコンと Amazon のサーバの間に、Amazon の証明書をもつ中継サーバを用意し、そのサーバがブラウザとなって Amazon と通信するのである。
Amazon は中継しているサーバに対して暗号化したデータを渡し、中継サーバはそのデータを盗んだ後、再度暗号化してボクの PC にデータを送るのである。
ただこの中継サーバは、本物の Amazon の証明書を持っている必要があるが、これならば秘密鍵が解らなくても、たぶんデータはぬけるんじゃないかと思う。つまり認証局と NSA が仲良くさえなれば可能ではないかと……( 間違ってたら突っ込みよろしく(汗

で、何をボクは心配しているのかというと、情報技術が進んだことによって、なんか世の中が凄い殺伐になって来ているというか、いや、もともと殺伐だったのが、よく見えるようになって来たというか……。
お花畑な思考なのかもしれないけど、科学が発達すれば、いつか労働はいらなくなり、人々は自由に時間を使い、好きなことができるようになるんじゃないかっていうことを幼少の頃からボクは考えていた。そして一部はそうなりつつある。

が、それよりも、為政者は古来からの夢を実現する方に科学技術を使う。
国民一人一人が何を考えているのか? 裏切るヤツはいるのか? 命を狙ってるヤツはいるのか? 他の国は何をしているのか?
これらが科学の力によってできるようになって来て、それをそのまま実行に移しているのだ。
国は疑心暗鬼に満ち、常にあらゆるものを監視し、あらゆるものを疑っている。そのメンタリティは紀元前から何も変わってない。

せっかくインターネットで国境そのものが少しだが意味のないものになりつつあるのに、非常に悲しいなぁと思ったのである。

とは言え、無防備では当然いられない。国益、国防、国民の財産・命……国が守っていかなければならないものはたくさんある。
これからますます人を監視することは容易くなってくる。何億、何十億という人間がいても、それらを網羅し、さらに個人を知ることもできる。もちろんその中には為政者も含まれてはいるんだろうけど……はてさて、どんな世界になっていくのやら。