piu lentoの日々 (piu lento days)

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

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

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

概要

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

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

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

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

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

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

主な機能・仕様

• スマフォやデジカメなど(以下、デバイス)から新しい画像など(以下、メディア)を(可能な場合は自動で)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. 書いてから、「別に予告なんてしなくてもいいじゃん(単なる自己満足だよ)」と思ったものの、中学の先生が、「すること・しようと思っていることを予め周りに言うと、(しなくちゃならない状況になって、)本当に実行できる」というようなことを言っていたのを思い出したので、そういう意味で この予告は意味があるのだろう。

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

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

 

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

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

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

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

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

機能追加・拡張案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℃以上は補正の調整が不要になる感じだが、そこで(いかにもデジタルにｗ)階段的に切り替えはできない(そうすると、切り替え点付近の値が不安定になる)ので、もう少し測定して「うまい具合」の補正式にしたい。

 

高血圧

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

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

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

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

 

白内障・飛蚊症・老眼

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

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

    • 

      テープなどを使わずに、簡単にカーテンのフックを延長する・2枚重ねる方法

      

      (左の方法を思い付く前) カーテンのフック2個をダクトテープで繋げてフックを延長した。

      

      同、片側の分を延長したところ。

      
      

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

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

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

 

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

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

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

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

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

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

 

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

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

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

 

鳩問題

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

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

 

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

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

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

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

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

 

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

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

 

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

使っているデビットカードが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 少し修正・加筆)

デスクトップ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を追加)

先日気付いた(というか、それまでは「まあいいか」にしていた)、バックアッププログラム(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アンロックプログラムは思ったより複雑になった(その前に作った環境セットアッププログラムはもっと複雑だ)。僕が求め過ぎるためにそうなるのか、もっと単純・簡単な方法があるのか、今は分からない(そして、「ちゃんと使えれば良し」で そのままに・・・ｗ)。

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

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

 

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

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

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

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

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

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