死後の世界がないのなら、作ってしまえばいいじゃない

Twitter からいろいろ日記になりそうなネタを集めてみた。

まずは江戸時代に作られたお話。詳しくは上記のツイートにあるのでそちらを参照してもらうとして、まぁ要するにオチが二段構えになっていて、そうだったのか! そうだったのか! と大どんでん返しが二回続く感じ。しかもキーになる女がずっと嫌なヤツと思いつつ……みたいな?

200 年以上前にすでにこう言う複雑な話があるっていうのは、嫉妬しちゃうよね。

こちらは企画のネタ。超文明の宇宙人が死後の世界を作ってあったっていう話(笑)。
科学(そして医学)は発達していけば多分そのうち寿命というものを克服するとボクは考えているんだけど、そんな連中でも死というものは必要な概念としてあって、現実世界からリタイアしたときのためにこの死後の世界が用意されている。
どうして死が必要なのかっていうのは、まだコレといったものは思い浮かんでないんだけど、漠然としているのは「やり直したい」とか「過去をなかったことにしたい」とか、あと犯罪者対策とか、単純にもう充分生きたので死にたいとか? 理由は一つではないよなとは思っている。
ただそれだけの超文明を築いた連中が未だに犯罪をするのかとか、やり直したいと思うのかとかイロイロ疑問は残る(汗)。
で、彼らの場合はその死後の世界から「やっぱやーめた」つって戻ってくることも可能だ。死を選んだ時点から再開してもいいし、生まれ変わってもいい。記憶を持って行くか行かないかも自由だ。

その死後の世界が地球人にも適用されちゃってっていうのが物語の始まりかなと思いつつ……。もしくは、かつて地球人に適用されていた時代があって、だから人間には死後の世界というのが色んな形で語り継がれている、とかね。

ところで寿命を克服するのは生命の営みというか、自然に反する(進化論に反する?)のではないかという意見があるが、たぶん反していないと予想される。もともと不老不死では絶滅してしまうリスクが高いことから、寿命と雌雄ができた。しかし科学力によって絶滅の心配もなく、また変化も必要なくなれば逆に寿命も雌雄も必要なくなるわけで、これは遺伝子が求める究極の生命体と言えるのではないだろうか?
ちなみにいろはとか翼をくださいとか 1/2 summer とかの舞台になっている世界は(Lay=Alld という名前が付いている)、エルフがその域に到達したことになっている。あの世界では地球から出て行っちゃったんだけど、エルフの中でハイエルフという種族はこの究極の生命体に到達し、女しかいない。但しこの「女しかいない」という設定の発端は別に科学的なことはどうでもよくて、「エルフは女しか認めん!」っていうただのボクの煩悩(ぇー

今やっている仕事でウチのサーバを使うことになった。
そういえばエロゲに関わっていた頃は、この amatsukami.jp サーバで Redmine やら BTS やら FTP やら SVN やらを提供していたんだけど、エロゲから抜けてからウチのサーバが仕事で使用されることはとんとなくなった。だからサーバを更新したときこの辺の設定をしないままにしていたんだけど、今回の件で BTS と FTP と SVN を整備した。また今までは SVN の通信を暗号化するためにわざわざ SVN 用に TCP ポートを開けてたんだけど、リバース プロキシを設定することによって HTTPS ポートにまとめることができた。

いやー、ほんとリバース プロキシって便利だわ~。

近々 Git も構築したいなと思っている。今の時代 SVN もないよなと思いつつ……。ただ Git はプログラマが使う分にはすぐれてるんだけど、そうじゃない人が使うにはまだまだハードルが高いなと感じる。ので、SVN の出る幕はまだまだあると思う。この辺はまた別記事で詳しく書きたいと思っている。

これ、ツイート時点では疑問だったんだけど、今は理解している。かつて「別名で保存」しかなかった頃は PSD で保存してしまうと、今 Photoshop で編集しているファイルも別名で保存した PSD ファイルになってしまう。これの何が困るかというと、元の PSD ファイルを使っていろんなバージョンの画像を作成しているとき、PNG や JPEG などの汎用ファイル形式で保存した場合はナンの問題もないのだが、PSD で保存してしまうと、今 Photoshop で編集しているファイルもこの「別名で保存」したファイルになってしまう。それに気付かずに作業をして上書き保存をすると、「別名で保存」したファイルに上書きされてしまい、元々の PSD ファイルは以前の状態のままとなってしまい、「別名で保存」の操作で保存したファイルは失われてしまうのだ。

ここで、「コピーを保存」にしておけば、編集中のファイルが切り替わることもない。

というわけでたぶん「コピーを保存」を作ったんだと思う。

結果的にボクも助かる結果となった。

下の写真は晩御飯に買ってきた松のやの豚カツ。0 時過ぎても買えるのは嬉しいよね。
野菜とご飯は家で用意できるので、カツだけ買ってきたw

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

リバースプロキシの秘密は preserveHostHeader にあり

ボクは aipo というグループウェアを一人で使っているのだが(笑)、一人で使うので、割と URL がテキトーだった。例に挙げれば、https://amatsukam.jp:3333/ って感じ。なんだよこの 3333 って数字は! みたいなw
https は本来 443 で動くのだが(なので何も指定しないと 443 番で通信しようとする)、そちらは色んな人がアクセスするための別のサービスが動いているため、ボクしか使わないグループウェアの方はテキトーなポート番号を割り当てていたのだ。

が、先日リバース プロキシというものを知ったボクはこの aipo も https://amatsukami.jp/aipo/ にできるのではないかといろいろ悪戦苦闘していた。

それがついに解決して、3333 を付けなくてもアクセスできるようになった。
Microsoft 製リバースプロキシである Application Request Routing の preserveHostHeader という設定を True にすることにより、インターネット網からアクセスしてきたホスト名でリバースプロキシ下にあるサーバ群にアクセスするようになった。
というわけでホスト名に関しては、まずは解決。

しかし問題はこれだけではない。aipo はルートディレクトリに配されている。どういうことかというと、https://amatsukami.jp:3333/ が aipo のホームページ(ホームディレクトリ)である。しかしこれを、https://amatsukam.jp/aipo/ にしたい。リバースプロキシだけでは、コレを解決できない(たぶん)。aipo 本体も https://amatsukami.jp:3333/aipo/ にしなければならないわけである。

んでなんとなーく aipo のドキュメントを眺めていると、昔 aipo ディレクトリで運用されていた名残があるような感じで、んじゃー、aipo フォルダってのを作ったら動くんじゃないかと思ってやってみたら動いたwwww
具体的には、aipo のインストール先である「dpl8110\tomcat\webapps」っていうディレクトリに、ROOT というディレクトリがあるので、それをそっくりそのまま aipo というディレクトリ名に変えるだけである(万全を期すなら、ROOT は残しておき、ROOT ディレクトリを aipo というディレクトリ名でコピーする)。こうすることによって、aipo は https://amatsukami.jp:3333/aipo/ で動くようになった。
次に aipo のプラグインなどを提供している container ディレクトリだが、こいつは単純にリバースプロキシで、https://amatsukami.jp/container/ ってアクセスが来たら、aipo のサーバにそのまま飛ばすようにすればよい。ただコレの欠点は、amatsukam.jp では container というディレクトリが使えなくなることだが、別に問題はないだろう(理想を言えば、aipo/container/ にするべき)。

また、3333 という数字をつけなくてすむようになったので、iPhone のカレンダーに aipo のカレンダーが取り込めるようになった。aipo に入力した予定表がそのまま iPhone でも見られる。イイ感じ!

下の写真はお昼に食べに行った「アカス」のランチ。タンドリーチキン付き。真ん中のはタンドリーチキンだよ! 見間違えないでよ!(何

気温とか 4K とかカレーのシミとかミルクとか

またまた Twitter から拾った、いろいろくだらない&どうでもいいネタ。

暑い! ってただそれだけである。残暑は長し。

まぁメモ程度に。1080p と較べるとファイルサイズはほぼ倍。電池は 10 ポイント多く使用した。さすがに 4K クラスとなると HEVC で録画したいんだけど、Premiere で読み込めないので未だに互換フォーマット。というか、PhotoshopHEIF に対応してくれないと移行でできない……orz
すぐ対応すると思ったのになかなか対応しないなぁ……。

そう!こういうのないの? ボクは白が好きなので、割と白を着るんだけど……時々食事の時失敗しちゃうんだよねぇ。そしたらもうそれは選択肢なくちゃいけなくなる。上のようなウェットティッシュがあれば、ちょいちょいってその部分に薬品(?)を浸透させて、そのあとウェットティッシュ側に吸い取るみたいな……そういうのないのかなぁ。

先日 TAMA Networks の旧コンテンツを別サーバに移した。そしたら、訪問者カウンタがおかしくなった。理由は簡単で、リバースプロキシ(Application Request Routing)経由でアクセスするため、旧コンテンツから見たらリバースプロキシしかアクセスしてこないためだ(笑)。
旧コンテンツに何千人、何万人来ようが、全部リバースプロキシが間に入るので、旧コンテンツからしたら一人がすげー勢いでアクセスしてくるな、って事にしかならないのだw

と言うわけで、リバースプロキシ側で HTTP ヘッダに HTTP_X_FORWARDED_FOR という名前で、アクセスしてきた人の IP アドレスを入れて、それを旧コンテンツに渡し、また旧コンテンツでは REMOTE_ADDR でカウントするのではなく、先ほどの HTTP_X_FORWARDED_FOR でカウントするように書き換えた。これで解決。

シティハンターだったっけなぁ? キャッツアイだったかなぁ。女子高生とかを「ミルク臭い」と呼んでいたのを思い出した。確かに 10 代の女の子って代謝が早いせいなのか、ミルクのような臭いがしてた。でも最近、JC も JK も大人びちゃって化粧やら香水やらするから、あの臭いはしなくなったよなぁなんてことをふと思う(ぁ
脱いだら解るけど。

そしてエロゲを作ってるからかもしれないけど、アレだよね、すっかりミルク臭いなんて表現は使わなくなったって言うか、もう女子高校生や女子中学生くらいが恋愛のターゲットになっても驚かれなくなったよなぁ……。エロゲだと容姿的にそれくらいが普通だもんなぁ。

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

さて、昨日は古い 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