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

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

あれー? なんだこれ。

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

なんだなんだ?

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

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

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

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

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

会社までの距離と落ちてたサーバ

昨日の夜、セキュリティ パッチが降ってきたので amatsukami.jp サーバを再起動したんだけど、そのまま起動を確認せずに寝落ちしてしまった。目が覚めたら普通に朝。サーバのことなど忘れて出社してしまった……(汗)。

会社で自分の予定表だのなんだのにアクセスできなくて初めてサーバが落ちたままなのを知る……。

しかも出向先なのでいきなり帰りますと言うわけにも行かず……結局 12 時間ほど落ちたままに。
はー。
原因は Hyper-VNIC ドライバが死んでたからなんだけど、うーん、なんだろ……こんなのなったことないなぁ……。

ところで行きの距離を測ってみたよ!
思ったよりあるなぁ…… 32km、往復すると 64km。一ヶ月 20 日通ったとすると 1280km かーって思ったけど、別に毎月 1500km くらい乗ってるからそんなに多いわけでもないの……か? 電車通勤がメインの時は 2 ヶ月で 1500km も行かなかったりしてたし。

あとは今日食べたもの。吉野家と、あと正常位強い成城石井で売ってたデンマーク小枝Carletti という会社らしい。でも原産国ポーランドって書いてあるなぁ。オレンジピールとね、チョコレートのバランスがイイ感じ。
この小枝の形はヨーロッパに昔からあるのか、それとも偶然の一致なのか、さらにそれとも小枝がパクったのか……なんだろうね?

結局サーバは夜の 8:44 頃復活したらしい……。

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

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

意外なおいしさの三田魚介センターと Laview と hMailServer

今日はどこで昼食をとろうか色々彷徨い歩いていると、なんか貝出汁のラーメン屋さんがあったので入ってみた。というか、どっちかっていうと海鮮居酒屋で、ランチタイムはラーメンを出す、という感じのようだ。
名前は『三田魚介センター』。

店内は誰もいない……。

ボクは醤油ラーメンと鮭明太メシセットを注文。
うん、貝の出汁は独特だね。コクがあるように感じつつ、割と淡泊であっさり。でも後味に、あの貝独特の味がすーっとしてくる。これがちょっと固めの麺に合うんだ。美味しい。
貝も、アサリ・はまぐり・牡蠣が入っている。
もっとも出汁で味は抜けてしまっているけどw
でも牡蠣が入ってるなんて、贅沢に感じられるじゃない。

鮭明太は明太子がよーくみたないとよく解らないw
けと食べるとちゃんと明太子の味する。
鮭と一緒に食べると、なんか不思議な味だ。というのもぱっと見、鮭しか見えないから食べた時に魚卵の味もして、脳がちょっとした混乱をする。でもご飯が進むw

4 枚目のレモンの入った奴は同僚が頼んだ塩レモンラーメン。こちらもあっさりしていて美味しかったらしい。

もっと繁盛していいのにって思ったんだけど、たぶん問題は門構えかなぁ。
海鮮居酒屋なのはなんとなーくわかるんだけど、ランチをやっているのかぱっと見解らない上に、ラーメン? ってなる。でもたぶんラーメン好きならこのラーメンを食べてみて気に入る人は多いだろう。だからラーメンを食べたい人に対してアピールすべきなんだけど、そうなってない。
ランチはいっそラーメン推しオンリーでいいと思う。

今日は 22 時頃会社を出たんだけど、石神井公園で通過待ちがあった。特急電車かもと思って、いそいそとホームの外に出て iPhone をかまえた。そしたらやってきましたよ! 銀色のボディのアイツが! 新レッドアローじゃなくて Laview。
いやー、本物もキモいっつーかなんつーか、なんか 20 世紀に思い描いていた未来の電車って感じでとても古くさく感じてしまうのはボクだけだろうか?(汗)

でも窓がデカいのは、いいなぁ。

たぶん 20 世紀では作れなかったいろんな技術が使われてるんだろうなと思いつつ、やっぱり古くささを感じる(ぁ

家に帰ったら、サーバ移行の続き。つーか、遅々として進んでないね(汗)。
今日はメールサーバを新サーバに移行したよ! 実は我が家のメールサーバは三段構えになっている。

SMTP ゲートウェイ→ spam フィルタ→メールボックス

さらにメールボックスは POP3IMAP で別々のサーバになっていた。
IMAP サーバはボクしか使っていない。
POP3 は XMail Server というサーバだ。IMAP には Microsoft Exchange 2010 を使っていたのだが、IMAP の方を hMailServer というのに切り替えることにした。

使ったデータベースは MySQL(正確には MarinaDB)。そして少し手間取ったのが証明書だ。
オレオレ証明書を使うことにしたのはイイのだが、どの形式の証明書が使えるのかよく解らず、いろいろ試行錯誤した結果、以下の通りの手順で使えることが解った。

  1. Windoews Server 上の IIS の証明書をエクスポートすると pfx ファイルというのができあがる。
  2. OpenSSL の以下のコマンドを使ってルート証明書を取り出す。
    • openssl pkcs12 -in [pfx ファイル] -clcerts -nokeys -out [crtファイル]
  3. OpenSSL の以下のコマンドを使って、秘密鍵を取り出す。
    • openssl pkcs12 -in [pfx ファイル] -nocerts -nodes -out [key ファイル]
  4. さらに秘密鍵からパスフレーズを取り除く
    openssl rsa -in [key ファイル] -out [出力ファイル]

こうして出来あがったファイルを hMailServer の  SSL の所にかましてやれば動くようになった。
ボクが一番ひっかかったのは 4 のパスフレーズを取り除かないとダメだって事。確かに hMailServer にはパスフレーズを書く欄がなくて、???とはなってたのよね……。

まぁこれで無事に SSL で通信できるようになった。iOS でもバッチリ。実は Exchange Server 2010 は TLS のバージョンが古くて iOS ではエラーが出まくりだったのだ。ちなみに Exchange Server をバージョンアップするという選択肢はお金の関係上ないってのと(汗)、Exchange Server 自体、いつの間にかサーバ単体では売らなくなった??