PHP のバージョンアップとカールス ジュニア

amatsukami.jpamatsukami.info の PHP をバージョンアップした。
しばらく様子を見る。
ちなみに移行したのはこの二つだけで他のサイトについてはまだ古いままで動かしている。

移行した理由は今まで使っていた 7.3 がサポートされなくなるからだ。
これと言ってトラブルは起きていない。が、別に速くなったりとかもしてないので、何が変わったわけでもないという感じではある(汗)。それよりも不安なのは PHP8 だ。

Windows Server では PHP のサポートをやめるらしい。となるとメンテナは PHP の中の人たちがやることになるわけだが……はてさて、Windows Server を諦める日が来るのだろうか……。

さて、今日は出社日だったので台場に行った。
お昼にカールス ジュニアに行った。
ウェスタンベーコンクリスカットポテトはなかった。残念。

まぁでも久しぶりに食べたら、マックよりはおいしいね!
って食べてから気付いたんだけど、クアアイナにすれば良かった……。→ 8/20 に行ってきました!

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

今はコロナ禍の影響でテレワークが続いている。
つまり家で仕事をしているわけだが、となると自宅の開発マシンはずっと電源がついている。
特に今は三つの仕事が重なってしまい、クソ忙しい毎日を送っている。
なので自宅の開発機も 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 年との台風発生の違いは現れるだろうか? 去年は妙に台風の数が多かったが……今年は果たして?

CentOS で PHP を動かすのに苦労する

長編小説が進んでない……。9 月からずっと忙しいのだ。
ただコロナ禍になって、テレワークになったので、だいぶ余裕が出来た。
ちょっと合間をぬって、東京守護神の公開している部分を整理した。まぁただそれだけなんだけど……。

仕事でまた Linux を扱うことになった。うーむ……。
といってもウェブサーバPHPMySQL を立ち上げるだけっちゃぁだけなのだが……。すべて滞りなく行ったと思ったら、なぜか Web で PHP が呼び出せない。ちなみに OS は CentOS 8 だ。いろいろ調べを進めていくと、Apache(ウェブ サーバ)上で PHP を動かすには三つの方法があるらしい。

  • prefork
  • worker
  • event

このうちボクが知っているのは prefork だ。だから prefork な設定をしてしまった。ところが CentOS 8 は event らしい。ということが解ったので、ごにょごにょして Apache の Config ファイルを書き換えて event にした。もー。

ところで今回もトリッキーなことをしている。実は会社から開発環境用を作るように言われたのだが、無料でっていう指示をされたので、いろんな Cloud のお試しを使おうとしたんだが、AWS, Google Cloud ともに無料期間をすでに食い潰してしまっていた(笑)。
で、最近ちょっとかじった Oracle Cloud を試そうとしたら、これがなぜか仮想マシンが作れないというか、なんかバグなのか OS のイメージが選択できなくて何をやってもダメだったので、結局、amatsukami.jp 上に仮想マシンを立ち上げた。
しかしながら amatsukami.jp には IP アドレスが一つしか無い。

そこでリバース プロキシの出番だ。開発用に飛んで来たアクセスを amatsukami.jp サーバが仮想マシンに飛ばしてやるのだ。まぁこちらはちょっと一悶着あったので、別記事にしたいと思う。

しかし日本のゲーム業界だとサーバはもっぱら Linux だ。Windows サーバに今の所出会ったことはない。社内インフラは Windows なんだけどねぇ……。ボクは Windows Server の人なので、Linux はほんと設定するのに時間がかかる……。

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 円。ご飯お代わり自由だったかな?
鳥はかなりゴロゴロ入ってるし、ミルフィーユ カツはやわらかくて衣サクサクだし、ハムカツは分厚くて中にチーズが挟んであって食べ応え充分。いやー、イイ店でした。ここは常連になりたいと思った店でした。

まぁでもハムカツとかミルフィーユカツとか鳥肉とか、なんていうんだろうね安いもので美味しくしようっていう感じなのかな……と<失礼

ふくの鳥と AI と WordPress

今日は同僚が鶏の唐揚げが食べたいというので、いろいろと彷徨った結果、『ふくの鳥』というお店に入った。ランチメニューがどれも鶏の唐揚げだったからだ。鶏の唐揚げって言うと、あの丸っこいのを思い浮かべるのだけど、ここのは全て一枚肉だった。
同僚は油淋鶏、ボクはカレーを選んだ。

カレー屋さんじゃないカレーはあれね、業務用ね。
当たり前か(^^;

鶏の唐揚げは美味しかったと思うんだけど、カレーがぬめぬめっとしてた。
イマイチ!

ポイント カードについて、このあいだひどい目に遭ったわけだけど(そこまで言う?w)、ふとこの間 THANK で見たロビを思い出して、そもそも AI が普及したらポイント カードいらないじゃん! ってことに気付いた。
いや、AI とかそういう単語を使わなくても現状でも可能だ。
要するに顔認識システムを店頭に置いておいて、会計の時にその人が常連さんなのかどうかを判別して貰えばいいのだ。その人の来店回数や今まで使ったお金の積算を表示するなんて簡単だ。そしてポイントの付与も楽々だ。
たくさん貯まってたら「○○ポイントたまってますけど、お使いになりますか?」と、店員が聞けばいいのだ。自動割引でもイイし、レジのタッチパネルに表示して使うかどうかを尋ねるのでもいい。

いやー、明るい未来が見えてきそうだ。これで財布が金も持ってないのにパンパンなんてことはなくなりそうだ。頼みますよ!

今、仕事をいくつも抱えているんだけど、どれもが PHP + HTML + Javascript な案件なのね。で管理画面があったりとかいろいろするんだけど、クライアントさんには WordPress でやれるようにすることが多い。要するにデザインとかウェブサイトそのものはクライアントさんが作って、システムというか仕組みの部分はボクが組んで、クライアントが作った WordPress 内に組み込むといった感じだ。

ただ 100% WordPress で済むようにはしていなかった。
ボクが作ったシステムの UI は、ボクが自分で HTML を組み、CSS を組んで提供していた。
でもこれだと見た目が良くない。ボクはデザイナーではないからね。それにシステムごとに CSS を組むのがめんどうくさかった。

そこでボクが作ったシステムを全部 WordPress 側で呼ぶ仕組みを作った。
これでボクが作ったシステムも全部 WordPress を通して表示されるようになった。UI も統一されるし、デザインも統一されるうえにクライアントも操作に戸惑うことも減る(まったくなくなるわけではない)。
今までは WordPress とボクのシステムとで管理画面をアクセスする場所が違っていたりしたので、その辺も統一された。

本当は SS とか貼りたいんだけど、開発中なので貼れない……

cURL と file_get_contents と Photoshop と

奈川に旅行している間、プログラミングをしていたと書いた。そしてその日記の中でどうしても動かないので組み直すことになったとも。その組み直す件が上のツイートだ。WebAPI といってネットワーク上で利用できるようにした機能群というものがある。これは様々なサービスを提供している会社が用意してくれている。
たとえば Twitter なんかはこの WebAPI があるおかげで、サードパーティのソフトやサーバなんかがツイートをしたり、色んなツイートに関する統計をとったりすることができるのだ。Facebook しかり Google なんかの様々な機能を利用するにはこの WebAPI というのが公開されていて、それを叩くことによってその会社がもつ機能を第三者であるボクらが利用することが出来るのだ。

でね、PHP で WebAPI を叩く(呼び出す)方法ってのはいくつかあって、ボクは手抜きが大好きなので、その中でも file_get_contents という命令を使ってやっている。これで今まで失敗したことはないし、それこそ大手ゲーム会社が提供する WebAPI も叩いてきたし、そのためのライブラリもすでに作ってあった。
ところが今回の仕事では、これがサッパリうまく動かない。
何度見直しても、悪いところが見つけられなかったのだ。

そこでもう一つのアクセス方法、cURL という命令に置き換えてみたら、渡すパラメータは一緒なのに動きましたよっていう話。えー……。そもそもボクの作ったプログラムからデータを受け取る相手サーバにとって、file_get_contents も cURL も大差ないはず。規格に定められてデータを渡しているだけなんだから。
でも、file_get_contents だとうまくいかなくて、cURL だとうまくいく。
何かが違うんだろう。

そしてその違いがわからないまま、WEB のプログラムを続けていいのか、ヲレ?<ヲイ
ちゃんと調べる必要があるよなぁと思いつつ……とりあえずクライアントの要望通りのプログラムは書けた。

ところで Adobe Creative Cloud の 2018 年版がリリースされた。いや 2019 年版か?w
よくわからんが、とにかく全てのアプリが一新された。
ここでボクが求めるのはただ一つ、Windows 版 Photoshop  で HEIF 形式のファイルが読めるかどうかだ。そして読めなかった……orz

これはもう Adobe は故意に対応するつもりがないで間違いないだろう。こまったなぁ……なんで対応させないんだろう??