ついに来た。サービス停止の案内。移行先検討を本格的に開始します。

 ようやく明日、梅雨入りとなる見込みで当分水やりの手間ははぶけそうです。

さて、以前に移行先の検討すると書きましたが、ついに2019年12月27日にサービス終了する旨のメールが来ました。後日代替サービスの案内を郵送すると記載されていました。最終的な判断は資料が届いてからにするとして、本格的に情報収集を始めます。
 また、これまでに仮決めしていた移行スケジュールは2019年10月に移行先決定でしたが、現行サービス終了から逆算してスケジュールを決めなおすことにします。※ 現在の運用状況だと、1か月並行運用、1か月切り替え期間、1か月予備期間くらいをとらないと余裕を持った作業ができなさそうです。

トマトの収穫時期について

http://q-and-a.gokigen-yasai.com/?eid=18

このサイトの情報によると、

トマト・ミニトマトは開花から毎日の平均温度を足していった積算温度で赤くなる日にちが決まります。
トマトだと800~1000℃(品種によって違います)
ミニトマトだと750~850℃(品種によって違います)くらいです。
」ということです。
積算温度で800℃と仮定して計算してみます。
5/21以降の平均気温を積算したグラフです。徐々に気温が上がっているので、短くなってきていますが、現在は36日で800℃に達します。

最初に開花を確認した記録は6/1でしたので、計算では7/6もしくは7/5が収穫見込日です。 昨日開花していた分をマークしました。あと2回ほどマークして大玉トマトとミニトマトそれぞれについて積算温度がどの程度で収穫できるのかを検証してみます。

きゅうり収穫

下の写真中央のきゅうりを収穫しました。まわりの葉は白く粉を吹いたようになっています。うどんこ病だとおもわれるのと、となりの1株が枯れてしまったので、農薬を使って対処しました。農薬は使いたくはないのですが、全滅は避けたいので酢系のものを使いました。

トマトもたくさん実が付いてきました。まだ、緑色のままです。これから雨の日が多くなりそうで、気温は低めに推移することになり来週くらいから収穫できそうな感じはあまりしません。実際に積算温度がどの程度で収穫できるものなのかをマークを付けて検証してみます。

いいね 家電リモコンのセンサー機能

ちょっと前に試しに設定していて忘れていた機能が動作して、やっぱりいいねと思いました。
それは、センサーで取得した明るさの情報をもとに家電を操作する設定です。次のように設定しました。

1)IFTTT連携の設定を行う。

2)IFTTTでつぎのようにAppletを作成する。

 2-1)then に RATOC remoconを選択する
2-2) リモコン明暗 (照度) を指定する
2-3) 基準値1(100Lx)より低いを選択する
2-4) Create Triggerを押す
2-5) that に RATOC remoconを選択する
2-6) エアコンの操作を設定する
2-7)エアコンの操作で 停止 を指定する。
2-8)Create Actionを押す

以上で設定は終わりです。

この設定で、電灯を消して部屋が暗くなれば自動的にエアコンが切れるので、エアコンの切り忘れを防げます。 逆にエアコンをつけたままにしておきたければ電灯を点灯したままにしておく必要があります。その場合でも離れたところからオンになっていることを気が付けます。エアコンの消費電力に比べれば電灯のほうはそれほど多くないので、消費電力的にも無視できるでしょう。
 RATOCの仕掛けに改善してほしい点を言うとすると、「 基準値よりxx 」という条件だけでなく、「xxx以上からxxx以下に変わった」など、条件をきめ細かくしてほしいところです。 現状の「 基準値1(100Lx)より低い 」の条件だと、電気を消した時点だけでなく、暗い時間帯に複数回”エアコン停止”の操作が行われることになります。エアコンの動作的には何も起こりませんが、リモコン操作がおこなれたのと同じで”ぴっ”という音がします。

そんな感じで、現在の状況に合わせて動作する仕掛けは、うまく使えばなかなか便利です。その点は、Amazon EchoとGoogle homeの音声アシスタントにも当てはまります。今の状態を認識したうえでそれに合わせてより期待に近い動作をさせるというものです。今の時刻、現在の場所、などです。「今日の天気は?」と聞くだけで、現在地の天気を教えてくらますよね。現状はGoogleのほうが状態認識しているものの情報量が多く、的確な動作をしていると感じます。

たとえば、つぎのようなものです。

・テレビがついているかどうか
  → リモコンボタンの電源操作は、ON/OFFどちらも同じ信号が送信されます。このため、テレビの状態を認識できていないと「テレビをつけて」の操作の結果として”テレビを消して”しまうことがあります。
Google home(Chromchast)の場合はリモコン操作でないので機能するのですが…

・誰が操作したか
  → 誰が操作したのかを認識してその人の設定で動作する。
   カレンダーなど個人アカウントと紐づいている情報にアクセスして動作します。

・今、何をしているか

ということ、スマートスピーカーは、その機器で認識した5W1H?を条件にして、それについて前置きする音声入力することなく機能するので違和感なく使えます。このレベルまではふた昔前のAIのレベルです。今どきのディプラーニング技術をこの5W1Hの管理に組み込めば、スマート何とかはさらに進化できるはずです。

WordPress 5.2.2の修正内容 と脆弱性  

WordPress5.2.2のことを書く前に、以前に書いたWordPress脆弱性で完結できていないものを再確認します。
まず以前に書いたCVE-2017-6514について書きます。JVNのDBには2019/6/6に登録されています。これは私がここに投稿した日より2週間ほど遅い。JVNの情報から修正内容など新たに分かる情報はありませんでした。最近の動きは6/14にある脆弱性チェックツールで検出できるように強化されたことが情報公開されています。このタイミングでの情報公開なのでWordPressの修正コードなどの情報をもとにチェックルールを作成したものと推測されます。まだWordPress側では脆弱性情報が公開されていません。現在関係機関と公開に向けて調整しているのではないかと推測します。
つぎに、WordPress5.2.1の修正情報の再チェックです。前回チェックしたときに内容チェックに終始して、後で更新されることは想定していませんでした。ぱっと見た範囲では、変わっていません。この状況だと更新される可能性がありそうです。
さて、本題のWordPress5.2.2の修正内容についてです。13件のバグ修正とWordPress5.2で追加したサイトヘルス機能をちょっと更新したとリリース情報には記載されています。

#45094 #46289 #46997 #47227 #47429 #47558 #47475 なし

#46749 4.3

#46881 #46957 #46960 #47070 #47158 5.2

作り込みバージョンの記載がないもの7件、4.3が1件、5.2が5件です。
バージョンの記載がないものの修正内容は次ように、脆弱性に関係しそうな記述はありませんでした。
#45094 ダッシュボードのいくつかのエレメントでフォーカスされない
#46289 メディアモーダルでのナビゲーションアローのリンク先間違い
#46997 テーマの更新でリンクが動作しない
#47227 サイトヘルスタブの文字列修正 → 5.2での強化分の修正
#47429 更新パッケージ
#47558 更新ページのアップデート → 5.2.2で勝手にアップデートした件でしょう
#47475 typoの修正

脆弱性に該当しそうな修正内容の情報はありません。5.2.2は”セキュリティ更新”として更新が自動適用されたり、修正公開の事前情報など脆弱性対処をしたりした状況と推測される状況なので、セキュリティ修正がリポジトリには登録されたソースコードはあるが、公開された修正項目には情報がないという状態だと思われます。
 以上の状況から、別途公開済みの5.2.2か5.2.1で修正された脆弱性情報が後日公開されるものと推測されます。


それから、サービス停止を引き起こしかねないアップデートを勝手に適用するというはそれ自体がDOSの脆弱性と言ってしまってもよいのではないでしょうか。サービス停止したことを自動検知して自動リカバリするとかいろいろな対処がありそうです。

太陽光発電システム導入環境での消費電力解析

これまで、太陽光発電のデータ解析について書いてきましたが、そもそもなぜ書き始めたかについて詳しく書いていませんでした。「パワーコンディショナーの消費電力」や「ここまでのまとめ」で、パワーコンディショナーの消費電力についての挙動をあるていど理解できたので、それを踏まえて気になっている点について解析してみます。

解析したかったのは、さきに書いたサイト3における「パワコン?謎の消費電力増加」の総消費電力量の増加の原因です。

問題の期間(2018年5月から2019年2月までの間)について、”パワコンでの解析”のように各時刻ごとの消費電力をプロットしてみます。

日ごとの毎時消費電力量

謎の消費電力増加 その4のデータと同様な絵柄ですが、5回ほど階段状に変化してそれぞれで別の挙動をしているように見えます。そこで、同様に朝と夕方の時間帯分をプロットしなおします。

日ごとの毎時消費電力量 朝方

朝方のデータから全体の階段情報変動はベースライン自体の変動に依存しているように見えます。つまり、太陽光発電システム以外で常に一定の電力を消費している何かが増えたと推測されます。

日ごとの毎時消費電力量 夕方

夕方のデータでは、1日に1分づつ変化するパワコンのモード切替時刻の影響により6/13以前と7/9から9/7あたりは19時台の消費電力が徐々に変化しているのがわかります。
9/14から12/1あたりは激しく変動しています。昼間と夜間の差は同じようにあるのでベースが変動していると推測できます。
12/1以降は5回ほど階段状に増減しています。それぞれの区間での昼間と夜間の消費電力差は同じです。この区間内での変動はベースラインの変動のみと考えてよいのですが、9/7以前にみられた19時、18時台の1日づつ変化するパワコンのモード切替時刻の影響が見られなくなっています。このパワコンの挙動の変化のタイミングと、消費電力量のベースラインの変化のタイミングが一致しているので、ベースラインの変化の原因がパワコンに依存しているのではないかと想像されます。次回、詳細を確認します。

なにー、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の修正内容をチェックはまた明日。

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

監視モニター用の画面が起動しないので、ほかのページを確認すると、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を再起動して、無事に復旧しました。

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

トマト、ミニトマトの結実

トマト
ミニトマト

トマトとミニトマトの実がなり始めました。花も順次咲いているので、この調子だと7月上旬からどんどん収穫できそうです。

「トマト・ミニトマトは開花から毎日の平均温度を足していった積算温度で赤くなる日にちが決まります。
トマトだと800~1000℃(品種によって違います)
ミニトマトだと750~850℃(品種によって違います)くらいです。」

ということですので、累積温度800℃として、 平均気温23℃から25℃として 計算すると開花から35日くらいと予想できます。6月1には花が咲いていたので、7月5日くらいには最初の収穫ができそうです。

ミニトマトは摘果を省きますが、トマトのほうは随時摘果していきます。

トウモロコシの追加

まだ梅雨入りの発表はありませんが、雨の日も少ないけど何日かあり、キュウリの実も付き始めました。僅かに残っていたスペースにトウモロコシを蒔きました。2か月ほど先行して蒔いたトウモロコシは半数ほどが20センチほどに育ってきています。長期間にわたって収穫することを目指してあと1回くらい時期を分散して蒔く予定です。

各列の奥のほうがトマトで、一番左の列はキャベツ。左から2番目はレタスと虫に食われてなくなったキャベツの跡、3番目は今回追加したトウモロコシ、一番右はぼぼ収穫し終わった大根の跡と先行で植えて生き残ったトウモロコシです。一番右側の列は最初にスギナの処置を全く行わなかった場所で、一番左はある程度スギナの処置を行った場所、この2つは明確な差があります。大根への影響はあまりなかたと思いますが、弱い作物なら育ちや育成中の作業に悪影響はありそうです。どこまで根っこの処置をするかは何を植え付けるかで決めるのもありだと思います。