濡れ衣事件、再び

今月の頭たったかに WordPress が 5.6 にバージョンアップした。
そしたら、CTRL+V でリンクを張ろうとすると、そのリンク先の概要が表示されるようになってしまった。この時、ボクはてっきり WordPress が貼り付けられたリンク先にアクセスし、アクセス先の概要データを読み込んで反映されているのかと思ってしまった。

ところが、今日、普通にテキスト エディタEdge でコピーした URL を貼り付けたら、普通にその URL の概要が貼り付けられたwww
マジかwww
Edge のせいだったのかよ!

というわけでこの間のタイヤの件に引き続き、またしても濡れ衣を着せてしまった……orz

もっとちゃんと確かめようぜ! これがもし人に対して行われていたかと思うと……恐ろしい。

 

未だに続いている某ソシャゲ。アイテム関連。
強いアイテムが出るようになったが、レア・レジェンドはまったく出ず。初期値でこの数値なら、レジェンドならかなりな数値になりそうなんだがなー。残念でならない。

Update の罠とセミと借りパク疑惑

TAMA Networks の日記には、記事の一番下に関連記事が 4 つ出るようになっている。これはいちいちボクが過去の記事を検索して貼り付けているわけではなく、Yet Another Related Posts という WordPress のプラグインが勝手にやってくれる。

コイツがバージョンアップしたのだが、バージョンアップしたら、日記の記事(つまりこのプラグインを使用しているページ)の表示が遅くなった。まじかー。バックアップとか取ってないよ?? と言うわけで他のプラグインに一時的に変えてたんだけど、翌日、修正版が出てた

すぐに修正されて良かった。

実はプラグインや WordPress 本体の更新はわりと頻繁にくるんだけど、毎回なにも気にせずに更新ボタンを押している。が、こう言うことがあるので更新前にはバックアップは必要だよなぁ……と頭の中では思いつつ実行に移していない(ぁ
もちろん何もバックアップを取ってないということはなくて、定期的にとってはいるんだけどね……。

今夏、初めてのセミの声を確認。7/21 は遅い方なのかなとちょっと思ったんだけど、東京では 7 月の後半だと思うので、特別遅いと言うことはないようにも感じた。少し過去を振り返ってみると、去年(2019 年)は 7/17 でもまだ鳴いてないらしい。いつ鳴いたかは記録を撮り忘れたようだw
一昨年(2018 年)は 7/11 には鳴いていたらしい。
2017 年の記録は見付けられなくて、2026 年は 7/16 だったようだ。

例の新型コロナ ウィリス騒ぎで日本中の学校がリモート授業に切り替わっているというニュースは結構前から耳にはしていた。それに弟家族には子供がおり、そちらも学校に通えていないんだみたいな話を聞いていた。でね、小学校なんかでは PC というかネット環境も含めてリモート授業を受ける環境がない家庭があるので、そういう家庭のために携帯回線とセットで PC を貸し出してるんだろうなっていうのも想像に難くない。

さらに、これはボクの偏見だが、そういう家庭はそもそも家計に余裕がなく、借りた PC はそのまま借りパクするんじゃないかって思ってたんだけど、どうもやはりそうらしい?

いちおう記事には返さなかった理由に触れられてはいるけど……いやーどうかなぁ(ぁ

三年前のマルウェアが今頃ひっかかる

今はコロナ禍の影響でテレワークが続いている。
つまり家で仕事をしているわけだが、となると自宅の開発マシンはずっと電源がついている。
特に今は三つの仕事が重なってしまい、クソ忙しい毎日を送っている。
なので自宅の開発機も 24 時間つきっぱなしだ。

でもマシンはついていても、ボクがマシンの前から離れるときはある。
例えば食事をしている時や、仮眠をとっているときだ。

Windows は一定時間操作されていないと(もしかしたら、ただのスケジュールかもしれないが)、マルウェアなどに感染していないか自己チェックを行う。そしてふと自席に戻ってくると、Windows Defender からマルウェア発見のお知らせが!

まじか!?

なにか踏んじまったのか?

って思って見てみたら……。

おー。これはボクが三年前に対処した WordPress を改竄するマルウェアだ。
そのときの顛末は日記にまとめてある

で、この改竄された WordPress、一応念のためにバックアップとしてこの開発機にとっておいてあったのよ。この開発機には PHP は入ってないし、そもそも隔離してあるので大丈夫だろうと。そして三年後の今日になって今頃、Defender が反応したというわけだ。

もしボクが対処しているときに反応してくれていれば、もっと楽だったんだけどねぇ……。
まぁこういうのはなかなか即対応は難しいとは思うが。
ただ、上のサイトを見に行くと、去年の三月にはすでに情報は上がっていたようだ。なぜ発見が今になったのかは謎である。

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

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

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

あれー? なんだこれ。

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

なんだなんだ?

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

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

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

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

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

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