WordPress 5.2が無事リリースされました。「Jaco」の読みは、「ジャコ」でいいようです。
今回はtracにいくつかポストしたり、翻訳を修正案を提出したこともあり、コア貢献者と翻訳者に名前が掲載されています。
tracのポストについては「KUSANAGI for Vagrant」を使用してパッチを作成しました。subversionを追加するだけで環境が整備できるのでとても便利です。
サイトヘルス機能の確認段階で気になったのは、翻訳テキストにアポストロフィ（’）を多数使用していたことです。自身で翻訳テキストの追加や修正の際は、意識しておいた方がよさそうですね。
去年に引き続き、鎌倉へ。今回はあえて「鶴岡八幡宮」を外し、「源氏山公園」から「銭洗弁財天」を経て「鎌倉大仏」をめぐりました。
そんなわけで、下車したのはJR横須賀線の北鎌倉駅。昨年はそのまま「円覚寺」へ向かったのですが、反対側の改札から出て少し大船駅側に戻り、交差点を左折。そこから「葛原岡神社」を目指します。この経路、はじめは緩やかだった上り坂も途中から勾配がきつくなります。途中、観光客らしき人に会いましたが、ゆっくり歩いた割に人に追い抜かれることはなく、かなりマイナーなルートなようです。
葛原岡神社に近づくにつれ子供たちの声が聞こえ始め、桜の木々がある緩やかな斜面で何組かお花見しておりました。桜のほか、椿？も咲いており、淡いピンクの中に赤のコントラストが目を引きます。葛原岡神社は源氏山公園のはずれに位置しており、ここで花見をしながら少し休憩です。
次は源頼朝像へ向かいます。途中、銭洗弁財天方面との分かれ道を横目に下ったり昇ったりを繰り返しながら源頼朝像まで到着。ぱっと見では桜は見当たりません。
ここで引き返して銭洗弁財天を目指してもよかったのですが、「源氏山」というくらいなので山頂まで行ってみました。はっきりとした目印が見つけられず、怪しげな階段を上りながら高いところを目指していくと、山頂っぽいところにたどりつきます。そこには「七福神」の石像？がありました。源頼朝像側へ下る道へ進みつつ、銭洗弁財天へ向かいました。
岩盤をくり抜いた銭洗弁財天の入り口に到着。テレビでは中の風景した見たことがなかったので、入り口がこんなことになっていたのは少々驚きです。入口のトンネルをくぐり、さらに連なる鳥居をくぐって、下之水神宮、上之水神宮、本社などをめぐります。奥宮には入るだけで、いわゆる「銭洗い」はやめておきました。
さて、ここから鎌倉大仏までは少し距離があります。銭洗弁財天まで来る途中で「葛原岡・大仏ハイキングコース」という立て札を何度か目にしており、「距離が1.9km、所要時間が45分」であれば、自分でもいけるかなと思い歩いてみることにしました。
結論から言うと、このハイキングコースは運動不足の私にはかなりハードでした。林の中をもくもくと歩いていく感じで、途中で元気おじいちゃん・おばあちゃんグループに道を譲りつつ、大仏のある長谷へ到着しました。
最後の目的地で大仏を拝み、鎌倉駅まで徒歩で戻り、この旅は終了です。
WordPress 5.2 Beta1が公開され、開発環境（Windows PC）でサイトヘルス機能を確認しました。
使用していないプラグインやテーマが残っているなどの警告が表示されたわけですが、PHPのバージョンも引っかかっていました。開発環境のPHPはバージョン7.2系をメインにしており、どうやらこれがいけないらしい。先日「Minimum PHP Version update」という記事が公開され、その記事中ではPHP 7.3が推奨されています。WordPress 5.2の正式版がこの条件のままリリースされるかは確定していないわけですが、遅かれ早かれPHPをバージョン7.3にアップデートする必要があります。
PHPの各バージョンのサポート期間を「PHP: Supported Versions」で確認すると、バージョン7.3は昨年12月6日にリリースされ、セキュリティサポート期間は2021年12月6日となっています。これに対しバージョン7.2のセキュリティサポート期間は2020年11月30日となっており、アップデート候補は7.2か7.3になります。
WordPress 5.2のリリース予定まで1月を切っています。ゴールデンウィークのドタバタは極力さけるたいので、実験を兼ねて本サイトのPHPを7.3へアップデートしました。
# php -v
PHP 7.3.3 (cli) (built: Mar 5 2019 13:50:38) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.3, Copyright (c) 1998-2018 Zend Technologies
これで少し様子を見て、問題なければ他サイトでも作業を行う予定です。
今年のことを何となく書いてみる。
昨年末、WordPress 5.0のリリースがあり、それにあわせてプラグイン「Login rebuilder」などをバージョンアップ。その作業の過程で発見したバグレポートをtracにポストしていました。そんなこともあって、「WordPress 5.0.2 Maintenance Release」に名前（tmatsuur）が掲載されました。とても久しぶりです。
今年に入ってからは「常用漢字チェッカー」のコンテンツにいくつか不具合を発見してそれを修正したり、その勢いでほんの少しだけ機能改良したりしています（地味なところなんですが）。このサイトのコンテンツを大きく変える予定はないのですが、いくつかのコンテンツには年号表記が含まれているので、新年号が発表されたら速やかに対応したいところです。
話は前後しますが、昨年WordPressのプラグインなどの翻訳ファイルを作成・編集するプラグイン「Poppoppoo」ができました。これまで翻訳ファイルの作成・編集は「Poedit」を利用してきましたが、今後はこのプラグインで対応していきます。なおこのプラグインはサーバー内（基本的には開発環境）のファイルを直接読み書きするため、公式サイトでは公開する予定はありません。ページキャッシュやサイトマップ更新関連など、最低限必要だと思う機能はできるだけ自前のプラグインでカバーできるようにと考えています。そんなわけで作りかけで「没」にしたものもあるわあけですが、今年も1つぐらいは新しいプラグインを作りたいものです。
さて、「寝かせている」といえば取得したまま放置されているドメインがいくつかあります。いつまでも寝かせたままというわけにはいかないので、それらを使って「新しい『サイト』を1つ以上立ち上げる」を今年の抱負とします。
ちょっと時間が出来たので、久しぶりに「PageSpeed Insights」でサイトをチェック。少し前に作った趣味のサイトの「速度スコア」はモバイルが50点台、パソコンが90点台でした。モバイルはもう少し何とかしたいと思い試行錯誤してみた。
「改善できる項目」に表示されたものは次の通り。
サムネイル画像にPNG-8ファイルを使用しており、全投稿のサムネイル画像を表示していたことが原因でした。
最初に試したのが「jQueryプラグインLazy Load」を使ったサムネイル画像の遅延読み込み。改善できる項目に変化はなく、モバイルの「速度スコア」はほぼ同じ。ということで基本に立ち返って画像ファイルのフォーマットをJPEG形式に変更してみた。サイトを作った時点でPNG-8形式を採用した理由はJPEG形式のノイズを嫌ったためだ。次世代フォーマットはブラウザが限定されるため、とりあえずはJPEG形式の画質を「80」にして、ノイズが気にならないレベルでファイルサイズを2/3程度に削減。再分析では「改善できる項目」から「次世代フォーマットでの画像の配信」は無くなりました。
「bootstrap.min.css」「font-awesome.min.css」が対象。どちらもサイトの「肝」であり、すぐに手は出せない感じ。
「bootstrap.min.css」「font-awesome.min.css」のほか、サイト固有のCSSファイルが対象。前2つはサイトの「肝」であり、サイト固有のCSSファイルをインライン化してみた。再分析ではサイト固有のCSSファイルは遅延読み込みのところから消えたのだが、「速度スコア」はほぼ同じ。ここはなかなか悩ましい。
現在のサイトはVPSを利用しており、この項目は分析のタイミングで表示されたり、表示されなかったりする。VPSを切り替えなければならないほど遅くはなく、サーバー設定で改善できる可能性があるのかはっきりしないので、しばらく様子見とした。
対象のサイトは「Bootstrap 4」と「Font Awesome」を使ったWordPressの独自テーマで構築している。「Font Awesome」を使っている部分はそれほど多くないので代替は可能かもしれないが、「Bootstrap 4」は根幹ということもあって替えは効かない。また「PageSpeed Insights」の「診断」には「過大な DOM サイズ」という項目があり、現時点のノード数1,400を超えている。全投稿ページにすばやくアクセスできるよう、多数のリンクや検索フォームを盛り込んでいることが要因。はてさて、どうしたものか。
昨日の夜、品川マイクロソフトさんで開催された「KUSANAGIハンズオン＆徳丸先生のセキュリティセミナー」に参加。軽く感想などを残したいと思います。
セミナー内容は以下の通り。
キーワードは「セキュリティROI」で、以前は（社内ネットワークに）『侵入させない』だったが、現在は『侵入されたことをすばやく検知し、すぐに復旧』とのこと。
「KUSANAGI for Vagrant」は社員の方が個人的に開発していたものがベースとのこと。box名が「yuya_tajima/kusanagi」になっている謎が解けました。
WAFの概要とその効果をデモサイトを使いながら紹介。
さてKUSANAGIハンズオンの中身ですが、（ちょっとズルをして）事前にKUSANAGI for Vagrantのインストールまで済ませておいたこともあり、個人的にはそれなりに進めることができました。それでも前半のyumコマンドの処理に時間がかかり、一部の方はここでだいぶ苦労された様子。後半のKUSANAGI WAFのパートがきつくなったのが残念でした。KUSANAGI WAFのところはう少し詳しく聞きたかった感じです。
KUSANAGI WAFのオン･オフはコマンドで簡単に切り替え可能ですが、初期設定のままではWordPressの管理画面の一部でも問題が発生するため、チューニング（設定リストの編集作業）は必須。実際に公開サイトで使用する場合は、適用しているテーマやプラグインに応じたチューニングが必要不可欠であり、緩い設定をしてしまうと攻撃を防ぐことができないため、それなりのノウハウが必要で、実運用は「ちょっと大変そう」というのが正直な印象です。今後、時間経過によって初期設定やチューニング方法が洗練されていくことに期待したい。
デモサイトを使った攻撃とWAFの検知では、徳丸さんの会社でも扱っているWAF製品の「SiteGuard」が使用され、問題がありそうなリクエストを「検知」するだけでなく、その可能性がありそうなリクエストを「監視」する機能がありました。管理画面上で「監視」から「検知」に切り替えできる機能が紹介され、攻撃発覚後の対応は比較的容易にできるそうです。WAFは既知の攻撃を防げるだけでなく、（その時点で）未知の攻撃を防ぐ場合があり、それなりに有用ではあるものの、誤検知も少なからず発生することは意識しておくべきでしょう。
さて、徳丸さんのお話であらためて意識させられたのが、「ナチュラルなリクエストは（WAFで）検知しにくい」的なニュアンスの内容と、不具合が見つかった場合は速やかにアップデートしていく責任があるということ。またプラグインの機能そのものが脆弱性になりうる可能性があることはプラグインを公開している身としては肝に銘じておきたい。
WordPressのアップデートが近づくと、公式サイトにプラグインを登録している方には「WordPress 5.0 is imminent! Are your plugins ready?」な感じのメールが届きます。このメールには登録しているプラグインのバージョン確認状況がリストされており、それらのアップデートの準備を始めます。ある程度の需要がありそうなものはWordPressのアップデートに合わせる感じで進める方針です。
とりあえず5.0 RC版の公開待ちですね。
WordPress関連の情報を掲載している「WordPress私的マニュアル」のテーマをリニューアルしました。主な変更点は次の通り。
まあBootstrap4を使ってテーマを作ってみたかっただけなんですけどね。
使っているスマホの契約更新月に伴い2年ぶりに機種変しました。
iPhone 6 Plus を Xperia XZ Premium に、
iPhone 6s を iPhone 8 に、といった感じ。
Xperia XZ Premium は久しぶりの Android 端末。発売から少し経っているのもあり、すぐにシステムアップデートとなって、アップデートの実行で 8.0.0 になりました。これの気になった点は、標準状態のバッテリーの減り具合。フル充電後の未操作で2日経過前にバッテリー残量が0になりました。とりあえず、標準でインストールされている「しゃべってコンシェル」と「スケジュール＆メモ」を無効化して経過を見てみたところ、未操作の場合は1日約7%の減りとなりました。しばらくはこの状態で使ってみようと思います。
iPhone 8 の方はというと、こちらも立ち上げ直後にアップデートが来ていたのでとりあえず実行して iOS 11.2.5 に。パッと見で気になったのが、画面がやや赤みを帯びていること。ネット検索して「設定」で調整できることがわかったので、「Night Shift」－「色温度」の設定を初期状態よりも「冷たく」側にスライドして調整しました。
こちらの端末で戸惑ったのが Gmail のセットアップ。実は以前の端末が Google アカウントの2段階認証に使っていて、セキュリティコード発行の操作を行っても MNP したこの端末には通知が届きません。この問題の対処方法はいくつかあるようですが、PC で Google アカウントの「2段階認証プロセス」にアクセスして、Xperia XZ Premium の電話番号を追加し、そちらをデフォルトに変更。これで無事 Gmail のセットアップが完了しました。
最後に料金プランを紹介。自宅・事務所ともWiFi環境なので、データ通信料を低く抑えたプランを選択しています。
| Xperia XZ Premium | docomo |
| 合計 | 5,500円（5,940円） |
| カケホーダイライト | 1,700円（1,836円） |
| spモード | 300円（324円） |
| データSパック（小容量）（2GB） | 3,500円（3,780円） |
| iPhone 8 | SoftBank |
| 合計 | 6,500円（7,020円） |
| スマ放題 | 2,700円（2,916円） |
| ウェブ使用料 | 300円（324円） |
| データ定額ミニ（2GB） | 3,500円（3,780円） |
今回の機種変は2週連続で「ヨドバシカメラ マルチメディア横浜」さんで行い、iPhone 8 の月額料金はいくつか割引が適用されて上記の値段よりも安くなります（Xperia XZ Premium と同程度）。もう少し安くおさえたところですね。
昨日、twitterにApacheの脆弱性に関するツイートがありました。
[2017/06/20 15:40 公表] Apache HTTP Web Server における複数の脆弱性に対するアップデート https://t.co/ynleZIuNok
— JVN 脆弱性レポート (@jvnjp) June 20, 2017
パッチが公開されているか微妙なタイミングだったのですが、昨晩中に手持ちのサーバーにアクセスして「yum update」だけ実行しておきました。日付が変わって今朝sshでログインしようとすると、タイムアウトでログインできません。全部ログインできないかというとそんなわけではなく、CentOS 6系は問題なくログインできましたが、CentOS 7系がログインできない状況でした。外は雨降ってるし、かなりブルーに。。。「まあ最悪はサーバーをリセットかな」と思ったわけですが、とりあえずサーバー（さくらのVPS）のコントロールパネルにアクセスして、「コンソール」からrootでログインを試行。なんとかログインできたので、原因の調査開始です。
はじめにsshのログを確認。ログインに失敗している形跡を示すログは見つかりませんでした。。。
ログがまったくないということなので、ファイアウォールの状況を確認。
# firewall-cmd --list-all
...途中、省略...
services: dhcpv6-client https ssh ...
サービスとして登録されていることは確認できたので、/usr/lib/firewalld/services/ssh.xmlを開いてみたところ、ポート番号がデフォルトに戻っていました。昨日の「yum update」によって、変更していたsshのポート番号が初期状態に戻ったようです。
<port protocol="tcp" port="22"/>ポート番号を変更してファイアウォール設定を更新。無事、sshでログインできるようになりました。
# firewall-cmd --reload
# systemctl restart sshd.service
今回の件、反省すべきところは「yum update」したら、別のターミナルからsshでログインできることを確認しなかったこと。今後は徹底しないといけないですね。