カテゴリー: web

なにー、WordPress5.2.2。 やってくれたな。

どこかで、自動アップグレードする設定とかあったのでしょうか？　　更新ボタンも押していないのに「WordPress5.2.2にアップグレードした」とメールが送られてきた。たしかに、WordPress5.2.2　が6/18にリリースされていて、　 https://wordpress.org/news/2019/06/wordpress-5-2-2-maintenance-release/ 　このサイトにも勝手に適用されていた。
　”更新”の記載には「最新バージョンの WordPress をお使いです。 今後のセキュリティ更新は自動的に適用されます。」と書かれている。 これを信じるならば、まだ セキュリティ情報は出ていないが 5.2.2で脆弱性の対処が行われたのでしょう。
以前に予想したとおりの状況ですが、勝手に修正を適用されてしまうのは想定外でした。 5.2.1の時みたいにセキュリティ強化した権限設定の影響でサービスダウンしてしまったらどうしてくれるつもりでしょうか。その辺の不満を越える危険をはらんだ問題だというならわからなくはないが、この仕掛けを基盤にして業務用に使用しているところは沢山あります。業務が止まったら大変なことになります。この辺を踏まえて設定で自動適用するかとか自動適用する脆弱性の深刻度レベルを設定できるようにするとか、工夫してほしい。

WordPress5.2.2の修正内容をチェックはまた明日。

Ｎginxが起動しない。そして、復旧。

監視モニター用の画面が起動しないので、ほかのページを確認すると、Nginxが動作していないと推測される状況でした。プロセスを確認するとNginxのプロセスは確かにいない。手動で、 Nginxを再起動しても、復旧しませんでした。

　こんな時は、慌てず原因調査します。nginxのログファイルerror.logには、つぎのとおり出ていました。再起動するたびにこれが出力されます。

[notice] 19828#9876: signal process started
[error] 19828#9876: OpenEvent(“Global\ngx_reload_16096”) failed (2: The system cannot find the file specified)

　logsディレクトリには ファイルnginx.pidが存在していて、このファイルには 16096と書かれていました。 上の” ngx_reload_16096 ”と同じ数字です。これはNginxのPIDです。tasklistでこのPIDが存在しないことを確認しました。また nginx.pid ファイルのタイムスタンプは2日前であり、かなり古い日付です。　この状況から、Nginxの終了処理が完了しないうちにOS再起動されてしまい、nginx.pidファイルが残留してしまったことが原因で、Nginxが起動できなくなってしまったと推測されます。
　ということで、 nginx.pidファイル を削除して、再起動します。

おや、再起動しない。ログメッセージはちょっと変わりました。

[error] 17420#13516: CreateFile() “XXXX/logs/nginx.pid” failed (2: The system cannot find the file specified)

おっといけません、” nginx.pidファイル を削除して ”いたつもりでしたが、 nginx.pid を開いたエディタを別名で保存した状態で開きっぱなしでした。 nginx.pid ファイルは存在しないけど、このエディタプロセスが nginx.pid のファイルディスクリプタをつかんでいる状態になっていました。　
　エディタも閉じて、Nginxを再起動して、無事に復旧しました。

ログメッセージをインターネット上で検索してみると、問題対処のためインストールしなおししている人がいました。復旧させるにはその方法もありますが、原因を特定しないと再発防止策の検討もできませんし、復旧に余計な時間がかかるかもしれません。そんなときはサービス停止の影響を最小化しつつ、慌てず原因調査しましょう。

WordPress脆弱性　、対処するも白画面そして解決　

WordPress脆弱性はプラグインでの新たな情報が出ていますが、本体とこのサイトで使用しているプラグインについての新たな情報はありませんでした。代わりといっては何ですがWordPress5.2.1の修正内容をチェックしました。重要な修正の内容は5.2で作りこまれたバグの修正でしたが、他の修正内容も確認しました。

5件は作りこみバージョンの情報がないもので、6件はWordPress5.1.1以前が作りこみバージョンのもの、それ以外はWordPress5.2で作りこまれたものです。作りこみバージョンがWordPress5.1.1とされた修正で、”jQuery Update 3.4.0”のアップデートがありました。これはWordPressで作りこんだバグではありませんが、jQueryでは”vulnerbility”とされているので、WordPressもこの脆弱性の影響があると判断したほうが良いでしょう。これは、 jQuery 3.4.0で対処された CVE-2019-11358 のことでしょう。ということでWordPress5.1.1も、 jQuery におけるクロスサイトスクリプティングの脆弱性の影響を受けるということなので、コメントを介して攻撃を受ける可能性があると判断し、WordPress5.2.1に更新します。

WordPress5.1.1から5.2.1にアップデートしましたが、 困ったことに 更新処理の途中で失敗し白画面となってしまいました。管理画面も白画面となり対処不能となったので仕方なくバックアップから書き戻していったん復旧しました。 類似の事象がないかチェックしましたがほぼ同じパターンのアップデートが成功していそうな情報がありました。違う条件はPHPのバージョンでした。そこで、PHP5.6をPHP7.2に上げて再度確認しましたが、アップグレード途中で失敗し白画面（500エラー）になる問題が再発しました。5.2.2で対処されることを期待して5.2.2を待とうかと思いましたが、うまくアップロードができている事例があるので、ログとかを見て調査することにしました。

まず、画面内容を再確認。

wordpress-5.2.1.zip から更新をダウンロード中…
更新を展開しています…
展開したファイルをチェックしています…
最新版をインストールする準備をしています…
メンテナンスモードを有効にします…
必要なファイルをコピーしています…
メンテナンスモードを無効にします…
更新が必要な翻訳が一部あります。更新が終わるまでしばらくお持ちください。WordPress (ja) の翻訳を更新しています…
翻訳が正常に更新されました。
ファイルをコピーできませんでした。: wp-admin/site-health.php
インストール失敗
WordPress のご利用ありがとうございます。 バージョン 5.1.1

インストール前の状態で、” site-health.php ”のファイルは存在しないので、ファイルを書き込み出来ていないのが原因でしょう。 wp-admin/ のフォルダの書き込み権限がないのでそれが原因でしょう。セキュリティ強化としてこのフォルダの書き込み権限を落としていました。書き込み権限を付加して、再度WordPress5.2.1へのアップグレードを行うことでアップグレードに成功しました。　アップグレード後は ” site-health.php ”などのファイル が作成されていました。書き込み権限を落として作業完了しました。

WordPress5.2.2については次回チェックします。5.1からのバグの修正があります。現時点では優先度はいずれもNormalなので近く公開されようとしている理由となっている修正はこの一覧にはないのかもしれません。

WordPress脆弱性 CVE-2017-6514

5/22に CVE-2017-6514の情報が公開されています。2年ほど間に登録されておりWordPress4.7.2に脆弱性があるとされています。JVNのほうにはまだ情報がないようです。 最新のWordPressでもまだ修正されていないのではないでしょうか？感触では、5.2.2で修正されそうな気がします。現時点のWordPress5.2.1.と5.2.2の修正内容には該当するものはなさそうです。これから5.2.2向けにコミットされるじゃないでしょうか？

バージョンアップ情報、脆弱性情報の自動チェックを正式運用開始

先に書いた「Webページの更新内容自体が、動的更新によるものかどうかを自動チェックして、通知するかどうかを切り分けるように強化」の完了し、うまく機能することが確認できたので、正式に運用を開始しました。また、「日本語でのメール送信」機能も組み込んだので見やすく、作業効率が改善しました。今後、新たなソフトウェアのチェックが必要になったときにチェックルールをメンテナンスしていきます。

WordPress5.2.1リリース、5.2.2も近いうちにリリース

脆弱性の情報は公開されていませんが、重大な修正が行われていると思われます。WordPress5.2にバージョンアップ済みの場合はすぐに5.2.1にアップグレードしたほうが良いでしょう。 立て続けにリリースしようとしているということは、5.2.2のリリースを待っている場合ではないと思います。 5.2より前のバージョンに影響があるとは書かれていないので、とりあえず静観します。

仮に、これらの修正に脆弱性の修正が含まれているなら、その脆弱性情報の公開は5.2.2のリリースの後になると推測しています。

移行先、　次期クラウド環境選定

　事実関係の確認ができおりませんが、利用しているクラウドサービスがサービス終了するという情報が出てきております。仮にサービス終了となると以降に数か月単位の準備と移行作業が発生するため事前に検討しておきます。一番良いのは、このクラウドサービスのサービス内容やレベルが向上することです。

　まず、この利用している機能・必要な機能・欲しい機能を整理します。

■現在利用していて、今後も必須の機能

  • 全般： 独自ドメイン　24年ほど継続して利用している独自ドメインを継続して使用したい。 容量：できるだけ多く、高速なものが良い。現状はバックアップ領域も含めて 150GB 利用可能です。
  • メール：メールアカウントの管理 →独自ドメインのメールアドレスを引き続き利用したい。 アドレス数の制限なく利用したい。
  • Web： Apacheサーバ
  • 言語：PHP5、Python2.6、シェル
  • DB：MySQL5
  • 定期実行：CRONでの定期実行、日次、定時実行。

■欲しい機能

・Python3

以上の機能について、各クラウドサービスを調査比較します。そして、「クラウドサーバサービスの比較」として、固定ページにて公開していきます。

Pythonで日本語メール送信

定期実行タスクの機能を使ってメール送信していましたが、content-typeを次のようにcharsetを指定したいのに、

Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US

つぎのように指定されています。
Content-Type: text/plain; charset=ANSI_X3.4-1968

このcharset指定のメールでは、日本語の文面が文字化けしてしまいます。受信したメーラーで明示的に文字コードを指定することで文字化けは解消しますが、いちいち指定する手間が大変です。そこで定期実行タスクのメール送信機能は使わずに、Pythonから直接送信するように変更します。

Python2.6で使用するので、 Uchida さんのコードを参考にさせていただきました。

参考のための補足情報：

・デバック方法
smtp = smtplib.SMTP(c[‘host’], c[‘port’])
の次の行に 「 smtp.set_debuglevel(True) 」を追加することで、メールサーバとの通信内容を確認できます。

・ユーザー名、パスワードの指定にはダブルクオーテーションでくくるのはNGです。ダブルクオーテーションもユーザー名、パスワードとして送信されます。

user = <アカウント名>
password = <パスワード>

このPython実装でのメールでは、charsetは次のように設定されます。

Content-Type: text/plain; charset="iso-2022-jp"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

以上の設定により 、メールの日本語文面を文字化けせずに参照することができます。 これをベースに、脆弱性情報の通知メールに送信機能を組み込みます。

脆弱性情報の通知メールの仕掛けの更新

結構、動的に更新されるのか、頻繁に脆弱性ページが更新されています。
このため、先に作成した（5/9）、バージョンアップ情報や脆弱性対処を含むパッチの提供情報の通知メールが2,3日おきに飛んできます。WordPress5.3の作業も始まって、この更新分もあります。デイリーなのか更新頻度がどの程度なのかで、チェック方法を検討しなおします。
とりあえずメール文面を強化して簡単に更新内容をチェックできるようにしました。
今後、Webページの更新内容自体が、動的更新によるものかどうかを自動チェックして、通知するかどうかを切り分けるように強化します。※

次期クラウドサーバーの選定準備

　Pythonコードをクラウドサーバー上への移行で、本来不要であってほしい手間が発生しています。これも関連して、別のクラウド環境への移行を検討します。この検討状況を公開する固定ページを作成していく予定です。
　上述の”本来、不要であってほしい手間”とは環境移行の手間です。この環境はPythonのバージョンが古く、Python 2.6は使えるが、Python3が使えません。このため、ローカルで実装しているPythonコードを移行するとエラーが発生することがあります。原因はPythonのバージョンの際のほかライブラリがないなどの環境の差です。OSが異なることが原因もこともあります。
今後の移行時の参考のために、この移行時に発生したエラーと、その原因、対処をまとめたページを作成しました。

概略は次の通りです。
・Pythonのバージョンが古くPython3が使えないため、requestなどのコードをPython2.6用に書き換える必要がある。
・BeautifulSoupがない？など、 使いたいライブラリがないので、どうするか対処が必要。