コンピュータ関連の問題と対処などノウハウを紹介します
過去の写真データを参照したくなって、古い媒体を整理しました。様々なタイプの媒体やバックアップしたデータも出てきました。中身をチェックしようとしてドライブ入れてみたが、読めないものもあります。今すぐには不要だが、バックアップしたものが必要となったとき読めるかどうかを整理しまします。
下表内の記号の意味
◎：読み書きを確認済み
〇：読めることを確認済み
無印：未確認
| ドライブ型番 | HL-DT-ST DVDRAM GH24NS90 | HL-DT-ST DVDRAM GH24NSD1 | 備考 |
| メディアタイプ | |||
| DVD | 〇 | ||
| DVD-R | × | ◎ | |
| DVD＋RW | × | ||
| DVD-RAM | × | 〇 | |
| CD | |||
| CD-R | 〇 | ||
| CD-RW | 〇 | ||
ドライブ自体が手に入らなくケースとか高額になってしまうなどの問題が発生するので、どの媒体が生き残りそうなのか、見極めたうえでバックアップ媒体をどうするのか考えたほうが良いですね。
消費電力ほぼゼロのはずの電気代が1か月で5500円とか、9500円に増えていることに気がつきました。調べると排水ポンプが稼働しっぱなしになっており、常に「ジョロジョロ」と排水されていることが原因と判明しました。普通は、「ドバー」っと一気に排水されて水がなくなると自動で止まります。これは排水ポンプのフロースイッチが効かなくなっていることが問題原因なので、本来は排水ポンプを修理もしくは交換するところです。しかし、費用も抑えたいし、コンセント側で電源をON/OFFしてやれば同じ動作ということで、余っていたスマートコンセントを付けてみました。そして指定した時刻に定期的に排水するように設定しました。この変更で、電気代は１か月で390円に激減しました。これは意図した通りなのですが、故障する前の電気代は1か月あたり1100円程度だったので、期待以上の削減です。ポンプの待機電力より、スマートコンセントの消費電力のほうが小さいとは思えないので、以前は現状のポンプの稼働頻度よりも高頻度でポンプが稼働していたと推測されます。
短時間に多量の雨が降った場合、自動では排水されず、水が溢れるかも知れないので、少し工夫してみます。
IFTTTのサービスを使って、雨が降り出したら排水ポンプを動かすAppletの設定をします。まずIFTTTで「New Applet」すると次が表示されます。
「+this」をクリックして実行する条件”トリガー”を設定します。ここでは「Weather Underground」を使っています。検索枠にサービスの名称” Weather Underground ”の頭から数文字を入れると選択肢が表示されます。
” Weather Underground ” をクリックします。
次に実行条件を選択します。雨が降ったら起動したいので、”Current condition change to ….”（現在の天候がｘｘｘに変わったら）を選択します。
”Current condition” は「Rain」（雨）を、Locationをマップで指定します。「Create trigger」をクリックします。
「＋that」をクリックして、何を実行するかを指定します。
”実行条件”と同様に、実行する処理をサービスの中から選択します。ここでは、利用するスマートコンセント”Meross”を指定します。
”Turn on”（電源オン）を選択します。
登録した”排水ポンプ”のスマートコンセントを選択し、「Create action」をクリックします。
設定した内容を任意の名前を指定します。 「Finish」をクリックしIFTTT設定を完了し保存します
以上で、「雨が降りだしたら自動で排水」することができます。排水ポンプを止めるほうはスマートコンセントのスケジュール設定で「1分後にオフ」を登録しているので、1分後に自動的に排水ポンプは停止します。
他のサービスやWebRequest、Webhook、独自実装を組み合わせて排水量制御とか、排水の代わりに灌水の制御をするようにして、雨の状況を予測して灌水するかどうかを制御するとかいろいろできますね。
定期実行タスクの機能を使ってメール送信していましたが、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がない？など、 使いたいライブラリがないので、どうするか対処が必要。
以前、脆弱性に関連して取り上げたWordPress5.2が5月8日にリリースされています。
・管理者アカウントでログインすれば新しいバージョンが提供されていることが左上の更新と赤に白抜きの数字で示されます。また、ダッシュボードや更新画面から最新バージョンに更新することができます。更新の前にバックアップするように案内されます。
・投稿者アカウントでログインした場合は、ダッシュボード上部に「WordPress 5.2 が利用可能です。サイト管理者にお知らせください。」と表示されます。
機能強化を行うメジャーバージョンアップやマイナーバージョンアップの場合、不具合が含まれているケースが多々ある。新たに提供されて機能を使いたいなら話は別だが、 必要がない機能しか提供されていないので、バージョンアップは急がなくてもよいでしょう。そこで、1か月程度は保留することにします。あまり放置するとほかの実行基盤のバージョンとの組み合わせで不具合が発生することがあります。そこで、１年以内にはバージョンアップを適用することにします。通常は、１年経過する前にセキュリティパッチが提供されて、セキュリティパッチを適用する必要が発生します。
WordPressの場合、Security Category Archiveのページ
https://wordpress.org/news/category/security/ をチェックしていれば、脆弱性対処を含むパッチが提供されているか確認できる。ざっと見て、2か月に１回程度の頻度で脆弱性対処パッチが提供されていることがわかります。
これにより、WordPressの更新頻度が頻繁であれば、特別な方法で通知されなくても気づくことができます。逆にWordPressの更新頻度が低い場合、脆弱性対策パッチ未適用状態で長期間運用される可能性が高くなりそうです。このパターンは対応できるようにしたほうがよさそうです。
ということで、バージョンアップ情報や脆弱性対処を含むパッチの提供情報をメールで通知する仕掛けを用意しました。今回の公開には間に合わなかったが次回の公開時には、実際に通知されることを確認します。
昨日の雷雨は、実測で5mmの降水量がありました。ここから5km程度離れている気象庁の測定ポイントでのデータは0mmでした。かなり激しい雷雨だったので広範囲に降ったように感じましたが局所的な雨でした。
4月以降の気象庁の降水量のデータは、実測データとほぼ一致していたので気象庁データで十分そうだったのですが、昨日の降水量データの5mmと0mmの違いは大きい。自動化するなどの元データにするには、もう少し正確なデータのほうが良いような気がするがどうだろう。
局地的なデータを取得できる何かいい方法など、コメントをお願いします。
脆弱性関連情報を「定期的に自動チェックしてメール通知するとか、検討してみよう。」ということで、とりあえずクラウドサーバ上にpythonコードを移行し、定期実行の手順を検証します。
phpから呼び出したところで、エラー。このクラウド環境は、Python2が動いていて、python3には対応していない。いまどきのクラウド環境ならPython3に対応しているのだろう。つぎの引っ越し先はPython3にも対応していることを条件に入れよう。その選定作業は別途行うことにします。※
Python2用にコードを書き換えて、チェック対象のコンテンツをダウンロードできることを確認できました。
つぎに、クラウド環境のコントロールパネルで定期実行タスクを設定します。
定期実行で、「with open(saveFilePath, ‘wb’) as saveFile:
IOError: [Errno 13] Permission denied: 」のエラーメールが送られてくる。
phpから呼び出した時とは実行ユーザが異なることが原因だろう。
ということで、パス指定を修正して、定期実行によりチェック対象のコンテンツをダウンロードできることを確認できました。
次は、脆弱性関連情報をチェックするPythonコードを用意します。
まるめると「投稿ごとにパスワード設定可能なユーザIDが共通のフォーム認証」ということです。Webエンジニアならこの表現で大体の挙動は理解できると思います。
Web技術的な表現で書くと、次の通りです。
・WordPressで共通のポストデータでパスワードを指定する ユーザIDの指定がない フォーム認証。
サイトで固定のクッキーを使っているのか、それともページごとに指定するクッキーで指定するのかと推測しましたが、パスワードをWordPress固定のポストデータで指定して、WordPressのクッキーでセッション維持をしていました。
これにより次の動作をします。ある投稿のパスワード入力フォームに別の投稿用のパスワードを入力すると、パスワードを入力した投稿は参照できないが、パスワードが一致した投稿は参照できるようになる。また、ある投稿Aを参照できる状態で、別の投稿Bを参照するためのパスワードを入力すると投稿Bは参照可能となると同時に投稿Aは参照できない状態に変わります。
結局、この機能、どこかで投稿参照用のパスワードを利用者に渡して参照可能にするというものでしょう。 実際に使っているというか、有効に使えているところがあるのでしょうか。
この機能って、公開、非公開をあとで切り替える機能ってこと? つまり、主な目的は公開済みのものを後で削除ではなく非公開に切り替えるということ？ 見せないようにするのに削除するのではなくスイッチを切り替えて見せないようにする。証拠保存が目的でしょうか？
非公開にすればタイトルさえ表示されなくなる。
機能名が、なんか変。 つまり「公開する」なのに「非公開」ってなっている点です。日本語に翻訳したところで変なことになっているのか？
やっぱり読み通りでした。英語だと、
「公開する」→Published
「非公開」→Private
です。
「私的：Private（プライベート）」の反対語は 「公的：public（パブリック）」なので、英語だと違和感がありません。 Privateを日本語に翻訳するときに”非公開”としたことで、機能名的な違和感が発生したわけです。
