復帰後最初のまぜはる

萌え時計に黒翼とテトメトを追加した。脇役もちょっとずつ追加できればなぁと思いつつ。
追加したあと、黒翼はすぐに出たがテトメトがなかなか出ない。レアキャラになってしまった。
萌え時計のキャラ表示決定部分は、今のところ完全に立ち絵ファイルのランダムである。そのため、表情やポーズが多いキャラほどヒットする確率は高くなる。テトメトはポーズも表情も少ないので、なかなかヒットしないのだ。
もう一つ、着物姿の黒翼(表記ではクロハ)もヒットしづらい。こちらは夜 Only になってしまっているためだ。ゴスロリの黒翼は F5 連打で割とすぐ出てくると思う。

と言うわけでお昼はまぜはるに行ってきた。台湾まぜそばで有名なお店である。
渋谷から浅草橋に戻ってきてからのリハビリ飯(ぁ
辛くて濃くてうまい、と思う。コレを置かずにご飯がいけてしまう(笑

リバースプロキシの秘密は 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 でも見られる。イイ感じ!

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

日乃屋の野菜カレーは根菜だった

日乃屋カレーへスペシャルカレーを食べに行った。最近、日乃屋カレー率高いなw
まぁ好きなんだからしようがない。
そして今回は、野菜とウインナーと鶏南蛮をトッピングに選んだんだけど、野菜がサツマイモにズッキーニ、パプリカ、レンコンというラインナップで驚いた(笑)。いやまぁ、全然いいんだけど、ただサツマイモはやっぱりモサモサしちゃうねー。ルーが甘いから余計甘くなっちゃうし。
レンコンはイイ感じ。パプリカとズッキーニも水分少なめでベチャッとならないようになってた。

そして今日も 9/25 だというのに 30 ℃越えである。

萌え時計をレスポンシブデザインに対応させた。サイズ指定がいっさい必要なくなり、萌え時計が配置された要素に従うようになった。だいたいは iframe を使って貼ると思うのだが、その iframe の大きさに勝手に合わせるようになる。
上のツイートでもブラウザいっぱいに表示された萌え時計の文字が、画像の大きさに合わせてちゃんと拡大されて、位置も概ね合っていることが解る。

詳しい記事はこちらに。

ただ今回の対応では縦横比が 1:1 じゃないと正常には表示されない。
萌え時計はそもそも 1:1 なので、まぁ別にいいかって感じではあるのだが……これが長方形だと今の組み方では文字の大きさを幅に対してしか見てないので、横幅に関しては正しく認識するけど、縦幅に関しては正しい大きさにならない。縦横比が 1:1 だと横の%=縦の%でもあるので正常に表示されるのだ。
縦に対して考慮してないのは、Microsoft Edge が対応してないから(汗
なのでそのうち、対応する予定。

SMB3.0 とか金融とか kobo とか

ボクはウェブサービス以外で自宅のサーバとやりとりするときは VPN をつないでやっているのだけれど、PC はともかく(起動時に VPN を勝手につなげるようにできるので)、モバイル端末ではイチイチ VPN 接続してからサーバにアクセスしなければならない。それに、VPN 分のオーバーヘッドも発生する。

VPN 経由で主に使うサービスはなんと言ってもファイル サーバだ。サーバ上にある様々なファイルにアクセスしたいわけだ。なので、Windows の共有フォルダがそのままインターネットで使えれば、VPN を経由しなくてもすぐに使える。

SMB3.0 から、それが可能になった。いや、今までも可能っちゃぁ可能だったんだけど、セキュリティ的にお粗末な実装だったため、とてもじゃないがインターネット網に出すわけには行かなかった。

と言うわけで、ちょっと自宅サーバの SMB をインターネット網に出して見た。

接続速い! ファイル転送も速い! いいじゃんコレ!!

でもねぇ、色々懸念点はある。この SMB は過去何度も攻撃対象にされてきた。SMB の穴を攻撃するマルウェアもたくさんある。そのため、市販のルータは SMB で使うポートを塞いでいることが多い。今回もボクの自宅のルータが SMB のポートを塞いでるせいで最初アクセス出来なかった。

もう一つ、SMB に対する世間の印象も悪いことが挙げられる。過去、そうやって漕ぐ駅対象にされたおかげで、とにかく SMB が使うポートは必ず塞ぐのが基本という習慣がすっかり定着してしまっているのだ。なのでボク自身は、ボクのルータの設定だけで住むが、他人に「ここにアクセスしてー」って手軽に渡せる代物ではないのよねぇ……。

まぁでもとにかくできることは解ったので、今後、使用する方向で検討していきたいと思っている。

金融の記事、時々見るけど、そもそも言葉がサッパリわからないんだよね。
みんな解ってて読んでるのかなぁ? ボクはサッパリ解らないや。上記の意味も、もー、何が何だかサッパリだ。で色々調べた結果、とある企業の株価が急激に下がったりしたときのための保険みたいなのがあって(ヘッジとクレジット デフォルト スワップ)、その保険料がすげー値上がりしてる(つまりその企業はいよいよヤバいって事)、っていう意味らしい。レーバーデー開けってのはアメリカの休日明けで、要するに休み明けにクレジットデフォルトスワップの値上がりがすげーカーブを描いてて、倒産は誰しもが解ってたんじゃないの? っていうような記事だった。

秋葉で画面解像度が 1920×1200 の Android 端末2999 円で売ってたので買ってきた。何に使うかというと、これで Windows でデュアル ディスプレイをやるのだ。会社の開発機は、1920×1200 のパネルが二枚あるんだけど(NEC と EIZO)、自宅は 1920×1200 が一枚しかないのだ。

そして反応速度に難はあるが、動画をずっと再生して奥分には問題なし。
ただ、7 インチに 1920×1200 は業務では文字が細かすぎて使えなかったww

気温とか 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