fix(i18n): overhaul Japanese translations, localise pending UI labels, and update documentation

- Overhaul Japanese translation catalogue and synchronize with current documentation
- Localise pending UI labels across dialogues, panels, and settings
- Add Japanese translation mapping for provisional LiveSync messages
- Update and refine all Japanese documentation files
- Strip weak ETag prefix in ObsHttpHandler for object storage compatibility
This commit is contained in:
Chihiro WATANABE committed 2026-11-04 10:38:55 +09:00
1 parent 0fe7d82f46
commit 5ffa3b76ed
32 files changed
+6154 -1549

No files matched your search

+105 -58
View File
@@ -1,93 +1,140 @@
# Quick setup
このプラグインには、いろいろな状況に対応するための非常に多くの設定オプションがあります。しかし、実際に使用する設定項目はそれほど多くはありません。そこで、初期設定を簡略化するために、「セットアップウィザード」を実装しています。
※なお、次のデバイスからは、`現在の設定をセットアップURIにコピー`と`セットアップURIで接続`を使ってセットアップしてください。
# クイックセットアップ
[英語版](./quick_setup.md) - [中国語版](./quick_setup_cn.md)
## Wizardの使い方
`🧙‍♂️ Setup wizard` から開きます。もしセットアップされていなかったり、同期設定が何も有効になっていない場合はデフォルトで開いています。
このガイドでは、最初のデバイスで通常のノート同期を開始し、その後、別のデバイスを追加します。オプション機能は、この基本的な同期が動作することを確認してから設定してください。
![](../images/quick_setup_1.png)
開始前に、次の準備をしてください。
### Discard the existing configuration and set up
今設定されている内容をいったん全部消してから、ウィザードを始めます。
- 対象となるすべての Vault をバックアップする。
- Obsidian Sync、iCloud 同期、および同じ Vault に書き込む他のサービスを無効にする。
- リモートサービスとセットアップ URI を用意する。
- セットアップ URI とそのパスフレーズを別々に保管する。
### Do not discard the existing configuration and set up
今の設定を消さずにウィザードを開始します。
たとえ設定されていたとしても、ウィザードモードではすべての設定を見ることができません。
この手順では、推奨されるプロビジョニング済み CouchDB の手順を説明します。サーバーとセットアップ URI の準備方法は[こちら](./setup_own_server_ja.md)を参照してください。
いずれかのNextを押すと、設定画面がウィザードモードになります。
## セットアップ URI の内容
### Wizardモード
セットアップ URI は `obsidian://setuplivesync?settings=` で始まります。認証情報を含む接続設定が暗号化されて格納されていますが、暗号化されていても URI 自体を安全に保管してください。
![](../images/quick_setup_2.png)
セットアップ URI 用のパスフレーズは URI を復号するためのものです。同期データを保護する Vault 暗号化パスフレーズとは別のものです。両方を安全に保管し、URI とそのパスフレーズを同じ経路で送らないでください。
順番に設定を行っていきます。
## 1台目のデバイスをセットアップする
## Remote Database configuration
リモートデータベースが新規の場合、またはサーバー全体を再構築する際にこのデバイスを明示的に正本とする場合に限り、この手順を使ってください。
### Remote databaseの設定
セットアップしたデータベースの情報を入力していきます。
1. 対象の Vault に Self-hosted LiveSync をインストールして有効にします。
2. `Welcome to Self-hosted LiveSync` 通知を選び、オンボーディングを開きます。
3. `I am setting this up for the first time` を選び、新しい同期をセットアップすることを確認します。
4. `Connection Method` で `Use a Setup URI (Recommended)` を選びます。
5. セットアップ URI を貼り付け、URI 用のパスフレーズを入力して `Test Settings and Continue` を選びます。
![](../images/quick_setup_3.png)
![暗号化されたセットアップ URI とマスクされたパスフレーズ](../images/quick-setup/guide-quick-setup-first-setup-uri.png)
これらはデータベースをセットアップした際に決めた情報です。
6. `Setup Complete: Preparing to Initialise Server` の内容を確認し、`Restart and Initialise Server` を選びます。
### Test database connectionとCheck database configuration
ここで、データベースへの接続状況と、データベース設定を確認します。
![](../images/quick_setup_5.png)
![1台目のサーバー初期化の確認](../images/quick-setup/guide-quick-setup-first-initialise.png)
#### Test Database Connection
データベースに接続できるか自体を確認します。失敗する場合はいくつか理由がありますが、一度Check database configurationを行ってそちらでも失敗するか確認してください。
7. 最終的な上書き警告をよく読みます。バックアップがあり、リモートデータを置き換える意図があることを確認してから、`I Understand, Overwrite Server` を選びます。
#### Check database configuration
データベースの設定を確認し、不備がある場合はその場で修正します。
![サーバー上書きの最終確認](../images/quick-setup/guide-quick-setup-first-rebuild-confirmation.png)
![](../images/quick_setup_6.png)
8. 新規に用意したデータベースでは、`No Synchronisation Settings Found` と表示される場合があります。新しいデータベースであることが確かな場合は、`Use this device's settings` を選びます。既存の設定があるはずなら、キャンセルして接続先のリモートを確認してください。キャンセルすると、Vault とデータベースへの反映を一時停止した状態で再起動します。リモートを確認するまで LiveSync を無効のままにしてください。`Could Not Read Synchronisation Settings` と表示された場合は再試行するか、このデバイスの設定を使って上書きを続行します。上書きには正常な接続が必要です。
この項目は接続先によって異なる場合があります。上記の場合、みっつのFixボタンを順にすべて押してください。
Fixボタンがなくなり、すべてチェックマークになれば完了です。
![新規データベースで想定されるリモート設定なしの選択肢](../images/quick-setup/guide-quick-setup-missing-remote-configuration.png)
### 機密性設定
9. `All optional features are disabled` の確認に進みます。通常の同期経路を確認するまで、オプション機能は無効のままにしてください。
10. 初期化と、要求された再起動が完了するまで待ちます。LiveSync の進捗表示が消えるまで Obsidian を開いたままにしてください。
![](../images/quick_setup_4.png)
別のデバイスを追加する前に、通常のテストノートを作成し、アップロードが完了するまで待ちます。
意図しないデータベースの暴露に備えて、End to End Encryptionを有効にします。この項目を有効にした場合、デバイスを出る瞬間にノートの内容が暗号化されます。`Path Obfuscation`を有効にすると、ファイル名も難読化されます。現在は安定しているため、こちらも推奨されます。
暗号化には256bitのAES-GCMを採用しています。
これらの設定は、あなたが閉じたネットワークの内側にいて、かつ第三者からアクセスされない事が明確な場合には無効にできます。
## 別のデバイス用のセットアップ URI を作成する
動作中の1台目のデバイスで、追加デバイス用のセットアップ URI を作成します。サーバーのプロビジョニング時に作成した URI を使い回すのではなく、1台目で実際に使われている設定を取り込めます。
![](../images/quick_setup_7.png)
1. 1台目で Obsidian のコマンドパレットを開きます。
2. `Self-hosted LiveSync: Copy settings as a new Setup URI` を実行します。
3. URI を保護する新しいパスフレーズを入力し、`OK` を選びます。
### Next
次へ進みます
![追加デバイス用 URI のマスクされたパスフレーズ](../images/quick-setup/guide-quick-setup-copy-setup-uri-passphrase.png)
### Discard exist database and proceed
すでにRemote databaseがある場合、Remote databaseの内容を破棄してから次へ進みます
4. 生成されたセットアップ URI をコピーし、`OK` を選びます。
![動作中の1台目で生成したセットアップ URI](../images/quick-setup/guide-quick-setup-copy-setup-uri-result.png)
## Sync Settings
最後に同期方法の設定を行います。
新しい URI とそのパスフレーズは別々に保管してください。URI は暗号化されていますが、認証情報と Vault 設定を含むため、引き続き安全に扱ってください。
![](../images/quick_setup_9_1.png)
## 別のデバイスを追加する
Presetsから、いずれかの同期方法を選び`Apply`を行うと、必要に応じてローカル・リモートのデータベースを初期化・構築します。
「All done!」(日本語環境では「完了!」)と表示されれば完了です。自動的に、「現在の設定をセットアップURIにコピー」のダイアログが開き、Setup URIを暗号化するためのパスフレーズを求められます(このパスフレーズはSetup URIを暗号化するためのもので、Vault自体の暗号化キーではありません)。
パスフレーズを入力すると、クリップボードにSetup URIが保存されますので、これを2台目以降のデバイスに何らかの方法で転送してください。
新しい Vault、または別途バックアップした Vault を使ってください。未同期のノートがある本番 Vault は、[Fast Setup の選択肢](./tips/fast-setup_ja.md)を確認せずに使用しないでください。
![](../images/quick_setup_10.png)
1. Self-hosted LiveSync をインストールして有効にします。
2. `Welcome to Self-hosted LiveSync` 通知からオンボーディングを開きます。
3. `I am adding a device to an existing synchronisation setup` を選び、デバイスを追加することを確認します。
4. `Device Setup Method` で `Use a Setup URI (Recommended)` を選びます。
5. 1台目で作成した新しいセットアップ URI を貼り付け、URI 用のパスフレーズを入力して `Test Settings and Continue` を選びます。
6. `Setup Complete: Preparing to Fetch Synchronisation Data` の内容を確認し、`Restart and Fetch Data` を選びます。
お好みのパスフレーズを設定してください。
クリップボードにSetup URIが保存されますので、これを2台目以降のデバイスに何らかの方法で転送してください。
![追加デバイスでのデータ取得確認](../images/quick-setup/guide-quick-setup-second-fetch.png)
# 2台目以降の設定方法
2台目の端末にSelf-hosted LiveSyncをインストールしたあと、コマンドパレットから`Use the copied setup URI (Formerly Open setup URI)`を選択し、転送したsetup URIを入力します。その後、パスフレーズを入力するとセットアップ用のウィザードが開きます。
下記のように答えてください。
7. 新規または空の Vault では `Overwrite all with remote files` を選びます。ローカルの作業がある Vault では操作を止め、[Fast Setup ガイド](./tips/fast-setup_ja.md)から適切な方法を選んでください。
- `Importing LiveSync's conf, OK?` に `Yes`
- `How would you like to set it up?` に `Set it up as secondary or subsequent device`
![Fast Setup のデータ取得方法の選択肢](../images/quick-setup/guide-quick-setup-retrieval-method.png)
これで設定が反映され、レプリケーションが開始されます。
8. 追加のローカルファイルの扱いを尋ねられたら、保守的な選択肢は `Keep local files even if not on remote` です。ローカル Vault を破棄してリモートと完全に同じ状態にする意図がある場合に限り、削除する選択肢を使ってください。
> [!TIP]
> **ファストセットアップ (Fast Setup)**
> 近年のバージョンでは、セットアップURIの読み込みやデータの全取得(Fetch All)を実行した際、より簡単に同期戦略を選択して即座に初期同期を完了できる **ファストセットアップ (Simple Fetch)** フローが利用できます。詳細は [ファストセットアップガイド](./tips/fast-setup_ja.md) をご参照ください。
![追加デバイスでのローカルファイルの扱い](../images/quick-setup/guide-quick-setup-local-file-policy.png)
9. データ取得、ファイルへの反映、および要求された再起動が完了するまで待ちます。LiveSync の進捗表示が消えるまで Obsidian を開いたままにしてください。
1台目で作成したテストノートが変更されずに表示されることを確認します。次に、新しいデバイスで2つ目の通常ノートを作成または編集し、1台目に届くことを確認します。
![プロビジョニング済み URI を使って同期された通常ノート](../images/quick-setup/guide-quick-setup-synchronised-note.png)
## 通常の同期が動作した後
オプション機能は、どの機能が管理するかと初期化の方向を明確にするため、1つずつ追加してください。
- 選択した非表示ファイルやフォルダーには[非表示ファイル同期](./tips/hidden-file-sync.md)を使用します。
- Obsidian のカスタマイズ設定には[カスタマイズ同期](./settings_ja.md#6-customisation-sync-advanced)を使用します。
同じファイルに両方の機能を有効にしないでください。
## 1台目で CouchDB を手動設定する
この方法は CouchDB の準備ができていて、セットアップ URI を利用できない場合に使います。表示されるオンボーディング画面で1台目を設定する手順であり、CouchDB サーバーのプロビジョニングや修復は行いません。後続のデバイスには、認証情報を再入力するのではなく、この1台目で動作確認後に作成したセットアップ URI を使ってください。
1. 対象の Vault に Self-hosted LiveSync をインストールして有効にします。
2. `Welcome to Self-hosted LiveSync` 通知を選び、`I am setting this up for the first time` を選択して、新しい同期をセットアップすることを確認します。
3. `Connection Method` で `Configure a remote manually`、続けて `Proceed with manual configuration` を選びます。
![オンボーディングでのリモート手動設定](../images/couchdb-manual/guide-couchdb-manual-connection-method.png)
4. `End-to-End Encryption` で同期データの保護方法を決めます。
- 通常の新規 Vault では `End-to-End Encryption` を有効にし、強力な Vault 暗号化パスフレーズを入力します。
- リモートドキュメントのプロパティも隠す場合は `Obfuscate Properties` を有効にします。
- Vault 暗号化パスフレーズは安全に保管してください。セットアップ URI を保護するパスフレーズとは別のものです。
![パスフレーズをマスクした CouchDB の Vault 暗号化設定](../images/couchdb-manual/guide-couchdb-manual-encryption.png)
5. `Choose a synchronisation remote` で `CouchDB` を選び、`Continue to CouchDB setup` を選びます。
![同期リモート一覧の CouchDB](../images/couchdb-manual/guide-couchdb-manual-remote-selection.png)
6. CouchDB の完全な URL、ユーザー名、パスワード、データベース名を入力します。
- Obsidian Mobile では HTTPS が必要です。HTTP は、デスクトップから信頼できるローカル接続を行う場合に限り使用できます。
- 選択したデータベースへの接続が許可された認証情報を使います。1台目を設定する際、データベースが存在しなければ作成できる権限も必要です。
![パスワードをマスクした CouchDB 接続情報](../images/couchdb-manual/guide-couchdb-manual-connection-details.png)
7. `Check server requirements` は任意です。表示中の認証情報を Obsidian の内部リクエスト API 経由で設定済みサーバーへ送信します。一部の検査には CouchDB 管理者権限が必要です。最初の検査は読み取り専用です。サーバー変更が提案された場合は、個々の変更内容を確認してから別途承認してください。
![CouchDB サーバー要件の検査成功例](../images/couchdb-manual/guide-couchdb-manual-server-requirements.png)
8. `Create or connect to database and continue` を選びます。オンボーディングを続けるには、この接続テストに成功する必要があります。
9. `Setup Complete: Preparing to Initialise Server` の内容を確認し、`Restart and Initialise Server` を選びます。
10. 最終的な上書き警告を読みます。このデバイスを正本とする意図があり、最新のバックアップがある場合に限り、`I Understand, Overwrite Server` を選びます。
11. 新規作成したデータベースでは `No Synchronisation Settings Found` と表示される場合があります。この新規データベースであることが確かな場合は、`Use this device's settings` を選びます。既存の設定があるはずなら、キャンセルして接続先を確認してください。キャンセル後は Vault とデータベースへの反映を一時停止した状態で再起動するため、リモートを確認するまで LiveSync を無効のままにしてください。`Could Not Read Synchronisation Settings` と表示された場合は再試行するか、このデバイスの設定を使って上書きを続行します。上書きには正常な接続が必要です。
12. `All optional features are disabled` の確認に進み、初期化の進捗が消えるまで Obsidian を開いたままにしてください。
通常のテストノートを作成し、同期されることを確認します。CouchDB に届いたら、[別のデバイス用のセットアップ URI を作成する](#別のデバイス用のセットアップ-uri-を作成する)、続けて[別のデバイスを追加する](#別のデバイスを追加する)に進んでください。これにより、2台目の設定を、1台目で実際に適用されたリモートプロファイルと暗号化設定に合わせられます。
+1495 -373
View File
File diff suppressed because it is too large. Load diff
+28 -27
View File
@@ -1,7 +1,7 @@
# IBM Cloudantのセットアップ
# IBM Cloudant のセットアップ
## インスタンスの作成
下記の手順で、試用のためにIBM Cloudantのインスタンスを作成できます。
下記の手順で、試用のために IBM Cloudant のインスタンスを作成できます。
1. 「リソースの作成」ボタンをクリックします。
@@ -10,70 +10,71 @@
1. カタログが開くので、「Cloudant」と検索してください。出てきた選択肢をクリックすると作成画面に進みます。
![step 2](../instruction_images/cloudant_2.png)
1. Liteプランを選択してください。
1. 無料の Lite プランを選択してください。
![step 3](../instruction_images/cloudant_3.png)
1. リージョンと環境を選択します。LiteではMultitenantしか選択できないので、Multitenantを選択してください。デフォルトで選択されています。
1. リージョンと環境を選択します。Lite では Multitenant しか選択できないので、Multitenant を選択してください。デフォルトで選択されています。
リージョンはお好みの場所で作成してください。
![step 4](../instruction_images/cloudant_4.png)
3. "Authentication Method"で「IAM and legacy credentials」を選択します。
1. "Authentication Method"で「IAM and legacy credentials」を選択します。
![step 5](../instruction_images/cloudant_5.png)
4. Liteプランが選択されていることと、Capacityを確認します。
1. Lite プランが選択されていることと、Capacity を確認します。
![step 6](../instruction_images/cloudant_6.png)
5. 確認ができたら、右側のCreateボタンをクリックします。
1. 確認ができたら、右側の Create ボタンをクリックします。
![step 7](../instruction_images/cloudant_7.png)
6. 上記の手順が正常に完了したら、左のメニューから「リソース・リスト」をクリックしてください。リソース・リストが表示され、「サービス及びソフトウエア」に作成したCloudantのインスタンスが表示されます。
1. 上記の手順が正常に完了したら、左のメニューから「リソース・リスト」をクリックしてください。リソース・リストが表示され、「サービスおよびソフトウェア」に作成した Cloudant のインスタンスが表示されます。
インスタンス名をクリックしてください。
![step 8](../instruction_images/cloudant_8.png)
7. ここで、"External Endpoint (preferred)" と記載されているアドレスを控えてください。後ほど使います。<sup>(\*1)</sup>
1. ここで、"External Endpoint (preferred)" と記載されているアドレスを控えてください。後ほどデータベース名と組み合わせて使用します。<sup>(\*1)</sup>
![step 9](../instruction_images/cloudant_9.png)
## データベースの設定
1. 「Launch Dashboard」ボタンをクリックします。そうすると、今度はデータベースのダッシュボードが表示されます。CouchDBには、Fauxtonというインターフェイスがあるのですが、それそのものです。
1. 「Launch Dashboard」ボタンをクリックします。すると、データベースのダッシュボードが表示されます。これは CouchDB の Fauxton インターフェースとほぼ同じものです。
![step 1](../instruction_images/couchdb_1.png)
1. CORSの許可設定を行います。メニューの「Account」をクリックし、「CORS」タブを開きます。
1. CORS の許可設定を行います。メニューの「Account」をクリックし、「CORS」タブを開きます。
最初は「Restrict to specific domains」が選択されているので、「All domains (\*)」を選択し直します。この反映は即座に行われますが、すぐに戻せるので大丈夫です。
ただし、Cloudant では `app://obsidian.md` を許可する設定は使用できません。
![step 2](../instruction_images/couchdb_2.png)
1. データベースが作成できるか確認します。メニューの「Databases」をクリックし、次に「Create Database」ボタンをクリックします。
右側にパネルが表示されますので、好きな名前を入力し、「Create」ボタンをクリックします。
右側にパネルが表示されますので、好きな名前を入力し<sup>(\*2)</sup>、「Create」ボタンをクリックします。
![step 3](../instruction_images/couchdb_3.png)
1. それっぽいメッセージが表示された後、データベースが表示されていれば、ほとんどセットアップは完了です。今後、ほとんどこの画面は使いません。Self-hosted LiveSyncからデータベースは作成できます。
1. 完了を示すメッセージが表示された後、データベースが表示されていれば、セットアップはほぼ完了です。データベースを作成できることを確認した後は、通常この画面を開く必要はありません。Self-hosted LiveSync からもデータベースを作成できます。
![step 4](../instruction_images/couchdb_4.png)
### 資格情報のセットアップ
### 認証情報のセットアップ
1. IBM Cloudに戻って、「サービス資格情報」をクリックしてください。おそらく何も表示されていないので、「新規資格情報」をクリックします。
1. IBM Cloud に戻って、「サービス資格情報」をクリックしてください。おそらく何も表示されていないので、「新規資格情報」をクリックします。
![step 1](../instruction_images/credentials_1.png)
1. 資格情報を作成するダイアログが表示されるので、わかりやすい名前を入力します。その後、役割に「管理者」が選択されていることを確認してから、「追加」ボタンをクリックしてください。
1. 認証情報を作成するダイアログが表示されるので、任意の名前を入力するか既定のままにして、「追加」ボタンをクリックしてください。
![step 2](../instruction_images/credentials_2.png)
備考: この「名前」はSelf-hosted LiveSyncで使用するUsernameとはまた別のものです。
備考: この「名前」は Self-hosted LiveSync で使用する Username とはまた別のものです。
1. 「サービス資格情報」に戻ると、新しい資格情報が作成されています。~~わかりにくいことに名前は「鍵名」に変わります~~。左側のボタンを押すと詳細が開きます。
1. 「サービス資格情報」に戻ると、新しい認証情報が作成されています。~~わかりにくいことに名前は「鍵名」に変わります~~。左側のボタンを押すと詳細が開きます。
![step 3](../instruction_images/credentials_3.png)
Self-hosted LiveSyncから使用するUsernameとPasswordは、表示されたJSONに記載されているものを使用します。
今回の図で言うと、Usernameは"apikey-v2-2unu15184f7o8emr90xlqgkm2ncwhbltml6tgnjl9sd5"<sup>(\*3)</sup>、パスワードは"c2c11651d75497fa3d3c486e4c8bdf27"<sup>(\*4)</sup>になります。
Self-hosted LiveSync から使用する Username と Password は、表示された JSON に記載されているものを使用します。
今回の図で言うと、Username は"apikey-v2-2unu15184f7o8emr90xlqgkm2ncwhbltml6tgnjl9sd5"<sup>(\*3)</sup>、パスワードは"c2c11651d75497fa3d3c486e4c8bdf27"<sup>(\*4)</sup>になります。
## Self-hosted LiveSyncに設定
## Self-hosted LiveSync に設定
![Setting](../images/remote_db_setting.png)
先ほどの設定例から引用すると、
| Items | Value | example |
| ------------------- | -------------------------------- | --------------------------------------------------------------------------- |
| 項目 | 値 | 例 |
| --- | --- | --- |
| URI | (\*1) | https://xxxxxxxxxxxxxxxxx-bluemix.cloudantnosqldb.appdomain.cloud |
| Username | (\*3) | apikey-v2-2unu15184f7o8emr90xlqgkm2ncwhbltml6tgnjl9sd5 |
| Password | (\*4) | c2c11651d75497fa3d3c486e4c8bdf27 |
| Database name | (\*2) | sync-test |
| Username | (\*3) | apikey-v2-2unu15184f7o8emr90xlqgkm2ncwhbltml6tgnjl9sd5 |
| Password | (\*4) | c2c11651d75497fa3d3c486e4c8bdf27 |
| Database name | (\*2) | sync-test |
となります。
のとおりです。
+424 -83
View File
@@ -1,93 +1,434 @@
# CouchDBのセットアップ方法
# CouchDB サーバーのセットアップ
## CouchDBのインストールとPCやMacでの使用
CouchDBを構築するには、[Dockerのイメージ](https://hub.docker.com/_/couchdb)を使用するのが一番簡単です。
ただし、インストールしたCouchDBをSelf-hosted LiveSyncから使用するためには、少々設定が必要となります。
具体的には、下記の設定が`local.ini`として必要になります。
## 目次
- [1. CouchDB を準備する](#1-prepare-couchdb)
- [A. Docker を使用する](#a-using-docker)
- [B. Docker Compose を使用する](#b-using-docker-compose)
- [C. CouchDB を直接インストールする](#c-install-couchdb-directly)
- [2. couchdb-init.sh を実行して初期化する](#2-run-couchdb-initsh-for-initialise)
- [3. デバイスから CouchDB に接続できるようにする](#3-expose-couchdb-to-the-internet)
- [4. クライアントのセットアップ](#4-client-setup)
- [手動セットアップ情報](#manual-setup-information)
- [リバースプロキシ](#reverse-proxies)
---
<a id="1-prepare-couchdb"></a>
## 1. CouchDB を準備する
<a id="a-using-docker"></a>
### A. Docker を使用する
<a id="1-prepare"></a>
#### 1. 準備
```bash
# 環境変数を設定する。
export hostname=http://localhost:5984
export username=goojdasjdas # 好きな値に変更してください。
export password=kpkdasdosakpdsa # 好きな値に変更してください。
# 保存データと設定用のディレクトリを作成する。
mkdir couchdb-data
mkdir couchdb-etc
```
<a id="2-run-docker-container"></a>
#### 2. Docker コンテナを実行する
1. 起動確認。
```
$ docker run --name couchdb-for-ols --rm -it -e COUCHDB_USER=${username} -e COUCHDB_PASSWORD=${password} -v ${PWD}/couchdb-data:/opt/couchdb/data -v ${PWD}/couchdb-etc:/opt/couchdb/etc/local.d -p 5984:5984 couchdb
```
> [!WARNING]
> コンテナがエラーで終了した場合は、couchdb-data と couchdb-etc のアクセス権を確認してください。
> CouchDB の起動後、これらのディレクトリの所有者は uid:`5984` になります。その uid に所有者を変更し直してください。
2. バックグラウンドで有効化する
```
$ docker run --name couchdb-for-ols -d --restart always -e COUCHDB_USER=${username} -e COUCHDB_PASSWORD=${password} -v ${PWD}/couchdb-data:/opt/couchdb/data -v ${PWD}/couchdb-etc:/opt/couchdb/etc/local.d -p 5984:5984 couchdb
```
完了したら、[手順 2](#2-run-couchdb-initsh-for-initialise)に進んでください。
<a id="b-using-docker-compose"></a>
### B. Docker Compose を使用する
<a id="1-prepare-1"></a>
#### 1. 準備
```
[couchdb]
single_node=true
max_document_size = 50000000
# 保存データと設定用のディレクトリを作成する。
mkdir couchdb-data
mkdir couchdb-etc
[chttpd]
require_valid_user = true
max_http_request_size = 4294967296
# 所有者をユーザー 5984 に変更する。
chown -R 5984:5984 ./couchdb-data
chown -R 5984:5984 ./couchdb-etc
```
[chttpd_auth]
require_valid_user = true
authentication_redirect = /_utils/session.html
<a id="2-create-a-docker-composeyml-file-with-the-following-added-to-it"></a>
[httpd]
WWW-Authenticate = Basic realm="couchdb"
enable_cors = true
#### 2. 次の内容を追加した `docker-compose.yml` ファイルを作成する
```
services:
couchdb:
image: couchdb:latest
container_name: couchdb-for-ols
user: 5984:5984
environment:
- COUCHDB_USER=<INSERT USERNAME HERE> # 好きな値に変更してください。
- COUCHDB_PASSWORD=<INSERT PASSWORD HERE> # 好きな値に変更してください。
volumes:
- ./couchdb-data:/opt/couchdb/data
- ./couchdb-etc:/opt/couchdb/etc/local.d
ports:
- 5984:5984
restart: unless-stopped
```
<a id="3-run-the-docker-compose-file-to-boot-check"></a>
#### 3. Docker Compose ファイルを実行して起動確認する
```
docker compose up
# 古いバージョンを使用している場合
docker-compose up
```
> [!WARNING]
> コンテナがエラーで終了した場合は、couchdb-data と couchdb-etc のアクセス権を確認してください。
> CouchDB の起動後、これらのディレクトリの所有者は uid:`5984` になります。その uid に所有者を変更し直してください。
<a id="4-run-the-docker-compose-file-in-the-background"></a>
#### 4. Docker Compose ファイルをバックグラウンドで実行する
すべて正常に完了し、エラーが発生しなかった場合は、`CTRL+C` で終了してから次のコマンドを実行します。
```
docker compose up -d
# 古いバージョンを使用している場合
docker-compose up -d
```
完了したら、[手順 2](#2-run-couchdb-initsh-for-initialise)に進んでください。
<a id="c-install-couchdb-directly"></a>
### C. CouchDB を直接インストールする
[公式ドキュメント](https://docs.couchdb.org/en/stable/install/index.html)を参照してください。ただし、完全に設定する必要はありません。管理者を設定するだけで十分です。
<a id="2-run-couchdb-initsh-for-initialise"></a>
## 2. couchdb-init.sh を実行して初期化する
Deno 2 が必要です。CouchDB の接続情報とデータベースの詳細をエクスポートし、プロビジョニング用のラッパーを実行します。
この手順の `username` と `password` は CouchDB の管理者認証情報です。Docker または Docker Compose の場合は、`COUCHDB_USER` と `COUCHDB_PASSWORD` に指定した同じ値を使用します。直接インストールした場合は、CouchDB のセットアップ時に設定した管理者を使用します。ラッパーは、管理者以外の同期用アカウントを別途作成しません。
```
export hostname=http://localhost:5984
export username='<INSERT COUCHDB ADMINISTRATOR USERNAME HERE>'
export password='<INSERT COUCHDB ADMINISTRATOR PASSWORD HERE>'
export database=obsidiannotes
curl -s https://raw.githubusercontent.com/vrtmrz/obsidian-livesync/main/utils/couchdb/couchdb-init.sh | bash
```
> [!TIP]
> fish では `hostname` が読み取り専用で、エクスポートできません。代わりに `env` 経由で値を渡してください: `curl -s https://raw.githubusercontent.com/vrtmrz/obsidian-livesync/main/utils/couchdb/couchdb-init.sh | env hostname='http://localhost:5984' username='<INSERT COUCHDB ADMINISTRATOR USERNAME HERE>' password='<INSERT COUCHDB ADMINISTRATOR PASSWORD HERE>' database=obsidiannotes bash`
次のように表示された場合:
```
CouchDB provisioning completed.
```
ラッパーは、レジストリでバージョンを固定した Commonlib を使用するコードをそのまま実行します。`database` を指定すると、データベースを作成し、Commonlib を通じて LiveSync のデータベースバージョンドキュメントを初期化します。`database` を指定しない場合は、CouchDB サーバーの設定のみを行います。
Docker Compose を使用していて上記のコマンドが動作しない場合、または `ERROR: Hostname missing` と表示される場合は、プレースホルダーを自分の値に置き換えて次のコマンドを実行してください:
```
curl -s https://raw.githubusercontent.com/vrtmrz/obsidian-livesync/main/utils/couchdb/couchdb-init.sh | hostname='http://<YOUR SERVER IP>:5984' username='<INSERT COUCHDB ADMINISTRATOR USERNAME HERE>' password='<INSERT COUCHDB ADMINISTRATOR PASSWORD HERE>' database=obsidiannotes bash
```
<a id="3-expose-couchdb-to-the-internet"></a>
## 3. デバイスから CouchDB に接続できるようにする
- CouchDB を信頼できるローカルネットワーク上のデスクトップデバイスでのみ使用する場合は、この手順を省略できます。
- モバイルデバイスでは、Obsidian は有効な証明書付きの HTTPS を必要とします。HTTPS を使用するために CouchDB を公開する必要はありません。
デバイスから CouchDB サーバーへの接続方法を選択します。自分で運用する[リバースプロキシ](#reverse-proxies)、プライベートネットワーク経由のアクセス、または任意のトンネルサービスを使用できます。[Docker プロファイル](../docker/README.md#profile-details)には例があります。
Cloudflare は任意の選択肢の1つです。次の例では、一時的なテスト用に [Quick Tunnel](https://developers.cloudflare.com/tunnel/get-started/quick-tunnels/) を使用します。ランダムなホスト名が表示され、トンネルを作成するたびに変わります。また、`cloudflared` プロセスを停止すると URL は動作しなくなります。Quick Tunnel はテストと開発用であり、本番用ではありません。継続して使用する場合は、選択した接続方法を設定してください。Cloudflare を選ぶ場合は、[Cloudflare Tunnel ガイド](https://developers.cloudflare.com/tunnel/get-started/)が参考になります。
```
cloudflared tunnel --url http://localhost:5984
```
次の 2024 年の出力は形式の例です。ホスト名は例示のみを目的としています。実際には、自分のトンネルが出力した URL を使用してください。
```
2024-02-14T10:35:25Z INF Thank you for trying Cloudflare Tunnel. Doing so, without a Cloudflare account, is a quick way to experiment and try it out. However, be aware that these account-less Tunnels have no uptime guarantee. If you intend to use Tunnels in production you should use a pre-created named tunnel by following: https://developers.cloudflare.com/cloudflare-one/connections/connect-apps
2024-02-14T10:35:25Z INF Requesting new quick Tunnel on trycloudflare.com...
2024-02-14T10:35:26Z INF +--------------------------------------------------------------------------------------------+
2024-02-14T10:35:26Z INF | Your quick Tunnel has been created! Visit it at (it may take some time to be reachable): |
2024-02-14T10:35:26Z INF | https://tiles-photograph-routine-groundwater.trycloudflare.com |
2024-02-14T10:35:26Z INF +--------------------------------------------------------------------------------------------+
:
:
:
```
トンネルが出力した URL をサーバーアドレスとして使用します。クライアントの設定とテストが完了するまで、トンネルプロセスを実行したままにしてください。
<a id="4-client-setup"></a>
## 4. クライアントのセットアップ
> [!TIP]
> 生成されたセットアップ URI は、新しい Vault の現在のデフォルトと、選択したリモートプロファイルを引き継ぐため、推奨される方法です。セットアップ URI を生成できない場合は、[1台目で CouchDB を手動設定する](./quick_setup_ja.md#1台目で-couchdb-を手動設定する)に従い、その後、動作中のデバイスから新しいセットアップ URI を生成して、追加のデバイスごとに使用してください。
<a id="1-generate-the-setup-uri-on-a-desktop-device-or-server"></a>
### 1. デスクトップデバイスまたはサーバーでセットアップ URI を生成する
ここでの `LIVESYNC_USER` と `LIVESYNC_PASS` は、Self-hosted LiveSync がこのデータベースへの通常のアクセス用に保存する認証情報です。手順 2 の管理者認証情報でもかまいません。このデータベースへの必要なアクセス権を持つ CouchDB アカウントを別途設定している場合は、そのアカウントを使用してください。プロビジョニングラッパーもセットアップ URI ジェネレーターも、その別のアカウントを作成しません。
デバイスから CouchDB に接続するときに使用するサーバー URL を使用します。上記の一時的な Quick Tunnel の例では、実行中の自分のトンネルが出力した URL を使用してください。
```bash
export LIVESYNC_HOST='<YOUR COUCHDB SERVER URL>'
export LIVESYNC_DB=obsidiannotes
export LIVESYNC_USER='<INSERT COUCHDB USERNAME FOR LIVESYNC>'
export LIVESYNC_PASS='<INSERT THE COUCHDB PASSWORD>'
export LIVESYNC_PASSPHRASE='<INSERT A STRONG VAULT ENCRYPTION PASSPHRASE>'
export uri_passphrase='<INSERT A SEPARATE SETUP URI PASSPHRASE>' # 任意
deno run --minimum-dependency-age=0 --allow-env https://raw.githubusercontent.com/vrtmrz/obsidian-livesync/main/utils/setup/generate_setup_uri.ts
```
> [!TIP]
> `LIVESYNC_PASSPHRASE` は、エンドツーエンド暗号化で同期 Vault のデータを保護します。`uri_passphrase` はセットアップ URI のみを保護します。異なる値を使用し、両方を安全に保管し、セットアップ URI とそのパスフレーズを同じ経路で送らないでください。
>
> `uri_passphrase` を省略した場合、ジェネレーターは暗号学的にランダムな値を作成し、一度だけ表示します。
ジェネレーターは、ランダムな ID キーの復旧コードも表示します。同じ Vault のセットアップ URI を再生成する可能性がある場合は、そのコードを保存してください。`id_recovery_code` として渡し直さないと、後で実行したときに異なるキーが作成されます。`id_mode=legacy` は、以前の ID 動作を使用する Vault に接続する場合にのみ設定してください。詳しくは[セットアップユーティリティのリファレンス](../utils/readme.md#setup-uri-generation)を参照してください。
ジェネレーターは、プロビジョニングユーティリティが使用するのと同じ、レジストリでバージョンを固定した Commonlib リリースを使用します。設定済みの CouchDB リモートプロファイルを作成し、新しい Vault の現在のデフォルトを適用して、Commonlib のセットアップ URI 契約でエンコードします。
デフォルトでは、URI は Ephemeral(一時的)であり、ジェネレーターが表示した正確な UTC 時刻までのみ開けます。これは作成から7日後ではなく、固定された7日間の UTC ウィンドウの終了時点です。URI に時間条件が必要ない場合、または既存の暗号化形式をサポートする古いクライアントで読み取る必要がある場合は、コマンドを実行する前に `uri_mode=persistent` を設定してください。
出力は次の形式になります。以下のタイムスタンプと値は例です。
```text
Generated couchdb Setup URI.
Ephemeral: usable until 2026-10-01T00:00:00.000Z (UTC).
Your passphrase for the Setup URI is: H7vX...a-random-32-character-value
This passphrase is never shown again, so store it safely.
ID recovery code: sls-id-v1:<64 lowercase hexadecimal characters>
Use id_recovery_code with this value and reuse the same remote settings when generating another Setup URI for the same Vault.
obsidian://setuplivesync?settings=%5B%22tm2DpsOE74nJAryprZO2M93wF%2Fvg.......4b26ed33230729%22%5D
```
セットアップ URI とそのパスフレーズは別々に保管してください。
<a id="2-setup-self-hosted-livesync-to-obsidian"></a>
### 2. Self-hosted LiveSync を Obsidian にセットアップする
1台目については、[クイックセットアップ](./quick_setup_ja.md#1台目のデバイスをセットアップする)に従ってください。現在のオンボーディング通知、セットアップ URI のインポート、サーバーの初期化、および新しくプロビジョニングされたデータベースで表示される安全確認について説明しています。
通常のノート同期が動作した後、その1台目で[新しいセットアップ URI を生成](./quick_setup_ja.md#別のデバイス用のセットアップ-uri-を作成する)し、[別のデバイスを追加する](./quick_setup_ja.md#別のデバイスを追加する)に従ってください。2台目を、プロビジョニング時に作成した初期セットアップ URI の保持に依存させないでください。オプション機能は、通常の経路が確認された後にのみ設定してください。[非表示ファイル同期には専用のガイド](./tips/hidden-file-sync.md)があります。
---
<a id="manual-setup-information"></a>
## 手動セットアップ情報
<a id="setting-up-your-domain"></a>
### ドメインの設定
ドメインの A レコードをサーバーに向けて設定し、任意の方法でリバースプロキシをホストします。
注: CouchDB をトップディレクトリにマウントすることは推奨しません。
Caddy を使用すると、SSL 付きでサーバーを自動的に提供でき便利です。
Caddy と CouchDB を同時に起動する [docker-compose.yml と ini ファイル](https://github.com/vrtmrz/self-hosted-livesync-server)を公開しています。Traefik を使用している場合は、下の[リバースプロキシ](#reverse-proxies)のセクションを確認してください。
また、サーバーログを必ず確認し、不正なアクセスに注意してください。
<a id="reverse-proxies"></a>
## リバースプロキシ
<a id="traefik"></a>
### Traefik
Traefik を使用している場合、この [docker-compose.yml](https://github.com/vrtmrz/obsidian-livesync/blob/main/docker-compose.traefik.yml) ファイル(下にも掲載)には、適切な CORS パラメーターがすべて設定されています。外部ネットワーク `proxy` が存在することを前提としています。
```yaml
services:
couchdb:
image: couchdb:latest
container_name: obsidian-livesync
user: 1000:1000
environment:
- COUCHDB_USER=username
- COUCHDB_PASSWORD=password
volumes:
- ./data:/opt/couchdb/data
- ./local.ini:/opt/couchdb/etc/local.ini
# Traefik に渡している場合はポートは不要
#ports:
# - 5984:5984
restart: unless-stopped
networks:
- proxy
labels:
- "traefik.enable=true"
# Traefik ネットワーク
- "traefik.docker.network=proxy"
# 'obsidian-livesync.example.org' を自分のドメインに置き換えるのを忘れないでください
- "traefik.http.routers.obsidian-livesync.rule=Host(`obsidian-livesync.example.org`)"
# 'websecure' エントリーポイントは基本的に HTTPS のエントリーポイントです。問題が発生した場合にのみ次のコードスニペットを確認してください。これがリバースプロキシする最初のコンテナでなければ、おそらく Traefik は正しく設定されています。
- "traefik.http.routers.obsidian-livesync.entrypoints=websecure"
- "traefik.http.routers.obsidian-livesync.service=obsidian-livesync"
- "traefik.http.services.obsidian-livesync.loadbalancer.server.port=5984"
- "traefik.http.routers.obsidian-livesync.tls=true"
# 'letsencrypt' を自分の証明書リゾルバーに置き換えてください
- "traefik.http.routers.obsidian-livesync.tls.certresolver=letsencrypt"
- "traefik.http.routers.obsidian-livesync.middlewares=obsidiancors"
# Traefik 2.x で CORS を動作させるために必要な部分はここから
- "traefik.http.middlewares.obsidiancors.headers.accesscontrolallowmethods=GET,PUT,POST,HEAD,DELETE"
- "traefik.http.middlewares.obsidiancors.headers.accesscontrolallowheaders=accept,authorization,content-type,origin,referer"
- "traefik.http.middlewares.obsidiancors.headers.accesscontrolalloworiginlist=app://obsidian.md,capacitor://localhost,http://localhost"
- "traefik.http.middlewares.obsidiancors.headers.accesscontrolmaxage=3600"
- "traefik.http.middlewares.obsidiancors.headers.addvaryheader=true"
- "traefik.http.middlewares.obsidiancors.headers.accessControlAllowCredentials=true"
networks:
proxy:
external: true
```
上記で言及した `traefik.yml` 設定ファイルの抜粋:
```yml
...
entryPoints:
web:
address: ":80"
http:
redirections:
entryPoint:
to: "websecure"
scheme: "https"
websecure:
address: ":443"
...
```
<a id="nginx"></a>
### Nginx
Nginx を CouchDB のリバースプロキシとして設定する際は、よくある間違いに注意してください。
1. Fast Fetch の進捗が止まり、無期限にフリーズしたように見える場合は、`proxy_buffering` が無効になっていることを確認してください:
```nginx
location / {
proxy_pass http://127.0.0.1:5984;
proxy_buffering off;
...
}
```
2. "413 Entity too large" エラーが発生する場合は、`client_max_body_size` を増やしてください:
```nginx
location / {
proxy_pass http://127.0.0.1:5984;
client_max_body_size 50M; # 必要に応じて値を調整してください
...
}
```
3. "404 Database not found" エラーが発生する場合は、CouchDB をルートロケーションに配置していることを確認してください(推奨):
```nginx
server {
server_name couchdb.domain.com
location / {
proxy_pass http://127.0.0.1:5984;
...
}
}
```
CouchDB をサブディレクトリに配置することも可能ですが、設定をそれに合わせて変更する必要があります:
```nginx
server {
server_name domain.com
location /couchdb {
rewrite ^ $request_uri;
rewrite ^/couchdb/(.*) /$1 break;
proxy_pass http://127.0.0.1:5984$uri;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
...
}
location /_session {
proxy_pass http://127.0.0.1:5984/_session;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
...
}
}
```
4. データベース接続の詳細設定でカスタム HTTP ヘッダーを追加した場合は、Nginx と CouchDB の両方の設定を更新してください:
Nginx:
```nginx
location / {
set $pass 1;
# カスタム HTTP ヘッダーを処理する例
if ($http_x_custom_header != 'foo'){
set $pass 0;
}
# 重要: OPTIONS リクエストにはヘッダーが含まれないため、常に CouchDB にプロキシする必要があります
if ($request_method = 'OPTIONS') {
set $pass 1;
}
if ($pass = 0) {
return 403;
}
proxy_pass http://127.0.0.1:5984;
...
}
```
couchdb-etc/docker.ini:
```ini
...
[cors]
origins = app://obsidian.md,capacitor://localhost,http://localhost
credentials = true
headers = accept, authorization, content-type, origin, referer
methods = GET, PUT, POST, HEAD, DELETE
max_age = 3600
origins = app://obsidian.md,capacitor://localhost,http://localhost
;カスタムヘッダーをリストに追加して、CORS が壊れないようにしてください
headers = accept, authorization, content-type, origin, referer, x-custom-header
```
このファイルを作成し、
```
$ docker run --rm -it -e COUCHDB_USER=admin -e COUCHDB_PASSWORD=password -v .local.ini:/opt/couchdb/etc/local.ini -p 5984:5984 couchdb
```
とすると簡単にCouchDBを起動することができます。
備考:このとき、local.iniのオーナーが5984:5984になります。これは、Dockerイメージの制限事項です。編集する場合はいったんオーナーを変更してください。
正常にSelf-hosted LiveSyncからアクセスすることができたら、お好みでバックグラウンドで起動するように編集して起動してください。
例)
```
$ docker run -d --restart always -e COUCHDB_USER=admin -e COUCHDB_PASSWORD=password -v .local.ini:/opt/couchdb/etc/local.ini -p 5984:5984 couchdb
```
## モバイルからのアクセス
MacやPCからアクセスする場合は上記の方法で作ったサーバーで問題ありませんが、モバイル端末からアクセスする場合は有効なSSLの証明書が必要となります。
### モバイルからのアクセスのテスト
テストを行う場合は、[localhost.run](http://localhost.run/)などのサービスが便利です。
```
$ ssh -R 80:localhost:5984 nokey@localhost.run
Warning: Permanently added the RSA host key for IP address '35.171.254.69' to the list of known hosts.
===============================================================================
Welcome to localhost.run!
Follow your favourite reverse tunnel at [https://twitter.com/localhost_run].
**You need a SSH key to access this service.**
If you get a permission denied follow Gitlab's most excellent howto:
https://docs.gitlab.com/ee/ssh/
*Only rsa and ed25519 keys are supported*
To set up and manage custom domains go to https://admin.localhost.run/
More details on custom domains (and how to enable subdomains of your custom
domain) at https://localhost.run/docs/custom-domains
To explore using localhost.run visit the documentation site:
https://localhost.run/docs/
===============================================================================
** your connection id is xxxxxxxxxxxxxxxxxxxxxxxxxxxx, please mention it if you send me a message about an issue. **
xxxxxxxx.localhost.run tunneled with tls termination, https://xxxxxxxx.localhost.run
Connection to localhost.run closed by remote host.
Connection to localhost.run closed.
```
このように表示された場合、`https://xxxxxxxx.localhost.run`が一時的なサーバアドレスとして使用できます。
### ドメインを設定してアクセスする。
DNSのAレコードを設定し、お好みの方法でリバースプロキシをホスティングしてください。
備考:トップディレクトリにCouchDBを露出させるのはおすすめしません。
Caddy等でLet's Encryptの証明書を自動取得すると運用が楽になります。
CaddyとCouchDBを同時に立てられる[docker-composeの設定とiniファイル](https://github.com/vrtmrz/self-hosted-livesync-server)を公開しています。
ぜひご利用下さい。
なお、サーバのログは必ず確認し、不正なアクセスに注意してください。
+23 -6
View File
@@ -4,13 +4,30 @@
![Synchronisation](../images/1.png)
1. ノートが更新された際、Obsidianがイベントを発報します。Obsidian-LiveSyncはそれをハンドリングして、ローカルのPouchDBに変更を反映します。
2. PouchDBは、リモートのCouchDBに差分をレプリケーションします。
3. 他のデバイスは、リモートのCouchDBを監視しているので、変更が検出された場合はそのまま差分がダウンロードされます。
4. Self-hosted LiveSyncはPouchDBに転送された変更を、ObsidianのVaultに反映していきます。
1. ノートが更新されると、Obsidian からイベントが通知されます。Self-hosted LiveSync はイベントを処理し、ローカルの PouchDB に変更を反映します。
2. PouchDB は差分をリモートの CouchDB に複製します。
3. 他のデバイスはリモートの CouchDB を監視し、変更を検出すると差分をダウンロードします。
4. Self-hosted LiveSync は、PouchDB が受信した変更を Obsidian の Vault に反映します。
図は2端末での単一方向として描きましたが、実際には双方向に、複数の端末間で実行されます。
図では2台のデバイス間の一方向として示していますが、実際には複数のデバイス間で双方向に同期します。
## ファイルイベントとストレージ書き込み
ファイルイベントは、Vault 内で検出された変更を表します。Commonlib はこれらのイベントをフィルタリングおよび直列化してから、ローカルデータベース内のファイルメタデータを更新します。したがって、キューに入った `DELETE` はデータベースの変更を要求するものであり、それ自体が物理ファイルを削除する命令ではありません。同期対象外へのファイル名の変更も、宛先ファイルがディスク上に残ったままデータベース上は削除扱いとなる場合があります。
逆方向の処理はデータベースのメタデータから始まります。レプリケーションされた変更やフルスキャンによってデータベースからストレージへのハンドラが呼び出され、競合およびコンテンツ保護ルールに従って Vault ファイルの書き込みや削除が行われます。古いファイルイベントによるメタデータの削除を防ぐことと、正当なレプリケーションによる削除を適用することは、別の判断基準として扱われます。
Commonlib の [Storage events and database-to-storage reflection](https://github.com/vrtmrz/livesync-commonlib/blob/main/docs/storage-events-and-reflection.md) には、イベントの境界、Commonlib 0.1.23 で導入された削除の再検証、およびその制限事項が記載されています。特に、削除保護機能は外部フォルダの大文字小文字の変更やパスの表記揺れの完全な収束を保証するものではありません。
## 現在の技術リファレンス
- [データベースのデータ構造 (Database Data Structures)](datastructure.md): 現在のメタデータおよびチャンクの形式、識別子の取り扱い、削除、リモート上の生の表現について解説しています。
- [Replicator のアーキテクチャ (Replicator architecture)](design_docs/replicator_architecture.md): プロバイダーの構成、アクティブな Replicator の公開、終了、および P2P の所有権について解説しています。
- [競合解決とリビジョン履歴 (Conflict resolution and revision provenance)](specs_conflict_resolution.md): 現在のリビジョンツリーおよびファイルの来歴ルールを定義しています。
- [チャンクの取得と待機 (Chunk Retrieval and Waiting)](design_docs/chunk_retrieval_and_waiting.md): 不足しているチャンクの到着と、処理が落ち着くまでの待機の扱いを定義しています。
- [パスコンポーネント長の互換性 (Path component length compatibility)](design_docs/path_component_length_compatibility.md): 255 UTF-8 バイトがパスの妥当性を判断する普遍的な規則ではなく、Android や Linux における互換性警告である理由を解説しています。
- [データ圧縮 (Data Compression)](specs_data_compression.md) および [ガベージコレクション V3 (Garbage Collection V3)](specs_garbage_collection.md): それぞれのストレージとメンテナンスに関する取り決めを説明しています。
## 帯域幅低減のために
![dedupe](../images/2.png)
![dedupe](../images/2.png)
+50 -25
View File
@@ -1,30 +1,29 @@
# ファストセットアップ (Fast Setup / Simple Fetch)
ファストセットアップは、2台目以降のデバイスのセットアップやデータベース再構築時のデータ取得・初期化処理を、直感的かつ迅速に行うための簡略化された同期フローです。
ファストセットアップ(Simple Fetch)は、新規または空の2台目以降のデバイスに初期複製する際の推奨フローです。復旧にも使えますが、取得時の選択によってローカルファイルが置き換わることがあります。すでに作業がある Vault で処理方法を選ぶ前に、価値のあるローカルデータとリモートデータを保全してください。正本を特定する方法は[復旧とフラグファイル](../recovery.md#first-choose-the-authoritative-copy)を参照してください。
従来のセットアップウィザードにおける複数の詳細なステップを踏むことなく、同期の基本方針を選択するだけで、データベースのダウンロードとローカルファイルのスキャン・反映を一連のプロセスとして自動的に実行します。
従来のセットアップウィザードにおける複数の詳細なステップを踏むことなく、同期の基本方針を選択するだけで、データベースのダウンロードとローカルファイルのスキャン・反映を一連のプロセスとして自動的に実行します。取得経路は、選択したリモートによって異なります。
---
## 仕組み
2台目以降のデバイスで **セットアップURI** をインポートした場合や、手動でデータの再フェッチ(Vaultルートに `redflag3.md` / `flag_fetch.md` を配置する等)が予約された場合、プラグインはリモートデータベースからのデータ取得スケジュールを設定します。
2台目以降のデバイスで **セットアップ URI** をインポートした場合や、手動でデータの再取得(Vault ルートに `redflag3.md` / `flag_fetch.md` を配置する等)が予約された場合、プラグインはリモートデータベースからのデータ取得スケジュールを設定します。
その後の起動時、プラグインはデータフェッチ予約モードで立ち上がり、**「Data retrieval scheduled(データ取得のスケジュール)」** という簡略化されたダイアログを表示します。
その後の起動時、プラグインはデータ取得予約モードで立ち上がり、**「Data retrieval scheduled(データ取得のスケジュール)」** という簡略化されたダイアログを表示します。
---
## 技術的な特徴
ファストセットアップは、高速かつ安全でクリーンな処理を実現するために、以下の最適化を行っています。
ファストセットアップでは、取得と反映に関して次の動作を行います。
1. **高速なストリーム受信**
- 全データを取得しますが、ストリーム受信によるレプリケーションを使用するため、処理が非常に高速です。
1. **CouchDB 向けのストリームベースの Fast Fetch**
- ストリームベースの Fast Fetch は CouchDB 専用です。リモートのメタデータを段階的に取得します。オブジェクトストレージと P2P は、それぞれ独自の取得経路を使用します。
2. **ストレージ反映の遅延による不要な警告の抑制**
- データのダウンロード中にローカルファイル(ストレージ)への書き出し(反映)処理をあえて遅延させることで、同期途中で発生しがちな「破損データ同期」や「サイズ不一致」などの一時的なエラー警告を抑え込みます。
- すべてのデータダウンロードが完了した後に一括してストレージへ書き出すため、不必要な警告画面でユーザーを混乱させません。
3. **時刻ベース比較の妥当性**
- 初期セットアップやリカバリーの段階(この状態に移行した直後)においては、概ねファイル更新時刻(タイムスタンプ)ベースでの単純比較を行うことで、十分かつ妥当な同期結果を得ることができます。これにより複雑な競合解決の手間を省きます。
- 取得中にローカルファイルへの反映を遅延させることで、リモートデータの取得中に発生する一時的な同期警告を抑制します。
3. **更新日時を比較してファイル全体を選択**
- **更新日時を比較して新しい方を採用** は更新日時を比較し、ファイル全体として新しい方のバージョンを選択します。ファイルの内容をマージする処理ではありません。作業中の Vault にこの方法を使う前に、価値のあるローカルおよびリモートの編集内容を保全し、[復旧とフラグファイル](../recovery.md#first-choose-the-authoritative-copy)を確認してください。
---
@@ -33,30 +32,31 @@
### ステップ 1: データの反映方法の選択
取得したリモートデータを、既存のローカルファイルとどのように統合するかを選択します。
1. **Compare time and take newer (newer-wins)**
- ファイルの更新日時を比較し、より新しい方を採用します。
- **推奨されるケース:** すでに Self-hosted LiveSync を使用しており、複数のデバイスで編集した変更内容をタイムスタンプに基づいて統合したい場合。
2. **Overwrite all with remote files (remote-wins)**
1. **更新日時を比較して新しい方を採用(newer-wins)**
- ファイルの更新日時を比較し、ファイル全体として新しい方のバージョンを採用します。両方のバージョンの編集内容を統合するものではありません。
- **推奨されるケース:** 両方のバージョンを保全した上で、更新日時に基づいてどちらかを意図的に選択したい場合。
- 作業中の Vault にこの方法を使う前に、価値のあるローカルおよびリモートの編集内容を保全し、[復旧とフラグファイル](../recovery.md#first-choose-the-authoritative-copy)を確認してください。
2. **すべてリモートのファイルで上書き(remote-wins)**
- リモートデータベースの内容を正(Source of Truth)として扱います。
- **推奨されるケース:** まったく新しいデバイスをセットアップする場合(空のVaultなど)。
- **推奨されるケース:** 新しい2台目以降のデバイスを、空の Vault でセットアップする場合。
- *警告: ローカルにあるすべてのファイルがリモートの内容で上書きされます。重要なデータがある場合は、事前にバックアップを取得してください。*
3. **Use the detailed flow (legacy)**
3. **詳細フローを使用(legacy)**
- 従来の詳細なセットアップウィザードダイアログに戻ります。
- **推奨されるケース:** データベースの構成オプションをステップバイステップで細かく制御・確認したい場合。
### ステップ 2: 競合および削除ルールの構成
ステップ 1 での選択内容に応じて、ローカルとリモートの不一致をどう処理するかを設定します。
#### 「Compare time and take newer」を選択した場合:
- **Delete local files if they were deleted on remote**
- 他のデバイスで削除済みのファイルをローカルからも削除し、Vaultを同期・クリーンな状態に保ちます。
- **Recreate remote files even if they were deleted on remote**
#### 「更新日時を比較して新しい方を採用」を選択した場合:
- **リモートで削除されている場合はローカルファイルを削除**
- 他のデバイスで削除済みのファイルをローカルからも削除し、ローカル Vault を整理して他のデバイスと揃った状態に保ちます。
- **リモートで削除されていてもローカルファイルを保持**
- 他のデバイスで削除されたファイルであっても、ローカルファイルを維持し、リモートデータベースに再度アップロードします。
#### 「Overwrite all with remote files」を選択した場合:
- **Delete local files if not on remote**
- リモートに存在しないローカル専用ファイルを削除し、ローカルのVaultをリモートデータベースと完全に一致させます。
- **Keep local files even if not on remote**
#### 「すべてリモートのファイルで上書き」を選択した場合:
- **リモートに存在しない場合はローカルファイルを削除**
- リモートに存在しないローカル専用ファイルを削除し、ローカルの Vault をリモートデータベースと完全に一致させます。
- **リモートに存在しなくてもローカルファイルを保持**
- リモートに存在しないローカルファイルをそのまま残します。ただし、同期後に重複ファイルが発生する可能性があるため、その場合は手動でクリーンアップを行ってください。
### ステップ 3: 自動同期の実行
@@ -64,3 +64,28 @@
1. リモートデータベースの高速ダウンロードを実行します (`fetchLocalDBFast`)。
2. ローカルファイルへの変更反映のため、フォアグラウンドでフルスキャン (`synchroniseAllFilesBetweenDBandStorage`) を自動的に実行します。
3. 処理が完了すると、プラグインは通常の動作状態へ復帰します。
### ファストセットアップが中断した場合
ファストセットアップは、ドキュメントを保存しながら最後に正常に保存されたリモートの位置を記録します。一時的な接続の中断が発生した場合、その位置から自動的に再試行されます。キャプチャされたリモートの状態が正常にすべて保存された後にのみ、完了が報告されます。
データの復号、リモートレスポンスの読み取り、またはローカルデータベースへの書き込み中のエラーによって処理が停止した場合、LiveSync は Vault スキャンを実行せず、再構築されたローカルデータベースの確定も行いません。保存された位置と取得フラグはそのまま保持されます。保存された有効な選択肢は、再起動時に確認ダイアログで再び利用できます。部分的に再構築されたデータベースが Vault に適用されたり、新しいローカル変更と混ざったりしないよう、ファイル監視とデータベースの反映も一時停止されたままになります。
**ログを表示** で最初のエラー内容を確認し、原因を修正してから Obsidian を再起動して、保持された状態から再試行してください。処理を続行する意思がある間は、取得フラグを削除したり、手動で Scram スイッチを再開したりしないでください。再起動後も同じエラーが解消しない場合は、LiveSync を一時停止したままデータを保護し、[レポートを収集](../troubleshooting.md#collect-a-report) してください。
## 取得フラグに記憶される選択肢
ファストセットアップは、選択肢を `flag_fetch.md`(または取得フラグがそれだけの場合は `redflag3.md`)内の `json` コードブロックに保存します。このファイルは通常の Markdown であり、Obsidian 内で開いて編集できます。選択肢が更新されても、状態ブロックの外側にある説明文は保持されます。フラグファイル全体は一時的なものであり、処理が完了またはキャンセルされたときに削除されます。
中断後に再起動すると、現在のリモートと保存された選択肢が表示されます。それらの選択肢で続行するか、選び直すか、あるいは予約された取得をキャンセルできます。前回の取得が完了したもののフラグを削除できなかった場合も含め、保存された選択肢が確認なしに適用されることはありません。
新しい参加(Join)を開始するか、別の取得を予約すると、`flag_fetch.md` は空のフラグに置き換えられ、新しい選択肢が求められます。両方のファイル名が存在する場合は、空の場合も含めて `flag_fetch.md` が優先され、完了時に両方のエイリアスが削除されます。
生成されるブロックには `type: "livesync-fast-setup"`、`version: 1`、および2つの安定した英語の選択値(`stage1` と `stage2`)が含まれます。接続の認証情報は保存されません。既存の選択肢の認識可能な組み合わせのみが受け入れられます。確認を行うと、P2P 接続設定を変更した後であっても、現在選択されているリモートに選択肢が適用されます。
空のフラグがある場合は、通常の選択ダイアログが起動します。空ではないフラグに対応する有効な選択肢が含まれていない場合、プラグインは新しい選択肢を指定して続行するかどうかを確認します。これには不正な形式の JSON、未対応のバージョン、重複した状態ブロック、不完全な Markdown のコードフェンスなどが含まれます。続行を選択した場合、ファイル内容は変更されず、今回の試行にのみ新しい選択肢が使用されます。再起動すると再度確認が行われます。プラグインが Markdown を修復したり、代替ブロックを追加したりすることはありません。取得を完了またはキャンセルすると、説明文を含めフラグファイル全体が削除されます。
ストレージの読み取りまたは書き込みに失敗した場合は処理が停止し、空のフラグとしては扱われません。処理の最後にフラグの削除に失敗した場合、その問題が解決するまでファイル監視とデータベースの反映は一時停止されたままになります。フラグが残っている場合、再起動時に再度確認が求められます。
以前のバージョンでは、選択肢をデバイスのローカルストレージに個別に保存していました。それらの値は完了した取得の後にも残存している可能性があるため、再利用されなくなりました。中断された処理の実行中に更新した場合は、もう一度選択肢を確認してください。この変更自体によってダウンロード済みのデータや Fast Fetch(ファストフェッチ)のチェックポイントが削除されることはありません。