PHPとMySQLをアップグレード

CentOS6.10で通常インストールされるPHP5.3.3ではWordPressのプラグインで問題が出てきたので、 remiレポジトリを追加してPHP 7.1.20にアップグレードしました。 PHPをアップグレードすると、大抵は連携しているMySQLもアップグレードする必要があるので、 MySQLも5.7にアップグレードしました。 本当は、CentOS自体を6から7にアップグレードした方が良く、 途中まではIntelのNUCのNUC5CPYHにCentOS7を入れて、移行環境を作っていたのですが、 現在ブログを動作させている、DN2820FYKHのCentOS6.10でPHPとMySQLをアップグレードしてから、 何処かのタイミングで置き換えた方がリスクが少なく出来ると考えて、PHPとMySQLのアップグレードに留めました。

そろそろ

最近はTwitterにばかり投稿していて、ブログの方は放置していますが、 流石にCentOS6シリーズでWordpressを動かすのは厳しくなってきていて、 プラグインがPHPのアップグレードの要求を出すようになってきました。 以前CentOS7を試しに入れましたが、色々上手く行かずにCentOS6に落ち着いたんですが、 また試してみないとダメになりそうです。

関連する記事を表示するプラグインをアップデートするとエラーになる件

wordpressは管理画面からwordpress本体やプラグインをアップデート出来るので大変便利ではあるのですが、 先日、関連する記事を表示するプラグイン「WordPress Related Posts」のバージョンアップの通知が有ったので、 アップデートしたらエラーが出てページ自体表示できなくなる現象が発生し、 その現象に気が付いたのが大阪旅行で新横浜に向かっている電車の車内でしたので、 スマホのアプリのターミナルからログインして「WordPress Related Posts」をリネームして強制的に使用不可にすることで、 回復しましたが、原因は「WordPress Related Posts」のバージョンが3.6.3ならPHP5.3をサポートしていますが、 3.6.4にするとサポート対象外なのでエラーが発生していたようです。 エラーが出る詳しい原因はソースを調べないとハッキリしませんが、恐らく「WordPress Related Posts」の3.6.4から 追加された新規の機能がPHP5.3では存在しないPHPの関数をコールしているのだと思いますが、 とりあえずwordpressの管理画面上にプラグインのアップデートの催促が出ているのがウザいので、 バージョン情報をダウンロードサーバ上のバージョンより大きい値に書換えて凌ぐしか無さそうです。 PHPのアップデートが難しい環境の場合、以下のファイルの4行目を「Version: 3.6.3」から「Version: 3.6.4」とすることで とりあえずは、管理画面にアップデート通知は出なくなります。 wordpress-23-related-posts-plugin/wp_related_posts.php なんか、3.6.3と3.6.4のソースのdiffを取ってみたところ、mixpanelという機能が悪さしているようです・・・。

一昨日の夜からサーバに接続出来なくなっていましたが・・・

ようやく復旧しました。 原因は、ダイニングの蛍光灯のシーリングライトが突然「カチカチ」と言う異音を発したため、 余っているLEDのシーリングライトと交換するために、ブレーカーを落としました。 そうそう、アマゾンでアイリスオーヤマのLEDシーリングライトCL6D-5.0が3800円位で売っていたので購入して、 こっそりリモコンの調子が悪いELSONICのLEDシーリングライトと交換していたので、 IEMCL3202N3が1個押入れに入っていたわけです。 アイリスオーヤマのシーリングライトは評判余り宜しくは無いのですが、 それでもリモコンの入手性とかはELSONICよりからマシだったりするのでねw ブレーカーを落とす際に、誤って光終端装置の電源まで落としてしまって、 外向きのIPアドレスが変わってしまい、名前解決が出来なくなったからです。 DDNSの「yosea.sytes.net」でも名前解決出来るので、 no-ipのページに接続すると、現在のIPアドレスがわかるので、 DNSのレジストラのIPアドレスを更新すれば良いのですが、 サーバとして動かしているNUCの電源も落としてしまっていたため、 no-ipの更新用のデーモンが動いておらず、外出している間は何も出来ない状態でした。 今のプロバイダは光終端装置を再起動しない限り、IPアドレスが変わらないので油断していました。 名前解決に関して、現在のIPアドレスがわからなくなると外出中は手に負えなくなるので、 何か仕組みを考えないといけないかもしれませんね。

wordpressのプラグインをアップデートしたら

以下のエラーが出て、記事を表示できていませんでした wordpress-23-related-posts-plugin/config.php on line 130 とりあえず、sshでログインして、「wordpress-23-related-posts-plugin」をリネームしたら、管理画面から入れるようになりましたが、今までwordpress本体とか、プラグインを管理画面からアップデートしても不具合でた事が少ないので、油断していました。 一応、アップデート後は記事の表示ができるか確認しないとね。

wordpressを高速化

Googleが提供している、webページの表示速度を計測してくれるPageSpeed Insightsで 当ブログの表示速度を計測してみたら、かなり遅いという結果が出ました。 メンテナンス性は維持しつつ、出来る限り表示速度を上げるべきだと思いますので、 小手先で出来るような対策を行ってみましたが、これからもう少しチューニングを行ってみますが、 ハードウェアは変更せずに、果たして何処まで高速化できるのでしょうかね。 とりあえず、Wordpress側に「WP Super Cache」というプラグインを導入して、 毎回PHPで動的にページを生成しないようにしました。 PHP側でも、「Zend OPcache」をビルドして有効にしてみました。 それと、APCも導入してみました。 APCを入れると逆に遅くなるので、無効化しました。 # yum -y install php-pear # yum -y install pcre pcre-devel # pecl install APC これで少しはマシにはなるかと思います。 あとは、PHPを7とかに上げると更に高速化出来るんですけど、 何分現在動かしてるOSがCentOSの6なので、色々と厳しかったりします。 PHP単体だけなら良いのですが、MySQLが絡むととても面倒だったりしますw CentOSを7に上げれば良いんですけど、今ウェブサーバとして動かしてるマシンがIntelの安NUC、DN2820FYKHですが、 これが以前試したところ、ハードウェアが新し過ぎてCentOS7がUEFIにまともに対応しておらず、 かなり苦労した憶えがあるので、CentOS6で止めていたりします。

[…]

ブログを続々と復元中

ここ最近作成した記事は、Chromeのキャッシュを拾い上げて、 画像とHTMLを貼り付けて復元完了ですが、 問題はそれ以前のデータ。 画像は編集したデータがローカルのマシンにあるので、 一度サーバにWordPressでアップロードすると、 勝手にリサイズしたファイルも生成してくれて、 所定のディレクトリに保存してくれるので良いんですが、 HTMLは無いのでどうしようかと思いましたが、 Google大先生のキャッシュにしっかりと保存されているので、 それを利用しています。 クローラでデータ回収されるのも、こういった時に役に立ちます。 そういえば、IntlliPeakの影響でS.M.A.R.T. の Load_Cycle_Countの回数が とんでも無い回数動作して壊れたと思っていたが、 どうやら構築当時の記事では無効にしていたようだ。

多分、サーバのディスクがトンだ

今日どうもサーバにアクセスできなくて、 色々調査してみたのだが、どうやらサーバに使用している、 NUCのDN2820FYKH2に搭載した、ディスクがトンだっぽい。 以前から、MicroSDHCにバックアップするシェルを書いて、 cronで動作させる仕組みを構築していたのだが、 どうもUSBに負荷を掛けると、Linuxからデバイスが認識されなくなって、 途中で頓挫していたのだが、そのまま放置プレイしていた矢先でした。 今は実家のDN2820FYKH2ではなく、現在住んでいる所のDN2820FYKH2で 動かしているが、かなりデータリカバリが大変になりそうな感じ。 まぁトンだと思われる原因は、ウェスタンデジタルのIntelliPeakだと思われ、 現にこっちのハードディスクのS.M.A.R.Tの「Load Cycle Count」も22万回を超えていたので、 慌ててIntelliPeakを無効にしましたが、何も考え無しに、ノート用のハードディスクを サーバ用途で使うのは危険という事ですね。 という事で、バックアップは大事だよと言うお話しでしたw

写真まで用意したのに・・・

記事まで書く時間がなかったりして、まだ未投稿になっている記事が 現在27件もあったりします。 どうしても、RAWで撮った写真を選別して現像して、 WordPressにアップロードまでは行くんですが、やはり文章を書くのが苦手というか、 他の人が見てわかりやすい文章を書くというのは本当に難しい。 特に話題が色々飛んだりすると、話の流れを纏めるのが困難になったりします。 しかし、これらも勿体無いから近いうちに公開まで漕ぎつける予定です。

気が付けばブログを書き続けて10年以上

このブログの一番古い記事を開くと、2005年6月19日の蟹サン排除記事で始まりますが、 当初はシックスアパート株式会社の「Movable Type」を使用させてもらっていました。 「Movable Type」は、更新の度に元データからHTMLファイルを生成する仕組みで、一度生成してしまえば、 後は静的コンテンツなので、サーバ負荷が低くく出来るというメリットがあった。 ただ、当時は「Movable Type」がシェアが大きく、ライセンス的に問題が出そうな方向に進んでいたので、 何か別のブログシステムを構成するCMS(コンテンツマネジメントシステム)に移行を考えていたところ、 某氏が自宅サーバで「Nucleus CMS」を使用していたので、 私も真似して「Movable Type」からデータをインポートして移行した。 「Nucleus CMS」への移行が終わったのが、特に問題は無さそうなのでという記事で、 これが2006年3月6日、つまり「Movable Type」を使い始めてからたった6ヵ月で移行したことになる。 当初は便利に使わせても貰っていたのだが、この「Nucleus CMS」を使ったCMSも長くは無く、 途中で「これはヤバい」というのを察知したのが、セキュリティーホールを放置したこと。 開発者不足で手がまわらないという事情があると思うが、流石にこれは危険と判断し、また別のCMSへ移行する決心をした。 当時、CMSは乱立状態で、どのシステムがシェアが大きくなるかわからない状態ではあったが、 色々調べていくうちに、「WordPress」がこの先シェアを伸ばしてくだろうと判断し、 「Nucleus CMS」から「WordPress」へ移行する決心を決めた。 だが、「Nucleus CMS」から「WordPress」へ移行するのが、一筋縄で行かず、 当然直接の互換性もないわけで、何とか試行錯誤を繰り返し、時にPHPスクリプトを書いたり、 人様が公開してくださっているスクリプトを改変したりして、 かなり苦労して「WordPress」へ移行した記憶がある。 その記事が2006年11月24日のとりあえず移行完了!!という記事。 やはり半年と少しで移行した感じだ。 それから約9年、途中で多少の波乱万丈はあったにせよ、「WordPress」は順調に機能を強化していて、 現在では「Movable Type」のシェアを抜いて、とても使いやすいCMSへと進化した。 また、Androidアプリから、自分が構築した「WordPress」へ楽に投稿できるようになった。 多分、これからも「WordPress」は愛用させてもらうことになるだろうと思う。 そして、「Movable Type」時代や「Nucleus CMS」時代に書いた記事で、 写真の移行が中途半端になっていたので、とりあえず全て見直して、完全に「WordPress」のルールに 乗るように修正した。 2日間で作業したが、実質3.5時間程度で終わらすことができた。 これも、「WordPress」の管理画面での操作性の高さと、新たにサーバを動かしている端末を、 DN2820FYKHへ置き換えたことによる、レスポンスを強化した結果であるのだろうと思う。