2019年05月15日に初出の投稿

Last modified: 2019-05-15

現在、SAKURA の専用サーバにて PHP 5.3.3 と Apache 2.2.15 を稼働させている。これらは、もちろんそれぞれの最新バージョン(PHP 7.3.5、Apache 2.4.39)からすると相当に古いもので、とりわけ WordPress のようなアプリケーションは、バージョン 5.2 以降だと PHP 5.6.20 が要求スペックとなったので、いまサーバで動いている WordPress をアップデートできなくなっている。そういうわけで、今日は朝から PHP と Apache をバージョンアップすることとした。とはいえ、このサーバはステージング・サーバであって、当社の事業で使っている LP や問い合わせフォームなどが混在しているが、本来は自社のテスト用であるから、必要以上に工数を使うのは無駄である。そこで、サーバの OS が CentOS 6 であることから yum を使うことにした。

作業の途中に細かいコメントを書き散らしていたため、Messages では乱れた内容になっていたのだが、最初にはっきりさせておくべきなのは、次の3点だ。

(1) さくらインターネットのリポジトリは致命的に古く、サーバを借りたら即座に削除するべきゴミである。

(2) remi や epel といった定番のリポジトリを無暗に導入しても新しいパッケージが使えるとは限らない。

(3) PHP 7 系統と Apache 2.4 系統を yum でインストールするだけで使えるかのように書いてる記事は、全てデタラメである。

特に (3) は重要だ。ふつう php を入れてから httpd を入れるのが正しい順番なのだが、PHP 7 系統は Apache 2.2 系統にしか対応しておらず、何も考えずに yum で php73 と httpd24 を入れると、必ず "Cannot load /usr/lib64/httpd/modules/libphp7.so into server" というエラーになる。そこに実際に libphp7.so があろうと、それが Apache 2.2 系統にしか対応してないからだ。こんなことは、実際にサーバでやってみれば子供でも分かることであり、これほどの重大なポイントについて何も触れていない記事というのは、要するに当人がやってみたこともない素人であるか、あるいは実際にそういうエラーが起きていても対処するスキルがないのであり、どちらにしても信用できる書き手ではない。

それから (1) は SAKURA で専用サーバを借りた人ならみんな知ってることだろうから、いちいち詳しくは説明しない。オンラインで検索すれば、yum を使ったインストールの手順として、remi や epel のような《最新版に対応したリポジトリ》を導入することから説明が始まるため、もう SAKURA のリポジトリを無視するというのは利用者にとっての「お作法」に近いものとなっている。僕も SAKURA とは15年くらいのつきあいなので、グランフロントの新しいオフィスでも見学がてら文句を言いに行ってもいいのだが(笑)、そんなことこそ時間の無駄というものであろう。作法として手順を学んだ人間は、ロボットよろしく無機質・無慈悲・無頓着にクズを無視して仕事をするべきである。言ってみれば、その無頓着の責任をとるために、われわれ会社の役職者というのは、しょーもない金額でも平社員より高い給料をもらっているのだ。(なお、リポジトリを提供する方は "It's a feature not a deficiency" などと言うのがフォーマットのようだが、PHP7 が出て何年になるというのか、CentOS の開発チームに指を折ってものを数える方法でも教えてやる人はいないのだろうか。)

そして盲点となりやすいのが (2) だ。とにかく、この手の話題については日本のような文化僻地だけでなくアメリカにもコピペ小僧が膨大な数の記事を書いているため、何か新しいソフトウェアを導入するとなれば何も考えずに remi や epel、あるいはロシアの怪しいリポジトリや mysql などパッケージに特化したリポジトリを導入するべく手順を解説している人が非常に多い。しかし、そもそも「リポジトリ」とはパッケージ、すなわちプログラムの置き場所であって、PHP なら PHP の公式開発者が提供しているソースコードとは無関係に配置され公開されているものだ。よって、有名なリポジトリになれば外部からの攻撃が増えるのは当然だし、それを検査する仕組みもなしに実務家がリポジトリを使うのはどうかと思う。もちろん PHP の更新を一手に引き受けているかのような活躍をしている remi のメンテナーとかは個人としては称賛に値するものの、クラックされていないという保証がどこにあるのか、yum を使っているだけでは全くわからない。したがって、願わくは検証可能な人々も使っているであろう、remi や epel を導入することに(だいたい yum を使おうという人に)反対はしないが、そういうリスクがあるという事実も考慮して、おかしな挙動を見せたときは正しくない場所からダウンロードして使っているソフトウェアではないのかと疑う選択肢も入れておきたい。

そういうわけで、手っ取り早く WordPress をアップデートできる環境にしたいなら、httpd は放っておいて PHP だけをバージョンアップした方がいい。しかし、うちの CentOS 6 の環境では rpm -Uvh ./remi-release-6.rpm でコマンドを打ちこんでも remi のリポジトリが /etc/yum.repos.d に入らなくなってしまった。手動で ".repo" ファイルを作成して編集してもいいが、この問題を放置していいものかどうか不安がある。そこで、キャッシュを削除してからいったん remi と epel を remove して入れなおしたら治った。

その後は、PHP73 へのアップデートを行う。httpd 2.2 系統のままであれば、特に問題なく進むが、一点だけ、yum update php でリポジトリを指定してアップデートしようとすると、

Lib_Utils2-1.00-07.noarch has missing requires of libssl.so.4()(64bit)

のように幾つかのファイルに問題が出るようだ。ただし、"--skip-broken" オプションでスルーできることはできるため、

# yum --skip-broken --enablerepo=remi,remi-php73 update php

と実行して PHP だけを 7.3.5 へアップデートした。いまのところ、問題はないようだ。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Twitter Facebook