WordPress5.3が11/12にリリースされたので、別に構築したWordPress検証サイトで動作確認しています。
WordPress5.3へコンテンツの更新を行った後に、DBの更新が行われる。DB構成が更新されていそうです。どこが更新されたのかは、ぱっと見ではわかりません。
→ 更新でトラブルが発生した場合、書き戻しするにはDBの書き戻しも必要となる。更新＆検証の際には、切り戻し時間にDB書き戻し時間も考慮しておく必要がある。当然だが、更新直前にDBデータのバックアップを行う時間も考慮しておく必要がある。
エディタ機能が強化された。 メニューに「ブロックのグループ化 」が追加されています。
全体的にはあまり大きな強化や変更はない。急いで更新したいというものはない。また、更新に関して、問題も特に問題はなかった。そのため、とりあえず5.3の適用は保留し、今後提供されると推測されるセキュリティパッチがで提供されたタイミングで更新することにする。
首里城火災で「防犯カメラの電源が、火災検知センサーの反応する直前に落ちていた、電気系統に漏電やショートなどの不具合が起きた可能性もある」ということらしい。
「 電気系統に漏電やショートなどの不具合 」などで火災が起きないようにいくつもの法律や基準が作られている。このような状況で一番ありそうな話は、法令や基準に従わず配線などを行っていたというところでしょう。その問題原因を徹底的に調査していることでしょう。その問題を作った人や企業は責任を追及されることが想像されます。特に今回のようなケースでは法律や基準を知らかかったからなんてことは許さないでしょう。その場合でも根本原因の分析は必要でしょう。そしてその要因として法令や基準が複雑であることがあるかもしれません。そうであるなら何らかの方法で容易に基準を満たしているかどうかのチェックを行えるようにする仕組みや基準の見直しが必要かもしれません。
別のパターンとして、法律や基準を満たしていたにもかかわらず火災に至ったケースが考えられます。 使用される機材等の変化から 現状の 法律や基準をではカバーできていないのかも知れません。この場合はだれの責任かはともかくとして、法令や基準の見直しは必要でしょう。そのうえで、そのような状況を引き起こしてしまった機器などに関して、何らかの法令違反がなかったか責任が追及されることになるでしょう。
あまりなさそうなのは、人為的に防犯カメラの電源が落とされたパターンですが、事故というより事件です。もしもそうなら、 防犯カメラの電源が落とされるまえまでに記録された情報から犯人を特定できるようにするべきで、今の時点でそのような情報がないということはそのような記録がないのでしょう。この場合、記録できていないか、そのような事実はないのかのどちらかですが、記録できていないのだとすると記録できるようにするための基準か何かが必要でしょう。
5.2.4セキュリティパッチが適用されてました。動作的には問題ないようなので、パッチ検証環境以外にも適用します。
このほかに、5.3 Release Candidate が出ています。特にほしい機能があるわけではないので、取り換えず様子見です。
そして、以前に旧版へセキュリティパッチの話を書きましたが、5.1.3が同時にリリースされていました。パッチリリースのところには情報公開されないのですね。ちょっと不親切な感じがします。
サーバが切り替わったので、古いサーバ宛のメールはほとんど来なくなりましたが、今日もまだ古いサーバに１件メールが来ていたので確認してみました。
”Security Notice. ……”というタイトルのspamメールでした。
送信ツールから、直接古いメースサーバ宛に送信されていました。普通のメールクライアントからの送信なら、送信用メールサーバーを経由するので、２段階以上の送受信となるはずですが、つぎのように、１段階だけでした。
この部分をチェックするだけでも、何らかのツールを使って送信していることが分かります。
メールのソース ：省略 X-Mozilla-Keys: Return-Path: <ｘｘｘ@mic.or.jp> Received: from tm.82.192.61.119.dc.telemach.net (tm.82.192.61.119.dc.telemach.net [82.192.61.119]) by mic.or.jp (Postfix) with ESMTP id 7070911002A03 for <ｘｘｘｘ@mic.or.jp>; Wed, 9 Oct 2019 10:25:50 +0900 (JST) From: ｘｘｘｘ@mic.or.jp> To: <ｘｘｘｘ@mic.or.jp> Subject: ：省略
そして、DNSを切り替えて、１週間程度経過しているにも関わらず、古いサーバ宛に送信されています。 どこかにキャッシュされていたDNS情報を取得して古いサーバ宛に送信されたことが考えられます。しかし、今回のケースだと、１週間以上前にもメール送信した実績があり、その時に取得したDNS情報をキャッシュしていて、昨日メール送信する際にその情報を使ってメール送信したと考えるのが妥当でしょう。 メールマガジンの配信など大量メール送信ツールにはDNS情報のようにキャッシュできるものはキャッシュして性能を稼ぐ実装を採用しているものもあります。そのような技術をspam送信に利用しているのでしょう。
10/2にDNS切り替えて サイト移行が完了していますが、残問題の対処を行いました。
・「tv.xmlが生成できず番組情報が未提供」
→元データ自体が提供さてない状態のため、ダミーのtv.xmlを配置し、404エラーを回避済み。
・「WordPress内でリンク切れが検出されている」
→問題ページを確認し、修正。リンク切れが解消したことを確認済み。
・「外部サイトに古いリンクが残っていることが原因で発生している思われる404エラー」
→移行元のサイト上で動作しているコンテンツから参照されている可能性があるため、移行元のサイトのコンテンツを削除した。調査に必要なものはパスを変更するなどしてアクセスできないように対処した。また、問題のURLにアクセスしてくるのがクローラーであるため、リンク元のURLがリファラーで確認することができない。クローラー自体が古いサイトのコンテンツをキャッシュしていることも考えられるので、クローラー自体から問題URLにアクセスしないようにrobots.txtにクローラーがアクセスしないように設定を追加した。
これにより、通常のブラウザでアクセスして404エラーが出た場合は、リファラーからリンク元のページが分かるはずです。
先週（2019年9月18日）から始めたサイト移行作業ですが、10/2 22:15ころDNS切り替え作業を完了しました。 いちおう、「移行完了宣言」 です。
アクセス制限個所はすべて解除しています。
切り替え確認において、合計６件の問題を検出しました。今回の移行が原因のもの3件、既存の問題1件、追加調査が必要だが既存の問題と思われるもの2件です。リンチチェックツールを使用したことと、xserverでは、アクセスログとエラーログが参照可能であること、sshが利用可能でしたので、効率的に問題調査ができました。
今回の移行が原因のものの内訳は次の通りでした。
・使用中の画像ファイルを不要ファイルに振り分けていたため、画像ファイルを移行しておらず、404エラーとなっていた。
・cron設定が未移行のため、必要なファイルが更新されていなかったため、表示される情報が古い情報のままであった。。
・１つのメールアドレスの転送設定で、1byte文字で入力するべきところを1文字だけ２byte文字であった。このためメールが転送されず、消失する状態になっていた。
既存の問題は、定期実行処理を実装していないためtv.xmlが生成できず番組情報が未提供あることと、など一部ファイルがないものです。
追加調査が必要なものはWordPress内でリンク切れが検出されていることと、外部サイトに古いリンクが残っていることが原因で発生している思われる404エラーの２つです。
ほかに継続的に不具合が発生している場合はコメントをお願います。
以下は、移行に関する状況と今後のスケジュールです。
２週間ほど、様子見した後、移行前の環境の情報が不要と判断で来たら、旧サーバの解約を行います。
先週（2019年9月18日）から始めたサイト移行作業ですが、10/2 22:15ころDNS切り替え作業を行いました。順次新サーバIPに切り替わっている状況です。
トップURLなどをアクセス制限をしています。確認完了したところからアクセス制限解除していきます。また、切り替え時に一部アクセスできないところがありました。問題個所は随時修正を行います。
移行完了後の「移行完了宣言」はまだ出せる状況ではありません。最長1週間くらいを予定しています。移行完了後に不具合が継続していた場合はコメントをお願います。
以下は、移行に関する状況と今後のスケジュールです。
・基本機能確認
– メール、設定 9/25一部実施済み； 暫定9/28完了、 正式 10/15完了予定
– Web 設定 9/25一部本番実施済み 正式 10/10完了予定
・WordPressコンテンツの移行
仮 9/22実施済み 正式 10/10完了予定
・DBデータ移行
仮 9/22実施済み 正式 10/10完了予定
・WordPress以外のWeb,DBは9/25移行実施済み。
・DNS設定切り替え、10/2 22:15実施。
先週（2019年9月18日）から始めたサイト移行作業ですが、移行先サービスでの動作検証および暫定移行作業および移行前の事前確認が完了しました。
これから（9/27から）、DNSの切り替え作業を開始します。つまり 「ドメイン切替え宣言」 です。外部に依頼するため切り替え完了までに１週間程度はかかると思われます。この期間は、更新作業を保留します。切り替え期間中もコメントの入力は可能ですが切り戻し等でクリアされることがあります。メールでの問い合わせも可能ですので比較的重要な連絡はメールを利用してください。ただしメールも同様に切り替わりますので、一時的に保留等が発生することがあります。移行完了後に「移行完了宣言」を出しますので、移行完了後に不具合が継続していた場合はコメントをお願います。
以下は、移行に関する状況と今後のスケジュールです。
・基本機能確認
– メール、設定 9/25一部実施済み； 暫定9/28完了予定、 正式 10/15完了予定
– Web 設定 9/25一部本番実施済み 正式 10/10完了予定
・WordPressコンテンツの移行
仮 9/22実施済み 正式 10/10完了予定
・DBデータ移行
仮 9/22実施済み 正式 10/10完了予定
・WordPress以外のWeb,DBは9/25移行実施済み。
2019年9月23日にWordPress5.3Beta1がリリースされていますが、旧版へのセキュリティパッチの情報は特にありません。WordPressは新版をリリースするときは１か月くらいかけて毎週のように更新版を出してきます。開発のほうに力を入れていて、セキュリティへの対処へ使うパワーがあまりない感じがします。
セキュリティ対処は外部の人の力に頼っていて、自己対処ができていないのではないかと思われます。このような状態では、新規開発部分に作りこまれる脆弱性は減らず、脆弱性がどんどん増えていく状態になるのではないでしょうか？
さて、追加でWordPress 5.2.3 で対処された脆弱性について確認します。 影響度と影響範囲の情報について追加情報が出ていますが、あまり詳しくありません。 CVE-2019-16220 （JVNDB-2019-009141）の場合、影響バージョンは WordPress 5.2.3 未満 となっています。該当機能が、初期バージョンから存在するのか疑問ですが、該当機能はかなり以前からあるので事実上すべてのバージョンに影響があるといってもよいのかもしれません。それから9/12の午後以降にJVNの情報公開がされていました。今後のセキュリティパッチはWordPress5.3に対して提供されることになると思われるので、どのタイミングでWordPress5.3に上げるのか、検証計画を立てておくなど検討しておいたほうがよさそうです。
先週（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なので、あまり苦労せずに移行できます。１点、XSERVERのデータベース名はサフィックスがサーバ名？に固定されているために移行前と同じデータベース名にはできず、エクスポートファイルのままだと「CREATE DATABASE IF NOT EXISTS ＜データベース名＞ DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;」とエラーが出ます。
SQLのファイルのデータベース名が書かれた個所を修正してインポートします。
データベースをCREATEしているなら、その個所を削除する
また、BizMWではローカルマシン上にDBがありましたが、XSERVERは別マシンなので、接続先の設定変更も行います。
■メール関連
BizMWではエイリアス設定がありましたが、XSERVERではエイリアスがなく、メールアカウントを作って転送設定をすることで代替は可能です。振り分け設定で転送が可能だが、これもメールアカウントを作っておかないと宛先不明でメールが消失する（送信元にも返されない）ケースがありそうです。
とりあえず、ここまでで一旦公開します。 引っかかった点などあれば随時更新します。
・基本機能確認
– メール、設定 基本検証は済； 暫定9/28完了予定、 正式 10/15完了予定
– Web 設定 9/23実施済み 正式 10/10完了予定
・WordPressコンテンツの移行
仮 9/22実施済み 正式 10/10完了予定
・DBデータ移行
仮 9/22実施済み 正式 10/10完了予定
