piu lentoの日々 (piu lento days)

サーバ＊のクラウドストレージ(Backblaze B2)へのバックアップに使っているソフト duplicacyが時々エラーを出していた。※ 調べたら4年近く試行錯誤していたが、最後の対処をしてから半年くらい起こっていないので、ようやく直った感じだ。

＊デスクトップでも使っている。

※随分前に書いた気がするものの、探しても出て来ないので、対策しつつ様子を見ていたのかも知れない。

(耳や臭いの問題と同様に)原因が はっきり分からないのだが、バックアップ中のメモリ不足かディスクアクセス過多、あるいはその両方ではないかと推測している。: 通常は問題ないが、(サーバのハード(仮想マシン)は貧弱なので)他に大量にメモリを使うか頻繁にディスクアクセスをするプロセスが一緒に動いていると、問題が起こるようだ。

現象

• クラウドストレージのprune(古い変更履歴の削除)処理時に、いくつかのチャンク(ブロック)が ないというエラーが出る。
  • エラーメッセージの例(発生し始めた頃のもの, 一部改変した)

2019-07-17 03:41:18.960 ERROR CHUNK_DELETE Failed to fossilize
the chunk fdXXXXXX: URL request 'https://YYYY.backblazeb2.com/b2api/v1/b2_hide_file' returned 400 File not present: chunks/fd/XXXXXX

• • そのチャンクを含むリビジョン(履歴)を削除するかexhaustive prune処理を実行すると、エラーは出なくなる。
• 問題のリビジョンのバックアップ時にはエラーは出ていない。

謎と検討

妙なのは、デスクトップとサーバで同じようにバックアップしているのに、サーバだけでエラーが起こることだ。しかも、サーバ(VPS)のハードが交換された あとから起こるようになった。 ← 実は その前から起こっていた。(記録のために残す)

そのことから、(OSは同様なので、)サーバとデスクトップのハード(リソースや性能)の違いが関係している可能性がある。

対処

半年くらい前(2022/11)に以下のように対処したら、問題が起こらなくなった。

• duplicacyのバックアップ処理のパラメタを調整し、使用メモリ量を減らすようにした。
  • オプションに -max-in-memory-entries 51200 を指定した。
    • → 使用メモリ量が200MB前後になった。 (無指定時は600MB以上になる場合があった。: 下を参照)
    • 値を減らすと使用メモリ量は減るが、比例は しない(下限がある?)ようで、10240と かなり小さくしても200MBは使うようだ。
• バックアップ処理と、メモリを大量に使用してディスクアクセスが頻繁なclamscan(ウイルススキャンソフト)が同時に動かないようにした。
  • どちらもcrontabで定期的に起動している(周期や時刻は異なるが、どちらも実行時間が長いので同時に動く可能性がある)ので、起動前に片方が実行中の場合はスキップし、次回まで延期するようにした(片方が終わるまで延々と延期する)。
    • 今気付いたが、微妙なタイミング(例: たまたま2つが同時に起動時刻になった場合)で同時に起動してしまう場合があるかも知れない。 ← プログラム(スレッドやプロセス)でないので、開始時刻(分)を違えておけば大丈夫そうだ。
  • こちらは上より先に実施したが、問題が全く起こらなくなる訳ではなかったようだ。

分かった切っ掛け

対処方法が分かった(問題が起こらないようにできた)切っ掛けは、ある時のduplicacyの更新内容に「使用メモリ量の削減」というものがあったことだ。※ もしかすると、他の方がメモリ不足でのトラブルを報告したのかと思った。

※僕はそれまで、duplicacyがメモリを大量に使用する可能性があるとは全く意識していなかった。想像だが、duplicacyの重複排除処理(重複ブロック(チャンク)の検索?)でメモリを使うのではないか。

なお、更新されたduplicacyのストレージ(スナップショット/リビジョン)は新しいフォーマットになって使用メモリ量が少なくなるというので、全部のスナップショットが入れ替わるまで(変更履歴の保存期間が過ぎるまで)使用メモリ量の変化を見ていたが、余り減らなかった。最初(duplicacyを更新した直後)が一番減った気がする。

それで、duplicacyと一緒にclamscanが動く時にメモリ不足になって、エラーの原因になるのではないかと推測した。ただ、OSのログにはメモリ不足関連のエラーは出ていないので、正確には、実メモリ(RAM)が不足して仮想記憶(ディスク)が使用されて(スワップ)、処理が遅くなってエラーの原因が発生するのではないだろうか。

duplicacyのエラーメッセージから考えて、原因はバックアップ時にチャンクがクラウドストレージに保存されないことがある(ただ、その時にエラーは出ない)というものだろうから、実メモリが不足してスワップが起こると処理が遅くなって、チャンクのクラウドストレージへの送信が失敗するのではないかと推測している。

処理が遅くなって送信が失敗することがあるとは思えないが、例えば通信のタイムアウトやリトライ処理のタイムアウトなどであろうか。前者とすれば、送信するチャンクのデータをメモリにバッファリングせず、ディスクから読み出しながら送っていて、たまに遅くなると送れないことがある? : いずれにしても、duplicacyの処理のロバスト性が今一つなのかも知れない。

そう言えば、以前duplicacyのフォーラムを調べたら、僕と同様に「チャンクがない」というエラーが出る方が問い合わせていたが、結局「再現せず」や本質的でない回答のあとは放置されて、解決していなかった。

そしてその方は怒っていた気がする。: その方のKopiaのフォーラムへの投稿からduplicacyに戻って、上の問題を知った覚えがある。

そこで、試しにduplicacyのバックアップ時の使用メモリ量の表示をさせてみたら※、600MB以上消費する場合があることが分かった。普通は それくらいは問題ないのだが、サーバのメモリ量は1GBと少ないので＊、他のソフトも大量に使用するとスワップが起こりそうだ。なお、prune時は使用メモリ量は小さく、100MB以下だった。

※メモリ量削減と一緒に そういう機能が追加された。

＊以前、たまにメモリ不足の問題が起こっていたため、仮想記憶(スワップ)を有効にしていた。その問題が何だったか思い出せないが、やっぱりduplicacyだったのかも知れない。

メモリ不足の他には、duplicacyもclamscanもディスクアクセスが頻繁なために処理が遅くなって、上と同様にチャンクのクラウドストレージへの送信が失敗する可能性も考えられる。更に、メモリ不足と頻繁なディスクアクセスが一緒になると、余計処理が遅くなって更にひどいことになりそうだ。

ちなみに、過去1年のサーバの稼働状況を調べたところ、duplicacyの使用メモリ量を制限した頃からスワップ頻度(ページ/s, 下の左のグラフ: 中央辺りから制限した)が減ったようだ。ディスクI/O頻度(回数/s, 同右)に関しては変化は少なく、逆に少し増えた感じだ(ただし、なぜか今年4月以降は小さくなっている)。ディスクを複数プロセスで同時に使うと、効率が低下して全体的な性能が低下するためだろうか。

グラフから、duplicacyのメモリ使用量が大きくてスワップが多かったことは確かそうだ。

※なお、同じ期間のメモリの状態(memory usage)、ディスク動作率(utilization)、ディスクの遅延(latency)、NWの通信速度、システム負荷(load average)に目立った変化は なかったので、グラフは省略した。

考察

いずれにしても、送信失敗時にエラーが出るはず・べきだが出ないのはduplicacyの問題(異常時の処理が甘い)か、これらが原因ではないかの どちらかだろう。

今後問題が再発すれば後者だし、逆に、duplicacyの使用メモリ量の制限を止め、常にclamscanと一緒に動かして問題が起これば、僕の推測が正しいことが分かる。が、面倒だし ほとんど無意味(僕が作ったものでないし、サポートが やる気ない: おそらく「環境の問題」で終わり)なのでやる気は しない。

もしduplicacyの問題だとしたら、「バックアップしたつもりなのに(エラーになっていないのに)、できてなかった」という、結構ひどいものだ。が、起こるのは限られた環境のようだし、駄目になるのは一部のファイルだけなので、致命的とまでは言えなさそうだ。でも、これは遊びのソフトじゃないので、重大な信頼性の欠陥だと思う。

補足すると、特定の環境・状況で処理が失敗するのは仕方ない(すべての環境・状況で使えるものは作れない)が、使った時に失敗したことが分からないのが問題だ。

そう言えば、作者は こういうエラーメッセージ関係の重要性を軽視しているようで、以前、「エラーメッセージ(か終了コード)が誤解する・分かりにくいから変更して欲しい」という要求を拒否していた。

これは単なる表示・見た目の問題ではない。ちゃんと作る(起こり得る すべての失敗を想定・想像する)のは大変だが、製品には必要だ。

試行錯誤

対処方法が分かるまでに以下を試したが、ほとんど効果がなかった。若干良くなるように見えたが、問題は起こった。

• バックアップ時の送信スレッド数を減らす。: デフォルト: 4個 → 1個 (-threads 1)
• バックアップ時の送信速度を下げる。: 約250kB/s (-limit-rate 250)など
• B2のメンテナンス時間帯(毎週1回)のバックアップを避ける。

これより、問題の原因はduplicacy単体ではない可能性が高いことが推察される。 ← 上も動作環境(NWやB2)が関係していることを推測して行ったので、これは言えない。 (22:11)

 

余談

何度か この件をduplicacyに問い合わせようと思ったが、ハードが関係していそうだし、上述のようにサポートが余り親切・適切でなさそうで解決する見込みがないので、止めていた。そして、もし僕の推測した原因が正しかったら、問い合わせても全く解決せず、(いつものように)ただイライラするだけだっただろう。

duplicacyは通常時は問題なく動作しているのだが、上に書いたように異常対応やロバスト性が心許ない気がしているし、サポートの態度にも問題がある。あと、バックアップの対象・除外設定と動作が複雑で頭が狂ってしまう。

そこで、以前書いたKopiaなど新しいバックアップソフトを検討したいが なかなか面倒だし、そっちが良い保証もない。他に やることが溜まっているので、検討するとしても来年と考えている。

 

PS. 書く前は手短かに終わらせようと思って居たが、長くなったし熱くなった(ムカついた)。調べたら長年苦労して来たし、作者がテキトーなのを思い出したせいだ。それにしても、国内・国外関係なく、いい加減なソフト屋が多い。ハードも同様だ(以前も同じことを書いた)。

気が向いたので、ちょっとKopia(クラウドストレージ対応のバックアッププログラム)を いじってみた。(「いじった」程度なので今後変わる可能性はあるが、)結構気に入った。今使っているduplicacyより ずっと使いやすい印象だ。

まず、ドキュメントが しっかりしていて分かりやすいし、GUIは気軽・手軽に使えるし(ちょっと試すのに充分良い)、CLIはduplicacyと違って「すっ」と(自然・普通に)使える。もちろん、その出力も分かりやすい。

duplicacyは ほとんど真逆で、ドキュメントは貧弱かつ分散している(いつも探す羽目になる)、(GUIは有料なので使ったことがない、)CLIは何度使っても分かりにくく、引数の指定も すぐには分からず、間違いやすいから神経を遣うし、出力だって分かりやすいとは言えない。。。

なお、現在のKopiaのGUIは(僕を含む多く?の人が大嫌いな)Electronベースだが、Goで作る計画もあるようだ。ただ、今でも、web版(サーバーモードで動かす)なら(大食らいの)Electronを使わずに済む。

事前に調べて気になって居た、ストレージの認証情報(キー、パスワード)が設定ファイルに平文で書き込まれるためにセキュリティ上の不安がある件は、それらを環境変数からも取れそうなので 何とかなりそうだ。

バックアップ対象(基本的に除外)の設定はgit(gitignore)と同様とのことで、(duplicacyより)機能は少ないものの、設定(想定)どおりに動く印象だ。設定ルールはサイトには詳しく書いてないが、gitignoreのドキュメントを見れば分かりそうだ。そもそも、gitignoreは いつも使っているからとっつきやすく、単純明快なのがいい。

duplicacyはバックアップ対象指定の機能は多い(対象/除外それぞれにワイルドカード/正規表現での指定が可能)ものの、そのせいで設定がグチャグチャになり、そのうえ謎が多くて、どう設定すれば思ったように動くのか分からず(対象と除外の順序関係が難しい)、いつも試行錯誤している。

そんなことになるのなら、Kopiaのように既存のものを使って、作る手間も使う手間も省くほうがずっと賢い。

バックアップ対象設定の動作確認も、duplicacyより ずっと やりやすい。duplicacyはdry-run+デバッグモード(上記のように設定が謎なので、「どうしてそうなった?」を出す必要がある)で起動して、長くて見にくい出力をチェックしなくてはいけないが、Kopia(コマンド: kopia snapshot estimate --show-files)は出力が簡潔なので、見ればすぐに分かる。もちろん、バックアップ対象のファイルが多い場合は出力も長くなるが、duplicacyよりは ずっと分かりやすそうだ。

という訳で、試す価値は充分ありそうなので、更にいろいろやってみたい。

なお、Kopiaは まだV0.11なので、正式に使うのには適さないと思うが(とは言え、ちゃんと使っているユーザーは多そうだ)、まあ、その分ゆっくり試せるとも言える。

 

PS. Kopiaはduplicacyより ずっと使いやすいものの、どちらも使ったことがない場合は、最初に これらの動作(バックアップ方法)の概念や概要や用語を理解する必要がある。これらは普通のファイル単位のバックアッププログラムと違う(対象をブロック化し、重複排除し、変更履歴を保存して格納する)ので、そこがハードルになるかも知れない。が、一旦分かれば、どちらも基本的には同様である。

PS2. わがままなので、まだちゃんと使ってもいないのに、「実はKopiaよりもっと いいものがあるのではないか?」などと思ったりもするが、まあ、それも おいおい調べてみたい。とは言え、最高のものでなくても、duplicacyより使いやすければ それで充分という気は大いにする。

 

(2023/5/8 14:30 誤記を修正)

ローカルでないバックアップは、duplicacyでクラウドストレージBackblaze B2 (以下、B2)とGoogle Cloud Storage Archive (以下、GCSA)に保存している。先日、そのB2の安価な代替が見つかった。

とは言え、現在B2に入れているデータ量は約75GBと とても少なく、月額料金はUSD 1未満(例: USD 0.4)なので、移行する必要性はない。

ちなみに、B2は月額料金が余りに安い場合は請求を延期するようだ(先月の請求が なかった)。クレジットカードの手数料が高く付くからだろうか。そのうち、「使用量が小さ過ぎるので、もっと使わないと退会になります」とか言われなければいいがｗ

それはiDrive e2で、ストレージの単価がUSD 0.004/GB/月※と、B2のUSD 0.005/GB/月より少し安い。それよりも魅力的なのは、ストレージの処理・操作やデータ転送が無料＊なことだ。一方、B2は処理・操作回数やダウンロードデータ量に応じて課金される。

※年払いの1TBのプラン(料金: USD 40)では、USD 0.0033/GB/月相当になる。なお、このプランの初年の料金はUSD 4である。

＊ダウンロードに関しては、「通常の範囲で」("good fit")のような制限がある。具体的には、保存しているデータ量の3倍までならOKで、普通に使うには充分そうだ。

データ転送が基本的に無料であれば、(滅多にないし、やりたくないが、)リストアが気軽にできる。

とは言え、90%以上(約1TB)のデータはGCSAに入っているので、フルリストアの費用は安くならない(GCSAからのダウンロードは超高い!)。が、今 B2に入れている基本的・アクティブな部分のリストアが無料になるのは、それなりにありがたい気がする。

また、具体的な案はないが、バックアップ以外の用途にも使えるかも知れない。

それから、細かいけど、10GB/月まで無料なのもありがたい。B2は、最初の試用期間が過ぎたら全部課金される。

こうして比べると、(今となっては)B2のセコさが目立つ。昔は他がなかった(高いAWSやGoogleなどが相手だった)ので良かったのだが、それに胡座をかいている(実際は そうではないのだろうが)うちに追い越されてしまうのではないか?

B2はアーカイブもやってないし、もう少し周りを見てアップデートする気はないのだろうか? 先日上場して一段落したのか、それで余り冒険ができなくなったのか。

「悪くないな」と思ったのだが、実はiDriveはB2にする前に少し試して止めたのを思い出した。が、それはe2とは異なるもので、ファイルベースのバックアップ用ストレージだった。e2はオブジェクトストレージというもので、基本的にブロック単位で格納するため、ファイルシステム的な機能は余りない。

気になる点は、速度、セキュリティ、使い勝手、継続性などであるが、多くは使ってみないと分からない。

以前の記録を見たところ、上記のファイルベースのiDriveは速かったようだ。ただ、ファイルシステムがWindowsを前提にしていてLinuxから使うには不便だった(例: sym-linkがない)ので止めた。

上述のように、e2はオブジェクトストレージなので、ファイルをブロック化してバックアップするduplicacyから使う分にはファイルシステム的な問題はない。

なので、今は いろいろ延期しまくっているTODOがあるものの、おいおい試してみたい。丁度、先日書いたKopiaというバックアップソフトも試したいので、それで使ってみたい。10GBまで無料なので気軽に試せるのがいい。

 

てな訳で、充分良いと思って使っていたB2ですら他に取って代わられる可能性が出るなど、クラウド関係のサービスは常時変わっていて、時々でもチェックしていれば 安くていいものが見付かることがある。※ が、一方で、新しいサービスがすぐに終わるということもあるので、そこら辺の見極めも重要だ。と言っても、外から事前に分かるものでもないので、いつでも乗り換えられるような仕組みや体制にしておくのがいいのだろう。

※ソフトも同様に、(僕の中では 設定が面倒臭くて謎の多い)duplicacyがKopiaに取って代わられる可能性がある。

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

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

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

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

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

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

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

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

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

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

これは推測だが、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に既に入って居るが、どういう関係なのかは分からない。 (やっぱり、面倒だってことしか分かってないｗ)

 

↓

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