webセキュリティパッチでないのに短期間でWordPress5.3.2がリリース。5.2系のパッチは?WordPress5.3.2が12/18にリリースされた。5.2.6はリリースされているかは自動適用されていないので不明。5.3.2での修正内容からは5.3.1で作りこまれた致命的なバグとわかります。これが短期間でのリリースの理由でしょう。1件のバグ(#48145)は煮え切らない解析の結果、5.3での修正(#45821)の影響で発生していると判断して、修正を行っている。意外にPHP側に問題があり、その問題回避をしているのかもしれない。いずれにしても、5.3.2は5.3以降に発生した問題の修正なので、これらの対処のために5.2.6がリリースされることはなさそう。分かりにくいが5.2.5が登録されていた。そのほか5.3.2リリースでは、5.3系のアップデートはこれで終わりで次は5.4とされている。5.3系へのアップデートは様子見とします。5.3.1に上がってしまっている環境については、5.3.2にアップデートすることとします。■それより、プラグインのパッチは?プラグインについては、当てられるものはパッチ適用する。wordpress5.3.2セキュリティパッチでないのに短期間でWordPress5.3.2がリリース。セキュリティパッチが出たけど、5.2.5が適用された。セキュリティパッチが12/13にリリースされた。同時に、5.2.5もリリースされたようだ。5.2.5についてはセキュリティパッチのページには掲載されていない。5.2.5が適用されたことは期待値どおりだが、5.2.5のことが情報公開されていない点がいまいちだ。修正内容の管理も5.3.1は情報があるが、5.2.5の情報がない。相変わらず管理が不十分な感じはぬぐえない。■で、パッチ適用はどうする?手動でのパッチ適用は、5.3.1しかできないようだ。これは5.3.に誘導する策略なのかと違ってしまうが、、、。テストサイトで5.3.1の検証を行う。そこで、問題が無ければ、ほかの本番系サイトにも適用していく流れにするしかなさそうだ。セキュリティパッチが出たけど、5.2.5が適用された。コメントWordPress5.3はとりあえず様子見WordPress5.3が11/12にリリースされたので、別に構築したWordPress検証サイトで動作確認しています。■更新する際に留意しておきたい点WordPress5.3へコンテンツの更新を行った後に、DBの更新が行われる。DB構成が更新されていそうです。どこが更新されたのかは、ぱっと見ではわかりません。更新でトラブルが発生した場合、書き戻しするにはDBの書き戻しも必要となる。更新&検証の際には、切り戻し時間にDB書き戻し時間も考慮しておく必要がある。当然だが、更新直前にDBデータのバックアップを行う時間も考慮しておく必要がある。■WordPress5.3での変更点の確認エディタ機能が強化された。」が追加されています。全体的にはあまり大きな強化や変更はない。急いで更新したいというものはない。更新に関して、問題も特に問題はなかった。そのため、とりあえず5.3の適用は保留し、今後提供されると推測されるセキュリティパッチがで提供されたタイミングで更新することにする。wordpress5.3WordPress5.3はとりあえず様子見にコメントWordPress5.2.4セキュリティパッチ5.2.4セキュリティパッチが適用されてました。動作的には問題ないようなので、パッチ検証環境以外にも適用します。ほしい機能があるわけではないので、取り換えず様子見です。以前に旧版へセキュリティパッチの話を書きましたが、5.1.3が同時にリリースされていました。パッチリリースのところには情報公開されないのですね。不親切な感じがします。サイト移行が完了していますが、残問題の対処を行いました。→元データ自体が提供さてない状態のため、ダミーのtv.xmlを配置し、404エラーを回避済み。→問題ページを確認し、修正。リンク切れが解消したことを確認済み。→移行元のサイト上で動作しているコンテンツから参照されている可能性があるため、移行元のサイトのコンテンツを削除した。調査に必要なものはパスを変更するなどしてアクセスできないように対処した。問題のURLにアクセスしてくるのがクローラーであるため、リンク元のURLがリファラーで確認することができない。クローラー自体が古いサイトのコンテンツをキャッシュしていることも考えられるので、クローラー自体から問題URLにアクセスしないようにrobots.txtにクローラーがアクセスしないように設定を追加した。これにより、通常のブラウザでアクセスして404エラーが出た場合は、リファラーからリンク元のページが分かるはずです。22:15ころDNS切り替え作業を完了しました。アクセス制限個所はすべて解除しています。切り替え確認において、合計6件の問題を検出しました。今回の移行が原因のもの3件、既存の問題1件、追加調査が必要だが既存の問題と思われるもの2件です。リンチチェックツールを使用したことと、xserverでは、アクセスログとエラーログが参照可能であること、sshが利用可能でしたので、効率的に問題調査ができました。今回の移行が原因のものの内訳は次の通りでした。・使用中の画像ファイルを不要ファイルに振り分けていたため、画像ファイルを移行しておらず、404エラーとなっていた。・cron設定が未移行のため、必要なファイルが更新されていなかったため、表示される情報が古い情報のままであった。・1つのメールアドレスの転送設定で、1byte文字で入力するべきところを1文字だけ2byte文字であった。このためメールが転送されず、消失する状態になっていた。既存の問題は、定期実行処理を実装していないためtv.xmlが生成できず番組情報が未提供あることと、など一部ファイルがないものです。追加調査が必要なものはWordPress内でリンク切れが検出されていることと、外部サイトに古いリンクが残っていることが原因で発生している思われる404エラーの2つです。ほかに継続的に不具合が発生している場合はコメントをお願います。以下は、移行に関する状況と今後のスケジュールです。2週間ほど、様子見した後、移行前の環境の情報が不要と判断で来たら、旧サーバの解約を行います。クラウドサービスDNS切り替え作業を完了「新サーバでの運用中」にコメントDNS切り替え作業を行いました。22:15ころDNS切り替え作業を行いました。新サーバIPに切り替わっている状況です。トップURLなどをアクセス制限をしています。確認完了したところからアクセス制限解除していきます。切り替え時に一部アクセスできないところがありました。問題個所は随時修正を行います。移行完了後の「移行完了宣言」はまだ出せる状況ではありません。最長1週間くらいを予定しています。移行完了後に不具合が継続していた場合はコメントをお願います。・WordPress以外のWeb,DBは9/25移行実施済み。クラウドサービスDNS切り替え作業を行いました。現在、新サーバでの運用中ですにコメントDNS切り替え作業を開始します先週(2019年9月18日)から始めたサイト移行作業ですが、移行先サービスでの動作検証および暫定移行作業および移行前の事前確認が完了しました。これから(9/27から)、DNSの切り替え作業を開始します。外部に依頼するため切り替え完了までに1週間程度はかかると思われます。この期間は、更新作業を保留します。切り替え期間中もコメントの入力は可能ですが切り戻し等でクリアされることがあります。メールでの問い合わせも可能ですので比較的重要な連絡はメールを利用してください。メールも同様に切り替わりますので、一時的に保留等が発生することがあります。移行完了後に「移行完了宣言」を出しますので、移行完了後に不具合が継続していた場合はコメントをお願います。・WordPress以外のWeb,DBは9/25移行実施済み。旧版へのセキュリティパッチは?2019年9月23日にWordPress5.3Beta1がリリースされていますが、旧版へのセキュリティパッチの情報は特にありません。WordPressは新版をリリースするときは1か月くらいかけて毎週のように更新版を出してきます。開発のほうに力を入れていて、セキュリティへの対処へ使うパワーがあまりない感じがします。セキュリティ対処は外部の人の力に頼っていて、自己対処ができていないのではないかと思われます。対処された脆弱性について確認します。影響度と影響範囲の情報について追加情報が出ていますが、あまり詳しくありません。該当機能が、初期バージョンから存在するのか疑問ですが、該当機能はかなり以前からあるので事実上すべてのバージョンに影響があるといってもよいのかもしれません。それから9/12の午後以降にJVNの情報公開がされていました。今後のセキュリティパッチはWordPress5.3に対して提供されることになると思われるので、どのタイミングでWordPress5.3に上げるのか、検証計画を立てておくなど検討しておいたほうがよさそうです。旧版へのセキュリティパッチは?にコメントサイト移行作業に関連して、BizMWとXSERVERの仕様の違いについて先週(2019年9月18日)から実施中のサイト移行作業に関連して、メモ代わりに、BizMWとXSERVERの仕様の違いに関して書きます。簡潔に書いてしまうと、XSERVERはBizMWよりもシステムエンジニア向けです。BizMWのほうがシステム管理をよく理解している開発者というより上級エンジニアが設計した一般利用者向けのシステムと言えるでしょう。UNIX系の知識があまりないならBizMWからXSERVERに移行すると分かりにくく使いにくく、コストが増加するかもしれません。逆にUNIX系の知識があれば、自由度が高い運用ができ、コスト削減できそうです。以降は、気がついた具体的なポイントを書きます。気が付いた順に書いたので順番は意味がありません■バックアップからの復旧バックアップは復旧方法から設計するというのが、バックアップ・復旧の基本と言われたりしますが、BizMWではWebコンテンツを過去にバックアップした任意のものにコントロールパネルからボタン一つで復旧できていました。初心者向けには分かりやすく、パッチ適用でのトラブルなどの障害からの復旧を短時間におこなうことができ非常によい仕組みです。XSERVERのほうは、利用者向けに提供された復旧の簡便な仕組みがありません。手動バックアップで作成したアーカイブをダウンロードできます、また日次で自動バックアップが動いています。バックアップから復旧させるには、手動でバックアップしたファイルをアップロードするか、費用を支払い、バックアップデータをバックアップディレクトリに置いてもらって、そこから手動で復旧させる必要があります。sshやcronが使えるので、自前で何とかできそうですが、あまり親切な設計ではありません。データベースのバックアップと復旧についてはXSERVERのほうが簡単です。サーバパネルで、手動バックアップの他、自動バックアップからの復元がボタン一つでできるようになっています。どちらが良いかは好みかもしれません。■SSHでの利用XSERVERでは、マルチドメイン運用でも、ドメイン間のファイルコピーをディレクトリ間のコピーで操作できます。sshになれていれば、かなり運用管理しやすい。BizMWではsshできなかったので、かなり楽になります。■データベースの移行XSERVERもMySQLなので、あまり苦労せずに移行できます。utf8_general_ci;」とエラーが出ます。SQLのファイルのデータベース名が書かれた個所を修正してインポートします。データベースをCREATEしているなら、その個所を削除するまた、BizMWではローカルマシン上にDBがありましたが、XSERVERは別マシンなので、接続先の設定変更も行います。■メール関連BizMWではエイリアス設定がありましたが、XSERVERではエイリアスがなく、メールアカウントを作って転送設定をすることで代替は可能です。振り分け設定で転送が可能だが、これもメールアカウントを作っておかないと宛先不明でメールが消失する(送信元にも返されない)ケースがありそうです。ここまでで一旦公開します。