Archive for the ‘My software’ Category

先日ちょっと書いた、ブログにボットが良く来る件でアクセスログを見ていたら、不正ログイン試行や悪質なアクセス※が結構多くて気になってしまった。

※例: シェルのコマンドを実行しようとするもの、大量のバイナリデータを送って来るもの。

以前にも何度か、目に付いた時に そのアクセス元近辺のIPアドレスをブロックするように設定したのだが、設定するスクリプトを変更するのは面倒だし失敗する可能性があるので、ブラックリストのファイルにIPアドレスを書いて、適宜追加できるようにしてみた。動作確認した時は うまく動いたのだが、たまたま翌日にカーネルの更新で再起動になった あとは繋がらなくなってしまった・・・

それでサーバ(VPS)のコンソールで調べたら、起動はしているもののNWが全然使えない状態になっていた。: ホスト名の検索(DNS)は駄目だし、プロバイダのDNSサーバにすらpingが通らなかった。

ログを調べると、networkd-dispatcherが"Unknown state for interface NetworkctlListState"という訳の分からないエラーを出していた。更新されたカーネルの問題・相性を疑っていたのだが、検索しても ほとんど出て来ないので、僕の環境の問題だと思った。

結局、(上のエラーの前に出ていたのだが、)systemd-networkdが起動しなくなっていたためにNWが使えなくなっていた。その原因は、上に書いたブラックリストのために追加した処理にバグがあり、必須のNWアクセスも遮断するようになっていたためだった。

そのバグというのが しょうもなくて、たった一個の余計な空白(下の $var のあと)が原因だった。シェルスクリプトに

if [ -n "$var " ]; then

のように書いてしまったのを気付かなかった(近眼+老眼+白内障(進行中)のコンボに加え、そもそも眼が不調だ)。$varが空の場合に以降を実行するのに、これでは 全く実行されない。その処理が重要で、実行されないとNWが全部遮断されてしまうのだ。。。

そもそも、空かどうか調べるのに"$var"のように " で挟んで書くのが良くなく(しかも面倒)、もっと間違い にくい書き方がある気はするが、今まで見たことがない。少し考えたい。

そこを直してサーバは回復し、ファイルに入れたブラックリストも ちゃんと動いた。

 

そして更にもう一個、隠れた問題が見付かった。Linuxの仕様なのか、NW-IFを有効にする前のスクリプト(/etc/network/if-pre-up.d/*)が何度も実行されるのだ。僕は そこに上述の悪質アドレスのブロックを設定するスクリプトを入れたのだが、今回初めて、それが何度(4回)も実行されていることに気付いた。

内訳は、実際のNW-IFに対するIPv4, IPv6が各1回、全体に対するもの?(IFACE="--all")、loopback(IFACE="lo")だった。

もちろん使う前に調べれば分かる・調べるべきことだが、余りにも おかしな・杜撰な仕様だ。今まで問題なかったので、スクリプトは何度実行されても問題ないようだが、念のため、一度だけ実行されるように修正した。

スクリプトに渡される環境変数のMETHODが"none", IFACEが"--all"の時だけ実行するようにした。ただ、これはどういう契機なのか分からず、将来は なくなるかも知れないので、実行されなかったら警告が出るようにした。

 

起きてから延々と作業して午後遅くまで掛かったが、そもそも、こんなIPアドレスのブラックリストなんて意味ないことに気付いた。

まず、不正・悪質なアクセスをするサイト(のIPアドレス)は無限にある。※ 良いブラックリストを手軽に入手できないかと検索したら、山のようにブラックリストが出て来たが、それらの いくつかと僕のブラックリストに共通のアドレスはなかった。

※今はまだIPv4がメインだが、v6なら本当に無限だ。それに、v6のアドレスは(プライバシー処理のため)基本的に「日替わり」だから、アクセス時のアドレスに永続性・再現性はない・・・

仮に 良いブラックリストを合わせて使うにしても、無限に多くのアドレスでフィルタリングできる訳はなく、段々重くなり、最後は破綻するだろう。

そして、悪質サイトはブラックリストに載ったらアドレスを変えるだろう。載らなくても随時変えるのではないか?※ 実際、以前アクセスして来たアドレスは、(ログを見る限り、)何度か失敗したあとはアクセスして来ない。それに対応するために余分な幅(例: v4なら256-65536個?、v6なら264個??)を持たせてブロックするとしたら、そのプロバイダの他の人までアクセスできなくなる。

※日本ではそうだが、固定IPアドレスの人が少ないこともありそうだ。そもそも固定にする意味がない。更に、上述のようにv6は基本的に固定でない。

そうやっているうちに、誰もアクセスできなくなりそうだ。

だから、IPアドレスでブロックする仕組みを作りは したし、定期的に不正・悪質なアクセスを調べようと思っては いるが、無意味だと思う。どこかで見たが、リアルタイムに挙動で判定するのが良さそうだ。それがWAFなのだろう。

手軽に使えるものがあるか、気になるところだ。

(23:30) 少し探したら、手軽(無料・簡単)なWAFは なさそうだが、無料のものは いくつか見付かった(例: NAXSI, ModSecurity)。

が、インストールや設定は容易では なさそうなので今後の課題とし、まずは現状の脆弱性などの問題をチェックしようとした。: Nikto2というツールとオンラインのスキャナ(例: InnuniWeb, Mozilla Observatory (HTTP), SSLTrust Free Website Safety & Security Check, WordPress Security Scan)を使った。その結果、軽微な問題は見付かったものの、概ね大丈夫そうだった。

ただ、脆弱性に関して余りチェックをしないもの(HTTPヘッダ辺りが中心の感じ → クライアントに被害を及ぼさないかがメイン?)が多かったので、もっとサーバにキツそうなもの(例: w3af, OWASPのいろいろなツール)でチェックする必要がある。

とりあえず、チェックで見付かったHTTPヘッダ周りの問題を修正した(できないものもあった)。

  • WebサーバとWPのセキュリティプラグインAll In One WP Securityが同じヘッダ(X-Frame-Options: SAMEORIGIN)を出していたため、設定値がおかしい(重複している)という警告が出たので、プラグイン側(Misc. → Frames → Enable iFrame Protection)を解除した。
    • 最初は どうして重複するのか分からず、苦労した。
  • (サーバ・OS依存のようだが、)ETagはリスクがあるとのことなので削除した。
  • httpsでのgzip圧縮にはリスクがある(BREACH攻撃)とのことだが、問題の起こらないタイプだけに制限しているので問題ない。
  • 一番の問題は、Content Security Policy(CSP)に対応していないことだ。: ページの修正が要りそうなので、容易には対応できない。

その他に、TLSの問題・互換性をチェックするものもあったので(例: Observatory (TLS), TLS Checklist inspector)、チェックして修正した。

  • 今はTLS 1.3に移行しつつあるようなので、(obsoleteらしい)1.1を止めて1.2と1.3に対応させた。
    • AEADというものに対応していなかったので、対応させた。
    • 1.3に対応させる時、Mozillaの、サーバの設定例を作るページが役に立った。
      • が、その設定と他のチェックが競合・矛盾する場合があって、(細かい問題ではあるが、)どうするか悩ましい。

あと、SQLインジェクションについても いくつかツールが見付かった(例: sqlmap, jSQL Injection)ものの、そもそもSQLインジェクションを良く理解していないので、正しくチェックできる方法を考える必要がある。

良く考えると、(考えなくても、)SQLインジェクションどころか、サーバのセキュリティ向上は2年以上前からTODOに入っており、今回も少ししたら忘れた振りをして放置する気がする・・・

 

PS. 全くの脇道だが、HTTPヘッダ関連を修正している時、Mozillaの設定サンプルにHTTP/2の設定もあって、調べたらサーバは対応しているので(もちろん、パフォーマンスが劇的に向上するなんて期待は しておらず、興味本位で)ちょっと試したくなった。

が、この「ちょっと」が いつもトラブルを招くのだ・・・w (9/24 8:31)

(9/24 14:39) やっぱり、ちょっとHTTP/2にしてみたw 今度は大きな問題は起こらず、webサーバの設定にHTTP/2を追加しただけで すんなり動いた。ただ、予想どおり、HTTP/2にしても速くならないどころか、わずかに遅くなった(例: このブログは約3%(約11ms)遅くなった)。ページの生成は並列に できないので、基本的には仕方ない。とりあえず試したかったのと、世の中の流れに追従するのが目的なので、まあいい。

このサーバをHTTP/2に対応させた。: Vivaldiの開発者ツールでプロトコル(中央辺りの"Protocol")がHTTP/2を示す"h2"と出ている(最後の"http/1.1"は外部サーバのもの)。

HTTP/2にしても速くない(遅い)原因を考えてみたら、当たり前の気がする。: そもそもHTTP/1.1では複数の接続で同時に転送していたのを、わざわざ1本(想像)にまとめて その中で多重化しているのだから、スケジューリング・多重化・非多重化処理が増えて遅くなりこそすれ速くなる訳がない。

HTTP/1.1の複数の接続では両端の機器や経路へのリソース的な負荷が重くなるが、それが問題なければ、1本にまとめるより ずっと効率が良いと思う。

あと、ヘッダをバイナリにするとデータ量は減るだろうが、元々ものすごく大きいものではないし、エンコード・デコードの処理が増えるから やっぱり少し遅くなるだろうし、ボディ(本体)は もともとバイナリ可なので、何も変わらない。

結局、接続を減らして処理が多くなるのに速くなるという理屈が不思議だ。HTTP/2はリソース面でエコだとは思うが、速度は期待できない。

不思議なのは、JoplinのデスクトップアプリがHTTP/2を使わない(なぜかモバイルアプリは使う)ことで、最新版に更新しても同じだった。良く分からないが、Joplinには構わないことにしているので良い。

他のアプリでは、PC(Linux)ではEvolutionは1.1だったが、意外にもSeamonkeyは2だった。Thuderbirdの新しいコードを取り込んでいるのか。スマフォ(Android)ではDAVx5は2だった。

作業に付随して起こった ちょっとした問題(これで疲れた)は、CLI版を更新したら なぜか起動しなくなり(以前もそうだったので、頭に来て更新しないことにした気がする)、ちょっと調べたらnodeのモジュール@aws-sdk/middleware-endpoint※が不足していたので、自分でダウンロードして追加したら動いた。

※パス: ~/.joplin-bin/lib/node_modules/joplin/node_modules/@aws-sdk/middleware-endpoint

構成ファイルが駄目なのか、nodeのバージョンの関係か。誰も指摘しないのが不思議だが、Joplinには構わないことにしているので、ここまでとした。

(9/24 18:12) 下のPS2にも書いたが、正直言ってHTTP/2はイマイチなので(実際、すぐにHTTP/3が出た)、対応したばかりだが止めた。処理が複雑な割に効果がないし、余計な機能はバグなどを生んでセキュリティ上のリスクになるから、ないほうがいい。

PS2. ようやくHTTP/2に追い付いたと思ったら、HTTP/3が出て居た。開発者ツールでGoogleのサイトを見ていたら"h3"というのがあって気付いた。今度はQUIC/UDPベースだそうで、応答は速そうだ。となると、結局HTTP/2はイマイチだったようだwww でも、HTTP/3も目論見ほど いいのか疑問はある。 (9/24 17:31)

  •  0
  •  0

前々回のPSに書いた、このブログのロゴ画像を「時替わり」で いろいろ出すのが意外に気に入ったので(+そこでも書いたように、ERNIE-ViLG Demoで描いた画像が気に入ったのも大きい)、それを改良した。

例によって やることは難しくないのだが、実装には結構手こずった。欲張るせいもあるが、老化で頭が回らなくなっているのだろうか?

以下のようにしたかった。

  • ロゴとして特別に選んだ・作った画像でなく、ブログの投稿に使った画像全体(あるいは新規も)から、気に入ったものを随時選んで出し、あるいは「引っ込め」たい。
    • → 表示する画像を特別なディレクトリにアップロードするとか、それ用の名前にするとか、注釈(キャプション)を特別なファイルに入れるとかせず、WPの仕組みだけで実現して操作を楽にしたい。
    • かといって、前に書いたように、複数画像の対象への一括設定/解除やキャプションの一括更新ができないとかの馬鹿らしい・面倒なこともしたくない。

一方、表示候補の画像を検索するために対象に「マーク」を付けたいのだが、標準のWPだと画像にはタグなどが付けられないという問題がある。

それらが付けられるのは、投稿などだけ。

WPのカスタムフィールドを使えば実装できそうだが、使い勝手が良くない。そこで、プラグインで何とかできないか探したところ、Media Library Assistant(以下、MLA)というものが見付かった。※ 本来は、WPのギャラリー(複数画像をまとめて出す部品: この投稿の一番下にあるもの)を高機能にするものだが、上記のような、画像など(attachment)にタグなどを付ける機能を持っている。

※これは ものすごく高機能で、僕の用途には もったいないくらいで、とても使いこなせない。今回も、本来の用法でないために却って苦労したw

なお、単にランダムに画像を出すだけなら いろいろあるのだが、特に、タグなどで出す候補を指定できるものは なかった。

次のような処理にした。

  • ギャラリーに表示する候補画像(画像以外、動画なども可能なはず)一覧を抽出できるように、MLAのattachment tag(Att. tag(画像: 右端の列))にギャラリー名(今回は"my_gallery"とした)を設定する。
    • こうすることで、ギャラリーに登録された画像を一覧することができる。
  • 画像のキャプションはWPのTitle(画像: サムネイルの右の列)に設定する。
    • カスタムフィールドなどでも可能だが、使い勝手(特に一括更新)を考慮して そうした。
  • ページの表示時は以下の処理を行う。 (注: 変更あり。最後に書く。: 9/14 8:42)
    1. 表示する画像情報がキャッシュされているか調べる。
    2. キャッシュされている場合、
      1. キャッシュから取得した画像情報からURLとキャプションを取得する。
    3. キャッシュされていない場合、
      1. ギャラリーの全画像数を取得する。
      2. 乱数で その中の1枚を選ぶ。
      3. 選んだ画像のURLとキャプションを取得する。
      4. そのURLとキャプションをキャッシュに格納する(今回は生存時間(TTL)は20分とした)。
    4. 画像のURLとキャプションをページの右上に表示する。

なお、前の版では、表示する画像をページ表示部とは別のプログラムで検索・選択していたが、今回はページ表示部だけで完結している。一長一短だが、こちらのほうが保守性は良い。

それから、やはり前に書いたが、表示する画像をページを表示するたびに検索するのは重そうなので、画像の生存時間(TTL)分キャッシュしておいて、その間は検索しないようにした。

キャッシュにはPHPのAPCuを使った。最初はファイルを使ったが、排他制御が厄介なのでAPCuにした。APCuにはTTL経過後にエントリがなくなる機能があるので、生存時間の実装がとても容易だった。

が、APCuにも排他制御の問題(複数のプロセスが同時にキャッシュを更新する場合)はあって、(この用途では必要ではないが、)一応実装した。apcu_entry()という関数を使った。

複数プロセスで同時に※キャッシュに書き込もうとした場合は、(当然ながら)先の情報を採用し、後から書き込むプロセスは、それまでに選んだものを破棄して先に書き込まれた情報を使う(すげ替える)ようにした。破棄した分の処理が無駄になって効率が悪いが、正しい方法は すぐには分からないので、とりあえず こうした。

※実際には同時でなく、どちらかが先になる。マルチプロセッサ/コアの場合は難しいが、OSが ちゃんと処理しているのだろう。

いろいろ苦労して(また疲れて)、動くようになった。結果は このページの右上のとおり(見るたびに変わっているはず)。

と、一言で終わってしまうが、いくら苦労したって、ちゃんと動けば それで終わりだw

 

(9/13 20:31, 9/14 8:42) 表示する画像の選択方法について

上述のように、当初は乱数で選ぶようにしていたが、様子を見ていたら、(PSにも書いたように、)ばらつき・偏りが大きいことが分かった。具体的には、頻繁に出る画像と なかなか出ないものがあった。気になって調べてみたら、最高/最低頻度の比が10前後と随分大きかった。

乱数の作り方・使い方に問題があるかと思って改良してみたが、余り改善できなかった。それから、通常の生成関数方法(PHPのrand())以外に いろいろ試したら※頻度比は2-3程度になったが、全く気に入らなかった。

僕としては全部の画像を平等に出したいので、特定のものが頻繁に出るのは全く許容できない。もし、特別気に入っているものを頻繁に出したいなら、そういう処理にする。

そういう用途では、音楽プレーヤーのような「シャフル」がいいのだろう。(処理が複雑になるのを別とすれば、)画像数が少なければ問題ないが、多くなった場合には一覧を作るのに時間が掛かりそうだ。

※試した内容や結果などの詳細は別の稿に書きたい。(→ 書いた) ただ、どの方法も「元」は同じ処理のようなのか、(下にも書いたが、)何万回も試行(実行)しないとだめなのか、頻度比に大きな違いはなかった。= 「効果なし」だった。

どうやら試行(実行)回数が少ないとばらつきが出るようだが、1000回以上でも頻度比が2では使い物にならないと感じた。

それで、実際の使い方に立ち戻って考えてみた。: ページを見る方にとっては、ページの変わる順番がどうであろうと、(一定時間経過後に)見るたびに変わればいいので、ライブラリ(ギャラリー)に格納された順番に表示するようにした。 → 最初はギャラリーの最初の画像を、切り替わりの時間になったら次に、最後まで行ったら最初に戻るようにした。

切り替わり時間(20分)ごとにリロードして表示されている画像の内容またはURLを記録するのを数十回も続けるのを2周以上※するような奇特熱心な読者にはバレるが、さすがにそういう方は居ないので大丈夫だ。

※計算したら、一周で約10時間掛かる・・・ → 実際にやるなら、スクリプトなどが良さそうだw

なんて余計なことを書かなければ いいのに、技術者なので つい書くw

変更後の処理は以下である。

  1. 現在表示されている画像の情報がキャッシュされているか調べる。
  2. キャッシュされている場合、
    1. キャッシュに格納した時刻から、現在表示されている画像の表示(経過)時間を求める。
    2. 画像の表示時間が切り替え時間(今回は20分)を超えている場合、
      1. キャッシュから取得した画像情報から現在表示されている画像の番号を取得する。
      2. 取得した番号+1の画像を選択する。
        • ただし、ギャラリー中の画像数以上になったら0(最初)にする。
    3. そうでない場合は、以降は実行しないで終わる。
  3. キャッシュされていない場合、
    1. ギャラリー中の最初の画像(番号= 0)を選択する。
  4. 選択した画像のURLとキャプションを取得する。
    • 画像の番号を指定してギャラリーから取り出す。
  5. そのURLとキャプションと画像番号をキャッシュに格納する(生存時間(TTL)は無限)。
  6. 画像のURLとキャプションをページの右上に表示する。

この変更のため、最後に表示した(現在表示されている)画像の番号も画像情報のキャッシュに保存するようにした。また、最後に表示した画像が分からなくなっては困るので、そのキャッシュの生存時間(TTL)を無限にし、画像を切り替えるタイミングは自分で計算するようにした。

この場合も複数プロセスでのキャッシュに対する同時アクセスは起こるが、どのプロセスの次の画像も同じ番号になるはずなので、構わず上書きするようにした。

 

PS. 本題には関係ないが、前の版もそうだったが、乱数が一様でないような感じがする。前の版は中央辺りに頻度の高いものがあり、その隣は頻度が他の1/2くらいと低かった。

今回は、まだサンプル数が少ないものの、全く出ない値(≒ 画像)がある。特に、最小と最大が出ていないのは、プログラムに誤りがあるのかも知れない。。。

(9/14 9:05) その後、やっぱり我慢ならないので、本文に追記したとおり、乱数は止めた。

  •  0
  •  0

近頃はAIが手軽に使えるようになり、描画システムがいくつか出て来た。最初に記事を見たのはMidjourneyというものだが、生成された絵が陰鬱とかゴチャ付いているとか大げさな印象で気乗りがしなかった。あと、Discordで操作するらしいのも面倒そうだった。

次は名前を思い出せないシステムだが、自分のPCで動かすには ものすごいリソースが要るとあったので「関係ないな」になって印象が薄い(もちろん、クラウドで動いているものを使えばいいのだろうが、パスした)。

その次にMimicが出て来たが、そもそも上の2つと同様な手順で描画するものではないので、放置していたら終わってしまった。

3番目は、良く読んでいるまとめサイトに「Mimicは潰されたけど、中国から これが出て来た」※みたいに書かれていた、ERNIE-ViLGである。生成された画像が(Midjourneyと違って)明るくて悪くなかったので興味を持って調べたら、デモサイト(ERNIE-ViLG Demo)で手軽に描画できるようなので、試してみた。

※実際にはMimicとERNIE-ViLGは全然違う種類なので同列にするのは正しくないが、どちらもイラストを描く人に脅威になるという点で並べられていたようだ。

が、それにしても、詳しくは分からないけど、仮にMimicを潰したって同様なものは いくらでも できちゃうんだから全く無意味だ。自分の作品を真似されるのが嫌なのは分かるが、その防ぎ方が間違っている。今だって「トレパク」があるんだから、同じことではないか?

まだ開発中のようだしデモシステムなので いろいろ不具合はあるし、結構時間が掛かることがある(終わらないことも多い)が、描画させるのは楽しく、いじっているうちに数時間経つことも多かった。

「あれは(どうすれば)描ける?」のように、思い付いた題材を描かせて試して気付いたことを、以下に列挙する。

  • 固有名詞には弱い(実は知ってるのに知らん顔する、「いけず」w)。 → 描きたいものを明示的に文字で表現・指定する必要がある。
    • 有名な固有名詞(例: The Beatles(の中国語訳))を指定しても、ストレートに出ることはない。
    • 概ね字面どおりに生成する。
    • ただ、実際には学習しているようで、雰囲気が近かったり近いものが出ることもある(中国で有名で、中国語での表記がぴったりの指示をした場合?)。
      • The Beatlesは、ちゃんと4人くらいのバンドが出て来た。
  • 描画の指示は中国語が良い。
    • 一時、英語や日本語などでも可能だったが、その後、中国語だけになったようだ。
    • 今でも外国語が可能かもしれないが、おそらく機械翻訳しているだけなので、的確な中国語での指示のほうが良い。
      • 実際、 芸能人の名前を日本語で指示するより中国で使われている綴りで指定したほうが似ている度合いが高くなった。 (下の女性芸能人を参照)
      • とはいえ、僕は中国語はできないので、DeepL翻訳やGoogle翻訳を交互に使って試行錯誤している。
      • あと、英語のほうが中国語に伝わりやすい感じなので、日本語だと伝わりにくいものは英語から訳した場合もある。
  • 描画技法(水彩, 油彩など)によって、結果が かなり違う。以下、好きな順。
    • 水彩: 芸術的(風)なことが多い。
    • クレヨン: 子どもっぽいこともある(それも味があっていい)が、暖かい いい感じのこともある。
    • 油彩: リアル、写実的。
      • 油絵の具の盛り上がりなどはないから、名前が良くない気がする。
    • チョーク: 線画が主。意外に いい場合もある。人物の写真が混じることがある。
    • Cartoon: 文字通り漫画・アニメ調。楽しい・ふざけた感じになることが多い。
    • 児童画: (余り試していない)子どもっぽいが、場合によっては いい感じになる。クレヨンに近そう。
  • 描いた絵は(僕から見れば)かなり「うまい」、「芸術的」。: 本当に僕には描けないものばかり。
  • 細部が「怖い」ことがある。: 例: 腕が3本、指が6本、腕や脚がぐにゃぐにゃ・・・ (→ : 指が ちょっと多いかも?)
    • でも、パッと見ただけでは分からないことがあるし、そういう表現と考えれば受け入れられることもある。
    • 描画のあとで自分で修正するのも、いいかもしれない。
  • 一期一会: おそらく、一度描いたものを再度描かせることは不可能だろう。
    • AIの処理的に そうなっている気がするし、AI自体が随時学習しているので、同じ結果は二度と出ない気がする。
    • しかも、処理の内容を示すようなIDもないから、あとで指定することもできない。
    • そういう意味で、本当に「一品もの」、あるいは、音楽の演奏みたいなものなので、気に入ったもの(そうでないものも)は保存しておくほうが良い。

次に、今までに描かせたもののうち、気に入ったものなどを載せる。今回は まさにギャラリーだw

以下、イラストのキャプションには描画指示の元となる日本語または英語 (→ 翻案・調整したもの) → 翻訳した中国語(= 描画指示), 描画技法を示す。

手始め(お遊び): 「ショートボブの女の子」, 「ポニーテールの子」, "Larry for leader" (「(UKの猫)Larryを首相に」という動き → 残念ながらTrussになったようだ), ある女性芸能人(恥ずかしいので名前は伏せる)

「ショートボブの女の子」は随分良い感じだ。catoonが合っていたのかもしれない。「ポニーテールの子」は(ショートボブで結構期待したのに)間違っては居ないけど今一つだった。が、左上がリキテンスタインぽくて好きだ。

“Larry for leader”は指示が悪かった。固有名詞のLarryでは本物のイメージが伝わらない。ただ、「リーダーに」という指示で、どうにかそれらしいものが出た。なお、猫のイラストとしては いいものが多い。

ちなみに、指示として「Larryを首相に」のように書いたら、禁止文言でエラーになって描画できなかった。そこは中国だ。

女性芸能人を日本語で指定では ほとんど似ていないけど別の人に似ているもの(例: 右上: 卓球の元選手, 右下: 昔のアイドル歌手)があったし、左下の人間離れした顔には妙にひかれる。女性芸能人を中国語で指定は、半分くらい本人に似ている、あるいは、イメージが合っている気がする。

誰か分かっちゃった方は こっそり連絡して下さいw

歌シリーズ: 「微笑がえし」, 「半分少女」, 「真っ赤な女の子」, 「私がオバさんになっても」

「微笑がえし」は水彩が良かった。水彩のロングヘアのものは今まで描画したものの中で一番気に入っている。※ そして、微笑んでいるけど微妙に困ったような寂しいような表情が歌に合っていてすごい。その隣のペコちゃん風なのも可愛くて好きだ。これは余白の取り方が うまいと思う。他に、チョークの素朴な感じにちょっとグッと来るものがあった。例えば、左上や中央下である。

※書く必要は全くないのだが、僕はショートボブやポニーテールの人が好きなのに、これが一番いいというのは自分でも おかしい・矛盾も いいところな気がした。が、良く考えると、これは僕が描きたかったもの(「微笑がえし」)に すごくマッチしているからいい・参ったのであって、必ずしも「僕の嗜好全体を通して最高」という訳ではないというところで納得(大人的な決着)した感じだ。

「半分少女」は いかにも可愛い少女になり、昔気に入って居たアナウンサーに似ているものもあった。なお、文字通り半分だけ描画されているものがあった。さすがに歌詞の内容までは理解(学習)されていないため、題の指定では歌に近いものは なかなか出ない。「真っ赤な女の子」も同様で、文字通り赤い服の子が多かった。これは指示が悪かったので仕方ない。歌の意味やイメージを伝えるべきだった。それでも、何となく近そうなものがあったので載せた。

「私がオバさんになっても」では上の曲での経験を踏まえ、歌詞の一部を翻案して指定した。が、それでも描く対象(若い女性)やその内面を想像して描いてもらうのは難しく(それはそうだ。書いてないものは分かりようがない)、全部却下だったが、あとから見返したら何となくそれらしいものが少しあったので、載せた。「で、どうなのよ?」と すごんでそうな感じのはおもしろいし、いろいろ喋っている(ちょっと慌てて問い詰めている?)感じのは何となく宇多田ヒカルに似ているのも気に入った。

黒猫 優作

Larry the catや歌と同様に、「優作」と指示しても全く無意味なので、僕の持つイメージを指示して いくつかいいものが出来た。一番気に入ったものを加工してツイッターのアイコンにした。

優作で感心したのは、僕なんかが黒猫を描くと真っ黒になってしまいがちだが、描かれたものの多くは明るさや色を加減して ちゃんと表現していることだ。あと、どれにも言えるが、背景の色遣いが好きだ。派手だけど やり過ぎでないところが うまい。

「時をかける少女」

(映画・アニメ風)

映画に英語の題"Girl Who Leapt Through Time"があったので、最初はその中国語を指定したが、人物が子どもになってしまった。そこで、映画の主人公は高校生なので そのように指定したら、映画やアニメのイメージに近いものが描けた。

なお、"highschool"は正しくは"high school"だったが、翻訳は大丈夫そうだったw 下の中学も同様。

(原作風)

が、その後、原作では主人公は中学生であることが分かった(すっかり忘れて居たが、「そういえば」と思って調べた)ので、中学生としても描いた。この作品は、どうしても原作よりも映画(あるいはアニメ)の印象が強いが、ジュブナイルとして書かれた原作に忠実に描くとしたら最初のものが一番近い気がする。

自分

自画像的なものを描きたくて、かなり試行錯誤した。自分の属性や好みを文章にして指示した。さすがに こだわりが強く、載せた以外にもボツ稿は かなりある。が、結局、自分を人間として描くことにこだわらないもの()でもいい気がしている。もう少し試したい気がするが、キリがない。

最初の頃は「モーツァルトが好き」を指示に入れていたために、その頃の雰囲気(例: 髪型や服装)になってしまった。同様に、僕とAIで言葉のイメージが違うため、「若くない」とか「50代」とかを入れたらお爺さんになったので、「中年」にした。また、「ピアノが好き」だと演奏の光景になることが多かったし、「眼鏡を掛けた」は猫まで眼鏡になることが多かった。そもそも、「技術者」を指示すると眼鏡になることが多いようだ。

自分で見て、一番雰囲気が近そうなものや気に入ったもの4つを先頭に示した。以降は、雰囲気はいいけど近くないとか全然違うけど気に入ったものである。

「モーツァルト」を入れたものにマイケル・J・フォックスに似ているものがあったのがおもしろい。他に有名人に似ているのは、松尾貴史タモリがある。そこら辺は、本人の画像を学習して生成している気がする。

バンドシリーズ: Yellow magic orchestra, Electric light orchestra

今までに書いたように、"YMO"や"ELO"では分かってくれない。それでも、YMOは少し分かっているのか、結構3人のものがあった。やっぱりクレヨンのは可愛いので、新しいYMOにならないか(強いて言えばBABYMETAL風?)。あと、いかにも女子向けのアニメ的なのもおもしろい。

ELOも、なぜか初期のロゴ的な電球は出た。まあ字面から想像できるものではある。クレヨンのは可愛いので、新しいロゴにして欲しいが、グループ(今はムサ苦しいオジさんだけ・・・)のイメージと全然違うので無理だ。

 

終わりに

使ってみて、(いろいろ欠点はあるものの、)僕には こういうので充分だと感じた。大げさだが、このシステムにより、絵が描けない僕が描けるようになったのだ。実体はAIがいろいろな画像を合成しているのだろうが、描く内容や描き方を指示できて、気が済むまで繰り返せて、最終的に自分が「これだ」と思ったものができる(しかも、他に同じものがない(はず))なら、自分で描くのに近いと思う。

実際、ERNIE-ViLGで描いた優作をツイッターのアイコン(アバター?)に使ったし、「自分」として描いたものを このブログのロゴ画像(右上)にも使いたいと思っている。ただ、どれがいいか迷うのと今の優作の写真も捨てがたいので、ランダムに切り替え表示するようにしたいと思っている。 → とりあえず、作ってテスト中。: 右列一番下の"Random logo test": 10-20分ごとにランダムに切り替わるようにした。 (9/6 13:14) → 良さそうなので、今までの優作のロゴ画像と交換した(今までのものも出る)。 (9/6 21:11) → 処理の概要をPSに書いた。 (9/7 19:36)

それから、よくニュースの記事に ありきたりなストックフォトを載せているが、なまじ写真なので誤解することが多くて意味がない(むしろ逆効果)。※ そういうのは止めて、こういうシステムで内容にマッチしたイラストを描いて載せるべきだと思う。

※だから、写真の下に「イメージです」とか「本文とは関係ありません」とか書いてあって、すごく馬鹿らしい。

あと、記事が対象としている本人の写真だって、その時に撮影したものでないものを載せるのは誤解を生むから良くない。例えば、深刻なニュースなのに(過去の)笑っている写真を載せたら、「不謹慎だ」とか不要な反感を かうこともあるだろう。

 

そして、以前も書いたと思うが、僕には今回試したイラストの描画のように音楽を演奏できるシステムができると うれしい。以下のようなイメージだ。

AI音楽演奏システムの操作のイメージ

  1. 曲名を指定するか、楽譜を入れる。: 例: K. 488
    • フリーのものは自動で楽譜を取得する。
  2. 演奏表現の仕方や、参照する・倣う演奏者・演奏があれば指定する。: 例: 「現代的かつダイナミックかつパワフルに」、「アンスネス(2022)風」
  3. 演奏を生成する。
  4. 全体の感じやパートや部分の感じ・表現を修正・調整
    • 例: 気になるパート・箇所を、再生しながら指定、文章や声で指示、楽譜や波形をマウスなどで指定して、「もっと滑らかに」。
  5. 気に入るまで3-4を繰り返す。

修正・調整は難しそう(音楽的才能や知識が要りそう)だが、そこもAIで補助できるだろうか?

 

PS. ランダムロゴ画像の処理の概要 (9/7 19:36)

機能: このブログのロゴ画像(ページ右上)を、設定した時間ごとにランダムに変更・表示する。

構成: ロゴファイル更新プログラムとブログのロゴ表示ウィジェットからなる。

動作

  • ブログのロゴ表示ウィジェット (phpで記述)
    • ロゴ画像格納ディレクトリ内にある、仮ロゴファイル(logo.sl: 実体の画像ファイルへのsym-link)を表示する。
    • 仮ロゴファイルのsym-linkの実体のファイル名を取得して、ブログのページのHTMLで表示する。
      • 実体でないと、suffixからファイルのタイプを判別できず、表示できない場合があるため。
    • 仮ロゴファイルや実体のファイルがない場合にはデフォルトの画像を表示する。
    • 画像の注釈をファイルから読み込んで、画像の下に表示するようにした。 (なければ出さない。)
      • 注釈は、画像個別かファイル名のパターンで指定することができる。
      • [個別] 画像ファイルのbasename + ".desc"
        • 例: test.desc: test.jpg(など)の注釈になる。
      • [パターン] 画像ファイル名の先頭の文字列 + "@.desc"
        • 例: EVD@.desc: "EVD@"で始まる画像ファイル(例: EVD@Screenshot_2022-09-06_05-26-56.jpg)全部の注釈になる。
  • ロゴファイル更新プログラム: update_logo.sh: crontabで定期的(20分ごと)に実行する。
    • 仮ロゴファイル(logo.sl)の最終更新時刻から10分以内なら処理しない。
    • ロゴ画像格納ディレクトリ内にある画像をランダムに選んで、仮ロゴファイルにsym-linkする。
      • 一般的な画像(JPEG, PNG, GIF)の一般的なsuffixを持つファイルを検索する。
      • 乱数はbashの変数$RANDOMを使った。
        • どうも偏りがある気がするが、平均は中央付近なので気のせいだろうか?
          • 乱数をファイル数に丸める処理(mod)が悪いのだろうか?
          • /dev/randomなどを使っても、同様な感じだった。
      • 前回と同じファイルになった場合は再度選ぶ。

備考

ブログのロゴ表示ウィジェットで全部処理させることもできるが、表示のたびにファイル一覧取得などを行うので、多少処理が重くなりそうなので止めた。一方、そうすれば、表示のたびに異なるロゴ画像を出すことができる。が、そこまでする必要はなさそうだと思った。

画像の注釈は、画像ファイル中のEXIF, XMPなどに格納して取得することも可能だが、それを表示のたびに実行するのは無駄だし重そうなので止めた。キャッシュすることもできるが、そこまでのものではない。

なお、表示時でなく更新時に抽出すれば重くならないが、抽出したファイルの管理が増えて、ちょっと煩雑である。

また、そもそもPNGでは そういう情報を格納できないので不都合がある。また、パターンでの指定ができないので、多くのファイルに同じ注釈を設定する時には設定だけでなく変更時も煩雑になる。

  •  0
  •  0

とりあえず、部屋のCO2濃度に応じて風呂の換気扇のon/offを制御するソフト(c2m-wj01-ac-fan.sh)ができた。それにより、火を使ったり汗をかくような作業をしている場合(→ グラフ: 右半分: 作業時, 高い山: 火の使用時)を除いて※、部屋のCO2濃度が常に概ね800ppmを下回るようにできて居る(ここ一か月の平均CO2濃度は約720ppmとなった)。 (→ グラフ: 過去1か月の変化, 過去1日の変化)

※その場合には換気扇が連続して回るので、しばらく経てばCO2濃度は下がる。

そして、適切に換気できるようになったおかげか、近頃は、夕方近くに頭痛が起こることや、外に起因する異臭(例: 煙草臭)がすることが ほとんどなくなった。就寝時の動悸についても改善はしたが、関係はまだ良くわからない。

CO2濃度に応じた換気扇の自動制御処理

基本的に、換気扇はタイマーで常時間欠運転しており、1人で安静にしている場合には室内のCO2濃度が増加しないようになっている。ただ、作業したり火を使ったりするとCO2濃度(の増加速度)が高くなり、間欠運転では換気量が足りなくなるため、PCからタイマーを制御してCO2濃度が下がるまで換気扇を連続して回す処理をしている。

以下に処理手順の概要を示す。

  1. センサ(CO2Mini)からCO2濃度を取得する。
  2. 換気扇を回していない場合
    1. CO2濃度が 高い(>= Th_H)場合
      1. 以下のいずれかの場合、換気扇を単位時間回す。
        • CO2濃度が すごく高い(>= Th_Hi)
          • この場合、換気扇を単位時間の2倍回す。
        • CO2濃度の変化率が大きい(>= Th_cr_p_Hi)
        • CO2濃度の短期間移動平均の変化率が大きい(>= Th_cr_st_ma_Hi)
        • CO2濃度の短期間移動平均が大きい(>= Th_st_ma_H)
  3. 換気扇を回している場合
    1. CO2濃度が低い(< Th_L)場合
      1. 以下のいずれかの場合、換気扇の運転を継続しない(ただし、すぐに停めずに現在の運転時間が終わるまでは回す)。
        • CO2濃度が すごく低い(< TH_Li)。
        • CO2濃度が高くなくて中期間移動平均のCO2濃度が小さい(< Th_mt_ma_L)。
    2. CO2濃度が低くない場合
      1. 換気扇を継続して回す。
  4. 次の処理・濃度チェック時間まで待つ。
  5. 1に戻る。

現在の動作設定を以下に示す。

  • 換気扇の常時間欠運転(タイマーによる)
    • On: 26分, Off: 14分 (On率: 65%)
  • 換気扇の自動制御
    • 処理(CO2濃度チェック)間隔: 1分
    • 換気扇を回す単位時間: 30分
      • ただし、CO2濃度が すごく高い(>= Th_Hi)場合は2倍(60分)。
    • CO2濃度を移動平均する時間
      • 短期間: 7分
      • 中期間: 10分
    • しきい値
      • 換気扇を回す関係
        • CO2濃度が右以上の場合、「高い」とする。 (Th_H): 775ppm
          • CO2濃度が右以上の場合、換気扇を回す。 (Th_Hi): 875ppm
          • 前回からのCO2濃度変化が右以上の場合に、換気扇を回す。 (Th_cr_p_Hi): 20ppm
          • CO2濃度の短期間移動平均の変化が右以上の場合に、換気扇を回す。 (Th_cr_st_ma_Hi): 10ppm
          • CO2濃度の短期間移動平均が右以上の場合に、換気扇を回す。 (Th_st_ma_H): 775ppm
      • 換気扇を停める関係
        • CO2濃度が右未満の場合、「低い」とする。 (Th_L): 750ppm
          • CO2濃度が右未満の場合、換気扇の運転を継続しない。 (TH_Li): 675ppm
          • CO2濃度の中期間移動平均が右未満の場合、換気扇の運転を継続しない。 (Th_mt_ma_L): 750ppm

 

作る時に苦労したのは、処理手順(アルゴリズム)※よりも、設定の調整である。いろいろなしきい値(上記)が定常的なCO2濃度や動作の安定性を決める。それらが不適切だと、いつまでも換気扇が回り続けたり、CO2濃度が下がらなかったり、下がってもすぐに上がって、頻繁に換気扇が回ることになる。

※アルゴリズムについては、思い付いたまま、かつ、動かしながら修正したので、上に示すように「何か複雑」になってしまった。

また、常時間欠運転のon/off時間やon率がCO2濃度の減少速度を決定するので、これを人によるCO2濃度の増加速度に合わせる必要がある。以前も書いたように、常にon率に比例する換気能力が得られる訳でなく、ある程度on時間を長くする、あるいは、on率を大き目にする必要があった。

あと、移動平均時間は換気扇を回す・停める「感度」を決める。

例によって、(題や最初に「とりあえず」と書いたように、)いろいろ改良したいことはあるが、現状で大きな不満なく使えているので、まあ、気が向いたら やって行きたい。

 

最後に、前回以降にCO2・換気関連で したことや分かったことなどを列挙する。

  • センサ(CO2Mini)関係
    • 設置位置の変更: メインディスプレイの後ろに設置した。
      • 強い呼気(深呼吸や溜息など)の影響を避けるため。
    • 遮熱・防風処理: CO2Miniは熱(急な温度変化)や風(室内の気流)の影響を受けやすいことが分かったので、それらを抑えようとした。
      • : 机の温度の影響を抑える(低減する、以下同)ため。
        • プラのカップ(ある飲み薬の計量用)と輪ゴムで作った。
        • 振動を抑えるように、中にスポンジを入れた(本当に効果があるかは不明)。
      • 遮熱板: メインディスプレイの熱の影響を抑えるため。
        • ただし、冷房などでの室温変化の影響は防げない。
        • 熱とともに、ディスプレイの下から通って来るであろう呼気も抑える。
        • 段ボールで作り、ディスプレイの側に断熱材(エアキャップ)を貼った。
          • どれくらい効くかは不明。
          • あと、貼る側もどっちがいいか不明だが、こっちがいいと考えた。
      • 防風板: サーキュレーターやエアコンなどでの気流の影響を抑えるため。
        • 段ボールで作った。
      • 遮熱・防風板: 上の二つを統合して簡略化した。
        • 遮熱板と同様に、ディスプレイの側に断熱材を貼った。
  • 部屋のCO2濃度について
    • CO2濃度の増減速度の例(速度は さまざまな要因で変動する)
      • 人による増加速度
        • 換気扇: off (1人): 約5-10ppm/分
          • 活動量によって増加速度は変わる。
        • 換気扇: 間欠on(on率: 65%)+自動制御 (1人): ほぼ0ppm/分 (長時間を見た場合)
          • 状況により正の場合(例: 0.3ppm/分)もある。
      • 換気扇による減少速度
        • 換気扇: 連続on (1人): 約3ppm/分
        • 換気扇: 連続on (無人): 約3ppm/分
          • 本来は上よりも減少速度が大きくなるはずだが、状況が異なるため、同じ値になった。
        • 換気扇: 間欠on(on率: 65%) (無人): 約2ppm/分
          • 約3ppm/分(連続on)*0.65= 1.95ppm/分なので、概ね想定どおりの換気率が得られた。
    • 作業するとCO2濃度は(急)増する。
      • 火気がなくても増える。
      • 汗をかくような作業だと増加速度は大きくなる。
      • 食後や日光が射した場合も増える。
        • 身体の代謝が大きくなるため?
    • 作業しなくてもCO2濃度は増える(溜まる)ので、換気は必要。
      • 近頃の住宅は24時間換気が必須になっている必要性が分かった。
    • その時によってCO2濃度の減りやすさが違う。
      • 原因不明: 風向き? 天気? 時間帯?
      • 外気のCO2濃度との差が小さいと換気効率が下がる(→ 室内の濃度が低くなると現象速度が落ちる)のはありそう。
  • 頭痛や就寝時の動悸と換気・CO2濃度の関係
    • 適切に換気(自動制御)するようになってから、午後・夕方の(頭痛薬が必要なほどの)頭痛は滅多に起こらなくなった。
    • 寝ている時の動悸は まあまあ減った。
      • 寝室の換気が悪かったせい?
        • 換気の影響は大きそうだが、それだけではない。
      • 近頃、寝ている時に暑いと(約28.5℃以上)動悸が することが分かったので、換気の他に、(寝る前と)寝ている時に寝室を適切な温度にする必要があることが分かった。
        • 寝ている時が難しい。: 同じ温度でも、体感で暑く/寒く感じることがあるため。
      • 上記以外に飲酒や疲れも関係ありそうだが、まだ良くは分からない。
  • 外からの異臭問題と換気の関係 (概略: 換気以外に さまざまな試行錯誤をしているので、「何とかなった」と思えた時に書きたい。)
    • 臭いを減らすには、基本的に換気し続ける方針で良さそう。(CO2と同様)
      • 外が臭いことはあるが、ずっと臭いままということはないので、換気すれば臭いは減る。
      • 換気しないと室内に臭いが溜まってしまう。
      • 一方、埃やゴミが溜まって臭い経路(= ダクト)があるので、そこからなるべく吸気しないことも重要そうなことも分かった。
    • 近頃、部屋が煙草臭くなることが ほとんどなくなった。
      • 換気とサーキュレーターの効果かも知れないが、まだ確定できない。
        • 今まで何度もあったのだが、大丈夫と思って少しするとブリ返す可能性があるので。
      • 暑くなって、外で、あるいは、家や車の窓を開けて煙草を吸わなくなったから?
        • ただ、涼しい日や雨の日も臭わないので、換気とサーキュレーター(+他の対処)の効果があるのかも知れない。

 

(8/1 7:32 写真のキャプションを少し修正)

  •  0
  •  1

換気扇の換気効果・能力を知りたくて、CO2センサを買い、自動測定・記録・グラフ描画できるようにしたら、本当に いろいろなことが分かった。

どうして買うことにしたかというと、外からの臭いの侵入を防止しつつ、換気効果が充分な換気扇の動作設定(on/off比・周期)を調べたいと思ったのだ。また、その頃(先月-今月頭)は結構体調が悪かったし(今も まだ完全ではない)、毎日のように夕方近くに頭痛薬を飲むほどの頭痛が起こっていたので、それがCO2の影響なのかも調べたかった。

以前買ったC国製の臭いセンサ JSM-131SC※が使えればよかったのだが、そもそも出る値が怪しかったし、先日、経産省のガイドラインでチェックしたら駄目なことが分かったので、新たに買うことにした。

※今は同じ型番のものは ないようだが、青い縦長(下半分が少し細い)で数字が4行で表示され、画面の下にボタンがX型に5個配置されたもので、CO2, TVOC, HCHOが測定できると うたっているもの(例: 写真: 右側)は同じだろう。

なお、表示行数が多く、ボタンが画面の下(写真の"Air Quality Detector"の部分)に横一列に配置されているもの(カラー液晶のものが多い)やケースの形状が異なるものの画面表示が同じものも同類と推測する。

近頃、それらのCO2センサを上記ガイドラインに沿うもの(NDIR式)に換えたものを見た気がする。

(6/19 19:53) そういう いい加減なセンサを一発で見分ける方法が分かった。TVOCの表示がある場合、単位が"ppm"ならアウトだ。TVOCの量を示す単位はμg/m3だ。「TVOCは*(例: トルエン)として測定している」というような注釈があれば別だが、なければ、作っている人が何にも考えてない証拠だ。ただ部品を集めて組み立てて、「(なんか分からないけど)数字が出ればOK」というだけ。

というのは、TVOCはいくつかの揮発性物質の総量なので、ppm(parts per million)では表せないからだ。TVOCをppmで出すのは、「財布の中にお金が何個ある」と言うようなものだ。コインと紙幣の総数を調べるようなものだが、一体どういう意味があるのか。

まあ、μg/m3でも同様な気もして来たが、こっちは財布で例えればコイン全部の重さなので、個数よりはマシだろう。

結局、安価なセンサでTVOCを出しているものは全部アウトで良さそうだ。手頃な価格でTVOCをなす物質(現在は13種類)それぞれの濃度を調べて総和できる訳がない。いい加減にしろだ。

(6/23 7:48) 余談というか駄目押し。: 上のクソなC国製センサの箱には誇らしげに"RoSH"と書いてあった。(フォントが同様なので)RoHSの間違いか わざとか分からないが、RoHSすら分かっていないか誤魔化しているのかも知れず、そういうところでも見分けられそうだ(まあ、箱は買わないと分からないことが多いが)。

調べてみたら、手頃な価格で(測定・計測マニアの)僕にとって まともな製品は少なかった。: 例えば、「日本製」をうたっていても、(僕にしてみれば)いい加減なものが多かったのは残念だ。「日本で組み立て」しただけで、製品企画とか検査とかサポートなどが ちゃんとしてないのなら、単に高いだけなのでC国製のほうがいい。

主要部品がC国製で、ただ それを使って組み立てているだけで「日本製」って言うのは、先日のアサリなどと同じでは?

そして、コロナの影響か、「ぽっと出」の会社が上述のガイドラインに合う(だけの)ものを出していたり(売れると思ったんだろう)、以前のクソなC国製製品のセンサをガイドラインに合うもの(化学式 → NDIR(光学)式)に換えただけの(と思える)ものが結構あった。

(細かい話) 調べて分かったことだが、ただNDIRのセンサにすればいいという訳ではなく、センサ自体の精度はもちろん、2波長方式でないと安定性や経時変化が良くないようだ。

それから、NDIRセンサは光で測定しているためか、あまり小さいものでは良くなく、長いもののほうが精度がいいという情報もあった。素人だけど、確かにそういう気がする。

NDIRに換えただけのものは ここまでで落ちる。

あと、「自動較正」を うたうものは一見便利そうだが、使用環境について結構危うい仮定・想定(= 使っている場所は、定期的に(例: 毎日1回)屋外と同等のCO2濃度(約400ppm)になる)をしているので、結構な落とし穴になる。かといって、単にそれを止めればいいものでもないから難しい。 (詳しくは後述)

自動較正を止められないものは ここで落ちる。

残った候補はどれも完璧ではなかったが、少し不安はあったものの、CO2-mini※という製品を買った。約6800円だった。

※USのCO2Meter.comという会社の製品(CO2Mini)を日本のカスタムという会社が自社ブランドで発売しているもののようだが、元々は台湾(ZyAura ZGm053U)あるいはロシア(Master kitまたはDadget MT8057MT8057S?)の製品のようだ。複雑な経緯だが、CO2Meter.comのページを見るとなかなか ちゃんとしているので、それなりに信頼できそうだ。

製品候補と評価

僕のCO2センサに対する要求条件は以下である。

  • NDIR, 2波長型センサ
  • 単体で使えるもの(クラウドベースやスマフォ必須でない)。
    • 可能ならPCに繋がる。
      • 通信の仕様が公開されている。
  • 価格: 1万円以下
  • 可能なら、温度, 湿度が測れる。
    • 更に可能なら、気圧, HCHO, CO, PM2.5なども測れる。

検索して比較した製品と、それらの仕様や口コミからの評価(個人的印象)を書く。

  • × NETATMO (リンク先は並行輸入品): 有名だしNDIRだが高い(3万円くらい)のと2波長でなさそうなのとCO2は手動測定らしいのとクラウドベースなので却下
  • × Awair (リンク先は違うかも知れない): 悪評が多いので却下
  • × LinkJapan eAir: 高い(2万円くらい)のと較正が面倒とのことなので却下
  • × GiA, Prana air SQUAIR+: Amazonにないので却下
  • × Huma-i: NDIRでないので却下
  • × ピピっと換気君, TOMO-CO2-002: 1波長のようなので却下
    • これと同じ外観の格安粗悪品が出回っているとのこと。
  • × OMNI HCOM-JP003: 1波長のようなので却下
    • 画面表示から想像すると、C国製のセンサをNDIRにしたようなものか。
    • このメーカーは質問を無視したので、たとえ機能・仕様が良くても却下した。
  • × EPEA-CO2-NDIR-07: 1波長なので却下
  • △- EPEA-CO2-NDIR-08: 「2波長」と書いてあるが、証拠がない(センサのデータシートに記載されていない)ので却下した。
  • △ ポケットCO2センサーPro: 2波長だが、高い(約2万円)のと自動較正を止められないので却下した。
    • ディスプレイなしのもの(Lite)にディスプレイを後付けしたため、使い勝手が考慮されていないのも良くない。
      • 通気穴が上下にあるのとUSBケーブルが邪魔になるので、ディスプレイが見えるように立てて置くことができない。
  • マーベル001: 製品としては妥当そうだったが、高い(1.7万円くらい)ので却下した。
  • Custom CO2-mini: 2波長、PCに繋がり、値段も妥当(約7-9千円)で、ほとんど問題がない。
    • 気になったこと
      • 精度が今一つ(±100ppm), 湿度補償がない。
        • センサが長く、精度が期待できそうな感じもしたが、仕様上は良くないようだ。
      • PCへの接続は可能だがサポートされていない。
        • データに変な暗号化がされており、ちょっと厄介・筋が悪い印象。 (→ 購入後に分かったのだが、数年前に暗号化が解除されていた。: 後述)
      • (口コミ) 当たり外れがある。
      • (口コミ) ディスプレイがCO2濃度と温度が交互表示で不便 → 目障りになる可能性がある。
      • (口コミ) 高周波音(10kHzくらい)がする → 耳障りになる可能性がある。 (→ 購入後にチェックしたが、高周波音は検出できなかった。後述: 6/15 16:21)
  • △- Radiant ZGm27: 2波長、約1.3万円で機能は妥当だったが、下のモノタロウのほうが同様な機能なのに安くて良さそうだった。
  • △ モノタロウ CO2モニター NDIRセンサー式: 2波長、約1万円で良さそうだったが、質問への回答が遅過ぎたのとPCに繋がらないので却下した。

上で△にした4つが「最終選考」に残った。

  • PCに接続する場合
    • ○ CO2-mini
      • 一番製品として出来が良さそう(まとまっていそう)。
    • × ポケットCO2センサーPro
      • 自動較正を止められないから却下。
  • PCに接続しない場合
    • × CO2モニター (モノタロウ)
      • 質問への回答が遅過ぎた。
    • × マーベル001
      • 高いので却下。

結局、一番出来が良さそうなうえにPCに繋がるCO2-mini(以下、USに合わせてCO2Mini)にした。

CO2Miniで気になること(上述)については、精度は そこまで求めないから良し(ただし、経年変化は抑えたいので2波長がいい)、PCへの接続は検索すると いろいろな例があるからできそうだし、できなくても「+α」なので良し、当たり外れは最初の数か月で分かる(1年保証)、高周波音があったらケースを何とかする、交互表示は我慢しようと考えた。

CO2Miniを使い始める。

Amazonに注文したら翌日に届いた。約6800円だった。早速動作確認したら、(運良く?、)全く問題なく動作した。また、上記の経産省のガイドラインでチェックして問題なかった。: 呼気で値が上昇し、アルコールの影響はなく、屋外では充分に値が下がった(10分くらいで約420ppmまで下がった)。

一方、上述のJSM-131SCでは呼気以外は すべて駄目だった。更に、居間でCO2Miniと一緒に測定したら、CO2濃度の値も変わり方も全く合っておらず、全くデタラメなものだと分かった。 (写真: 左: CO2Mini: 995ppm, 右: JSM-131SC: 523ppm)

気になって居た高周波音は聞こえず、バックライトがなくて明るくないせいか、ディスプレイの交互表示は気にならなかった。

ただ、見たい表示と違う場合に待つのが面倒なことがある。が、(後述のように)PCで状態が分かるようにしたので、ディスプレイを見る必要は ほとんどなくなった。

それから、例によって「ちょっと改良」して(背面の通気が悪そうだったので、背面パネルをメッシュにして机上の明るさ・温度センサ(YL-40)のベースの上に設置した(ベースの厚みのため、少し持ち上げる脚を付けた※)。

※脚は、いつもの楽天のポケットWi-Fiの緩衝材をテキトーに切って作った。

(6/23 14:11) 測定を続けているうちに、どうも室温が変わる時にCO2濃度が異常な値になる(大きくなる)ことがあるような感じがした。背面パネルと換えたメッシュは通気が良過ぎるため(保温が悪く)、CO2センサと温度センサ(内の空気)の温度が食い違って正しい温度補正ができず、濃度がおかしくなるのではないかと推測した。それで元々のパネルに戻したら、YL-40の温度(室温)との差が大きくなる(とは言っても±0.5℃以内だろう)ことはあるものの、CO2濃度は確かそうな値になった。

なお、設置位置や置き方にも変更があるが、別の稿に書きたい。

CO2MiniをPCに繋ぐ。

PCに繋ぐのも思って居たより簡単で、届いた日の夕方には出来てしまった。そのためのソフトを探すと いろいろなものがあるが、製品を選んでいる時から参考にしていた、インテックス 平林さんの「CO2 計測 - USB」(2017)に載っているLinux用を試したら、ちょっと修正した※だけで動いた(→ 最初に取れたデータをスプレッドシートに取り込んでグラフにしたもの)ので、それに手を入れて使っている。

※以前は、CO2Miniのデータは暗号化されていてデコードする必要があったが、近頃のものは暗号化されなくなったようで、そのままではデータが読めなかった。が、少しいじってみたり、データをダンプしてみたりしつつ、「物は試し」でデコード処理をスキップしたら読めるようになった。CO2Miniからのデータ取得で苦労したのは ここだけである。

そのプログラムはソースファイル名が"a.c"だったりと、かなりワイルドな感じではあるが、一発でコンパイルできて起動した(ただし、上記のように製品の仕様が変わったために、そのままではデータは取れなかった)ので、例とかサンプルとしては必要充分なものだと思う。逆に、やたらに機能を豊富にされると、本当に必要な部分が分からなかったり、抽出が難しかったり、依存関係で問題が生じて使えなかったりするので、これでいい。僕のスタイルとは随分違うが、悪い印象は なかった。

ただ、実行プログラムにsetuidするのは控えたいので、sudoでrootで動かしている。

参考までに、オリジナルからの変更内容は以下である。

  • プログラムの名前を"co2mini_daq"に変えた。
  • 一定時間ごとにデータ取得を繰り返すようにした。
    • 取得間隔は1分にしている。
  • データを取得した日時をデータの前に出すようにした。
  • CO2MiniのデータがUSBのバッファに溜まって遅延するのを防ぐため※、取得間隔以内でも連続してデータを取得し、それらを平均した値を出力するようにした。
    • そのため、CO2濃度も浮動小数点で出る。
    • ※本当に溜まるのかは分からないが、CO2Miniを抜いても しばらくデータが出続けていたので、溜まっていると考えた。
  • 仕様に書かれていない「謎のデータ」(タイプ(item)が"P", "B"以外のもの)も出力するようにした。
    • 本来のデータと区別できるように先頭に"#"を付け、行数を減らすため1行にまとめて出す。
  • エラー処理・リトライ処理を追加した。
    • 例: CO2Miniを抜いても、再び挿せば(別のポートでもOK)データ取得が再開される。

CO2Miniを使い倒す。: 自動測定・記録・レベル表示・グラフ化できるようにした。

簡単にPCに繋がったのに気を良くして、CO2Miniから取得したデータ(CO2濃度, 温度(≒ 室温))をログに記録し、CO2濃度に従ってデスクトップ(Xfce)のパネル(タスクトレイ相当)に本体のランプ的なインジケーター(水色: 低※, オレンジ: 中, 赤: 高)を出すようにしマウスオーバーで濃度と温度が出るようにした。

※本体のランプの低は緑だが、緑は少し浮くのと余り好きでないので、(どちらかと言えば嫌いでない)水色にした。あとで気付いたが、空気が綺麗なイメージにも合って良さそうだ。

また、測定データ(CO2濃度, 温度)をPCの状態表示ツール(Munin)でグラフに描けるようにできた。※ これで、それまでのようにデータが記録されたログファイルをスプレッドシートにインポートしてグラフを描くなんてチマチマした作業不要で、待っていればグラフが出来ているようになったから、とりあえず何も言うことはないw(とはいえ、いろいろテキトーだし、まだやりたいことはある)。

※ついでに、CO2Miniの温度(≒室温)はYL-40での室温に どのくらい近いか調べたいのと、室温とPCのCPUやマザーボードの温度の関係を確かめたかったので、そういうグラフも描くようにした。

CO2Miniの感想・メモ

期待していたよりずっと いい(ちゃんとした)もので良かった。こういうのは久し振りだ。強いて挙げるとすれば、以下のような「ちょっとしたこと」があった。

  • 上にも書いたが、背面の開口(穴)が小さくて通気が悪そうな気がした。
    • 実用上は問題ないと思うが、反応速度が遅くなりそうな気がしたので、手元にあったメッシュ(アンプのカバーに使った残り)に交換してみた。
      • ただ、実際に使ってみると、メッシュでも反応速度が遅い場合もあって、効果は良く分からない。気流などの要因もあるのかも知れない。
  • 温度の精度は今一つな感じ。(ただし、充分に仕様(±1.5℃)の範囲内)
    • 室温測定に使っているYL-40の温度センサと比べると、0.5℃未満(概ね0.3℃くらい)でズレることがある。
    • 平均値はYL-40と概ね合う(差は0.2℃程度)。
    • CO2濃度(精度±100ppm)もそうだが、余裕を見て(ワーストケースを考慮して)実際より悪目の精度を仕様に出しているのかも知れない。
      • 正直者? 逆サバ?w: 僕は こういうスタンスのほうが好きだ^^
  • 湿度や気圧は測れない。 (仕様にないので当然)
    • CO2MiniからはCO2濃度と温度以外に謎のデータ(複数)も出て来るので、そのどれかが湿度や気圧ではないかと思って ちょっと試した※が、駄目だった。
      • ※値がそれらしくなる計算をした値と、温湿度計の湿度やアメダスの気圧を比較した。
    • それらを少し解析した情報があったが、結局分からなかった。
    • 却って気になる・・・
    • まあ、それらが補正に必要で測定できているなら温度同様に表示・出力するだろうし、仕様に書くはずだ。「書いてないものは付いてない」というセオリーどおりである。
  • (僕の個体では、)口コミにあった高周波雑音(10kHz辺り)は出ていない。
    • オーディオ調整用コンデンサマイクで測定したが、3-20kHzの間にCO2Miniから出る音は検出できなかった。
      • CO2Miniの電源をon/offして比較したが、スペクトラムに顕著な違いはなかった。
        • スペクトラムの18kHz辺りの山は、CO2Miniの横のディスプレイからの雑音と考えられる(マイクを離すと小さくなるため)。
        • 同じく8kHz辺りの山は、測定を停める時のマウスクリックに伴う雑音である(クリックするたびに音量が変わり、今回はoffのほうが大きい)。

以下は備忘録である。

  • 背面カバーは爪で固定されているだけなので、容易に開けられる。
    • 設定ボタンが どこにも固定されていないので、背面カバーを外すと落ちる。
    • カバーを付ける場合は、カバーを机などに置いて穴にボタンを入れ、そこに本体を被せる。
  • CO2Miniに作業した直後はCO2濃度が高く出る。
    • センサ温度に関係しているようで、温度が高いと濃度が実際より高く出るようだ。
      • 温度が正しくなるまで待てば良い。
  • CO2MiniのUSBデバイス名は"USB-zyTemp" (04d9:a052)。

以下に各種情報ページを列挙する。

  • Reverse-Engineering a low-cost USB CO₂ monitor (2015)
    • CO2Miniの暗号化を解読した話
      • 随分苦労したようだけど、暗号化されなくなってしまった・・・
  • USB Communication Protocol for CO2mini (2019)
    • CO2Miniの(暗号化が解除されたあとの)通信仕様 (公式)
  • CO2-miniの通信が暗号化解除されていた (2020)
    • CO2Miniからデータ取得するプログラムを手直ししたあとに見つかった。
  • CO2MeterHacking (2018)
    • 機種が違うため湿度が取れているが、CO2Miniでは常に0しか来ない。
  • CO2-miniを分解してみた (2021)
    • 買う前に内部が見られて参考になった。
  • CO2 + Temperature sensor based on MT8057 and ESP (2019)
    • ロシア語(マニュアルなどは英語), センサなどのマニュアルとプログラム
    • CO2Miniのものとは仕様が異なる。
  • Software for CO2 Monitor (2015)
    • データ取得プログラム (同様なものが新旧多数あり)
  • ZyAura CO2 & Temperature & Humidity Sensor (2021)
    • CO2MiniをESP homeとかいうものに組み込む情報
    • CO2Miniのシリーズは いろいろあるようだ。: MT8057, MT8057S, MT8060, ZGm05, ZGm053U, ZG1683R, ZG1583RUD
  • Предупреждён — значит, вооружён. Часть 1 (Warned - then armed. Part 1) (2015)
    • ロシア語, CO2Miniを使った いろいろな実験? (読めないので詳細不明)
      • ドアや窓に隙間があるほうが換気が良いということなどが書いてあった(どのパートかは忘れた)。まとめからも、この人は そういう居住環境のことをしている方だろうか。
    • Part 3まであり、3では実験の他に内部を少し解析している。
  • MT8057 Детектор углекислого газа (MT8057 Carbon dioxide detector) (2015?)
    • ロシア語, MT8057(この辺りがCO2Miniのシリーズの発端?)の販売ページ(今は終了)。
  • Обзор измерителя углекислого газа CO2 (Overview of the CO2 carbon dioxide meter) (2015?)
    • ロシア語, 構造や仕様の説明など。詳しいことが書いてあって、なかなかためになる。
    • センサの期待寿命や較正頻度も書いてあった。: MT8057とCO2Miniのセンサは同じもののようなので、寿命は5-10年くらいで較正は3年ごとで良い感じだ。
      • "ie. the sensor’s life time is 5-10 years. It is necessary to calibrate the sensor approximately once every three years."
  • Управляем вентиляцией с помощью детектора углекислого газа MT8057 (We control ventilation using the MT8057 carbon detector) (年不明)
    • ロシア語, CO2Miniにリレーを付けて換気扇を制御する、いかにもロシア的な改造。
      • なかなかおもしろそうで、こういう乗りは大好きだ^^
      • ページの下の方の出来上がり図的な写真に にこやかに(不自然な)ポーズをとる女性だけでなく、猫ちゃんが ちゃっかり写っているのがいい。きっとロシアでは普通の構図なんだろうけど、妙に新鮮だ。
        • それにしても、出窓なのかも知れないけど壁が分厚い。一方、寒そうなのに二重窓ではなさそうだ。

部屋のCO2や臭いに関して分かったことなど

まだ数日しか使っていないが、以前は分からなかったことが大分分かった。ちゃんと測って状況を正確に把握するのは重要だと再認識している。

  • JSM-131SCは全くあてにならないデタラメ、crapだった。
    • CO2Miniの半分くらいの値が出る(比較した時点での話)。
    • 換気しても値が変わらない。以前は変わったが、別の要因(TVOC系?)で変化したようだ。
  • CO2Miniを導入する前の換気扇の動作設定(On: 23%, 7分)では換気が不十分なようで、CO2濃度は1100ppmを超えていた。その設定ではCO2が減らず溜まる一方だったようだ。
    • その状態で換気扇を連続して回すと、10分くらいで値が1000ppm近くまで下がり、空気が綺麗な感じに近付いた。
    • そこで、換気扇の動作設定を修正して なるべく800ppm以下を維持するようにしたら、以前より随分良くなった。
    • 冒頭に書いた、午後になると起こる頭痛はCO2が溜まって起こったのかも知れない。
      • 元の換気扇の動作にして本当にCO2のせいだったかを確かめることは可能だが、頭痛だの不調になるのは嫌なので、気が進まない。
        • まあ、確証はなくても改善できたので良しとしたい。
  • (上の理由として考えられること) 換気扇の間欠動作の換気能力が想定(計算)と合わなかった。
    • 換気能力がon(回す)率に比例しないようで、on時間が短いと換気能力はon率から求めた値より低い。
    • On時間が15分以上なら、想定に近い換気能力が得られる感じ。
      • 30分だと充分良い。
    • その理由は分からないが、以下を推測している。
      • 換気扇を回してから換気効果(例: CO2が減る)が出るまでに時間が掛かる(遅延時間)。
      • ステップ応答みたいなもので、on率=出力振幅にならない。
        • 空気の動きに対する部屋の特性はLPFみたいなもので、急な変化は減衰して効果が小さくなってしまう?
        • ただ、その「減衰した分」がどうなるか謎。
      • On時間と排気(換気)量は比例するのかも知れないが、換気扇近く(人が居ない)の空気はCO2が少ないため、「遅延時間」部分の排気はCO2の低減に寄与しない?
      • 空気に慣性があって、長く動かすと気流ができて排気効率が上がる?
        • 実際、長く回していると風(気流)を感じる。
    • → そのため、換気扇の間欠動作の各モードの設定を変更し、基本的にはon時間を30分以上にしている。
      • いろいろ試したところ、on/offそれぞれ30分(on率50%)なら、この部屋で一人で安静にしている場合にCO2を漸減できるようなので、それを標準の動作モードにしている。
  • 外の空気は(意外に)綺麗。
    • 玄関の辺りで測ったら、10分くらいで420ppm前後(ほとんど自然の最低値)になった。
  • どういう訳か、朝(7-8時頃)にCO2濃度が上がる。
    • その頃に食事して代謝が活発になるせいか、近くの道路が通勤で混んで車の排ガスや中での喫煙や、近くの工事の関係かと想像しているが、まだ分からない。 → 更に観察が必要である。
      • 食事であれば、昼や夜も上がるはずだが、必ずしもそうでもない。
      • 道路が空いていても上昇することはある。
      • 工事がなくても上昇することはある。
  • (当然ながら、)部屋に人が居なければCO2濃度は下がる。
    • 人によるCO2濃度の増加は意外に大きく、人が居なければ換気効率が随分向上する(CO2濃度の減少が大きい)。
    • 人が部屋に居ると かなり換気しても400ppm付近までは下がらないので、自動較正は不可能(逆効果になる)。: 詳細は後述。
      • 無人で換気扇を連続して回せば可能かも知れない。
        • → 外出した時に試したら、CO2濃度の減少速度は約-200ppm/hくらいで、400ppmまでは下がらなかったが、もう少し長ければ行けそうだ。
  • (これも当然ながら、)部屋で火(ガスコンロ)を使うとCO2濃度が激増する。
    • 10分くらいで250ppmくらい上がった。 (→ グラフ: 右端)
    • 「火を使う時は換気扇を回せ」ってのは十理あるw
  • 部屋に嫌な臭いがない時に感じる「空気が綺麗な感じ」(いわゆる「新鮮な空気」的)はCO2濃度とは関係なさそう。
    • → 臭い物質とCO2は同じではない(それは そうだ)。ただ、部屋に空気が入るところで物質がフィルタリングされる訳ではないから、臭いのない状態でCO2濃度を下げるようにすれば臭い物質の濃度も下がるはずだから、その方針は悪くなさそうだ。
      • ただ、(以前も書いたが)外が臭い場合には どうしたらいいかが分からない。
    • 一方、CO2には臭いはないものの、濃度が高い場合には臭いを感じるという情報を見た気がするので、CO2濃度が高いために部屋に嫌な臭いがするように感じる場合もあるように思う。
      • そうでなくても、部屋のCO2濃度が高いということは臭い物質も溜まっているだろうから、それだけ臭くなる確率が高いことは確かだ。

今後やりたいこと

CO2濃度の自動測定が出来るようになり、(先日書いたように)PCから換気扇のリモコン(換気強度の設定)も出来るので、それらを繋げればCO2濃度に応じた換気扇の自動制御ができる。例えば、いつもは弱めの換気強度(換気扇の動作モード)にしておき、CO2濃度が高くなったら しばらく(例: 15-30分)回すなどである。あるいは、CO2濃度に応じて自動で換気強度を切り替えることも考えられる。

あと、季節に応じて換気強度を変えることも考えられる(冬や夏に換気し過ぎると空調が効かなくなりそうなので)が、空調のために換気を弱めるのも良くないから、余り調整の余地はないかも知れない。

なかなか おもしろそうだ(実際にやると疲れるが)。

CO2センサの自動較正機能について

CO2センサには自動較正/校正/補正機能があるものが多い。いくつか種類があるが、基本的には、ABC(automatic baseline calibration)と呼ばれる方式である。調べてみると余りにも乱暴な方式なので、僕は即座にoffにしたくなった(実際、CO2Miniの電源を入れて すぐにoffにした)。というのは、(上にも書いたが、)測定地点が定期的に(例: 毎日1回)屋外と同等のCO2濃度(約400ppm)になることを想定し、決められた期間の中で最低の濃度が(例えば)400ppmであるとして測定値を補正(引き算)するだけのものだからだ。

「あのぉ、屋外は確かにCO2濃度は低いけど、その値は場所や季節や時間で かなり変動するし、そもそも測定場所が屋外と同じように綺麗になる保証は ないんじゃないすか?」と言いたい。

これがどういう問題になるかというと、自動較正が起こるたびに値がふらつく(較正前後で不連続になる)のは確かだし、CO2濃度が常時低くならない場所では確実にCO2濃度が低く出るし、そうでない場所でも長く使うと表示されるCO2濃度が低くなっていくかも知れない。

確かにセンサの経年変化を補償する必要はあるし、その点で これは便利だから あってもいいが、on/offできなかったら話にならない。※ 実際、検索したら、この機能があるのを知らずに農業(ビニールハウスだったか)に使ってしまい、あとからoffにしていると思われる例が出て来た。

※Offにできない製品は、企画段階で使い方の検討が不十分だとか、そもそも詳しくない人が作っている可能性がある。もし、常にonで使っても問題ないような特別な用途・場所向けの製品なのなら、そういう注意を書くべきだ。いずれにしても、会社の見識や真面目さが疑われる。

偶然にも、上のCO2Miniのデータ取得プログラムの平林さんも僕と同様な意見なので安心した。以下、少し長いが、その「CO2 計測 - USB」から引用する。

多くの簡易測定器で使われているのは ABC Calibration(Automatic Baseline Calibration) と呼ばれる方法で、 週に一度は無人で CO2 発生源がなく、 測定場所の CO2 濃度が外気と同じになるだろうという期待に基づいたものです。 つまり、8 日間といった区間に於ける CO2 濃度の最低値(base line)を 400 ppm に校正してしまいます。 しかし、住宅、オフィスなどの施設は常時居住者が居て、 CO2 の最低レベルは 600 ~ 800 ppm になりますから、 これを使うと実際の濃度より 200 ~ 400 ppm 低い測定値が得られ、 大きな誤差が出ます。

以上のようなことから、僕だったら、経産省のガイドラインに「自動較正機能があるものはon/off切り替えが可能なこと。」と その理由、on/off設定の目安を入れるだろう。

なお、購入したCO2Miniは その自動較正をon/offできるのはいいが、その場のCO2濃度で即座に較正する機能はなく、自動較正し続けるか8日後に1回だけ自動較正するという設定しかない。

それで、仮に経年変化を較正するには どうしたらいいか考え、以下のようにしようとしている。

  1. 経年変化を較正する時、「8日後に1回だけ自動較正する」設定にする。
  2. 屋外にセンサを持参してCO2濃度が充分低い状態で充分(1時間くらい?)待つ。
    • → その値が最低値として記録されるはず。
  3. センサを元の場所(室内)に戻す。
  4. → 8日後に、屋外で記録された低い値で較正されるはず。

この時に問題になるのは、屋外で測定する時と部屋に戻る時にセンサの電源をonにし続ける必要がありそうなことだ(センサにはバックアップ電池や時計はないから、電源を切ったら「8日間」というのが分からなくなってしまう)。そのため、モバイルバッテリーと補助電源の付けられるUSBケーブルを用意する必要がありそうだ。

そのケーブルには、モバイルバッテリーからPCに、あるいはその逆に電源が逆流しないような仕組みが欲しい。

あるいは、(上に少し書いたが、)換気扇を連続運転して外出して(部屋を無人にする)、部屋のCO2濃度を充分に下げられれば外に持ち出さなくて済み、補助給電可能なUSBケーブルなども不要だ。

試したら、長時間掛ければ行けそうな雰囲気ではある。 (グラフ: 右端近くで急に下がっている部分)

そもそも、どのくらいの頻度で較正すべきか調べたら、CO2Miniのメーカーのサイトの資料"AN131 – CO2 Sensor Calibration: What You Need to Know"には以下のように書いてあった。

How Often Should A CO2 Sensor Be Calibrated?

The more accurate CO2 level reading required, the more often it should be calibrated.
・ Scientific Experimentation – Before each test
・ Personal Safety – Weekly to monthly
・ Greenhouse – After each growing season
・ Manufacturing – Bi‐Annually to Annually
・ Indoor Air Quality – Annually, or not required if ABC is used

OEM品であろうCO2Miniが上と同じでいい保証はないが、ある程度の目安にはなる。僕は"Indoor Air Quality"レベルでいいので、年に1回(多くて半年ごと)で良さそうだ。

また、上の資料には経年変化の影響も書いてあり、

Over many years, both the light source and the detector deteriorate, resulting in slightly lower CO2 molecule counts.

と、「ちょっと低くなる」という感じなので、2波長センサで出荷前にメーカーで検査している前提であれば、余りシビアに考えなくても良さそうだ。

製品選びにまつわる クソおもしろくない話

(以下、「営業妨害」とか言われると面倒なので、会社名などは書かない。)

証拠のない機能・仕様を うたっている会社があった。センサ(素子)メーカーが公表していないことが書いてあっても信用しにくい。今まで書いてない機能が実装されていたことは ほとんどなかったから(あって価値が上がるものを書かない理由は ない)、逆に不信感が増す。例えば、そのセンサを分解して内部の写真を示すとかメーカーからの情報を載せるとか すればいいと思うが、なぜしないのだろう?

質問に回答しない会社があった。買わないと質問すらできないようで(そういう返事すらなしで単に無視された)、まあ、論外なので止めたほうがいい感じだ。

経産省のガイドラインに助言した人が、実はガイドラインの対象となる製品(CO2センサ)を出しているメーカーの関係者だったということもあった。更に、正体不明とも思えるページ(ページを出している会社名などが書いてない)で製品を紹介していたり(ステマ的に思えるが、あれは広告なのか?)、そこでも自分が関わった製品を所属大学の肩書(メーカーの関係者とは書いてない)で推薦していたり・・・

「息の掛かった」とか「お友達」ってやつ? どこにでも居そうだけど、大嫌いだ。

全体的に、コロナ需要で急に参入したとか、ガイドラインが出てから、従来は半導体(化学)センサだったものを急にNDIRセンサに換えたもの(もちろんC国製)が多く、眉唾が多い印象だった。

製品企画時点でのユースケース・仕様・機能の検討が不充分なものも多い。単に「組み合わせて動いたから売ろう!」みたいな・・・

安いとは言え測定器なので、精度などの検証や長期的安定性などの評価をすべきだが、そういう情報を根拠(エビデンス)も一緒に載せていないのは おかしい。それ以前に、精度などが書いてない(分解能は ある)かセンサ(素子)の仕様を転載しているだけ(= 自分で測ってない?)の製品が多く見られるのは おかしい。もっと真面目にやれって思う。

 

まあ、「魑魅魍魎が跋扈」って感じかも知れない。もちろん、個人的印象である。

  •  1
  •  0

(部屋の異臭問題のまとめを投稿してからと思って居たが、もう少し様子を見る必要があるので、こっちを先に出す。)

そもそも読者が少ないうえにニッチなものだからニーズは ほとんどないと思われるが、他を探しても僕の欲しい機能のものがなく(開発当時)、自分では便利に使っているので、(他の作業が一段落したこともあり、)公開したくなった。そのための作業が結構あるのと体調が今一つ不調なので、とりあえず予告を。夏(が終わる?)頃までには出したいと思っている。

もし、「すごく欲しい!」という方がいらっしゃったり、質問がございましたら、「いいね」を押して下さるなりコメントして下さると励みになります^^

概要

AndroidスマフォをPCの近く(実際にはルータに繋がるところ)に置いておけば、撮影した写真などを自動的にPCに取り込み、"年/四半期/日"のディレクトリに振り分ける。

「Google Photosのローカル版みたいなもの」と言えそうだが、ほとんど使ったことがないので良く分からない。

外出時に撮影した写真は帰宅して少し(5-30分くらい)経てば自動的にPCに入り、(小さい家では、)家の中や周囲で撮った写真も同様に、撮るそばからPCに入る。

スマフォ以外では、USB PTP対応のデジカメなども、PCに接続すれば自動で取り込まれる。

取り込んだ画像には「新規画像」を示すEXIFのタグ("New")が付くので、画像管理ソフト(例: digiKam)のタグで分類する画面を開けば容易に区別できる(下を参照)。

スマフォの写真をPCに自動取り込み後、digiKamで新規画像(タグ: "New"で識別される)が表示されている画面

なお、新規画像の整理や後処理が終わったら、上記のタグの設定を解除すれば(新規には)表示されなくなる。

主な機能・仕様

  • スマフォやデジカメなど(以下、デバイス)から新しい画像など(以下、メディア)を(可能な場合は自動で)PCに取り込む。
    • 前回最後に取り込んだものの次から取り込む。
    • スマフォなどWi-Fi対応デバイスの場合は、定期的に自動で取り込む。
    • USB接続デバイスの場合は、PCに接続したら自動で取り込む。
      • 現状はPTPのみ確認済み。
  • デバイスの接続方式
    • Wi-Fi (正確にはLAN)
      • Wi-Fi経由で定期的に(約5-15分間隔)自動でチェックする。
      • デバイスがルータに繋がったら自動で認識する。
        • 正確には、上記のチェック間隔でデバイスが接続されているか調べる。
      • ルータへの接続または新規メディアの生成後、だいたい5-30分くらいで新規メディアが取得される。
        • スマフォがスリープしていると取得は遅れるが、取り込まれないことは滅多にない。
    • USB
      • デバイスをUSBでPCに接続したら自動で取り込む。
        • 実際にはLinux(UbuntuかLinux MintかThunarかその他か不明)の仕組み(リムーバブルドライブとメディア)を使って開始する。
  • 取り込みのモード
    • 自動取り込み
    • 手動取り込み
      • 取り込まれるのを待てない場合に利用可能。
      • PCからの開始とスマフォからの開始の両方が可能
  • 取り込んだメディアの処理
    • 元々のファイル名に固有のID(整数)を追加し、複数デバイス間のファイル名の競合を防ぐ。
      • IDはデバイス情報(機種名, シリアル番号)と親ディレクトリ名(例: 100SHARP)から生成する。
      • 例: DSC_6328_2964489332.JPG
    • 年/四半期/日のディレクトリに振り分ける。
      • 例: Pictures/2022/2022_04-06/2022_05_26/
      • 年の次が月だと細かいので四半期にした。
    • タグを付けて、画像管理ソフトで新しい画像を識別可能にする。
      • 画像管理ソフトdigiKamがタグとして認識する"Subject"に"New"を設定する。
      • 注: EXIF(XMP)の格納できないメディア(例: 動画)にはタグは付けられない。
  • 対応メディア
    • 静止画, 動画, オーディオ
  • PC画面での表示
    • 自動取り込みモードの場合、取り込み完了後に簡単な通知(数秒で消える)を出す。
      • 取り込みが失敗した場合は、取り込み経過(ログ)を表示するウインドウを出す。
    • 手動取り込みモードの場合、取り込み経過(ログ)を表示するウインドウを出す。

動作環境

  • PC: 古過ぎないデスクトップLinux (Ubuntu 20.3 LTS, Linux Mint 20.3など)
    • 動作確認済み環境
      • OS: Linux Mint 20.3 Xfce
      • 画像管理ソフト: digiKam 7.3.0
  • スマフォ: 古過ぎないAndroid (sshdアプリが動くもの)
    • 推奨sshdアプリ: SimpleSSHD
    • 動作確認済み環境: Android 9 (シャープ AQUOS sense lite)
  • Wi-Fiルータ: スマフォを使う場合に必要。
    • スマフォとPCは同じセグメントに繋がっていること。 → その後、(別件で)別セグメント(「ルータの向こう」)でも可能にできた。 (6/2 17:43)
    • 動作確認済み機器: I/Oデータ WN-SX300GR
  • デジカメ: USB PTP対応のもの
    • Mass Storageからの自動取り込みは未確認(実装した気もするが忘れた)。
    • メーカー独自規格の通信方式は不可。
    • 動作確認済み機器: キヤノン IXY digital 3000IS
      • iPhone 6sやNexus 4も対応しているはずだが、昔のことなので現在は不詳。

補足

「ソフト」と書いているが、実際には単一のものでなく、複数のプログラムなどからなるので「システム」と呼ぶほうが正しいが、そこまで大掛かりでもないので こうした。

そんな訳で、個々のプログラムの名前はあるが、全体としての名前がないことに、今気付いた。

 

PS. そもそもはWindowsを使っていた時にキヤノンの画像取り込みソフトとACDSeeを使っていたのだが、Linuxに移っても同様の手順・使い勝手を実現したくて(既存のものを探し・試したが いいものがなかったので、)USB版の画像取り込みプログラムを作ってdigiKamと組み合わせ、その後スマフォ(USB接続)に対応し、更に、スマフォ側でAutomagicのスクリプトを動かしてWi-Fi経由で自動で取り込めるようにし、Automagicのディスコンに伴って不要にして今に至る。

PS2. 書いてから、「別に予告なんてしなくてもいいじゃん(単なる自己満足だよ)」と思ったものの、中学の先生が、「すること・しようと思っていることを予め周りに言うと、(しなくちゃならない状況になって、)本当に実行できる」というようなことを言っていたのを思い出したので、そういう意味で この予告は意味があるのだろう。

(以前にも書いた気がするが、)その先生には いろいろ話したいことがあるものの、結構昔に亡くなってしまったので、もう同窓会などでも会えないのが残念だ。

  •  0
  •  1

(TVは観てないけど)「ナレ死」と似たような感じ、あるいは、仕事じゃないけど状況報告みたいに、今までに書いたことで単体にするほど大きくない、いろいろな「その後」(現状)をまとめて書く。

 

換気扇制御システム (間欠運転リモコン)

自画自賛だが、なかなか便利なものを作ったと実感している。特に、PCのGUIでリモコン操作(動作モード(= 換気の強さ)の変更、指定時間連続onなど)できるのが良い。なお、念のため(C国の製品や自分を信じ過ぎちゃいかん)、定期的に過熱などの安全面を点検しているが、今までのところ問題はない。

そして、自分で作ったものだけど、大分、使い方のコツとか丁度良さそうな設定が分かって来た。

  • 今は、換気扇のon/off周期30分、on率23%(on: 7, off: 23分)を通常動作にしている。
    • それまでは周期を45分にしていたが、後述のように、周期が短いほうが換気具合が平坦に近付くと考えたためである。
  • 空気が悪い感じがするなど、ちょっと換気したい場合は、15分くらい連続して回すと大体は良くなる感じ。
    • 思い付きの値だが、丁度いいようだ。
  • 追って別の稿に書く予定ではあるが、外が臭い場合には換気を停めたほうがいいことに(再度)気付いた(以前にも気付いた気がするが、忘れて居た)。
    • これは難しい。部屋に臭いが入ってから停めると臭いが排出されないように思うので、事前に検出する必要がある。。。
    • 次善の策は、部屋に臭いが入ったら、しばらく(外の臭いが消えるまで)換気を弱くすべきなのかと思っている。
  • 以下、周期に関する技術的な考察
    • 周期(= on+off時間)が短いほうが、換気具合が平坦に近付き、空気の質(例: 室内のCO2濃度)も安定すると推測する。
      • 平均して同じon率の周期でも、周期が長いと、例えばCO2濃度の変動が大きくなる。
      • PWMやD級アンプや1ビットDAC(DSD)の周波数が高いのと同様に、周期を短くすることは換気扇をon率と同等の強さで常時回すのに近付く。
    • ただ、周期が短いとon/off頻度が増えるので、タイマーのリレーや換気扇の寿命が短くなる。
      • 換気扇については、推測だが、on/off頻度が高いと突入電流が流れる回数が増えるため、モーターのコンデンサの劣化が速まるのではないか。
        • 一方、そもそも このような自動間欠運転は想定されていないだろうから、自動運転するだけで寿命が短くなるので、周期の長さは大きな問題ではなさそうだ。
          • 周期が30分の場合、一日に48回もon(/off)するのと同じだ。業務用ならまだしも、家庭用の換気扇は そういう想定では ないのではないか。
            • ただ、トイレの換気扇とすれば、例えば5人家族で1人1日8回使うとすると、on(/off)される回数は40回/日と近い値になる。でも、8回/日は多いか。

例によって できただけでは飽き足らず(単に遊びたいだけw)、以下のような思い付きがあるが、実施するかどうかは不明・未定である。

機能追加・拡張案1: リレーの状態の取得

少し前に、PCからタイマーの現在のリレーの状態(onかoffか)を取得する方法を考えた。ただ、おもしろいけど結構面倒で、やる意味があるか不明だ。

概要: PCとタイマーが通信していない時に、リレーのon/off状態をシリアルの信号線(例: PCのRXD(受信データ))に出力し、使っているシリアルインタフェースIC(FTDI)のGPIO的な機能を使ってそれを読む。

このシステムでは、PCからコマンドを送らない限りタイマーからデータは来ないので、通信していない時にシリアルの信号線が通信プロトコル上正しくない状態になっても、(PCはそれを分かっているので)問題は起こらない。

機能追加・拡張案2: 換気扇の重複運転の防止

トイレの換気扇が動いている時は、本システムが制御する風呂の換気扇を停める仕組みも思い付いた。仕組みは簡単だが、これも やる意味があるか不明である(せいぜい、窓に張ったシートの張力を抑制できる程度)。

トイレの換気扇がonの場合、風呂の換気扇を制御しているリレーをonにしないように(あるいは、トイレの換気扇がoffの場合だけリレーをonにする)すれば良い。

簡単だけど、AC100Vが絡むので安易にはできない。

機能追加・拡張案3: リモコンの通信の無線化

これも、上と同様に やる意味があるか不明(現状の有線接続で見栄え以外の問題はない)ではあるが、興味はある。

以前も書いたようにWi-Fiモジュールを買えばいいが、いろいろ面倒なので、古いスマフォを使いたい。が、それも結構面倒そうだ。

一番面倒なのは、古いスマフォは電池が駄目になっていることだ。電池が寿命になったあとで交換品を買ったが、不良品か詐欺で使えなかった。今は ほとんど売っておらず、それらを買っても使える確証はない。

あ! 書いたあとで思い付いたが(無線でなく)有線でも、昔 流行りそうで ぽしゃった、ACの線を使うLAN(PLC)なら良さそうだ。けど、アダプタはもう売ってない うえに、あっても高そうだ。でも、このシステムは速度は全く要らないから、もし安く手に入れば手軽でいいかも知れない。

とは言え、LANなので相手(タイマー)側はシリアルでは済まず(小さいPCやスマフォが要る)、そこが面倒だ。「ACの線で繋がるシリアル」は見た気がするが、高い・・・

 

温度センサの補正式の調整

少し前から中・高温域の補正式を調整している。今は大体27.5℃くらいまでできている。なかなか暑くならないので進みが遅いが(ただ、完全に暑くなると温度の上昇速度が大きくなって、参照用温度計との応答速度の差が大きくなるから難しい)、もう少し経つと本格的に暑くなって終わりになりそうだ。

と書いていて気付いたが、今日は暑くて冷房していたから、やればできたかも知れない。ただ、昨日(冷房せずに)作業していたら夕方には弱い熱中症みたいになったし、夜に暑くて目が覚めて冷房したので、連日は避けたほうが良さそうだ。

去年の夏に合わせた温度計算式が今も有効なようで、大体27℃以上は補正の調整が不要になる感じだが、そこで(いかにもデジタルにw)階段的に切り替えはできない(そうすると、切り替え点付近の値が不安定になる)ので、もう少し測定して「うまい具合」の補正式にしたい。

 

高血圧

なぜか、去年の今頃より低い感じで、通常量の降圧剤を飲むと、朝の「上」が125mmHgくらいになることが多い。

  • (もう少ししたら書く予定だが、)外からの異臭(煙草・薬品・農薬臭)が随分緩和できたために良くなった? 単に暖かくなったせい?

血圧が低い時に降圧剤を飲むと調子が悪くなるので、半分にして飲んで居る。

  • そうすると、 朝の「上」は130mmHgくらいになる。
  • 以前は、低い時は飲むのを止めていたが、低いのが続くなら半分ずつ毎日飲むのが良さそうだと考えた。
  • 今後も低い状態が続くなら、医師に言ってみる予定。

 

白内障・飛蚊症・老眼

当然ながら、白内障も飛蚊症も良くは ならないが、悪化もしていない気がする。が、室内での見え方(特にディスプレイ)が今一つ(飛蚊症が邪魔)だ。

  • 真上に照明があるのと、真横の窓が眩しいのも関係あるかと思っている。
    • メガネのレンズとの関係もある気がする。
  • 眩しい窓対策
    • (これもあとで書く予定だが、)一部のレースのカーテンから臭いが出るようなので、しばらく(臭わない)1枚にしていたが、やっぱり眩しいので、臭わないものを買って追加した。
    • カーテンを2枚重ねて付ける・フックを延長する工夫
      • 以前は、1枚目(外側)のカーテンのひだに2枚目のカーテンのフックを掛けていたが、もっと確実な方法を思い付いた。
        • いつものように、寝ている時に思い付いた気がするが、下に書いたように、作業している時に思い付いたのかも知れない。
      • 1枚目(内側になる)用のフックのカーテンを付ける部分の底部に2枚目用のフックを引っ掛ければ良い。フックだけあれば、金具やテープなど何も要らない。それぞれのカーテンの取り付けは斜めになるが、レースのような薄いものでは問題なさそうだ。
        • 2枚重ねる前に、丈の短いカーテンをなるべく下に付けようとしている時に「発見」した。
          • なので、上のフックにのカーテンを付けなければフックの延長となり、1枚を下げて付けられる。
        • これを思い付いた切っ掛けは、2枚重ねる方法を改良しようとして、その前にカーテンを下げるために延長したフック(下を参照)を見たら、延長のために付けた上側のフックにもカーテンが掛けられることに気付いたことだ。
      • これを思い付く前は、1枚目用(実際にはダミー)のフックの底部近くにダクトテープで2枚目用のフックを貼り付けて延長していたのだが、もう一組(別の窓)分作るのは面倒だし、弱そうだし、高さの再調整が困難なので、もっといい方法がないかと思って居た。

白内障に戻ると、昨日か今朝か、有名人(知らない人)が、手術して視界が かなりクリアになったという話を目にして、手術の怖さが少し減った。あと、僕は まだ濁って見える訳ではない(日光が眩しいのと左右の見え方がアンバランスになることがある程度)ので、「もう少し」余裕がありそうだと少し安心した。だから、そういう体験談は意外に有用な感じだ。

老眼は進行したかどうか不明だ(近視は進んでいない)。相変わらず老眼鏡は作っていない。近視用でも2本(普通用と自動車運転用)あるから それ以上は持ちたくないのと、遠近両用は今一つという話が多いし、実際に仕組みをみると無理があるからだ。

そのため、近頃は、近くの物を見る時に、眼鏡を外す以外に少しズラしてレンズの下や上から見るという、いかにもジジイ的なこともする。(でも、一人の時だけしかしないはずw) これ、目には悪いのだろうか? 筋肉的なもので、多くなければ問題ない?

 

(主に寝ている時の)動悸・頻脈

結局、原因不明で、余り変化(改善)なし。

  • お酒は多少関係ある(飲むと、その夜は確実に動悸・頻脈が起こる)。
    • ただ、飲まなくても動悸・頻脈が起こることも多い。
  • が、コーヒーは関係なさそう。
    • それでも、飲み過ぎは良くないので、以前よりは減らしている。
  • やはりSAS?
  • 日中もある。

ある記事で、夕食・飲酒後に体温が下がらないうちに寝ると自律神経が狂う(→ 動悸・頻脈などの原因にも)とかいうのを見たが、遅くまで起きてから寝ても変わらなかった。そもそも、起きているのが辛いw

体温と言えば、昨夜は暑くて目が覚めた(その時は動悸が強かった)が、冬でも暑くて動悸が起こるのだろうか? そこまで暖房は効かせていなかったが。

ただ、自律神経の問題かも知れない気はする。あるいは更年期的なもの?

 

耳の不調(突発性難聴・メニエール病 → 耳閉感・耳鳴り)

この時期(5月の連休明け辺り以降、夏まで?)は心身の調子が狂うようで(結構前から毎年同じように不調になる)、右耳も調子悪い。: 耳鳴りや軽い耳閉感が続いている。

  • 毎年のように起こり、時間が経つと治るので、医院には行かない。
  • 気にしすぎて振り回されるほうが良くなさそうだ。

 

鳩問題

(書いたあとで思い出したので、ついでにw) ベランダの鳩よけ網は まだ問題なさそうだ(外からの臭い対策でシートで窓を塞いでいて簡単にはベランダに出られないので、詳しい確認はできない)。たまに近くで鳴き声がしたり、窓の前を横切る影が見えるが、隣に巣を作っているのかも知れない。鳩は長生きだということなので、しばらくは そうなのだろう。

鳩の他にコウモリ(暖かくなって増えて来た)も防げている。あと、以前飛び込んできた小鳥は、あれ以来来ない。学習したのか、最初のは事故(勢い余って?)だったのか。その種類の鳥は元気なようで、たまに金具(換気口?)でカチャカチャ音を立てたり、朝賑やかに鳴いているが、そういうのは害でないから嫌ではない。たまに車に糞を落とすようだが、コウモリの尿よりは少ないので、まだ良しとしている。

 

車のオイル・フィルタ交換に気乗りしない問題

更に本当についでに。以前ちょっと書いただけだと思うが、いつも行っているディーラーの系列店の板金作業の不始末で、いつものディーラーすら嫌になり、本来は(確か)2月にするはずだった予定を延々と延ばしている。今日も予定には入れたが行かず仕舞いだ。来月後半から12か月点検の時期なので、それと一緒でも いい気すらしている。

その店は近くないが、以前は多少だるくても、「あのおっちゃんが居るかもなあ」と思って行ったが、今はそんな気分は全然起こらない。。。

そう言えば、その(いつもの)店には以前から数回トラブル(大小)に見舞われていることを思い出した。とは言え、僕の経験上、その店以上に いいディーラーは滅多にないのも事実なので、どう折り合いを付けるかだ。

本当に、プロの癖に いい加減なことをする店や連中には関わりたくない。時間もイライラも、無駄でしかない。

 

こうして見ると身体の不調の話が多いが、歳を取ったせいとか原因不明のものが多いから仕方ないね・・・

身体の不調(不調と言うよりは「劣化」)と言えば、他にも気になることはあるが、新しいものなので別途書きたい。

 

PS. ここに書いてないもので初出時は未完だった件でも、その後決着したものは その稿に書いてあることが多い。ただ、探すのが面倒で不親切ではある。

  •  1
  •  0

先日気付いた(というか、それまでは「まあいいか」にしていた)、バックアッププログラム(duplicacy)が使うクラウドストレージの認証情報とバックアップデータの暗号鍵(以下、認証情報)が平文で保存されていた件。デスクトップはGNOME keyring(以下、GKR)を使って何とかできたが、サーバが難しかった。

というのは、デスクトップと違ってサーバには通常はログインしないので、GKRをアンロックする(= パスワードを入れる)契機がないのだ。前回書いたように、そのパスワードをサーバに安全に保存するのは難しい(それを暗号化して保存するとしても、そのための鍵・パスワードをどうするかになって、キリがない)。

「普通」は どうしているのか気になるが、少し調べても分からなかったので(前回書いたように、今だとTPMを使っているのかも知れない)、自分なりに何とかした。

以下のような骨組みにした。

  • デスクトップと同様に、クラウドストレージの認証情報はGKRのキーリングに保存する。
    • キーリングのパスワードはサーバには置かずに管理(記憶または保管)する。
  • サーバが(再)起動後はキーリングがアンロックされていないので、認証情報を使うプログラム(具体的にはクラウドストレージへの自動バックアッププログラム)は失敗する。
    • 失敗するとメールで通知が来る。
    • サーバは基本的には再起動しないが、自動更新の内容によっては再起動する。
      • 再起動はそれほど頻繁ではない(ただし、連続する場合もある)。
  • 失敗の通知が来たら、僕が手で(デスクトップから)サーバのキーリングをアンロックする。
    • アンロックするまで自動バックアップされないが、バックアップは数時間ごとなので、僕が「ちゃんと」して居れば大きな問題にはならない。
    • 今はありそうもないが、長期の外出中にサーバが再起動した場合などにはアンロックできずに問題になりそうなので、その時に考えたい。
      • アンロックするには、パスワードがあってサーバにsshできればいいので、いざとなればスマフォでもできそうだ。
        • → 試したらできた。: Androidのターミナルアプリ(Termiusを使った)でsshでサーバにログインし、アンロックプログラム(gkr-unlock.sh)を起動し、パスワードマネージャ(KeePass)からキーリングのパスワードをコピー・ペーストして入力すれば良い。最後の方に載せた画面例と同様の操作である。 (5/24 9:09)

上の仕組みを実装し、どうにか動くようになった。細かい点を以下に書く。

  • デスクトップと異なり、認証情報はGKRのログインキーリング(以下、キーリング)に格納される(デスクトップはデフォルトキーリング)。
    • GKRの仕組みを完全に理解していないせいもあるが、seahorse(GUIアプリ)を使わずにアンロックできるのは、(現在は)ログインキーリングだけなので、仕方ない。
      • gnome-keyring-daemon --unlockでログインキーリングをアンロックする。
      • 昔は任意のキーリングをアンロックするプログラム(pam-keyring)があったようだが、なぜか なくなってしまった。
        • GNOMEのLibsecretのAPIを使えばできそうで、試したらデフォルトキーリングのアンロックはできたが、「ちょっと試す」以上だと複雑かつ情報が少なくて、任意のキーリングについては途中で挫けた。。。
    • 認証情報はデスクトップのデフォルトキーリングの用法にならい、属性serviceとusernameで種類を識別・区別できるようにした(要するに、同様に格納した)。
      • サーバではseahorseが動かないので、キーリングの初期化と認証情報の格納にはgnome-keyring-daemonとsecret-toolを用いた。
      • 以下の手順でキーリングを初期化・格納した。
        1. 既存のキーリング(~/.local/share/keyrings)を使わないなら削除する。
        2. dbus-launch --sh-syntax のようにしてdbus-daemonを起動する。
        3. 上で表示された文字列(DBUS_SESSION_BUS_ADDRESS=...を実行して、Dbusの環境変数を設定する。
        4. echo -n パスワード | gnome-keyring-daemon --unlock のようにして空のキーリングを作り、パスワードを設定する。 (既存のキーリングの場合は単にアンロックする。)
        5. secret-tool store --label="ストレージ名" service アプリ名 username ストレージID のようにして、それぞれの認証情報を格納していく。
    • 作成したキーリングをアンロックするプログラム(gkr-unlock.sh)は、アンロック後、GKRにアクセスするのに必要なDbusの環境変数(DBUS_SESSION_BUS_ADDRESS)をファイルに保存する。
    • この辺りの基本処理のコードを以下に示す(実際とは若干異なる)。dbus-launchがGKRにアクセス可能なDBUS_SESSION_BUS_ADDRESSを設定するので、それをファイルに保存する。

echo "$PW" | dbus-launch
sh -c "gnome-keyring-daemon --unlock -d -r;
echo export DBUS_SESSION_BUS_ADDRESS=
\$DBUS_SESSION_BUS_ADDRESS
> $dbus_env_save_file" >&- 2>&- &

※見やすくするため改行したが、実際には全部が1行である。

$PWには あらかじめ入力したキーリングのパスワードを、$dbus_env_save_fileには環境変数を保存するファイルのパスを格納しておく。

  • 認証情報を使うプログラムは、secret-toolでキーリングにアクセスする。
    • デスクトップと異なり、Dbusの環境変数が設定されていないため、そのままではアクセスできないので、環境セットアッププログラム(setup_dupl_agk.sh)経由で起動する。
      • デスクトップのcrontabでの実行時も同様なので、デスクトップと同じ環境セットアッププログラムが使えるようにした。
    • 環境セットアッププログラムは、上記のキーリングをアンロックするプログラムが保存したDbusの環境変数を読み込み・設定・exportして、目的のプログラムを起動する。
      • なお、dbus-daemonやGKRを起動したユーザー以外(具体的にはroot)はGKRにアクセスできないようなので、バックアッププログラムが使うクラウドストレージの認証情報をキーリングから取得し、環境変数に設定・exportしてバックアッププログラム(duplicacy)が使えるようにする。
        • duplicacyは、設定ファイルやGKRだけでなく、環境変数からも認証情報を取得できる。
      • Dbusの環境変数を保存したファイルは再起動すると なくなるので、再起動後は自動的に失敗する(古い無効な環境変数でアクセスして、おかしくなることはない)。
  • デスクトップからは、サーバのキーリングをアンロックするプログラム(gkr-unlock.sh: サーバと同じもの)を実行する。
    • gkr-unlock.shは、sshでサーバに接続して、サーバ側のキーリングをアンロックするプログラム(gkr-unlock.sh)を起動する。
    • 基本的には、サーバでgkr-unlock.shを起動するとキーリングのパスワードを要求して来るので、(手で)入力してアンロックする。
    • ただ、毎回パスワードを手で入力するのは面倒なので、サーバのキーリングのパスワードをデスクトップのキーリングに入れておき、アンロックするプログラムはそのパスワードを自動で取得してサーバに送るようにした。
      • そのため、サーバのキーリングのパスワードを複雑なものにできる。
      • また、アンロック時はサーバにssh接続するための鍵のパスフレーズを入れるだけで良い(sshエージェントを使えばそれも不要になるとのことだが、それはしていない)。
      • sshエージェントを使えば、サーバの再起動を検知したら自動でアンロックすることも不可能ではないだろう。
      • そのため、サーバのキーリングのパスワードはパスワードマネージャ(Keepass)とGKRの2箇所に重複して保管されて管理の点で良くないが、利便性のためなので「仕方ない」とした。

いつものように、今回作ったGKRアンロックプログラムは思ったより複雑になった(その前に作った環境セットアッププログラムはもっと複雑だ)。僕が求め過ぎるためにそうなるのか、もっと単純・簡単な方法があるのか、今は分からない(そして、「ちゃんと使えれば良し」で そのままに・・・w)。

以下に、デスクトップからサーバ(ホスト名をserverとする)のキーリングをアンロックする画面(?)の例を示す(一部を変更した)。起動後、"Enter passphrase-"のところでssh鍵のパスフレーズを入れる。"bin/gkr-unlock.sh"で始まる行はサーバ側のアンロックプログラムの出力である。

$ ./gkr-unlock.sh server
./gkr-unlock.sh: Obtaining remote host server's GKR password: attrs.: service=gkr-unlock, username=server.
./gkr-unlock.sh: Executing on rem_host: server: bin/gkr-unlock.sh
Enter passphrase for key '/home/user/.ssh/server_id':
bin/gkr-unlock.sh: Enter GKR password (empty to abort):
bin/gkr-unlock.sh: Starting dbus-daemon and gnome-keyring-daemon...
bin/gkr-unlock.sh: Saved dbus-env. to /run/user/9999/dbus-env.
bin/gkr-unlock.sh: Succeessfully unlocked GKR.

DbusやGKRのプロセスを停めて基本的な確認はしているものの、まだ、実際にサーバを再起動して そのあとの復旧(再アンロック)手順に問題がないかを試して居ないので、何か問題が起こりそうだ。早目に再起動して確認・対処することもできるが、(面倒だしw、)通常はちゃんと動いているから 自動更新での再起動を待っている(そして慌てる)。

→ (5/26 6:40) 今朝、自動更新での再起動があり、(意外にも?)想定した復旧(再アンロック)手順で うまく行った。

 

セキュリティを改善できたものの、(詳しくないなりに考えると)気になることは ある。

  • 基本的にキーリングは常時アンロックされたままなので、システムに侵入されて、ユーザー権限が取得されてDbus関係の環境変数が分かれば、GKRに接続できて認証情報を取得できてしまう。
    • デスクトップでも同じことではあるが、サーバだと更に心許ない。
    • ただ、ユーザー権限が取得されても「大丈夫」なように防御するのは大変難しい(SE Linuxを使いこなす必要があるのではないか。それでも完全かは分からない)ので、「仕方ない」とした。
    • それでも、この対処をすることで、認証情報が平文で設定ファイルに保存されなくなったので、仮に設定ファイルが流出しても被害が少ないという点で意味がある。
      • まあ、本当に「最低限の対処」をしたということだ。
    • その点で、GKRを信頼し切って、全部の認証情報を格納する「パスワードマネージャ」として使うのは良くないと思う(実際に、僕はそうしていない)。
      • gpgにはアンロックのタイムアウトがあるので良いが、サーバでは使いにくい。
      • 書いたあとで思い付いたが、認証情報を使うたびにアンロックするようにするのがベターかも知れない。
        • その時のパスワードは、動き続けるプロセスが保持するようにする。そのプロセスのメモリを読まれない限り、安全だろう。
        • とは言え、ユーザの権限を取得されれば駄目だし、そのプロセスはアンロックされたままのGKRと同じことか。

サーバではないけど、スマフォの権限の制限がAndroidですら厳しい(僕にしてみれば「Linuxなのに何もできない」)のは、こういうことに起因するのだろうと思った。

それから、クラウドストレージに関しては改善できたが、気になるものは他にも いろいろある(例: ブログサーバプログラムの設定ファイル)。簡単にはできないので、いい案を思い付いて やる気があれば着手したい。あるいは、既存の何かがあるかも知れない。

まあ、まず、一般的なサーバでは「普通」はどうしているかを調べるべきかも知れない。

SE Linuxだけど、手に負えなくて「全部解除」とかいうオチだったりはしないよね?w

  •  0
  •  0

去年の夏に作った、YL-40の温度センサ(サーミスタ)で室温を測定する仕組みの続き。冬に低温での補正をしたが、予想どおり、その時に調整した範囲を超えたらズレて来た。本物の温度計と比べたら、25.5℃以上で、補正式の想定する温度差より0.3℃くらい低い(→ 温度計からは0.6℃くらい低い)感じだった。合わないのは嫌けど※、測定も調整も面倒なので延期して居たものの、段々差が大きくなったので 仕方なく先月の中頃に着手した。

※とは言え、そもそも、0.6℃くらいの差なんて「誤差の範囲」なんだから気にしなくていいという話(悪魔の声)もあるw

気分ならぬ気温次第でチェック・調整できる温度が決まるので なかなか進まなかったが、近頃は暑い日も出て来て大分進んだ。今日は室温が26.5℃くらいまでチェックできたので、去年の夏の出来上がった頃の温度(室温: 27.5-28℃くらい)まで もう少しだ。

サーミスタの温度の補正に関しては、素子の特性の温度変化(下を参照)以外に、基準として使った温度計(「シチズン大」)と温度センサの応答速度(熱容量)の違い、シチズン大の特性・精度、ADCの分解能や性能※や特性変動、それに、隣にあるディスプレイの熱の影響や空調とそれに伴う室内の気流も関係しているので、なかなか単純ではない。

※当初は、オフセットのグラフ(赤の点線)に見られる、不自然な変曲(屈曲)点はADCの性能(オフセット(上下)、直線性(曲がり)、変換精度(傾き))によると思って居たが、今はサーミスタの特性によるものかと思っている。

それでも、なぜか飽きずに(暇に飽かせて?)温度の測定・差のチェックと補正式の改良を続けて、どうにか満足できる感じになった。

冬には一つの直線で補正したが、(ちょっと前から薄々感付いて居たように、)それではうまく行かず、今は4つの直線で補正している。補正のためのオフセット(センサの温度に加える量)はグラフの赤の点線である。どうも、センサの特性に いくつかの変曲点があるようで、妙な形になっている。

書いてから思い出したが、冬に試行錯誤していた時、どうも19℃辺りに変曲点がある気がして2つの式にしていたが、それは不自然だと却下して1つにした。(グラフ: 黒の点線) 当時は低温だけだったので1つでも何とか合ったが、今となっては最初の勘が当たっていた。

補正パラメタの調整は、補正後の温度の線(グラフ: オレンジの直線)が上下に広がる測定点群の中央を通るように、あるいは、センサとシチズン大の温度差のグラフ(これは補正後の温度の線に沿って上下を拡大したものと等価である)で点群の分布が正負(上下)均等になるように、補正式(オフセット)が通る点を設定している。欲を言えば あと2本くらい増やしたいが、面倒なので しないで済ませたい。プログラムの作りを、直線の本数(実際には、補正式が通る点の数)を任意に増やせるようにすれば少しは手間は減るだろうが、それも面倒だw

まあ、そこまでやるなら、きっと「うまい曲線」があるはずで、補正(オフセット)のグラフは いかにも良く見る形だけど どういう式かは浮かんで来ない。: 3次式を45°の軸でフリップさせた形? → 1/3乗の式? (← 似ては居るが、0付近が垂直になるので違うようだ。 ← 式の構成によっては そうでもなさそうだ。) だとしたらなぜ?

そこで画像検索してみたら、サーミスタのBという定数は温度で変わるので(だから、実際には「定数」ではない)、温度とBの関係を求めて正確な温度を求めている方が居た。だから、理想的な補正式(曲線)のグラフを描けば そういう(温度に対するBから温度の補正値を対応させる)形になるのだろう。※ 実際、参照したページの「図6:出力電圧から「変数B」と「定数B」でサーミスタ温度に換算結果」は僕の補正のグラフと何か関係ありそうな雰囲気だ。

※実際には、上の方法では正確な温度が直接求められるので「補正」する必要はなく、補正式のグラフも意味がない。

ところで、この方は どうやって任意の温度を生成しているのか分からないが(恒温槽?)、僕にはそれができない(実際には、現在と同様に いろいろな室温で測定すればいい)のと、補正式を作り直すのが面倒なので(こっちが大きいw)、とりあえずは現状のままにしておく。

温度域別のグラフでオフセットを比べると、低中温域(21℃くらいまで)は従来(グラフ: 黒の点線)と改良版(グラフ: 赤の点線)の差が小さいので問題なかったのだが、中高温域では差が大きくなって、最初に書いた「温度が合わない」問題と辻褄が合う。実際、23℃以上(→ グラフ)でのオフセットの差は大ざっぱには0.3℃以上で、(最初に書いた)僕の印象に合う。

改良版の補正式を使用したところ、現在のところは、(室温が急激に変化しない状態では、)シチズン大との温度差が概ね(ひいき目に見て)±0.3℃以内※に収まるようになった。

※測温系の分解能(ADCと回路構成に依存する)が約0.24℃なので、これくらいなら許せる。

夏に近づいて室温が28℃くらいまでになれば(、一周回って)、補正の調整は ひとまず終了だ。

が、上に挙げた、サーミスタのパラメタBを温度の関数として温度を求める方法が結構良さそうな気が しつつあるし、センサ類の経時変化や夏の測定方法が今一つだったかも知れないので、また差が出る気もしている。

まあ、その時はその時だ。

なお、Bを温度の関数として温度を求めるにしても、その式は僕の補正式を含めた温度計算式を滑らかにしたものに近いはずであるだろうから、現状からの大きな精度向上は期待できなさそうな気はする。今の温度差は温度計算式以外の要因(特に熱容量の差)も大きいと思うからだ。

 

 

PS. 本題には全く関係ないが、y= x1/3のグラフを探していたら、「y=1/3x二乗のグラフらしんですけど−」という質問(?)があって、僕だったら何を答えていいか分からないところを ちゃんと答えている方が居て感心した。

偉そうだけど、「これの何が分からないのか全く分からない」というのが正直なところだ。その質問を理解して教える教師は偉いと思う。ただ、その教え方(「考え方」)が学校式とか受験用の気がして、本当に実用になるのか疑問はある(もちろん、教師次第だろう)。

 

更に離れるが、上の前か後に、「実はE= mc2の"2"は1.9・・・とかじゃないのか」という質問に、正しいだろうが全然説明になってない、「当たり前のことだ。勉強してないの?」みたいな回答をし、その後、良くある訳の分からない深過ぎる話(δだの数直線だの間隔・連続だの)を書き連ねた人が居たが、そういうのが居るから物理とか数学が嫌いな人間が増えるのだと思う。

実際にグラフを描くと、E= mc2とE= mc1.99は全く違う(値になる)と思うが、式の見た目は近く見える。それに、上の木で鼻を括ったような回答の奴自身も「近似的に証明されている」とも書いているのだから、1.99・・・だったら かなり近いかも知れないではないか。(数学嫌いなので知らんけどw)

 

更に脱線して、別の質問「数学が特異な人たちは、こういう数式が分かるんですか?−」でもやっぱりオタ偉そうな人が多くて苦笑した。数学嫌いの僕は こんな面倒な式は理解する気は全くなくて、必要ならプログラムを書くだけだ。

しかも、この式には間違いがあるではないか(回答を読んで分かった)。なのに、気付かずに したり顔で偉そうなことを書く連中って一体???

あと、回答にあったが、これが誤差を計算するものなら、絶対値でなく2乗の理由が理解できない(全部の回答を読めばいいのかも知れない)。「幾何学的な性質」とか サラッと書かれても「は?? 何ですか?!」だよ!!

だいたい、以下は すごい違和感しかない。

誤差には正も負もあるので、打ち消しあってゼロになったりするのは困る。
だったらを2乗すればいい。
全部プラスの数字にして、それを全部足し合わせて、足した個数で割り算する。
もともと2乗していたんだから、ルートすることでもとに戻せば、1回あたりの誤差として使える

僕にすれば、正負で打ち消し合うのが困るなら、まず、絶対値だ。なぜか2乗して、それを加算したのをsqrtしたって元に戻るとは思えない(ここは すごく強引だと思う。: 2乗は非線形だから、そのあとに加算したものをsqrtして線形に戻るかって話だ。まあ、多くの専門家が何も言わずに使うのだから問題ないのだろうけど、それが本質的に問題ないのか、実用的になのかは重要だ)。それよりは、絶対値を加算して平均したほうが ずっといい(素直だ)と思う(実際、上の回答の2乗に関係する行(2, 4行目)を除けば、絶対値のほうが適しているのに、なぜ2乗なんてして処理を増やすのだろうか)。まあ、きっと何か理由があるんだろう。

僕は(正しかろうがそうでなかろうが、自分の用途に問題なく使えるのであれば、考えるだけ無駄・本質でないので)「そういうもの」として粛々と使うだけだ。

 

と、最後はなぜか 数学(が得意気な人)に対する怨嗟になってしまった。。。

  •  0
  •  0

少し前から気になっていたのだが、バックアップに使っているクラウドストレージの認証情報を平文で保存しておくのは良くないので、ちゃんとしようと思った。

ストレージに限らず、サーバのアプリ(例: 某有名ブログサーバ)では、時代遅れ(そのうえ、恥知らずにも長年弱いままにしている)にもID, パスワードをテキストファイルに平文で保存しておくものが多い。

ユーザの認証情報はDBに暗号化して(実際にそうしているかは不明)格納しても、DBのID, パスワードは平文という間抜けさだ・・・

(5/4 18:34) ブログサーバソフトの設定が暗号化できないか調べたら、やっぱりなさそうだ。それどころか、Stack overflowみたいなフォーラムで、ある人が「設定を暗号化しても使う時は復号化するだろうが。そこをハッキングされたら同じことだから無意味だ」みたいに回答していて苦笑した。

確かに文面としては間違っていないが、そういう1/0の考えをするなら、DBの暗号化どころかキーリング(以下参照)でもなんでも、すべての保護機能・手段が無意味・不要になってしまうが・・・ こういう輩が被害に遭うのではないか。

ちょっと考えたが、(面倒かつ重くなりそうだけど)設定にアクセスするところを改造すれば暗号化できるように思う。誰もやってないのは 不可能なのか興味ないのか。いずれにしても、「鍵をどうするか」(以下に書いている)っていう問題はある。

問題は、そういう情報を暗号化する(それ自体は容易)として、それを使う時には復号する必要があり、その暗号化・復号化のための鍵をどこに保存し、どうやって取り出すかである。誰でもアクセスできるようなところに保存したら、全く意味がない。特定ユーザ(のプロセス)に許可するとしても、それに成りすまされたら駄目だ。

調べてみると、「ログイン」のような操作をしないシステムでは暗号化して保存するのが難しい(復号する鍵をどうするか?)ので、上述のサーバの弱さは どうしようもない面があることが分かった(けど、多くのシステムは「それなりに」ちゃんとしているのではないか?)。

「ログイン」の操作自体が重要なのでなく、そのコンピュータの外(部外者が容易にアクセスできない場所: ログインの場合は、ユーザの頭(注: ポストイットの場合も多いw))に鍵を保管し、そこから鍵を入れることが重要なのだと理解した。

これは推測だが、Windowsは必ず(一度は)ログイン(ログオン)をするので、この辺りが結構うまく行っているのではないか。Windowsサーバは使ったことないが、普通のデスクトップではログイン情報を保存できるから、それに似たような感じなのではないか。ただ、保存したログイン情報の暗号鍵は どうしているのだろうか?

更に推測だが、その辺りはNTの時に苦労していたのかも知れない(昔、そんなことを本で読んだ記憶がある: 内部で抗争しつつ作ってたんだったか?)。

そういう訳で、デスクトップなら、前に書いた(その稿の暗号化の話は、この問題を考えていて思い付いた)GNOME keyringが使えそうだが、サーバでは難しい。

というのは、GNOME keyringは(デスクトップの)ログイン時にキーリングをアンロック(≒ 復号化)するが、ログインせずに動いているサーバではアンロックするタイミングがないからだ。

GNOME keyringの処理を少し調べてみたら随分原始的で、ログイン時に入力したパスワードをそのままアンロックする処理に送り込んでいるだけのようだ・・・

ここはもう少し賢く、パスワードのハッシュを比較するとか、認証サービスに問い合わせた結果でアンロックの可否を判定するとか やりようはあると思うが、遅れているのだろう。その辺りで使われているPAMには そういう上等な機能があるのだと思って居たが、そうではないのか、GNOME keyringが使っていないのか。

ところで、僕のデスクトップは自動ログインでログインする(パスワードを入れる)タイミングがないのに なぜか使えているので、不思議に思って調べたら、自動ログインの場合はキーリングのパスワードがなく(空)、暗号化されていないことが分かった。

実際に確認したら、キーリングは単なるテキストファイルで、普通に読めた。。。: 間抜け過ぎる!

そういえば、忘れて居たが、結構前に、ログイン後にダイアログが出るのが鬱陶しいのでパスワードを空にしたような気がする。 (← 良くやる「馬鹿なこと」そのもの!)

 

結局、デスクトップもサーバも脆弱だったというオチだった。それで(、まずはデスクトップを)どうにかしたくて考えたが、余りいい案はなかった。以下に書く。

  • × GNOME keyring以外(例: gpg)を使う。: 安全に鍵を保管する問題は同じなので無意味。
    • GNOME keyringでもgpgでも、TPM (Trusted Platform Module)の機能を使えばできそう(な気がした)だが、PCもサーバも非対応である。
      • ただ、TPMへのアクセスの許可はどうするのか分からない。それを保存したユーザならできるとかでは余り意味がない。これに認証が要るならログインと同じことだ。
  • △- [デスクトップ] 自動ログインを止める。
    • もしもの時に、家族がPCにアクセスできなくなる。
      • 一応、起動したあとで見るべき場所が分かるようにしているし、PC以外の手段も用意しては居るが、「面倒」とか「分からない」とかでアクセスしない可能性が99.9%と思われる。(その時は僕の手を離れているので、それでも良い。)
  • △+ [デスクトップ] GNOME keyringにパスワードを付けるが、自動ログインのままにし、ログイン後にGNOME keyringを最初に起動した時に入力する(ダイアログが出るはず)。
    • サーバでは、gnome-keyring-daemon --unlock にパスワードを入れればアンロックできるので、どうにかして入れれば良い。
      • なお、Xの動いていないサーバでは、dbus-run-sessionでgnome-keyring-daemonを動かす必要がある。
    • アンロックしない限り、キーリングを使うプログラムは動かなくなるが、(上記の)家族がアクセスできなくなる問題は回避できる(家族がアクセスするファイルは暗号化しないとする)。
  • △ [デスクトップ] 外付けUSBメモリなどに鍵を保管しておき、最初に読み込んでキーリングをアンロックする。
    • 盗難などに弱いが、自動ログインしている時点で脆弱なので良し?
    • サーバでも、最初(再起動後)にデスクトップから鍵を送るようにすれば、同様にできる。ただ、sshでアンロックするプログラムを起動するほうが楽かも。
    • 面倒な割に実効性は少ない?
    • ちゃんとやるなら、生体認証デバイスのようなものを使うのがいいのだろう。
      • 単なる思い付きだが、銀行の認証のようにスマフォで指紋認証できたら便利だがなあ・・・
        • でも、これは既にありそうなので、あとで調べたい。
        • → (既にあるものがなければ、)直接 スマフォの指紋認証を使うのは難しそうだが、スマフォから鍵を送ってアンロックするのはできそうだ(基本部分は自作の画像転送の仕組みが使える)。スマフォは指紋認証で開くので、間接的には指紋認証を通すことになる。PCだけでなくスマフォ、そのうえに この方式までハッキングされなければ、きっと安全だ(要確認)。 (18:31)

 

いつものように僕が間抜けなことを実感した。とりあえずは、GNOME keyringにパスワードを付けて暗号化し、ログイン後にアンロックしようと考えている。

どこまでしっかりすればいいか分からない(おそらく、どこまでやってもキリがない)が、とりあえずは、間違ったり予期せぬ問題で認証情報の入った設定ファイルが流出しても ひどいことにならないようにしたいと思っている。

その点でサーバ(で動かしているアプリ)は頭が痛過ぎるが、根本から駄目なものは(すぐには)どうしようもないから、デスクトップをやってから徐々に何とかしたい・・・

そこにSE Linuxが出て来るのだろうか? (すごく面倒だってことしか知らんけど) それに似たようなものにAppArmorがあり、使っているLinuxに既に入って居るが、どういう関係なのかは分からない。 (やっぱり、面倒だってことしか分かってないw)

 

(5/3 8:21) GNOME keyringにパスワードを付けて暗号化するのを試したら、いくつか思い違い(あるいは細かい情報)が見つかり、やろうとして居たことが容易にはできないことが分かった。

まず、デフォルトのキーリングが暗号化されている場合、ログイン時に自動でアンロックすることはできる。最初に入力したパスワードが保存され※、次回のログイン時にそれを使って自動でアンロックできる。ただし、(上に書いたように、)自動ログインの場合はできず、パスワード入力ダイアログが出る。

※パスワードはloginキーリングに入る。

そして、ログイン時にキーリングをアンロックする時、gnome-keyring-daemon --unlockで解除するのに指定するのはデフォルトのでなくloginキーリングのパスワードで、それはログインパスワードである。 (確かにそうで、都合良くデフォルトキーリングと思い込んでいた。)

 

それで、ログインまたは起動時にデフォルトのキーリングがアンロックできないと、それを使ういろいろな自動起動アプリに支障が出る(例: Evolutionはメール取得できない)ので、ひとまずは自動ログインを解除した。

ログインパスワードを外部から入れてloginキーリングをアンロックするとしても、ログインまたは起動時にタイムリーに入れないと不都合が起こって嫌なので、「スルっ」とできる方法やデフォルトキーリングの解除を保持する方法を考える必要がありそうだ。

本質でないところにも面倒があるな。

(5/3 19:44) 例によってしつこく粘り強く試行錯誤していたら、大分近づいた。: 自動ログインで起動したあとで、そうでない時のようにloginキーリングをアンロックして、デフォルトキーリングのアンロックを自動でできるようにする手順が分かった。以下のようにすれば良さそうだ。

  1. キーリングを使いそうなログイン時の自動起動アプリを停める。: 完全には無理だった(使っていそうなもの(以下に例を示す)を随分停めたが、まだ起動後にログインパスワード入力のダイアログが出る)が、何とかなる。
    • GNOME keyring daemon, seahorse, Vivaldi, Firefox, Spotify, Thunar, Dropbox, Evolution, Seamonkey, Joplin
    • 上の他に、Policy kitとNetwork Managerも怪しかったが、起動しなくなりそうなので試さなかった。
  2. 再ログイン(自動ログインを設定してreboot)する。
  3. 起動後、起動してしまったgnome-keyring-daemonを停める。
    • pkill -TERM -f gnome-keyring-daemon
  4. gnome-keyring-daemonにログインパスワードを入れて起動し、loginキーリングをアンロックする。
    • echo -n LOGIN-PW | gnome-keyring-daemon -r --unlock
      • 注: パスワードの最後に改行があるとアンロックに失敗する(が、エラーにならないので分かりにくい)。なので、キーボードから手で入力するとアンロックできず、うまく行かない。
      • gnome-keyring-daemonのオプション -r は不要だが、念のために指定した。
    • パスワード入力ダイアログを出す例
      • zenity --password | tr -d '\n' | gnome-keyring-daemon -r --unlock
  5. キーリングを使う(自動起動)アプリを起動する。
    • 例: seahorse, Evolution
    • 実際に使う場合はスクリプトで一括自動起動がいいか。

いろいろな落とし穴があって苦労したが、どうにかなりそうな感じだ(いろいろ作るのは面倒だが・・・)。デフォルトキーリングのパスワードは複雑なので入れるのは手間だが、ログインパスワードはsudoコマンドで いつも入れているから、それほど面倒ではない。それに、この方法なら、上に書いたような、スマフォからパスワードを入れるといった複雑な処理が不要になって好都合だ。

結局、最初にログインパスワードを入れるなら自動ログインでない場合と同じではないかと思われるが、そうではない。僕から見れば同じだが、(もしもの時に)家族が起動した時に、パスワードが分からなくてもデスクトップが開けて ある程度のことができる点が違う。できないのは、上の例に挙げたようなアプリを使う作業だが、そういうのは不要だし することもないだろう。

他に分かったこととして、dbus-daemonを停めるとデスクトップが終わってしまうことがある。以前から何度か、突然画面が真っ暗になって「全部終わり」になってしまうことがあったが、これだった(スクリプトの作成・確認中などに間違って停めてしまった)ような気がする。詳しくは分からないが、重要な要素なのだろう。

(5/12 9:03) 上の手順で使う自動起動アプリを起動するスクリプトの詳細を考えたものの、作るのとデバッグが面倒で保留(うだうだ)していたら、何も作らずに済ませる うまい手を思い付いた。

デフォルトキーリングにパスワードを設定して自動ログインで起動すると、デフォルトキーリングを使うアプリが起動した時点でデフォルトキーリングのパスワード入力のダイアログが出るので、それにパスワードを入れれば良い。: ごく当たり前の手順である。

アプリによっては、パスワード入力が遅いとエラーになる可能性もあるが、今のところは問題は起こっていない。

今までは、デフォルトキーリングのパスワードを複雑なものにして覚えられないから、ログインキーリングに(覚えている)ログインパスワードを入れることで済ませようとしていたが、デフォルトキーリングのパスワードを覚えられる・覚えているもの(例: 何かの使い回し)にすればいいのだ。

セキュリティ上は若干弱くなるが、そもそも自動ログインにしていること自体が弱いので、多少は目をつぶろう。

これで、残りはサーバの対処だ。やり方は分かっているものの、やっぱり面倒ではある。

 

(5/23 12:13) 一安心していたのも束の間、duplicacyのフォーラムを見ていたら、今まで気付かなかったduplicacyの脆弱性(正確には、仕様上のセキュリティの弱さ)が分かった。

Passwords, credentials and environment variablesの最後に

vkl Jan '21

Personally I don’t like the idea of storing Google Drive token as a plain text file. Is there any way to store it safely?

とあるが、回答がなく放置されている・・・ 別の稿にも書いたが、作者は今一つ良くない。こういう細かい(けど とても重要)ことが面倒な(セキュリティに関する良識・常識・知識が余りないのか、どうでもいいと思っている)のだろう。

上ではGoogle Driveだが、Google Cloud Storage(GCS)も同様で、URLとトークンがあればアクセスできてしまうはずだ。だから、トークンはパスワードと同じ位置付けで、平文で保存してはいけない。

最悪でないのは、GCSのトークンとduplicacyのストレージの暗号化パスワードは別なので、アクセスできても解読できないことだ。ただ、ファイル(チャンク)の削除などは可能だろう。

ちゃんと対処するにはduplicacyの改造が必要だが、それは大変だし保守が面倒になるので、もう少し容易な方法を試してみたい。例えば、duplicacyを起動する前にトークンをFIFOに格納しておき、1回だけしか読めないようにするとか、一時ファイルに格納して、duplicacyを起動して少ししたら(トークンが読まれた頃合いに)削除するとかだ。

他には、暗号化可能な設定ファイルにトークンを格納するrclone経由でGCSにアクセスすることも考えられるが、GCSに透過的にアクセスできるのか良く分からない。

段々、duplicacyの良くない点が見えて来た。。。とは言え、他にいいものがあるかというと、なかなかない。

(5/23 15:35) とりあえず、FIFO(実際にはduplicacyのstdin※)経由でGCSのトークンをduplicacyに送るようにした。以下のような処理にした。

  1. あらかじめ、キーリングにトークンの内容を保存しておく。
    • キーは (ストレージ名)_gcs_token_bodyとした。
    • 元のトークンのファイル(平文)は、安全な場所に保管してから削除する。
  2. duplicacyの環境設定・起動プログラム(別の稿の「環境セットアッププログラム」, "setup_dupl_agk.sh")は、ストレージがGCSの場合、以下を行う。
    1. duplicacyにトークンを指定する環境変数 (ストレージ名)_GCS_TOKENを"/dev/stdin"に設定する。
    2. キーリングからトークンの内容を読み込む。
    3. 読み込んだ トークンの内容をduplicacyのstdinに送るようにして、duplicacyを起動する。
      • duplicacyは環境変数に指定された"/dev/stdin"をトークンファイルとみなしてトークンを読み込む。

※stdinでなくFIFO(named pipe)でもduplicacyは動いたが、処理を簡単にするためにstdinにした。それに、FIFOはタイミングによっては他プロセスに先に読まれてしまう(奪取される)可能性があるが、stdinはプロセス固有かつ、書き込んだ側がそのプロセスを起動するので、他プロセスに先に読まれる可能性は かなり低い点で良さそうだ。

トリッキーで本当にできるのかと心配だったが、今のところは動いている。

そもそも、duplicacyが、トークン(平文)のパスでなく内容をキーリングから参照すればいいだけなのだが、なぜか そうなっていない。環境変数でも参照できるようにすることを考えると、長過ぎるからか。

  •  0
  •  0