Archive for May, 2022

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

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

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

概要

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

使っているデビットカードがGoogle Payに対応したので登録してみた。スマフォのカメラでカードを写すと番号などが自動入力されて楽だった。

ただ、有効期限とセキュリティコードは入力されなかった。セキュリティ上の問題があるから わざと出さないのかも知れない(でないと、他人のカードを写して登録できてしまうかも知れない)。

それから早速コンビニで使ってみたら、なぜか認識されなかった。セミセルフレジでクレジットカードのカテゴリのボタンを押したのだが、そうでなく、Google PayやApple Payなどのカテゴリ(PayPayなどと一緒?)があって、それを指定すべきだったのかと、あとで思った。

が、気になるので調べたら、クレジットカードのカテゴリでいいようだ。ただ、ページの下のほうに、小さく、スマフォがスリープ状態の場合は駄目みたいなことが書いてあって、それかと思った。それで、次の日はスマフォを復帰させてからタッチしたら、みごとに使えた。決済時にスマフォの画面にカードの絵が出た。どうやら、QUICPay(スマフォがどういう状態でもタッチすればOK)とは違うようだ。

そういえば、SuicaもGoogle Payに入れているけど、自販機などで使えた試しがないのは、長期間使っていなくて停止されている以外に この問題もあったのかも知れない。

↑ 試したら、スマフォの電源をonにしても使えなかったので、Suicaは電源に関係ないけど、長期間不使用で停止されていることが分かった。それにしても、駅に行かないと解除できず、いつも面倒だ。なぜ そんなことするのか全然理解できない。 (5/24 18:05)

いや、Google Payのデビット(クレジット)カードは仮想クレジットカード番号というものを使うらしいので、それで決済時にアプリが動く(= スリープ状態でない)必要があるのかも知れない。

タッチの前に いちいちスマフォのボタンを押すのは、なんか面倒だ。他にも、セルフレジでない場合には、店員さんにタッチ決済を理解してもらうのが大変な場合がある※のに、カードも出さずに(スマフォを出して)「クレジットカードのタッチ決済」とか言っても なかなか厳しい気がする。おまけに、店によっては(タッチする場所があるのに)クレジットカードは挿し込むしかない場合もあるので、こっちの頭の切り替えも煩雑だ。

※タッチ決済と普通のクレジットカード決済の操作が同じか違うか店によって違うし、タッチ決済できるのに、できないと思い込んでいる店員が居て難儀したこともある。そもそも、「クレジットカード(決済)で」と言うのが面倒だが、「カード(決済)で」だと別のカード(例: 店の電子マネー)と思われる可能性すらあり、クレジットカードのタッチ決済のハードルは高い。更に、少ないものの、クレジットカード=デビットカードでない店もあるから大変だ。

そう言えば、以前、上のような背景(タッチ決済できないと思い込んでいる店員の居る店)で、きちんと「クレジットカードのタッチ決済で」と言ったら、店員さんが褒めてくれた。「何種類もあるから、言ってもらえると助かる」みたいなことを言っていた。

あと、カードはスマフォでタッチ決済しても紙のレシートは来るので、それを財布に仕舞うという間抜けな面倒もある。

以前も書いたように、「電子レシート」がスマフォに届けばいいのだが、まだそこまでは無理か。

更に、どういう訳か、Google PayなのにGoogle Payの管理ページ(webまたはアプリ)には出ず、(Googleでない)通常のデビットカードの管理ページで見るしかないようで、どういう管理・仕組みなのか謎だ。

そんな感じなので、果たしてGoogle Payでデビットカードを使う意味はあるのかと思って居た。が、カードを財布から出さずに済むし、結果として挿したまま・置いたまま忘れることもないのは(僕には)大きなメリットだと考え※、使い続けることにした。

※実際、今までに数回、挿したまま帰ろうとしたことがある。

そうしたら、今日、すごいメリットがあることに気付いた。: デビットカードを使うとメールで通知が来るのだが、カード会社の仕様なのか、店名が書かれておらず(数日後に管理ページを見ないと分からない)、金額と日時程度だ。が、Google Pay(のデビットカード)で払うと、ちゃんと店名(ただしローマ字)が出るのだ。

店名が出るのはいいが、同じ仕組みで やれば出来ることがGoogle Payでしかできないのが不思議だ。Google Payは処理が高速とか、即座に検索できる加盟店一覧のDBを持っているとかいう話なのだろうか。

同じような操作だけど実は処理経路が違っていて、Google Payの場合は、「Googleのクレジットカード処理」(仮想クレジットカード番号を本物の番号に置き換える関係?)※を通すために、すぐに店が分かるのかも知れない。その情報をデビットカードの会社に通知するから、メールに店名が書かれるのか。

※その処理の時、店が正当かどうかも確認せずに素通しする訳にも行かないから、決済のたびに店のIDをチェックし、その時に店名も出るのか。そういうチェックは普通のデビットカードでもしているはずだが、店名まで検索していると遅くなるから ちんたらあとでまとめてやっているのだろうか。

(何はともあれ)細かいことだけど、使った直後に店まで確認できるのは かなりのメリットだ。実は、そのデビットカードを申し込む時に説明(店名が分かるのは数日後)を読んだ時から、ここを何とかして欲しいと思って居たのだ。

という訳で、いろいろな面倒はあるものの、二つの大きなメリットがあるので、使えるところでは(多少は我慢して)Google Payのデビットカードを使うことにした。

 

(5/24 8:02 少し修正・加筆)

  •  1
  •  0

デスクトップPCのクラウドストレージへのバックアップに、Backblaze B2 (以下、B2)に加えてGoogle Cloud Stroage Archive (以下、GCSA)も使うのを開始してから約半年経った。

B2は変更頻度の高い「新しいデータ」のバックアップに、GCSAは基本的に変更しない「古いデータ」や大容量データ(音楽など)のバックアップ(アーカイブ)と、階層的に使っている。

特に問題はない。

だけでは 余りにも ざっくりし過ぎだが、本当にそうなのだ。あえて書くとすれば、一つだけ心配なこととして、GCSAに保存しているデータを いざ使おうとしたら「駄目」になっていた※とかいうことがないかである。が、こればかりはどうしようもない。抜き出してチェックするにしても、頻繁にするとアクセスの料金(結構高く付く)が かさむためだ。まあ、Googleとバックアップに使っているソフト(duplicacy)を信じるしかない。

※GCSA: 「すまん、いつの間にかストレージが おかしくなってたわ」的な・・・

ちなみに、今まで4年くらいB2でduplicacyを使っており、(ヘマして消してしまったファイル)少量を数回リストアしたことがあるが、問題が起こったことはない。もちろん、バックアップでもduplicacyに起因する大きな問題は起こっていない。

以下、データ量・料金や気付いたこと・事前の想定と違ったことなどを書く。GCSAと一緒に使っているB2についても書く。なお、B2にはデスクトップ以外にサーバのデータもバックアップしているが、別ものなのとデータ量が小さいので以下には含めていない。

現在のデータ量と料金

  • GCSA: 約946GB, 約150円/月 (税込み) → 年額見込み: 約1800円 (税込み)
    • 月によって追加バックアップをしたりするため、微妙に異なる。あと、為替相場でも変わる。
  • B2: 約80GB, 約52円/月 → 年額見込み: 約630円 (現在のデータ量からの予想。USDで支払いのため消費税抜き(どういう扱いかは不明)。1USD= 130円とした。)
    • 正味のデータ量は約30GBなので、約20円/月 → 年額見込み: 約240円になるはず。
  • 合計: 約1TB, 約202円/月 → 年額見込み: 約2430円

他のPC用バックアップサービスはデータ量無制限が多いので比較が難しいが、僕としては充分に安いと感じる。B2とGCSAを合わせた単価は約USD 0.0015(0.2円)/GB・月相当で、普通のストレージに比べれば随分安い(ただ、それらと同様に気軽にアクセスできる訳ではない)。

気付いたこと・事前の想定と違ったことなど

  • GCSA
    • 日本法人を経由するためか、消費税が掛かるのを意識せずにいて、最終的に請求される料金が当初の想定より1割増えて、思わぬ落とし穴だった。
      • だったら、料金を円建てにして少しは為替変動を吸収して欲しいものだ。まあ、国からの指導(「(消費税含む)税金納めろ!」)※で やってるだけなのかも知れないが。
        • ※そういえば、AWSも日本法人からの請求になったようだ。
        • そうは言っても、(消費税の根拠・規則は知らないが、)海外にあるクラウドを日本で使うのは、国内で「消費」していると言えるのか疑問だ。どこが提供しているにしろ、何らかの役務を国内で利用しているから そうなのか。
        • だけど、海外の店から通販で買って輸入する場合には消費税が掛からないのとは矛盾する気がする。
        • まあ、専門家に聞くしかない。
    • 消費税だけでなく、近頃急に円安になったため、始めた時から結構(約1割)値上がりした。
      • 今のところ、日々の料金の増加は月の2/3くらいが5円、1/3くらいが4円になっている。
    • 当初は気付いていなかった使い方が分かって来た。
      • 料金を大きく増やさずに小まめに少量(例: 1GB以下)の追加バックアップすることが可能。
        • バックアップ前にしている整合性チェックを省けば良い。
          • 大体、1円/回+データ量比例分程度になる。(チェックありだと5円/回+データ量比例分)
          • 整合性チェックは、大量のバックアップをする時などにする。
        • → 今は、必要なら週末に追加バックアップをしている。意図せずに古いデータ領域に追加してしまうことが結構あるため。
          • それをうまく誤魔化す(別の場所に置いて何とかする)作業よりは、普通に一緒に置いてバックアップするほうが楽なので。
  • B2
    • 正味の(事前に期待していた)データ量まで減るか、まだ不明。
      • 履歴(約6か月分)が保存されることもあり、正味のデータ量は30GBなのに対し、今月のprune(履歴削除)処理の前は その5.7倍(170GB)だったのが、prune処理によって2.7倍(80GB)にまで減った。
        • なお、GCSを使い始める時点では約450GB(うろ覚え)だった。
      • かなり減って料金は充分安くなったが、まだ「本物」ではない(正味のデータ量より随分多い)。
        • この増分は、履歴によるのかオーバヘッド(ファイルを削除したため、余計な部分が残って居る)なのか、まだ分かっていない。
      • 今後もprune処理で減るかも知れないので、もう少し様子を見ることにした。
      • もし減らなかったら、新しくバックアップし直すか、そのままか、安い方にする。

 

PS. 本文とは直接関係ないが、バックアップに使っているソフトduplicacyの問題らしきものが一つだけある。: デスクトップでなく、サーバ(VPS)だけで起こることだが、たまにduplicacyのprune(古い履歴の削除)処理が失敗することがある(「(pruneで削除しようとしている)チャンクがない」というエラーが起こる)。数か月に一回くらい起こる。

なかなか原因が分からなかったが、どうやら、clamscanの実行中にduplicacyでpruneかバックアップをすると起こるようだ(バックアップの場合は、そのチャンクがpruneされる時に起こるようだ)。試しに、clamscanの実行中はduplicacyの起動を延期し、逆にduplicacyの実行中はclamscanの起動を延期するようにしたら、起こらなくなった。

ただ、まだそれほど長く確認していないので、関係ない可能性はある。

clamscanの実行中は負荷が高く空きメモリが少ないので、duplicacyの処理やB2のサーバへの通信が異常になってしまうのかと想像しているが、確証はない。また、この問題はデスクトップでは起こらないので、サーバのVPSとの相性のようなものかも知れない。VPSはメモリ量が少ないのでその関係だろうか?

そういえば、プロバイダの保守でVPSのプラットフォーム(ハード+ホスティングソフト?)が更新されてから起こるようになった覚えがあるので、VPSとの関係がありそうだ。どこに聞いたらいいか分からず、難しい。

PS2. 同じくGCSとは関係ない話。: duplicacyに問題はないが、いくつか不満はある。例えば、資料が今一つ(基本的なものはあるけど不充分で、残りはフォーラム(作者(と それらしき人)がtipsとして書いているものが多い)を探して見るしかない)、使い勝手が今一つ(なんか ごちゃごちゃしている → 資料が不充分になる、やりたいことができるか・どうしたらできるか不明、できそうなことができない、バックアップ対象選択フィルタの機能が貧弱)とか、動作・中身が複雑で把握しにくい(→ トラブル時に調査・復旧しにくい)ことだ。

更に、調べていて偶然見付けた、未解決の問題が放置されているのも気になった。おそらくユーザーの使用環境に起因するのだろうが、放置する姿勢が良くない。

これ以外にも、ごく真っ当な修正要望(エラー時にも0を返すのは良くない)にも対応していない。 → 良く居る頑固な開発者のようだ。

そして、先日、別の稿に書いた認証情報の格納方法の件で他にいいもの(例: rcloneのように設定ファイルを暗号化できるもの)がないか探してみたら、duplicacyと同様なカテゴリのものでKopiaというのが見つかった。まだv0.10.7だけど、雰囲気や資料は良さそうなので、しばらく様子を見たい。ただ、これはストレージの認証情報をファイルに平文で書くので、そこが ちゃんとされない限り使えない。

それでも、試してはいないものの、Kopiaには(duplicacyと同様に)CLIとGUIがあるが、duplicacyと違ってGUIも(今は?)無料なので、手軽に使いたい方には いいかも知れない。あと、duplicacyと違って、バックアップストレージをマウントして中身に手軽にアクセスできるのは すごく便利そうだ。

 

(5/23 5:33 少し加筆・修正。PSを追加; 7時 PS2を追加)

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

数か月前に、メモリ使用量が多くなってしまった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

なぜか僕は臭いにも敏感になってしまい、日々闘っているw

とは言え、鼻は良くない(いつも詰まっている)し、自分の臭いだって いろいろあるはずだけど、そういうのには気付かない(たまに、通常とは違う狭い空間に行くと気付くことがある)から、相対的とか主観的な話だ。

近頃は、(以前から書いている)部屋の異臭(外から来る煙草、薬品・農薬のような臭い)が、いろいろな苦労の末に どうにかなりそうだけど、まだ気が抜けない状態(効果の確認中)だ。それとは別に、以前から嫌だった別な臭いに対処した。

それは、一時使っていた(けど、いろいろ ひどいので止めた)iVideoというモバイルプロバイダのレンタルWi-Fiルータなどのソフトケースに付いていた臭いが しつこくて、全然抜けないことだ。: 旧居から引越す前後に使っていたので2年以上経つのだが、引越しの時の梱包で その「臭いケース」を入れた段ボールに一緒に入っていたコード・ケーブル類に臭いが付いてしまって消えないのだ。

更に、引越しの日に、ルータのケースを一時的に車に入れていただけなのに(コード類の箱は大きいから車に載せなかったはずなので上の記述と矛盾するが、貴重品なので気が変わったのか別の時に入れたのかも知れない)、車内にも臭いが付いてしまい、つい近頃まで抜けなかった(今も わずかに臭うことがある)。

ちなみに、引越しの前も その「臭いケース」に困ったので、密封した袋に入れて保管していた。上記の梱包や車に入れる時もそうして居たはずだが、気を抜いたのか、狭い空間で溜まったのか分からないが、臭いが漏れてしまったようだ。

それから、コードの被覆は主に軟質塩ビで、特有の臭いがあると言われているが、僕は気になったことがない。これは、そういう素直な・生易しいものでは ない。

どういう臭いか表現が難しいが、近頃検索して分かったのは「クッサい香水」だ。香水ほど強くはないが、周りのものに まとわり付いて離れない嫌らしい臭いだ。妙なことに、臭いに手触りがあるようで、それに侵されたコードは変な手触り(粘り気のない油っぽさが手に まとわりついて、気持ち悪い)に成り果てて居る。

昔のドラマ風に書くと、「お前なんて うちのコードじゃない! 出てけっ!!」、あるいは、「この薄汚ねえコード、どっから来た!!」って感じだ。全く。

iVideoの発送担当者が そういう下品な香水などを付けていたのか、返却後にケースに散布したと思われる除菌スプレーの類※が そういう臭いだったのかと想像している。

1回だけでなく、数回レンタルした時のケース全部が臭ったので、たまたまではない。

※書いたあとで気付いたが、歯科に行ったら 問題の臭いに似た臭いが身体に付いたので、除菌スプレーの類ではないか。まあ、歯科でどういう薬剤を使っていて、どれがその臭いなのかは不明だが。 (5/18 15:06)

今の家では、その臭いコード類は 口を少し開けた押入れケースに入れておいて、臭いが発散して消えるのを期待していたのだが、丸2年経っても消えないので、業を煮やして何とかしたくなった。

確か、以前も(全部か一部か忘れたが、)水で拭いた気がするが、効果はなかった。ケースの口を少し開けるようにする前には中に脱臭剤を入れて居たが、その効果もなかった。

以下の順に試行錯誤した。4のウォッシャー液までは効果がなかったため、作業を追加して行った。

  1. 全部を台所用除菌アルコールで拭いた。
  2. 窓際に干した
  3. 臭いの消えない数本に掃除用ウェットティシュー、車の洗剤、液体石鹸を試し、効果を比較した。
  4. 全部を車のウォッシャー液で拭いた。
  5. 窓際に干した
  6. 臭いの消えない数本を湯(約60℃)に漬けて試した。
  7. どうしても臭いの消えないものを選別し、隔離した。

最初に台所用アルコールで拭いて干してみた。効果があるものはあったものの駄目なものも多く、今一つだった。それで、手元にあった掃除用ウェットティシュー、車の洗剤、液体石鹸を試したところ、ウェットティシューは少し効果があったが車の洗剤は全く効果がなく、石鹸は多少効果がありそうだったが、それ自体の臭いが付くので却下した。

なお、臭いの有無は、コードを折って平たいループにしたところに鼻を近付け、息を吸って確認した。それぞれのコードを同じ条件で調べるため、なるべく同じ量(長さ)のコードを嗅ぐ必要がある。

どれも今一つだったので、消臭方法を検索してみた。: 一番近いと感じたのは、ビニルのバッグに付いた香水の臭いの取り方だった(それで臭いの表現方法を思い付いた)。方法・使うものとしては、(濃い)アルコール、重曹、クエン酸、塩素・酸素系漂白剤、マイクロファイバーの雑巾、湯などが出て来た。アルコールは(濃度は薄いけど)試していたし、重曹やクエン酸はコードには使いにくいし、漂白剤は扱いにくいので止めた。マイクロファイバーは多少効く気がしたが、そのページは それらの宣伝だったので却下した。

それで、ふと思い付いて(何となく効きそうな気がした)ウォッシャー液を試してみた。成分を見ると、界面活性剤やメタノール※などとなっており、後者には結構危険を感じたが、換気に気を付けて試したら、まあまあ効果があったようだ(実際には、単に長時間干していた効果だったのかも知れない)。

※ウォッシャー液に(エタノールなどでなく)メタノールが入っていることは全く意識して居なかったし、そういうのを人や自転車やバイクも居る道路で噴霧していいのか、結構疑問だ。濃度が薄い訳でもなく、約17%(重量)だった。全部のウォッシャー液が そうではないのかも知れないが、そのうち健康被害の問題になるかも知れない。

なお、湯は熱湯で なかったためか、効果がなかった。長時間煮ないと駄目なのかも知れないし、仮に効果があったとしても、全部を処理するのは大変なので、却下した。

妙なのは、(どの方法でも)処理した直後は効果があっても、時間が経つと臭いがぶり返すことがあることだ。温度も関係しているようで、部屋が暖かくなる(大体25℃以上)と臭いが強く出て来る。それから、臭うコードとそうでないものを近くに置いても、臭いが転移することは少なそうだった。

あと、コードの被覆によって臭いの吸着力が違うようで、臭いが取れないコードが結構あった。例えば、EthernetのTPケーブルは概ね駄目だった。他に比べて被覆が薄い(成分が少し違う?)ことや、長いために臭い成分が付く量が多いのが関係あるのだろうか。あと、JVCやソニーを含むピンコードや、パナを含むACのテーブルタップのコードも駄目だった。これも成分の関係か。そして、いかにも被覆の厚いAC電源コード(3端子のもの)は駄目だった一方で、なぜかUSBケーブルは優秀(「臭いが消えた」の意)だったので、被覆の厚さよりも成分が関係して居そうだ。

そういえば、一緒に入れていた機器(ポケットWi-FiやPCファン)のケースなどやコード類を入れていた押入れケース(PP?)自体は臭くなかったので、軟質塩ビが臭いを吸着しやすいのかも知れない。

一週間近く拭いたり干したりしても埒が開かないので、臭いの消えないものは諦めて隔離し、袋に入れて保管することにした。捨てたいところだが、結構量が多く(全部の1/3-1/2くらい)て もったいないので、他にない時に使えるように そうした。

良くない例えだが、この臭いは、放射性物質同様に半減期が長いのではないだろうか? 少なくとも10年は ありそうだ。その「仮処分」方法も似ている・・・

臭いの有無で分けたコード類は、一旦 元の押入れケースに収めたのだが、通気が悪そうで 臭い(消えたと思っても微妙に残って居るはず)が籠もって減らなそうだったので、段ボールに入れ上面を開放してある程度通気するようにした。それを机から離れた場所に置いた。

これで一旦終了だが、少し経ってから臭いがどうなっているか、調べてみたい。

でも、「臭いコード」は見たくも ないな・・・

 

iVideoには本当に懲り懲りだ!

 

(5/17 12:55 わずかに加筆)

  •  1
  •  0

結構前の話。妙なところで いろいろ細かく、今回は、PCのメインディスプレイの左右の微妙な傾き(0.1°オーダー)が気になって対処した話。

メインディスプレイには90°回転させて縦でも使える仕組みがある。僕には必要ないが、あっても悪くはないと思って居た。が、この機種(EIZO CX241)だけかも知れないが、実は良くなかった。回転させる角度が水平でも垂直でもロックできない(クリックのようなものがない)ので、正確に水平に合わせられないのだ。※ しかも、このディスプレイは、水平にしようと思ってフルに回転させても、水平になるところから少し回転し、その若干ズレたところでに合う癖があるので(支点の精度の問題だろうか)、水平の調整も保持も難しい。あと、横長ディスプレイは左右に長いので、わずかな回転でも端での傾きが目立つことはあるだろう。

※これは一応プロ(写真など)用(僕は それで買ったのでなく、故障時に修理不能で交換品がこれだった)なのに、プロは水平・垂直には無頓着なのか、別のアームで きっちり合わせるのか不明だ。

最初の頃にも気になって、設置・移動したあとは目視で合わせていた(←で水平が合っているかは、今は不明)のだが、何かの拍子に傾いてしまったのに しばらく気付かなかった(この時は高さまでズレていた)。

気付かなかったのには訳がある。ディスプレイは必ずしも正面から見る訳ではなく、少し斜めから見たり、逆に、ディスプレイの面を机の長辺に対して平行に設置して居るとは限らず、そういう時は傾いて見える(もしかしたら水平に見えることもあるだろう)からだ。更に、僕自身の傾きもありそうだ。というのは、撮った写真が(水平を合わせて撮ったつもりなのに)大抵数度(3°以下)傾いているからだ。

写真の傾きがひどい場合、画面で見て調整するが、ディスプレイが傾いていると正しく検出・調整できず、問題がありそうだ。とは言え、上述のように、ディスプレイが水平になっていても他の要因で傾いて見えるので、実際には、ウインドウの枠などから傾き度合いを判定しているのだろう。

そういうことを考えれば、実際には厳密に水平を合わせる必要はないのかも知れないが、性格として気になる。

「曲がっては いかん!」と、物理的・強制的に水平を確保したくなった。それで、ディスプレイの左右の端の下部と机の間にスペーサー(高さ: 約2.1cm)、要するに「つっかい棒」を挟み(写真: 左右の白いもの)、ディスプレイをそれに押し付けることで、概ね水平が合うようにした。実際には、スペーサーの高さの差や入れる位置(前後・左右)によって わずかなズレは出るが、そこは良しとした。これなら、見るだけで水平と高さがズレていないか確認できるので、便利だ^^

おもしろい(というかおもしろくない)のは、こうして水平を合わせると何となく傾いて見えることだ。それまでのズレ(水平より少し進んだとことで止まるため)に慣れているのか、(上述の)僕の傾きなのか、実際にスペーサーの高さが合ってないのか、分からない。

↑ 気になってスマフォのアプリで測ったら、机上に置いた場合とディスプレイの下の縁の段に置いた場合で(0.1°単位で)同じ角度だったので、スペーサーは大丈夫なようだ。なお、スペーサーがなくても目視で合わせられるが、やはり不安定で、水平より「行き過ぎる」(大体0.5°未満)ことがある。

更に興味深いのは、地震があるとディスプレイが浮くのか、スペーサーがズレることだ。少し後ろに行っていることが多い。

スペーサーは、以前から重宝している、楽天のポケットWi-Fiの緩衝材を使った。楽天もポケットWi-Fiも使い物にならなかったが、これとACアダプタとSIM※は役に立っている。(って、結構使えているではないか)w

※と書いていたら、7/1から1GB以下でも0円でなくなるので、SIMも「使えない」ものになった。早く解約しないと。簡単なのだろうか?? (5/13 11:58)

→ 少し様子を見ようと思って居たが、トップの発言を書いた記事を見たら、自分でも具体的に何かは分からないのだが、どうにも「だめだこりゃ」状態になった感じで、即座に解約した。なお、まだサーバは空いていたようで、全く つつがなく解約できた。その簡単さは ありがたかった。 (5/13 18:51)

なお、サブディスプレイは回転しないものの、本体とスタンドの精度で傾いている可能性はある。が、不思議と水平が合っているかは全然気にならない。おそらく、元々机の端にあって僕に向かって画面が斜め(水平方向の回転)になって居るのと、これで写真やドキュメントを見ることがないからだろう。

 

PS1. 大画面で湾曲しているディスプレイに僕は耐えられるのか、興味がある。元々そういうのは邪道なので絶対に嫌だと思っているが、(怖いもの見たさで)実際に使ってみたら どういう印象になるのだろうか?

PS2. 傾きには関係ないが、ディスプレイ繋がりを。: ディスプレイにコードを挿す時、どこにコネクタがあるか分からなくて(コネクタが段の下面に下向きに付いているため)四苦八苦し、首や腰が痛くなるので、別の作業(机の定期オイル塗り)のついでにマスキングテープで目印(ACとHDMI)を貼った。繋ぐコードが多くなければ、これが便利そうだ。

それから、背面にUSBハブを付けた(順序は こっちが先だった)。それまでは、支柱に結束バンドで付けていたのだが、遠くて不便なので手が届きやすいところに両面テープで貼ってみた。ただ、この位置は たまたまHDMIコネクタに重なって、上述のマスキングテープの目印が見やすいところ(上側)に貼れなくなったという落とし穴があった。ハブを剥がして少し動かしたかったが、貼り直すのが面倒なので そのままにした。

ディスプレイの背面にUSBハブを付けた。また、コードを挿す位置を分かりやすくするため、マスキングテープの目印を貼った。

 

昨日だったか、たまたま、ニュースの見出しに「ディスプレイの背面に貼れるUSBハブ」というのがあった。そういうのは、こうして(テキトーな安いのを)両面テープででも貼ればいいと思うが、何か特別な機能でもあるのだろうか?

↑ 記事を見てみたら、VESAのネジ穴に付けられて上下にスライドできるそうな。でも、そのスライド、本当に使うかなあ・・・ それに、VESAのネジ穴に付けるなら、スタンドが付かないのでは? (そこはうまくやってる?) あと、USB3対応のせいもあるが、随分高かった(> 5千円)。まあ、録画用HDDを繋ぐとかにはいいけど、それでも高い気がした。

ただ、TVの録画用HDDならUSBポートに直接繋げばいいから、ハブは要らない気がする。何台も繋ぐ? TVだってポートは2個くらいありそうだが、そうでもないのか? まあ、興味ないし関わりたくないので、どうでもいいやw

一方、PC用として考えると、ますます用途が不明だ。PCのHDDをディスプレイ裏に置くのか? 落ちたりして怖いと思うな。まあ、今は いろいろディスプレイの上や裏に置いて場所を「有効活用」するのが流行っているから、そういうことか。でも、リスクが高いな。他に、webカメラやマイク・スピーカーなどはUSB2で充分だろう。

結局、僕の感覚では、「USB2の安いハブを両面テープで くっ付ければ充分」ということになる。が、まあ、好きなものを使って好きなことをすればいいので、余計な話だ。

  •  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