サイト移行作業の状況について


先週(2019年9月18日)から始めたサイト移行作業ですが、移行先サービスでの動作検証を行い、移行先サービスでの事前動作検証が完了しました。これにより、移行先をXSERVERに確定しました。試用での検証を終了しましたので、これからフル機能での動作検証を進めます。まずは、新規ドメインでのWeb動作の検証と、メール機能の検証を行う予定にしています。
 その後、既存サーバの情報の最新状態を移行先に転送して、いったん更新作業を保留します。この状態で、ドメインを新サーバに移行します。ちなみにMIC-NETのサーバのドメイン引っ越しはこれで6回目です。引っ越し期間中サービス停止を最小化するようにしますが、コンテンツ類が巻き戻って見えるなどの不具合があるかもしれません。ドメイン切替えに時に「ドメイン切替え宣言」、移行完了後に「移行完了宣言」を出しますので、移行完了後に不具合が継続していた場合はコメントをお願います。

以下は、移行に関する状況と今後の概略スケジュールです。

・基本機能確認
– メール、設定 未; 暫定9/28完了予定、 正式 10/15完了予定
– Web 設定 9/23実施済み 正式 10/10完了予定

・WordPressコンテンツの移行
   仮 9/22実施済み 正式 10/10完了予定
・DBデータ移行
   仮 9/22実施済み 正式 10/10完了予定

キャベツを収穫した後、もう一度キャベツができる?

キャベツを収穫した後の切り株から脇芽が育ってきました。

下の写真は 7/16に収穫した切り株から育った芽です。8/3撮影

8月から9月の暑い時期はキャベツの成長はほぼ止まった状態でした。 育ったわき目は、結局どうなったかというと、まだ成長していると思われますが、とりあえず1個収穫してみました。400gほどで小さいですが、ちゃんと結球していました。切り株ではなく普通に植えたキャベツもこの時期はあまり成長しない感じです

「 収穫後のキャベツの根は畑に置かずに片付けましょう。 」とか書いているサイトもありますが、なぜそうなのか理由を書いていません。種苗会社だから当然の記述かも知れませんが、納得できる理由がなければ試してみましょう。
「 結球し始めると耐寒性は多少弱くなります。秋まきでは、ある大きさ以上の株が一定期間低温にあうと花芽ができ、春になるとトウ立ちする 」と書かれています。この条件であれば、5月くらいに定植したものは冬を越えるまで何度でも収穫できそうな感じがします。

マロ さんのサイトの記述では越冬後に切り株でも少しは” セカンドキャベツ”を収穫できているそうです。
 なにかをうまく制御すれば、繰り返し収穫できないものだろうか。

ネットワーク障害発生、色々調べたが原因特定できないまま解消。

昨日、原因不明のネットワーク障害が発生し原因調査と対処をしていましたが、原因不明のまま解消しています。NTT側の障害の可能性もありリアルタイム障害情報などを確認し、「障害があるかも」の情報があり注視しながら進めていましたが実質的に何もしないまま解消しています。以下状況と対処内容、今後の障害に対するメモです。

1. 2019/9/19 15:00ころネットワークが使えなくなる障害が発生。
復旧のため、PC再起動、ルータの再起動を行ったが復旧せず。
 状況を確認したところ、LAN内で同一セグメントの別マシンにPingも通らない。
 → 自マシンのIPが想定外のアドレスに変わっている。→ DHCPが機能していないとおもわれた。
2. 自マシンを固定IPに変更した。
 → これでもLAN内で同一セグメントの別マシンにPingも通らない。ルータにもPingが通らない。
#なんか変だ、発想を変えて、使えるものを確認してみる。
3. 別のWiFi回線を使ってインターネット上の情報を見てみる。特に情報がないためNTTの回線の問題ではないかもしれない。事象発生から10分くらいしかたっていないのでまだ情報が出ていないだけかもしれない。携帯電話から光電話に電話をかけてみると問題なく電話がかかってきた。
#ますますオカシイ、外部回線の問題ではなさそうなので自前で対処するしかなさそうだ。
4. よくあるインターネット接続できない場合のPCやルータの再起動では回復しなかった。
#これは自分で地道に原因調査して、回復させるしかなさそうだ。
5. まず最小限の範囲から回復させていくことにする。
 自マシンと同一セグメントの別マシンの通信を復旧させることにした。この隣のマシンにPINGが通らないは異常な事態だ。単純に手元のHUBが故障したのかと仮説を立てて確認をしようとしていたところで、別系統の無線LANで接続している機器から次々とインターネットに接続できない旨のメッセージが報告された。
#おや、これは単一障害ならやはりルータの問題か?と問題原因の仮説を見直すことにした。
6.いったん、電源を切ってみる。
 →これでも、 自マシンと同一セグメントの別マシンの通信ができない。固定IPなのにPingも通らない。
#これは、かなり異常な状態である。使える機器を狭い範囲で確認して順番にひろげていくことにした。
7. 一度、HUBにつながったケーブルをすべて外して、 自マシンと別マシンだけにして、Pingしてみる。問題なくPingが通った。
#当たり前だが久しぶりにようやく動いた。
8. 1本ずつ、ケーブルをつないで動作確認してみる。ある1本のケーブルをつないだところで、そこまで通っていた 自マシンから別マシン へのPingが通らなくなった。ネーブルを外すと、Pingが通るようになる。このケーブルの先に問題がありそうなことが判明した。ただ、このケーブルの先にルータがあり、このケーブルを接続しないと、インターネットには接続できない。
#このパターンの場合、ループしている可能性が一番高い。しかし、その後の調査でもループは見つかっていない。長引きそうだが、インターネットの接続を早く復旧したいので、メインルートから復旧を試みることにする。
9.問題のケーブルの先のHUBに接続されたケーブルをすべて外してルータのみ接続した。→ これによりインターネットへの接続が復旧した。
10. 先に外したケーブルを接続しなおし、動作確認を行った。→ 障害発生前の状態に復旧した。
#結局、障害の原因は不明であり、ケーブルの挿抜だけで復旧したことになる。今度同様の事象が発生したときは、パケットキャプチャも行うことにする。

WordPress セキュリティパッチのみ自動適用するには

 WordPressのセキュリティパッチに関して検討および対処してきましたが、多数のプラグインの利用とWordPressのパッチリリースのスタンスや情報公開の仕方を考慮してパッチリリース状況の監視と適用の手順を見直しました。
 セキュリティパッチのみを適用するということが、WordPressの場合は「セキュリティ修正が含まれているのにメンテナンスパッチ」となっていたり、「プラグインのセキュリティ問題の対処をセキュリティ修正としない」とされていたりする状況からあまり妥当でないとなっていると判断しました。

つまり、ポイントは次の2点です。
・WordPressがいうところのメンテナンスリリースとセキュリティリリースとを区別して別の取り扱いをする意味はあまりない。メンテナンスリリースとされていてもセキュリティの対処が含まれている場合がある。
・ メンテナンスリリースとセキュリティリリースのどちらも適用しないと問題があるかどうかを確認できない場合がある。

以上の状況から、つぎのようにします。

「テスト用サイトを立ち上げておいて、テスト用のサイトについてはパッチを自動適用する設定にしておく、パッチ適用のメールが来たら動作確認を行い、本番環境に適用するかどうかを吟味し適用手順を確立したうえで適用作業を行う。」

具体的なサイト移行作業を始めます


2019年9月18日時点で本サイトはBizMWのサービスを利用していますが、2019年12月27日でBizMWのサービスが終了するため、本サイトを他のホスティングサービスへの移行作業を行います。移行先については事前調査済みですが、再度、最新の状況を調査して移行作業を行います。
 移行先に関しておすすめなどの情報があればコメントをください。

次の観点で試行確認を行い、移行を進めていきす。

・基本機能確認
– メール、設定
– Web 設定

・WordPressコンテンツの移行
・DBデータ移行

移行先の検討その後


以前に、書いた移行先の検討ですが、 ”代替サービスの案内を郵送” はまだですがメールとWebでの案内がありました。その情報を先に公開した移行先の情報に反映しました。この結果から移行先の検討絞り込みをし、移行に向けて試行検討を開始します。


1)代替サービスについての資料の受領。 2019/8/下旬→ 9/10メール受領、郵送分は9/17時点で未受領。

2) 移行スケジュールの確定。 2019/8/25→暫定で以前のスケジュールで作業中。
3) これ以降のスケジュールは、代替サービスの案内書類の受領時期により見直しする。
3-1) 書類レベル調査完了 2019/8/30→ほぼ済だが郵送待ち(9/17時点)
   ここまでに代替サービス案内を入手済みと仮定。未入手ならスケジュール見直し
3-2) 移行先候補 最大3つまでに絞り込み 8/31
3-3) 実地調査 9/1-9/15 実サイトを仮運用して調査
3-4) 移行先確定 9/16
3-5) 申し込み環境構築 9/17-9/20
3-6) バックアップ・復旧、定期実行パッチ等の運用操作の動作検証 9/20-9/30
3-7) 現行サイトからのサイトデータの仮移行 10/1-3
3-8)移行後の環境の動作検証 10/3-10
3-9) 移行後環境の操作手順等手順書類更新作成 10/11-10/15
3-10) ドメイン切り替え依頼 10/16
3-11) 現行サイトからのサイトデータの移行(仮本番) 10/17-20
3-12) プロバイダによるドメイン切替作業&反映 10/16-10/30
3-13) 新クラウドサーバでのドメイン運用開始 11/1
3-14) 新クラウドサーバでのmic.or.jpドメイン運用検証 11/1-15
3-15) 現行サイトからのサイトデータの移行(本番) 11/1-2
3-16) 検証期間予備 11/16-11/30
3-17) ドメイン移行期間予備 12/1-12/27
  

スケジュールの項番3以降は、前回公開したスケジュールと同じです。

なお、移行先等は移行先検討のページに記載しています。

WordPress 5.2.3 セキュリティパッチの適用

2019年9月5日にリリースされたセキュリティ&メンテナンスパッチWordPress5.2.3について書きます。 wp-config-sample.phpが更新されていましたが、動作に影響がある変更はなく実質的には気にする必要はありませんでした。5.2.1のように白画面になることもありませんでした。
 しかし、” Page Visit Counter ”がエラー(具体的に何のエラーなのか情報がない)で止まっていました。この停止問題はプラグインを設定ページで有効化することで解決しています。

WordPress 5.2.3 で対処された脆弱性について確認します。 WordPressのサイトの情報では1件ごとに明確にされるべき影響度とか影響範囲の情報がなく、問題検出者への感謝?の公開の場でしかありません。何とかしてほしいが、他のサイトで確認してみましょう。 9/12時点でJVNのほうにはまだ登録されていないように見えます。NVDの情報では、つぎの7件がWordPress5.2.3で対処されたことが分かります。

CVE-2019-16223WordPress before 5.2.3 allows XSS in post previews by authenticated users.
CVE-2019-16222WordPress before 5.2.3 has an issue with URL sanitization in wp_kses_bad_protocol_once in wp-includes/kses.php that can lead to cross-site scripting (XSS) attacks.
CVE-2019-16221WordPress before 5.2.3 allows reflected XSS in the dashboard.
CVE-2019-16220In WordPress before 5.2.3, validation and sanitization of a URL in wp_validate_redirect in wp-includes/pluggable.php could lead to an open redirect.
CVE-2019-16219WordPress before 5.2.3 allows XSS in shortcode previews.
CVE-2019-16218WordPress before 5.2.3 allows XSS in stored comments.
CVE-2019-16217WordPress before 5.2.3 allows XSS in media uploads because wp_ajax_upload_attachment is mishandled.

9/11にDBに登録されたばかりで影響範囲など詳しい情報はまだありませんでした。

想像ですが、9/12時点で過去バージョンに対してセキュリティ修正のみ(WordPress5.1.2?)を提供しようと準備しているように見えます。5.2.3のリリースには「In addition to the above changes, we are also updating jQuery on older versions of WordPress. This change was added in 5.2.1 and is now being brought to older versions. 」の記述があります。しかし明示的には5.1.2について特にアナウンスしているようには見えないので、本当にリリースされるかはわかりません。どうしても欲しければチームに入って推進すればよいかもしれません。

Linuxホットスポット検証のため USB WiFiデバイスをいくつか動作検証してみました

・ホットスポットの動作確認した環境はつぎのとおりです。これはLinuxで最初に動作確認できたLenovoのノートPC G570での操作をベースにしたGUI操作のみのチェック手順です。
HW:
・ Intel(R)   USB 3.1
・USB2.0
OS:
・ Windows10 バージョン 1903 OSビルド 18362.295
・ Linux Ubuntu 19.04

以下にそれぞれの仕様と各OSでの動作状況をまとめました。動作確認はインストール
[表中の記号の意味]
〇:上記OS で ドライバ等の追加インストールなしで利用可能
×: 上記OS で ドライバ等の追加インストールなしで利用不可
△: 上記OS で ドライバ等の追加インストールで利用可能。ドライバ無は×
▼: 上記OS で ドライバ等の追加インストールしても利用不可。 ドライバ無は×

型番TL-WN725NWDC-433DU2HBK802.IINPT-N330multibyte
写真写真
メーカTP-LINKELECOM Cangad Saikogoods
pinTOP
参考AmazonAmazonAmazonAmazonAmazon 写真と違う
金額700円
(送料630円)
2,389 円
(送料 0)
299円
(送料300円)*6
480円
(送料0)
¥398
(送料0)*6
インターフェイスUSB2.0USB2.0USB2.0USB2.0
周波数2.4GHz2.4GHz
5.2,5.3,5.6GHz
2.4GHz2.4GHz2.4GHz
伝送方式11b/g/n11ac,11a,
11b/g/n
11b/g/n11n? 11b/g/n
送信出力10mW/MHz以下
Win10 子機 〇 *7× *3
Win10 HotSpot〇*b〇*b 〇 *7*b× 〇 *b
Ubuntu 子機△ *2
Ubuntu HotSpot× *1▼ *2 *5〇*bx *4〇*b
Ubuntu hostapd×? *8×? *8
Ubuntu
使用ドライバ(チップ)
RTL8188euRTL8812au(RTL8188CU) Ralink MT7601U(RTL8188CU)

*1:HotSpot起動時にエラーが発生し、正常にHotSpotを起動できない。
*2: USBデバイスとは認識するが、WiFi機器と認識しない。(メーカサイトではLinux未対応) ドライバをmake インストールすることで認識
*3: mini-CDつき、インストールすれば使えるかもしれないが、保留。
*4: WiFiのHotSpotのメニューがグレーアウトされている。
*5:HotSpot起動操作で WARNログ( device (デバイス名): Activation: (wifi) Ad-Hoc network creation took too long, failing activation)を出して、起動に失敗する。
*6:配送に非常に時間(2、3週間)がかかった。発送元は台湾。
*7: mini-CDつきだが、使用しなくてもWin10で動作した。
*8:ドライバが未対応?

参考:以下はUSBモジュールではありませんが、参考のため動作確認した結果です。

型番G570
写真
メーカLenovo
周波数2.4GHz
伝送方式11b/g/n
送信出力? (比較的弱い)
Win10 子機
Win10 HotSpot〇 ※b
Ubuntu 子機
Ubuntu HotSpot〇 ※a
Ubuntu hostapd〇 ※b
Ubuntu
使用ドライバ
AR9285

※a:Ad-Hocモードで動作する。
※b:Infraモードで動作する。

トマトを大量消費するメニューはなにがよい?

相変わらずトマトだけは大量に実っています。ピークは過ぎたものの毎日ミニトマトは2パック分、大玉トマトは2個くらいのペースで収穫できています。

そして食べきれずに数日分が貯まることもしばしばあります。そのような大量のトマトを消費するおいしいメニューランキングをかきます。 

第三位:
トマトのあさづけ:
 キュウリと一緒にあさづけしています。


第二位:
トマトライス
 よくオムライスの中にはいっているチキンライスに近いのですが、さきにトマトをトマトピューレにしておいて、炊き込みます。

第一位:
スパゲッティミートソース
 出来合いのソースを使わない場合はホールトマト缶を使うことが多いともいます。その缶詰の代わりに追熟して十分に熟れたトマトを使います。トマトが少ないと水っぽいソースになりがちですが、多量のトマトを使って十分に煮詰めるとうまみの濃いソースに仕上がります。

これ以上におすすめのメニューがあればコメントください

アプリに関係なく(ラなんとかも、なんとかgoにも)使える位置偽装

ここまでに書いた内容を読み返せばどのような手法で位置偽装するのかITエンジニアには理解できるでしょう。実現のためにはいくつかの条件はあるが、比較的簡単に実現することができた。
 要するに「 会社引っ越し後、WIFIで位置情報を検索すると前の住所が表示されます。 」や「 GoogleChrome・マップの位置情報 」などで起きているWiFiの情報に基づく位置情報の誤認識を利用するということです。これは意図せずおきれば誤認識なのですが、誤認識を誘発し一定の制御のもとにおけば、それは位置偽装といえるでしょう。この位置偽装の特徴はモバイル機器に追加アプリをインストールする必要がないことと、アプリに関係なく利用できることです。追加検証と有効性については別の場所で行うことにします。

 ここで扱う位置情報は本来の目的ではない情報を別の個人情報として扱うべき情報を組み合わせて実現した便利な機能により得られた情報です。情報提供者にほぼ無断で別の目的で利用していると言ってしまってもよいかもしれません。それはさておき、上の方法での位置偽装はいわゆる偽装アプリをインストールするわけではないので、偽装を検出することは困難というか、ほぼガードすることはできないでしょう。なんとかgo++のように利用できなくなったり復活したりというイタチごっこは発生しません。 さらにアプリに関係なく利用できるのも特徴です。