Archive for the ‘Linux’ Category

換気扇の換気効果・能力を知りたくて、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

少し前に、スマフォ(AQUOS sense lite)の電池が減るのが速くなった気がして※気になったのだが、古くなって電池が劣化して来たためではないかと思い、また、実際に測定するとバラつきがあって以前の値になったこともあるので、その時は問題ないと考えた。が、実はそうではなく、本当の原因は分からないものの、思わぬことで電池消費率(= 消費電力)が増えることが分かり、意外な対処で解消できた(と思われる)話。

※アイドル状態で大体1%/h(→ 1日で1/4くらい減る)で、以前は もう少し小さかった記憶がある。

発端は、ニュース記事で、あるMVNOがIPv4(以下、v4)のグローバルアドレスを割り当てるのを止めてプライベートに できるようにするというのを見たことだ。今時、スマフォにグローバルアドレスを割り当てること自体が時代錯誤(どうして そんなに確保してるんだ?!)だが、それを(客の要望で)プライベートにするのもおかしかった。わざわざそんなことをする理由は、グローバルアドレスが割り当たっているとスマフォの消費電力が増大するという説※があるからだ。

※詳しくは知らないが、グローバルアドレスの場合、ポートスキャンなどで頻繁に外からIPパケットが来て、そのたびに端末が動いて電力を消費する(と推測されている)ためのようだ。その説が本当かは分からないが、いかにも腰が重いプロバイダがわざわざ対処するくらいだから、正しいのだろう。

僕のプロバイダはプライベートアドレスだから、それ自体は僕には関係なかったが、ふと、IPv6(以下、v6)が気になった。IPv6は全部グローバルアドレスのようなものなので、上のv4と同様なことが起こるのではないかと思った。

それでスマフォのモバイル(LTE)設定を調べてみたら、一時はv6対応にしていたものの、その後気が変わったらしくv4だけになっていた。それで、LTEのv6に関しては問題なさそうなことが分かった。

が、LTEでなくWi-Fi(光)でも同様な問題がありそうな気がした。スマフォのOS(Android)はv6対応で、ルータにはファイアウォール(仕様は不明)はあるものの、それを通過したパケットには反応する。v6のアドレスは幅広いのでポートスキャンのパケットが来る可能性は低そうだが、ルータやプロバイダなどの管理用パケット(そういうものがあるのかは不明だし、頻度も不明)やPCからのパケット(ブロードキャスト)は届きそうだ。

そこで、スマフォのLTEだけでなくWi-Fiもv4だけにして試したくなった。

ただ、AndroidのWi-Fiだけv6を停めることはできず、全体のv6対応を停められるかはメーカー依存のようで、僕のは不可能だった。そうするとルータで切ることになるが、僕のルータ(I/Oデータ WN-SX300GR。以下、I/Oルータ)は普通の家庭用のものなので、LANポートごとどころか全体でもv6のon/offができない。※ もちろん、LANポートごとのフィルタリングもできない。プロバイダに頼んでIPoEからPPPoEに切り替える手はあるが、時間が掛かるうえに全部がv4になるため、PCまで遅くなってしまう。

※そもそもIPoEモードで使っているので、普通は そこでv6を停める意味がない。

そこで、もう一台、v6非対応のルータを使うことを思い付いた。手持ちの古いルータはv6非対応なので、元のルータにその古いルータを繋ぎ、古いルータのWi-Fiにスマフォを繋げばv6がカットされる はずだ。

実際には、古いルータでなく、消費電力が小さいため、死蔵していたコンパクトWi-Fiルータ(TP-Link TL-WR802N, ルータモード。以下、TP-Linkルータ)を使った。v6対応だが、非対応にできるので使えた。

以下のような構成・接続である。

WAN → [I/Oルータ] → [TP-Linkルータ (v6 off)] Wi-Fi → [スマフォ (v4)]
(光, IPoE)              +→ [PC (v4/v6)]

主な設定

    • I/Oルータ: スマフォが誤って接続することがないように、Wi-Fiをoffにした。
    • TP-Linkルータ
      • WAN(I/Oルータ)側: デフォルトルータとDNSサーバをI/Oルータに設定した。
      • LAN(Wi-Fi)側
        • DHCPサーバ設定(スマフォへ): デフォルトルータをTP-Linkルータに、DNSサーバをI/Oルータに
    • PC: スマフォへのルーティング設定(スマフォのセグメントへのルータをTP-Linkルータに)を追加した。

この構成は、良く駄目だと言われている「2重ルータ状態」だが、意外にメリットがあるのかも知れない。僕はスマフォの通信速度は全く求めていないから、これで全く問題はない。

試したら、確かにスマフォの消費電力が減った。大体0.2%/h減った。: それまでは0.8-1%/h辺りだったのが0.60-0.75%/h辺りになり、以前のような減り方になった。

次に、ルータとスマフォのWi-Fi接続の問題の可能性も考え、TP-Linkのルータをブリッジモードにして試したところ、消費電力は減らなかった。ブリッジモードはv6のパケットも通すので、予想通り、v6が原因の可能性がありそうだ。

とは言え、v6が原因でスマフォの消費電力が増えるというのは どうにも腑に落ちない。上述のv6パケットが(頻繁に)来る以外に、そもそもAndroidのv6の処理が重くて負荷が高いのかも知れない。スマフォが古いのでCPUパワーが追いつかないのか。

他に考え付くのは、スマフォとルータとの「相性」である。実際、TP-Linkルータに接続すれば消費電力は増大しないが、それが何によるのかは分からない。

I/Oルータのログは簡素なので特に何も出て来ず、調べようがない。

そういえば、I/Oルータに繋いでいる場合、(別の稿に書いた、)PCからスマフォの画像を自動取得する処理でスマフォに繋がらない(スマフォが見付からない)ことがあるが、TP-Linkルータでは ほとんど起らないので、何かあるのかも知れない。

例えば、しばらく通信がないと、I/OルータあるいはスマフォがWi-Fiの接続(いろいろな層があるとして、比較的下のほうではないか)を切ってしまうが、なぜかTP-Linkルータでは切られないということがあるのかと思っている。

その他の要因として、上記のスマフォの画像を自動取得する処理の負荷が考えられるが、PCをスリープさせていて自動取得が行われない時でも消費電力は減らないので、主因ではなさそうだ。

あと、問題とは直接関係ないが、スマフォの電池残量表示から消費電力を計算すると、たまに予想外に値が大きく・小さくなることがある。それは残量の誤差(正確には表示分解能)による場合が多そうだ。というのは、Androidが表示する電池残量は1%単位なので、実際の残量は 表示値から表示値+1%未満※まで(表示値-1%未満から表示値や、表示値±0.5%も ありうる)の間の「どこか」であるためだ。

※0.5%と考えると、比較的うまく行くのかも知れない。

1%単位の表示値から正確な残量を求めるには、連続して残量変化を調べて残量曲線の細かい区間の傾きを求めれば、中間の時刻での残量を計算することができそう(直線補間)だが、手では困難だ。

あるいは、残量が変化した正確な時刻と残量を記録し(そういうアプリは ある。例: My Battery Monitor)、(任意の時刻の残量でなく)それを元に消費電力を求めるのが良さそうだ(が、今となっては遅い。→ ちゃんと確認したいので、上記のMy Battery Monitorを再度入れた)。

実際、数時間(3時間など)では誤差が大きくなることがあり、10時間くらい見ないと確からしい値は得られなかった。

例: 残量差から消費電力を計算する時、開始残量表示が90%、3時間後の終了残量表示が87%の場合

普通に計算すると、(90-87)/3= 1.0%/h となる。

一方、残量の表示分解能の影響を考慮すると、終了残量(開始残量も同様だが、簡単のため、ここでは終了だけを考える)は 87-88%の間 と考えられる。それを仮に87.5%とすれば、(90-87.5)/3= 0.83%/h となり、上の値より17%も小さい。

もし、開始残量もズレていたら、更に差が大きくなる場合がある。

 

という訳で、スマフォの電池は劣化してなさそうだし消費電力は減らせた(元に戻せた)ものの、原因が分からず もやもやするが、ひとまずは良しとしたい。

でも、時間が経つと別な要因で消費電力が増大して「あれ? また?」とか思いそうだ・・・

あと、実は最後に書いた、スマフォの電池残量の表示分解能の影響だけの問題で、実は、「何も問題はなく、だから解決すら していなかった」(= 全部 夢か幻、プラシボ効果。「は? 何寝ぼけてんだ!」w)というオチもありそうだが、何度も測定・確認したので、そうではないことを願っている。

と書いたら、本当に消費電力が激増してしまった。必要なくなったアプリをアンインストールしたのが関係しているのかと思って再起動して様子を見ているが、スマフォへのssh接続も遅くなってしまった。相変わらず謎は多い。。。 (10:41)

Androidの電池残量のグラフ(↓)を見てみたら、消費電力が激増したところを過ぎたら ほぼ平坦になって、三角形の窪みとか斜面の宅地のようになっているので、「謎の理由」で残量の測定がうまく行かなかったようだ。最終的に辻褄が合うのも不思議だ。

もしかすると、その辺りでアンインストールしたアプリ(Gsam Battery Monitor)が電池や消費電力関係のものだったからだろうか?

Androidの電池残量のグラフ: 「時間前」の辺りで一時的に残量が激減したが、なぜか元に戻った。

また、ssh接続などが遅いのが頻発していた件は直らない。外出して戻ったら直ったと思ったが、単に充電中のためだった。Androidやルータの設定が どこかおかしいのかも知れない。(Androidがやっている)LTEとWi-Fiの切り替え・併用は難しそうだし、謎は多い。 (18:11, 19:24)

 

PS. この問題を何とかする過程で、公開予定のPCからスマフォの画像を自動取得するソフトも結構改良できたのが良かった。それだけでも価値があった^^

  •  0
  •  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

先日気付いた(というか、それまでは「まあいいか」にしていた)、バックアッププログラム(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

数か月前に、メモリ使用量が多くなってしまったFirefoxに見切りを付けてVivaldiに乗り換えた。ところが、それから少ししたら、なぜか、Vivaldiのメモリ使用量も多くなってしまった。丁度Chrome(Chromium)の更新後だったので、うまく整合しなくなったのかと推測し、少し経てば直ると思って居たのだが、直る気配は なかった。Vivaldiがメモリリークしているのかと思って調べたが、そういう情報はなかった。

結論を先に書くと、メモリリークのようなVivaldi自体の問題ではないが、特定のChromeのアドオン(Chromeでは"extension"だが、ここでは「アドオン」と書く)とVivaldiの相性の問題のようだ。: 具体的には、アクティブでないタブを自動でサスペンド(Chromeでは"discard"?, Vivaldiでは"hibernate")するアドオン(The Great Suspenderなど)で、どういう訳か、その「Chromeの内蔵省メモリ機能を使う」設定が うまく動作しなくなる(逆に動作するように見える)のが原因のようだ。

なお、メモリ管理はLinuxとWindowsなどでは異なるだろうから、この現象は おそらくLinux版特有と思われるので、そういう題にした。

現象は、Vivaldiを起動後 数時間から数日経つと、メモリ使用量が増大する。僕は約240個のタブを開いているが、アドオン(オリジナルのThe Great Suspender)でタブを自動サスペンドしているため、通常はメモリ使用量が10GBを超えることがない。それが、ある時に10GBを超えてしまい、何もせずに(タブをアクティブにしない)待っても減らないのだ。

Vivaldiは諦めたくないので※、どういう時にメモリ使用量が増大するか頻繁にチェックしていたら、メモリ使用量が増大している時はプロセス数(≒ アクティブなタブ数*k(1.5辺り?) + B(10辺り?))も多くなっている(例: 80以上)ことが分かった。* それで、定期的(15分ごと)にVivaldiのプロセス数とメモリ使用量を記録・チェックしてみたが、切っ掛けは分からなかった。

※実はちょっと くじけてw、(省メモリの評判がある)Edgeを試したが、Windows版には あるらしい省メモリの設定がLinux版には なかったので、すぐに止めた。

*アクティブでないタブがサスペンドされなくなるのか、サスペンドしたタブ(のプロセス)がゾンビのように復活するのだろうかと想像するが、詳細は分からない。

それから、表示するページやVivaldiの設定やアドオンに関係するかと考えて、原因になっていそうなページを開いてメモリ使用量の増加を調べたリ、Vivaldiの設定を変えてみたり、ほとんどのアドオンを無効にしたり、タブを自動サスペンドするアドオンを換えたり、そのアドオンの設定を変えてみたが、改善しなかった。

それで、駄目元(と言うか破れかぶれ)で、自動サスペンドするアドオン(今はThe Marvellous Suspenderを使っている)の設定"Apply Chrome's built-in memory-saving when suspending"(以下、「省メモリ設定」)をoffにしたらどうなるか試してみた。

VivaldiでThe Marvellous Suspenderの省メモリ設定(下側)をoffにして試した。

この設定をoffにすると、タブのメモリが「うまく」解放されないだろうから、メモリ使用量が更に増大して とんでもないことになるはずだから普通はしないが、「onにしても増大するなら、offでは 一体どのくらいひどくなるのか見てやろうじゃないか!」と思ったのだ。

すると、いつ「とんでもないこと」が起こるかと待ち構えているうちに忘れてしまい、気付いたら問題が起こらなくなって居た。信じられないことだが、再度 省メモリ設定をonにしたら現象が起こったので、どうやら これが原因だったようだ。

今も半信半疑で使っているのだが、Vivaldiを起動してから6日くらい経っても現象は起こっていない。

5/18 9:13 プロセス数: 41, メモリ使用量: 5.5GB (平均: 133MB/プロセス)

どうしてアドオンの省メモリ設定が逆になる(正確には「逆に働く」)のかは分からない。想像だが、元々Vivaldiは(Chromiumに対する)その設定をonにしていて、アドオンでもonにすると、設定が反転したり動作が無効になってしまうのだろうか。

フォーラムに出せば何か分かりそうだが、Vivaldiのフォーラムかアドオンのフォーラム(あれば)か、どちらに出せばいいか不明だ。あと、他の方が特に文句を言っていないのも気になる。そういう場合は僕の環境に問題があることがある。

なお、省メモリ設定のないアドオン(確か、Auto Tab Discard)でも現象が起こったので、設定があるもののonに相当するのだろう。ちなみに、本物のChromeでは現象が起こらない(オリジナルのThe Great Suspenderが ちゃんと動く)ので、Vivaldiに何かありそうだ。あるいは、ChromeとChromiumに違いがある?

書いたあとで思い付いたのだが、Vivaldiにはタブをhibernateする機能がある(惜しいことに自動でない)。それで、アドオンがタブをChromeの省メモリでない方法で「サスペンド」すると(そういう機能があるのかや、それに意味があるのかも不明)、うまい具合にVivaldiのhibernate機能が使われて、メモリが「うまく」解放されるのだろうか? 逆に、Chromeの省メモリでサスペンドすると、Vivaldiの管理とズレてしまって うまく解放されないことがあるのかも知れない。

とりあえず うまく行って良かった。もうしばらく様子を見たい。フォーラムは疲れる(気力が要る)ので、覚えていて余力がある場合にするw

(5/27 6:07) その後 メモリ使用量の増大は起こっていないので、解決したようだ。 (→ 題を更新した。)

 

おまけ (5/23 5:03)

(メモリ使用量には関係ないが、Vivaldiとアドオンに関連するので書く。) ブラウザのウインドウに任意の文字列を追加するアドオンWindow Namer and Restorer BETA(以下、Window Namer)はKeePassXC用のアドオンKeePassXC-Browserと相性が悪い。どういう訳か、KeePassXCが取得するタブのURLが(同じウインドウの)別のタブのものになってしまうようで、KeePassXCから別のURLに対する認証情報を取得してしまう。

近頃、ID・パスワードが自動入力されない、あるいは、別のサイトのものが入力されることがあって、おかしいと思って調べたら、Window Namerが悪かった。

Window Namerで ウインドウの名前にカテゴリ(例: "[News]")を付けることで、複数のウインドウの区別が楽になって便利だったが、KeePassXCが誤動作するのは かなり不便なので使うのを止めた。

なお、これはVivaldiだけで起こる問題なのか、Chromeでも起こるのかは不明(未確認)。

 

PS. そういえば、Firefoxでも同様な現象が起こっていたが、まあ、あっちは構造も仕組みも全く違うから、単に腐ってメモリリークしているだけなのだろう。。。

PS2. 本題には関係ないが、Ceronでちらっと目にした、「検索にクソブログしか出て来なくてムカつく」とかいう件について書く。

まず、そのスレに書かれていた、最後に「いかがでしたか?」と出るのは ブログでなくアフィリエイトや まとめサイトだ。一緒にしないで欲しい。そして、ブログやWordpressサイトをひっくるめて「クソ」と言われたり、一括して検索結果から除外したいとか言われるとムカつく。まあ、ブログサイト全体を平均すると役に立たないものが多いだろうが(でも、今はアクティブなサイトが減っているから、アクティブなものだけなら有用なものが多い気はする(希望))。

個々のブログサイトの質、検索結果に出て来る候補のマッチ度合いは玉石混交だけど、それは(昔の)図書館などで目的の情報を探せるかどうかに似ている気がする。: 検索する側の能力・努力や探す気力・情熱も関係するのではないか。

細かい経験則として、英語でも検索すると、目指す答えに近付く可能性が高まることはある。個人的には、分野によるが、コンピュータ関係は英語のほうが ずっと効率が良い気はしている。

とは言え、英語のサイトにも、新しいページに古い情報をそのまま載せていたり、他サイトのコピペや最後に「いかがでしたか?」のような類のクソは多いので、安心はできない。

そして、自分で碌に考えも試しもせず、ちょっと検索してパッと「答え」を得ようとするのは安直過ぎると思うし、それでは無理だ。「そんなに世の中は甘くない」だ。そもそも、今は昔よりずっと情報が多いではないか。

  •  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

自分謹製とは言えカードリーダーが今一つ不安なものになってしまったmicro SDの代わりに、非常時のために財布の中に入れておこうとして買ったカード型USBメモリも駄目だったので別のものを探しているうちに、まず、非常用メディア(USBメモリやmicro SD)をどうする(何をどうやって所持するか、データをどう格納するか)のが一番いいのかを考えるほうが重要なことに気付いて、そうした。

そして、当初は財布の中なら いつも持ち歩くから効果的だと考えて居たが、紛失した場合を考えると、その中に入れる情報によっては事態を更に悪化させることに気付いた。

具体的には、財布には免許証、クレジットカード、健康保険証などを入れているので、それだけでも大変なリスクだが(何とかしたいが、利便性を取って危ないままにして居る)、更に非常用データ(例: サーバのssh鍵)が一緒になったら、それこそ「何でもできそう」ではないか。

実際にはssh鍵にはパスフレーズを設定しているので、紛失しても直ちに危険にはならないが、繰り返せば当たる可能性もあるし、sshの設定など、その他のいろいろな情報を合わせると攻撃のヒントになるだろうから、油断はできない。

そこで、非常用メディアを部屋の鍵と一緒に持ち歩くことを考えた。こちらのリスクは、メディアに住所の書かれたデータが入っていた場合、部屋に泥棒に入られる可能性がある程度と考えた。

比較した当初は、財布のほうが住所・氏名が分かるから戻って来る可能性が高い(鍵だと何も分からないから、まず返って来ない)と考えたが、甘過ぎる想定なので却下した。もちろん戻らず、悪用されることを前提にしなければいけない。

そういう訳で、非常用USBメモリを部屋の鍵のキーホルダーに付けて持ち歩くことにした。鍵は財布同様かそれ以上に いつも持つだろうから有効そうだ。そして、格納するファイルには住所を書かない(書く場合は暗号化する)ことにした。同様に、サーバのssh鍵のように流出するとマズいものは暗号化して格納することにした。

キーホルダーに付けるのなら、大抵の(本体が丈夫でストラップ穴があれば良い)USBメモリが使えるようになって選択肢が増える。そして、たまたま(?)、昔 展示会でもらって、micro SDの前に非常用にしていたものがあるので、当面は それで試してみることにした。そして、(今更ながら、)先日のカード型USBメモリのような轍を踏まないように、メディア全体に書き込みと読み出しを行ってチェックしたところ、当然というか意外というか、全く問題がなかった。

このUSBメモリは通販で すごく良く見る、ちょっと柔らかいプラの本体に回転する金属のカバーが付いたもの(→ 。ただし、僕のは容量2GBでアクセスランプはない)で、いかにもいい加減なものだが、中身はちゃんとしていた。が、外見が同じでも中身が違う場合があるので、同じものを買っても大丈夫な保証は なさそうだ。

データの暗号化の方法については詳しくないので、なるべく安全そうで手軽なものを探した。ただ、Linux以外に(その気になれば)Androidでも復号できるようなオープンな仕様のものが良いので、gpgコマンドを使った。gpgは かなりいろいろなことができるが、(初歩的な?)パスフレーズ(パスワード)での暗号化(gpgの-cオプション, symmetric cipher)にした。GPGのキーを一緒に持ち歩いて別のシステムに再設定しなくても、パスフレーズを覚えていれば復号できるからだ。

暗号化アプリなんて山ほどあるだろうが、大抵は自分のことしか考えてない(例: 独自フォーマット)ため、上記のように、全く別のOSで復号するのが不可能なものが多そうだ。あと、アプリの寿命も重要で、知らないうちに消滅してしまって、いざという時に手に入らなかったら目も当てられない。

gpg以外では暗号化ZIPファイルでも同様なことが可能だが、Windowsが起源なのと、使い勝手が(UNIX的でなくて)好きでないので却下した。詳しくはないが、(総当り以外で)ZIPの暗号が破られたという話は聞かないから、実際には ZIPのほうがずっと手軽であろう。"PPAP"と叩かれたけど、使い方が誤っていただけで 仕組み自体に悪いことはない。

なお、gpg(symmetric cipher)で暗号化する時(非常用メディアにファイルを格納する時)にはパスフレーズを入力する必要があるが、定期的な更新時に毎回手で打ち込むのは面倒なので、GNOME keyringに格納しておき(seahorseやsecret-toolコマンドを使う)*、メディアの更新時にsecret-toolで取得してgpgに設定するようにした。※

*secret-toolは初めて使ったのだが、他の鍵(パスワード)と同様に格納するには、attributeとして"service"で種類を、"username"でその種類内の鍵の名前を指定すれいいようだ。以下に実行例を示す。

secret-tool store --label="非常用メディア" service "EmgData" username "ekey"

上を実行すると、パスフレーズを入力するダイアログが出て来る。

格納したパスフレーズを取得するのは簡単で、以下のようにすれば良い。

secret-tool lookup service "EmgData" username "ekey"

※具体的には、以下のようにしてgpgにパスフレーズ($pass_phrase)と圧縮アーカイブ($cmp_arch)を入力している。

( cat << /EOF/
$pass_phrase
/EOF/
cat "$cmp_arch" ) | gpg -c --batch --pinentry-mode loopback --passphrase-fd 0

パスフレーズをechoやgpgの引数で指定するとpsコマンドで見えてしまうので、避けた。ファイルディスクリプタ(--passphrase-fd)を9とかにすれば もっと分かりやすそうだが、すぐには できなかったので0(stdin)にした。

ファイルディスクリプタを変えるのでなく、FIFOを使って渡すのがいいのかも知れないが、煩雑だし、FIFOはファイルだから逆に脆弱になるのかも知れない。

厳密に見れば弱いところがあるが、デスクトップに侵入されて(、自分のメモリ空間を見られまくられて)いる状態を想定し出すと何もできなくなってしまうので、今のところは これで良しとした。

gpgでファイル単位で暗号化することもできるが、煩雑に思えたので、暗号化するディレクトリ全体のアーカイブを圧縮したもの(例: tar+gz)を暗号化するようにした。

この用途にはgpgtarというコマンドがあって便利だが、下記の更新チェックをするために使っていない。

それから、無駄にメディアに書き込まないよう(寿命を延ばすためと、安物のせいか、たまに書き込みが すごく遅いことがあるため)、更新していないファイルを書き込まないようにした。暗号化してないものはrsyncでできるが、暗号化したものは難しい(煩雑な)ので、圧縮したアーカイブ全体のハッシュ(例: MD5)で判定するようにした。メディアを更新した時に そのハッシュも保存し、次回の比較に使う。

なお、gpgで暗号化すると全く同じデータでも毎回中身が異なるので(全然分からないが、時刻でパラメタ(シード?)が変わる?)、暗号化前のハッシュを使うことにした。

 

以上のような処理(+その他細かい いろいろ)をする同期(転送)スクリプトを作り、定期的に非常用メディアを更新するようにし、使い勝手やメディアが壊れないかやその他の問題の有無を見て行こうと思っている。

まあ、このメディアを使うことがないのが一番だがね・・・

 

PS. その後、(上のプログラムを作る時からやろうと思って居たのだが、)スマフォにも非常用データを同期するようにした。

元々、スマフォからカメラなどの画像を自動取得するプログラムがあるので、その「ついで」に非常用データを転送するようにした。転送する部分は、上のUSBメモリへの転送スクリプトを ほとんどそのまま使えた(転送先を指定できるようにしただけ)。

自動取得するプログラムは、カメラ情報に追加同期コマンドを設定できるようにし、それが設定されていたら定期的(例: 8時間)に実行するようにした。その時、転送先として画像取得用にマウントしているスマフォのディレクトリを指定する。

これで、仮に非常用USBメモリがなくても、スマフォがあれば何とかなるようになった(はず)。 (4/26 11:31)

  •  1
  •  0

(溜まったネタを時系列に こだわらず書いている。今回のは前々回の「瞬壊したSDカードリーダー−」のカードリーダーを買う切っ掛けである。)

ちょっと思い付き(後述)を試そうとしたら、物を4つも壊してしまった(と思った)。以下である。:

  • PQI Air Card II (以下、Air Card)
  • micro SDカード
  • 100円ショップのカードリーダー(以下、100円カードリーダー)
  • I/Oデータのカードリーダー(以下、I/Oカードリーダー)

他に、非常用micro SDカードも壊れたかも知れなかった。

が、実際に壊れていたのは100円カードリーダーとI/Oカードリーダーだけだった。後者は何とか修理できて、micro SDカード2枚は無事なことが分かった。ただ、Air Cardも怪しい感じだった。というか鬼門だ。今までに何度も(本来の使い方では ないことをしようとして、)随分苦労して成功したことがない。

Air CardをWi-Fi - シリアルアダプタにしようとした。

「思い付き」とは、Air Cardを換気扇タイマーのWi-Fi - シリアル接続用に使い、PCからタイマーを制御(リモコン)できないかと思った。Air Cardの基板にはシリアルポートが出ている(はずな)ので、それが使えれば良い。以下のような構成を考えた。

PC → Wi-Fiルータ → (Wi-Fi) → Air Card → (シリアル) → 換気扇タイマー

ただ、障害・課題は多い。

まず、シリアルポートが本当にある(出ている)か不明だ。: 端子の位置が分かっているのは古い(IIでない)Air Cardで、僕のAir Card IIは基板の部品配置が違う うえに基板に端子名も書いてないので、シリアルポートの端子を探すところから始めなくてはいけない。

次に、端子を見つけるために・見つかったとして、基板上のすごく小さい端子(「ランド」: 直径0.5mmくらい?)に線を接続する必要がある。通信用以外に電源も繋げる必要がある。

更に、Air CardではLinuxが動いており、シリアルポートはコンソールとして いろいろな情報が出力されるので、それを停めなければいけない。その他に、シリアルポートの通信速度と電圧(38.4kbps, 3.3V)をタイマー(9600bps, 5V)に合わせる必要もある。

かなり面倒なので何度も却下したのだが、実物があるので ついやりたくなってしまった。(PCのシリアルポートの準備などは別途書く) そうしたら、Air Card IIのシリアル端子は ほぼ一発で見つかった。: (IIでない)Air Cardの情報(→ )から推測した位置にあった。(: "UART?"の下の円内)

実は、もう一箇所、候補の場所(図の円と"4"の間の"+"と その上)があったが、試す前に片方が電源だと分かったので却下していた。

「もしかしたら行けるか?!」と思って気が急いて作業が雑になったせいか、このあとで100円カードリーダーとI/Oカードリーダーを壊してしまった。

100円カードリーダーの故障

100円カードリーダーを改造して常に電源(3.3V)がSDカードの電源ピンに掛かるようにして※Air Cardを挿して試していたのだが、何かがおかしかった(ショートか過負荷?)ようで、100円カードリーダーがSDカードを認識しなくなってしまった(PCにも認識されない)。

※そうした理由は、それまでの試行ではAir CardはPCからアクセスしないと起動しなかったので、それがカードリーダーの電源制御(PCからアクセスしないと、SDの電源が入らない)によるものかと思ったためである。今となっては そうではなく、Air Cardの仕様だったようだ(後述)。

ただ、(前の稿にも書いたように)それでも3.3Vが出るのが不思議だ。想像だが、カードリーダーのチップ3.3V生成部(レギュレータ)は無事だが、それ以外の部分(PC対応部かSDカード制御部)が壊れたのだろうか?

I/Oデータのカードリーダーの故障

それで、電源容量が足りないのかと思って※ I/Oカードリーダーから電源を取ってみたが、やっぱりAir Cardは うまく動かなかった(理由は後述)。

※正しくない。普通に100円カードリーダーに挿している時は動いていたので。

この時、Air Cardの中身(micro SD)にPCからアクセスしたくて、I/OカードリーダーのSDスロットにAir Cardを挿したら壊れた。: I/OカードリーダーからAir Cardに確実に電源を供給するためにSD端子の根本に付けた半田が盛り上がっていたために(面倒だったので、線は切ったが半田は取って居なかった)、Air Cardを差し込んだ時にSDソケットの電源ピンが後ろに押されて抜けてしまったのだ。(: 長方形の窓の中の8個の小さい長方形の中央付近の歯抜けになった部分)

カードリーダーを動かしたらカラカラ音がしたので、中を見たらピンが抜けているのが分かった・・・

さすがに、ピンを何かで代用することはできない(強度も接触も確保できない)ので、「大失敗だ・・・」と諦めたのだが、運良く 抜けた電源ピンが作業机の下のフローリングの板の継ぎ目で見つかった(席に戻る時に光って見えた)ので、どうにか修理した。折れずに すっぽり抜けたので、運が良かった。

I/Oデータのカードリーダーの修理

古い製品だからかシールドが厳重で、SDソケットの端子に触れなかったので、まずシールドを開けた。それから、抜けたピンを慎重に挿して半田付けしたら、運良く直ってPCで認識できたので、シールドを元に戻して修理が終わった

ただ、今後の耐久性や信頼性は低そうなので、新しいカードリーダーが必要になった。

なお、直ったカードリーダーで壊れたと思ったmicro SDカード2枚を試したら、運良く壊れていなかった。

Air Cardを断念

結局、Air CardはPCに接続せずに電源を繋げただけでは、Lunixが うまく起動しない(途中で進まなくなる。: の最後の行のように、"0,"が連続して出る)ことが分かった。それを直すにはファームウェアを書き換える必要があり(方法は分かっている。: 参照(Post #170))、不可能ではないが面倒だ。しかも、そうしてもAir CardのLinuxからmicro SDにアクセスできないとのことだ。

それでも試そうとした。が、ファームウェアを書き換えるためにはAir Cardに新しいファームウェアの入ったmicro SDを挿して起動する必要があるのだが、Air Cardのケースが密閉されていない(上下に分離した)状態でmicro SDを挿すのが困難(接触不良になる)な問題があった。それで、Air Cardのmicro SD端子に線を繋いで延長して外にmicro SDソケットを付けようとしたが、端子のピッチが細かくて手持ちの線(余り細くはない: 被覆が厚い)を安定に繋げるのが無理なので、断念した。

何度目かは分からないが、惜しかった(全然?!)ものの 今回も駄目だったので、二度と変な気を起こさないように、物理的に破壊して捨てた。

怒りの余り衝動的に(「カッとして」)ではなく、冷静に、二度と無駄なことをしたくないので そうした。駄目なものは駄目で、関わっては いけない。

Air Cardなんて大大大大っ嫌いだ!

  •  0
  •  0

僕にとって、ブラウザでBackspaceでページが戻れるのは かなり重要だ。それができないと、いちいちマウスジェスチャするかAlt+←を押さなければならず、煩雑だ(パッとできない)。更に馬鹿なことに、Firefoxはショートカットキーを変更できなくしてしまった。他の件(例: アドオン切り捨て)も合わせて 一体誰のために何をしているのか分からず、とにかく早く他に移りたかった。

そして先日、Chromeのメモリ使用量が少なくなったことに気付き、更に、VivaldiはBackspaceが使える(それどころか、ごく当たり前のことだが、ショートカットを自由に変更できる)ことに気付いた(思い出した)。そして数日前にVivaldiが更新され、Chrome同様にメモリ使用量が少なくなった可能性があるので測ってみた。

その結果、最新のVivaldi(5.1.2567.46)はFirefox(97.0)と比較し得るくらい少なくなったことを確認したので、移ることにした。参考までに、以下にVivaldiとFirefoxの1タブ当たりの平均メモリ使用量を示す。

  • Vivaldi: 201MB/タブ
  • Firefox: 200MB/タブ

測定条件

  • バージョン
    • OS: Linux Mint 20.3
    • Vivaldi: 5.1.2567.46
    • Firefox: 97.0
  • 測定方法
    • 21個のページ(僕が良く使うニュース、買い物、地図など。どちらのブラウザも同じ)を数分間隔で開いたあとのメモリ使用量の増分を求め、ページ(タブ)数で除算して1タブ当たりのメモリ使用量を求めた。
    • メモリ使用量は、ブラウザのプロセスのpsコマンドのRSS(resident set size)の合計とした。

メモ

  • Vivaldiは、ページ(タブ)を開いてから少し経つ(1-2分)とメモリ使用量が減ることが多い。
    • また、ガベージコレクションなのか、タブを開いたあとのメモリ使用量が開く前より減ることもあった。
  • Firefoxも同様だが、全ページを開いたあとで何もせずに居たらメモリ使用量が増えた。メモリリークがあるのではないか。
    • 以前(2018年)はFirefoxは70MB/タブくらいだった(その時はVivaldiは217M/タブだった)が、いつからか浪費するようになってしまったようだ。
      • 今回は途中までは それほど大きくなかった(10タブで154, 20タブで186 MB/タブ)が、全部を開いてから時間が経ったら増大して上の値となった。
    • 近頃、何も特別なことをしていないのにFirefoxやシステムのメモリ使用量が増大することがあって不思議だったのは、メモリリークのせいだと分かった。
  • 仮にメモリリークが直ったとしても、Firefoxに移った当初の2倍以上になってしまい、Vivaldiとの比が当初の1/3から1/1.3まで上がったので、今となっては使う意味が完全になくなった。

Vivaldiは、何もしなくてもタブバーが縦に出せることだけでも充分僕好み(僕に言わせれば、正しい・正しく ものを作っている、あるいは「分かってる」・「筋がいい」)だが、以下をカスタマイズ・調整した(したい)。

  • 「新しいタブ」(Ctrl+T)でアドレスバーにフォーカスしない。→ Quick commandsという機能を使って対応できた(以下にその処理を書く)。それをCtrl+Tに割り当てた。
    1. New Tab
    2. Focus Address Field
  • ウインドウに名前を追加するアドオンがない? → "Window Namer and Restorer BETA"で「概ね」できる(不満はあるが、できないよりは良い)。
    • 複数のウインドウを開いていると、最小化した状態から戻す時に区別できなくなるので、ウインドウ名にそのウインドウのカテゴリを追加して区別を容易にしている。
  • [未解決] タブバーのタブの幅(高さ)が少し高く、タブが増えるとスクロールが要る。 → アドオンで何とかなる?
    • 今は、関連するタブをスタックさせて、見えるタブ数を減らして緩和している。
  • [未解決] カレンダーは どうにか動くが、今ひとつ。: betaのためか。
    • これがちゃんと動けば、Seamonkeyは要らなくなる。
  • [未解決] メールも動かない。: TLSハンドシェイクエラーになる。 → (StartTLSでなく)SSL/TLSならOKだった。
    • これがちゃんと動けばEvolutionも要らなくなる。
    • (2/18 10:44) その後更に試したら結構惜しい。: 最初に使えなかったのは、IMAPがStartTLSに対応していないためのようで、思い付いてSSL/TLSのポートを指定したら使えるようになった。
      • ただ、アドレス帳がCardDAVに対応していないので、まだ実用には向かない。が、ちょっと使った感じは悪くないので、「もう少し」の感じはする。

ちょっと使った感じでは、Firefoxより ずっと柔軟で良い!

のだが、例によって いいことずく目ではなく、以下の問題が出た。

  • サイト・ページとの相性問題
    • Twitter: 日本語入力(Fcitx+Mozc)が駄目。
      • ツイートの入力で、文字抜けや順序の乱れだけでなく それまでに入れた文字列がすっぽりなくなることがある。
        • → Linuxのアプリ(Choqok, Cawbird)は今ひとつだったので、とりあえず、Seamonkeyのブラウザを使っている。
        • → SeamonkeyはFirefox系のためか、やっぱりメモリリークするので、Epiphany(GNOME Web)を試している。 (2/19 5:28)
        • → Epiphanyはページ内の動画が再生できないので、Falkonを試している(Ubuntuのパッケージのものなので少し古い(3.1.0))。これも省メモリ(起動直後で約300MB)だ。 (2/19 9:29)
        • → なぜか、Falkonは すごく重い・遅いことがあるので、Epiphanyに戻した。 (2/20 3:24)
        • → 動画が再生できないのは不便なので、Falkonの余計そうな機能をoffにして再度試している。 (2/21 8:46)
          • なお、その前にEpiphanyの最新版を試そうとしたが、Flatpakなのに ちゃんと動かなかった(「WebViewがクラッシュ」とかいうエラーの連続で表示できない)ので止めた。
        • → Falkonには隠れたプロセス(QtWebEngineProcess)があり、それを合わせたメモリ使用量は約940MB(300+640MB)とFirefox(起動直後にtwitterを表示すると約1.1GB)と同様で わざわざ使う意味がないことが分かったので、twitterだけはFirefoxを使うことにした。 (2/20 18:58)
          • Falkonが重かったのはQtWebEngineProcessのため かも知れない。
      • その他のサイト・ページの日本語入力は、Twitterに比べれば問題ない。
        • WordPressのクラシックエディタは、文字抜けはないが、未確定文字の下線(Fcitxを改造して出るようにした)が出たままになることがある。
        • 「普通の」テキスト入力フィールドは問題なさそう。
    • [暫定対処] Ceron: スレッドを開くとハングすることがある。解決策が分からず、どうしたものか・・・
      • マウスカーソルがブルブル震えて操作できなくなり、強制終了するしかなくなる。大丈夫なこともある。
      • JSの動きの違い? ただ、検索しても出て来ない。 → 何かのアドオンが悪い?
        • → 試しに、CeronではuBlock Originを無効にしたら、その後は起こらなくなった。たまたまか効いているのかは不明だが、これで使ってみる。 (2/17 5:51)
          • Vivaldiには広告ブロック機能があるので、それを有効にしてCeron中の広告をブロックできている。
    • [Vivaldiの問題ではない] Impress watch文字が太い。 ← ページのスタイル設定(CSS)が太字のため(ひどいデザインだと思う。とは言え、比較したITmediaも別の点で ひどい・・・)。それでもFirefoxが細いのは、「太字」(bold)に使う種類(weight?)が違うのかも知れない(逆に、太字なのに太く見えないのは どうかと思う)。
      • 以下に、太字に設定しているソースを示す。
.news-headline-block ul>li {
    border-bottom: 1px dotted #aaaaaa;
    font-size: 81%;
    font-weight: bold;
    width: 100%;
}
      • 実際、ほとんどのサイト・ページでは同じように表示された。(→ 例: ITmediaVivaldi, Firefox)
        • なお、なぜかVivaldiにはtweetのボタンが出てないが、細かいことだし使わないので問題ない。
  • 時々挙動不審。。。
    • 素がいいので、今後段々良くなるのを期待したい。

 

なお、実際に使用している時のVivaldiのメモリ使用量は、5ウインドウで約100個のタブを開いている(ただし、アドオンThe great suspenderで しばらく使っていないタブを休止させている)場合、例えば4-6GB程度と、Firefox(メモリリークしていない場合)の時と大差ない。

そして、Firefoxと同様にメモリ使用量10GBで警告を出すようにしているが、普通に使っていて まだ出ていないから良さそうだ。Chrome系は随分省メモリになったものだ。と書いたが、そうではなく、「Firefoxは随分大喰らいになったものだ」が正しい。

 

PS. 書いてから気付いたが、僕はFirefoxの前はVivaldiを使っていたので、約3年ぶりに戻った。なお、その前はFirefoxだったようなので、行ったり来たりだ。

 

(2/20 8:08 一部の書式を変更、わずかに加筆・修正)

  •  2
  •  0

結構前から、MySQLのサーバ(mysqld)が自動更新された後に自動起動せず※、不便な思いをしている。停まると使っている側(例: このブログ)がエラーになるので、ログインして手で起動する必要がある。

※推測だが、更新のスクリプトが間抜けで、更新後にうまく起動できないのではないか。

それが面倒なので、去年くらいから、crontabで定期的(10分ごと)にmysqldが起動しているかチェックし、していない時は起動するようにして居た。

ただ、ほとんどの場合は起動しているので、定期的にチェックするのは無駄だし、起動していない時に10分も待つのが嫌なので、以下のような自動起動処理を作った。

  1. 自動更新のログ(/var/log/apt/history.log)に、mysqldの更新が記録(追記)されるのを待つ。
    • tail -F -c 0 ファイル名 | egrep --line-buffered パターン
  2. 少し(10秒)待つ。
    • もしかしたら起動されるかも知れないので。
  3. mysqldが起動しているかチェックする。
    • systemctl status サービス名
  4. 起動していない時は起動する。
  5. 処理の実行が分かるようにメールを出す。
  6. 1に戻る。

ある程度は動作確認したが、ちゃんと動くかは次回の更新まで確かめられない。

そしてデバッグする羽目になる?w

 

MySQLは(僕にしてみれば出来が悪く、)ことあるごとに面倒を起こすので止めたいのだが、互換性があって容易に移れるものがないので我慢している。

 

PS. 書いたあとで調べたら、mysqldのサービスファイル(/lib/systemd/system/mysql.service)の "Restart=on-failure" を以下に換えるといいようだ。

Restart = always
RestartSec = 10

何かの考えが あった(やっぱりサボりたい?w)のだろうが、MySQLのパッケージに原因があった。ただ、この問題は以前は起こっていなかったため、本当に上の変更でいいのか疑問があるので※、適用するのは保留する。

※妥当であることを確認するには、問題が起こっていなかった時のサービスファイルを「発掘」して比較するのだろうが、面倒だ。

↑ ちゃんと動いていた頃のサービスファイルの発掘はできなかったが、サーバのOSをUbuntu 20に更新した時(2020/11)にsystemd(サービスファイル)による管理に変わったので、その最初のサービスファイルから ずっと駄目だったのではないか。

 

(2/6 5:12 OSのバージョン記載漏れを修正)

  •  1
  •  0