Ellinikonblue.com Weblog

　Ellinikonblue.com Weblog で、PA-API v5 に対応するに当たって、 最初、WSL 上の Ubuntu (18.04 LTS) で、 テスト用のサブルーチンを作り込んだのですが、 なんとか Ubuntu で、応答がもらえるプログラムができて、 今度は同じそれを CentOS 7 で動かしてみたところ、 エラーしか返ってこない状況に悩まされ続けました。

　モジュールに不足があるわけでもなく、最後は Perl のバージョンまで疑ったのですが、 結論、LWP::Protocol::https のバージョンアップを行っただけで、 Ubuntu で通ったプログラムがそのまま、 CentOS でも動きました。

　LWP::Protocol::https のバージョンの差（このバージョンアップに紐付いていくつかのモジュールも 自動的にバージョンアップされますが…）で、何が起こっていたのかまでは正確に言及はできませんが、

perl -MIO::Socket::SSL=debug3 test.pl

として、実行したときの応答が明らかに違うので、原因はこのモジュールで間違いないと思います。

　CentOS は　yum でインストールできる 標準リポジトリから perl 本体もモジュールも拾ってきていました。
　いざ、モジュールのバージョンアップとなった際、昨今は cpanm と言う便利なコマンドがあって、 これを使って LWP::Protocol::https をインストールすると、 依存関係も含めて必要なモジュールはすべて拾ってきてくれて、 かつ CentOS の 標準リポジトリからインストールしたモジュールより優先して使用してくれるので、 実質、モジュールのアップデートを行えば perl のバージョンアップなどせずともすべて解決しました。

　このあたりの perl の環境整備や cpanm については、別途、 今後のことを含めてもう少し詳しめにまとめておこうと思います。

　Wordpress は 5.2 から、 MariaDB の動作要件も 10.1 以上とされていますので、 ついでに MariaDB も 10.4.6 で Stable Release となった最新版に、 CentOS 7 標準リポジトリの 5.5 から アップグレードします。

　万が一に備えて、必ずデータベースのバックアップをしてから実施して下さい。

　バックアップが終わったら、まずは

curl -sS http://douwnloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash

として、MariaDB の 最新 Stable 版へのリポジトリを登録します。
　この登録が無事終われば、

sudo systemctl stop mariadb
sudo yum update

とすれば、最新版の 10.4 系がアップデート候補に挙がってくるようになるので、 実行すれば、MariaDB 5.5 から一気に 10.4 でも、 データも引き継がれ、アップグレードされるはずです。

　ただし、アップグレード直後は、MariaDB が起動していませんし、 システム起動時にも起動しない設定に戻るので、以下のように起動してください。

sudo systemctl enable mariadb
sudo systemctl restart mariadb

データを引き継いでうまくアップデートできなかった場合は、一度、 MariaDB を 初期化してバックアップから復元して下さい。

　以上、の処理が終われば、Wordpress も アップグレードできるようになっているはずで、それが終了すれば（手順は端折ります）、 無事、Wordpress 5.2 へのアップグレードは完了です。

　Wordpress を 5.2.x へアップデートするために、 PHP を CentOS 7 標準の 5.4 から 7.2 へアップデートします。

　PHP の最新は 7.3 系ですが、7 系であれば、 Wordpress の動作要件は満たしますし、 セキュリティーサポートは来年末まであリ、 また Ubuntu の最新 LTS 18.04 でも 標準で採用されていることもあり、 さらに自分でも構築したことのある PHP 7.2 をターゲットにしますが、 やり方は基本、PHP 7.3 でも同じはずです。

　PHP は Remi リポジトリから導入します。まずは EPEL/Remi リポジトリを導入します。

sudo yum install epel-release -y
sudo rpm -ivh https://rpms.remirepo.net/enterprise/remi-release-7.rpm

　次に現状インストールされている PHP 5.4 のパッケージを確認します。

rpm -qa | grep php

　PHP 本体他、Wordpress の動作に必要な パッケージもあるはずなので、これらをまとめて同等のパッケージをインストールするため、 メモっておいてください。
　また PHP の設定ファイル (/etc/php.ini) もバックアップをとっておき、 バージョンアップ後に設定を反映させるなり、 7.2 インストール後にバックアップと置き換えるなりの 作業が必要になります。

　その上で、PHP 5.4 をアンインストールし、以下のように PHP 7.2 を導入します。

sudo yum remove php* -y
sudo yum --enablerepo=remi,remi-php72 install php php-mysqlnd php-gd php-xml php-xmlrpc php-mbstring php-mcrypt php-fpm php-opcache php-apcu -y

　上記の例では、PHP 本体の他に php-fpm や OPcache/APCu も合わせてインストールしています。 ここは先ほどメモしたパッケージで、足りないものは適宜足してください。
　これで PHP 7.2 へのアップデートは終了です。

Ellinikonblue.com Weblog 「 WordPress 5.2 から PHP 5.6 が必須になった件」

「WordPress"1000倍"高速化」チューニング 第一弾──「PHP 5.6」「OPCache」「APCu」を導入する (1/2) 「WordPress"1000倍"高速化」チューニング 第二弾──「PHP 7」を導入する (1/2)

　Wordpress の 2019 年 6 月時点の最新版 5.2 から、動作に必要な PHP のバージョンが 5.6 以上でないと、 アップグレードできなくなってしまいました。

　一方で CentOS 7 では、 標準リポジトリからインストールできる PHP が 5.4 という状況で、お気軽にレンタルサーバーで Wordpress していた人は、 容易にアップグレードできなくなってしまい、 PHP の古いバージョンによる脆弱性云々より、これによって放置される Wordpress サイトが増える方がちょっと心配。

…なんですが、人のことを心配する前に、個人的には面倒見ている Wordpress は なんとかせざるえず、ちょっと前に、 クリーンインストールで PHP 7.2 + MariaDB 10.2 で 1 サーバ立てたのですが、やろう、やろうと思って、結局、 この作業工程をドキュメントまとめておらず、 これから何台、この作業をやらなくてはならなくなるか見えないので、 今のうちにまとめておくことしました。

　やることは…

1. PHP のアップデート
2. MariaDB のアップデート
3. Wordpress のアップデート

となります。

　MariaDB も CentOS 7 の 標準リポジトリでは 5.5 になり、Wordpress の 動作用件では、10.1 以上とされているので、おそらくこちらは必須ではないように思いますが、 まとめて一度ですませておくことにします。

　では各項目ごとにまとめていきます。

　この正月、久々に長い休みが取れたと思ったら、サーバーの移行を手伝わされることになって、 久々にインストールしたての CentOS 7 から 設定し、LAMP （死語？w ）の準備、初チャレンジとして WordPress の データ移行まで経験させてもらったのですが、こういう作業をする際、 OS から LAMP までは、いつも同じサイトの情報を参照させてもらっているのに、 毎度、Google 検索から入るので、 やっとその効率の悪さに気がついて、メモっておくことにしました。

サーバーの基本的な設定 さくらインターネットのVPS（仮想専用サーバー）構築・設定マニュアル サーバーの設定から WordPress のインストールまで 入門ガイド｜VPS（仮想専用サーバー）はさくらインターネット 　今回は人んちだと思って、CentOS 7 の上に、 Apache 2.4 は そのままパッケージインストールしたのですが、 PHP は 7.2 、 データベースは MariaDB も 10.2 を入れ込んでやりました (^^)v

　その際、WordPress の動作環境のチューニングは、以下の記事を参考にしました。 ちなみに、以下の記事も WordPress サイトを 構築するたびに、これまでよく拝見させていただいてました。 とにかく速いWordPress 　ご参考になれば…m(_ _)m

　Ubuntu 16.04 を 使っていたときにやれていた、やりたいことは 18.04 でできているので、 不具合というわけではないですが、ちょっと気になる症状が出て、それをなんとか解消できたので、 メモっておきます。

1. ebtables のアップデートがエラーになる
　最初からそうだったかは、記憶が定かではないのですが、 apt を使ってアップデート行うと、ebtables のアップデートの際、エラーが出るのようになりました。
　下記の記事を参考におまじないを唱えると、解消しました。 Ubuntu 18.04 on WSL で ebtable のアップデートがエラーになる備忘録 　そもそもにして ebtables が何をしているのか、このおまじないは何をやっているのかまで、 見きれてないのですが、その後大きな問題もなくアップでとできているので、由としています。

2. gem update で openssl がエラーになる
　18.04 で ruby をインストールするとくっついてくるネイティブエクステンションに openssl があるのですが、これがアップデートしようとすると、コンパイルできずにアップデート出来ません。
　これは

# sudo apt install libssl-dev

　として libssl-dev パッケージをインストールすると解消します。 以前、ffi でもエラーが出たときがあって、そのときは同様に

# sudo apt install libffi-dev

　として libffi-dev をインストールしてやればエラーはでなくなりました。 付属でくっついてくるなら、コンパイルで必要ならライブラリも依存パッケージとして、 インストールしといて欲しい…と思わなくはないです (_ _;A

　個人的に Windows 10 の Fall Creators Update で 最も有用だった新機能は、間違いなく正式版になった WSL(Windows Subsystem for Linux) で、 cmder をコンソールにして、 Ubuntu を使ってますが、 CUI ベースの作業は、もうこれ一つでほぼ完結できる便利さ。

　この便利な環境、いろいろ活用していますが、 Windows を使っていても man がその場で引けるのはとっても便利！ (^^)b

　ただもちろん初期状態では英語のマニュアルしか入っていないので、 まずは以下の方法で、WSL の Ubuntu を 日本語化。

sudo apt-get install language-pack-ja-base language-pack-ja
sudo update-locale LANG=ja_JP.UTF-8 LANGUAGE=”ja_JP:ja”

　そして、以下のように日本語マニュアルをインストールすれば、 Windows 端末でも、いつでもどこでも man が引けるようになります。

sudo apt-get install manpages-ja manpages-ja-dev

cmder を使う #2 - Ellinikonblue.com Weblog

　調べると、皆さんよく忘れるようなので、自分もきちっとメモっておくことにします。

　Linux 環境を新規に構築すると、少なからずコンパイル環境が必要になるときがあり、 個人的にはよく Sass を使える環境を整えるときなどに、 Ruby の ネイティブエクステンションのコンパイル環境を整えなければならなくなるので、 このときに「あれ？どうだっけ…」とほぼ 100% なります orz

　具体的には、Ubuntu では

apt-get install build-essential

　CentOS では、グループインストールで

yum groupinstall "Development Tools"

　ちなみに Sass 環境を整えるには、 Ruby 関連のパッケージをまとめて、

apt-get install build-essential ruby ruby-dev

とすれば gem で Sass なとを インストールすることができるようになります (^^)b

　先般、興味本位ではなく w 本気で使ってみようと、 Ubuntu GNOME 16.04 LTS を、 ESXi に仮想環境を用意してインストールしました。

　インストールはなんのトラブルもなかったのですが、 インストール直後に画面解像度を変えられず少々苦労し、 その後、日本語が入力できないことに気づいて、ちょっと調べました。

　以下のドキュメントを参考にさせていただきました m(_ _)m

りなっくす〜ワールド /superjeter007 のブログ 「 Ubuntu Gnome 16.04 LTS リリース＆セッティング！」

　設定だけで iBus-Mozc はプレインストールされているので、 すぐに使用が可能になりました。
　こういう一手間がいるところが、お気軽な日本語 Remix とは違うところ。

　今、個人的に GNOME3 になれようとしているので、 今回は Ubuntu GNOME を インストールしましたが、いちいちアクティビティを押下するために、 左上にマウスを持って行くことに早々に辟易としたので、 上記のドキュメントにあった Plank という ランチャーをインストールしてみました。
　すでに Ubuntu GNOME では 標準リポジトリからインストールできるようになっています。

# sudo apt-get install plank

でおっけー。

　普通に便利になった (^^)b

　よし使うぞ！＞Ubuntu GNOME

• Plank in Launchpad

Ellinikonblue.com Weblog 「 Ubuntu GNOME 16.04 LTS をインストールしました」

　最近しっかり追っかけていないので、順調なのかどうかはわかりませんが、 Ubuntu 二年ぶりの LTS(Long Term Support) 版 Ubuntu 16.04 LTS が リリースされたので、これを使ってみようと言うことで、早速、インストールしてました。

　コードネームである Xenial Xerus （おもてなしのアラゲジリス）が示すように、 Ubuntu もだいぶ煮詰まってきているので、 今回は Ubuntu GNOME を インストールしましたが、この際には何のトラブルにも遭遇しませんでした。

　ただ ESXi の仮想マシン上にインストールしたので、 Ubuntu GNOME のインストール直後、 画面解像度が変えられずに困りました。
　ちょっと調べると、これもすでにナレッジがあって、 ESXi の仮想マシンのプロパティで「ハードウェア」を選んで、 その中のビデオカードの「ディスプレイおよびビデオメモリ」の設定を 「設定の自動検出」にして仮想マシンを起動すれば、苦もなく解像度を変更できました。 「ディスプレイおよびビデオメモリ」設定において「設定の自動検出」とは、 何をやっているのかまでは調べませんでしたが、 今回、Ubuntu GNOME を インストールした目的は単なるインストールテストではないのでスルーしました。

　また Ubuntu GNOME を インストールし直すハメになったら確実に忘れていそうなのでメモっておきます (._.)φ