ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-28 23:55:49 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update Japanese translation files

Browse Source
This commit is contained in:
mDuo13
2020-06-05 17:21:18 -07:00
parent 5d47d4f288
commit fcad9d0376
110 changed files with 9094 additions and 2955 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
content/tutorials/manage-the-rippled-server/configuration/configure-history-sharding.ja.md
View File

@@ -10,10 +10,10 @@
履歴シャードを保管できるように`rippled`サーバーを設定する前に、履歴シャードストアーに割り当てるディスク容量を決定する必要があります。これはまた、デフォルトのレジャーストアーに保持する履歴の量にも影響します。シャードストアーのサイズを設定する際には、以下の点を考慮してください。
- レジャーストアー（`[node_db]`スタンザにより定義される）は、履歴シャードストアーとは別のストアーです。レジャーストアーはすべてのサーバーに必要であり、そこには一定範囲の最近の履歴が保管されている _必要があります_ 。保管する範囲は、`online_delete`パラメーターに使用可能な状態で維持するレジャーの数によって定義されます。）（デフォルトの設定では、最新のレジャー2000個が保管されます。）
- レジャーストアーに2^15個以上のレジャー（32768）が保持されている場合は、レジャーストアーからシャードストアーへ最近の履歴のグループを効率的にインポートできます。
- 履歴<sup></sup>シャードストアー（`[shard_db]`スタンザにより定義される）は、履歴シャードを保管する場合にのみ必要です。履歴シャードを保管しないサーバーではこの構成スタンザを省略する必要があります。履歴シャードストアーのサイズは`max_size_gb`パラメーターでギガバイト単位で定義されます。サーバーは完全なシャードを保管するため、この容量を最大限利用します。
- シャードには2^14個のレジャー（16384）が含まれており、シャードの経過期間に応じて約200 MB～4 GBを専有します。古いシャードほどXRP Ledgerでのアクティビティが少ないため、サイズが小さくなります。
- レジャーストアー（`[node_db]`スタンザにより定義される）は、履歴シャードストアーとは別のストアーです。レジャーストアーはすべてのサーバーに必要であり、そこには一定範囲の最近の履歴が保管されている必要があります。保管する範囲は、`online_delete`パラメーターに使用可能な状態で維持するレジャーの数によって定義されます。（デフォルトの設定では、最新のレジャー2000個が保管されます。）
- レジャーストアーに2<sup>15</sup>個以上のレジャー（32768）が保持されている場合は、レジャーストアーからシャードストアーへ最近の履歴のグループを効率的にインポートできます。
- 履歴シャードストアー（`[shard_db]`スタンザにより定義される）は、履歴シャードを保管する場合にのみ必要です。履歴シャードを保管しないサーバーではこの構成スタンザを省略する必要があります。履歴シャードストアーのサイズは`max_size_gb`パラメーターでギガバイト単位で定義されます。サーバーは完全なシャードを保管するため、この容量を最大限利用します。履歴シャードストアーは、 _必ず_ ソリッドステートディスクまたは同様の高速なメディアに保管します。従来の回転式ハードディスクでは不十分です。
- シャードには2<sup>14</sup>個のレジャー（16384）が含まれており、シャードの経過期間に応じて約200MB～4GBを専有します。古いシャードほどXRP Ledgerでのアクティビティが少ないため、サイズが小さくなります。
- 履歴シャードストアーとレジャーストアーはファイルパスを分けて保管する _必要があります_ 。必要に応じて、レジャーストアーと履歴ストアーをそれぞれ別のディスクやパーティションに配置するように設定できます。
- 完全なレジャー履歴をレジャーストアーと履歴シャードストアーの両方に保持できますが、冗長な処理となります。
- シャードの取得にかかる時間、`rippled`サーバーに必要なファイルハンドル数、およびメモリーキャッシュ使用率は、シャードのサイズの影響を直接受けます。
@@ -24,7 +24,7 @@
{% include '_snippets/conf-file-location.md' %}<!--_ -->
以下のスニペットに、`[shard_db]` スタンザの例を示します。
以下のスニペットに、`[shard_db]`スタンザの例を示します。
```
[shard_db]
@@ -33,9 +33,9 @@ path=/var/lib/rippled/db/shards/nudb
max_size_gb=50
```
**ヒント:** シャードストアーにはNuDB（`type=NuDB`）を使用することが推奨されます。NuDBはRocksDBに比べ、シャードあたりの使用ファイルハンドル数が少なくなります。RocksDBは、保管するデータのサイズに応じて拡張するメモリーを使用するため、大量のメモリーオーバーヘッドが必要になる可能性があります。ただし、NuDBはSSDドライブで使用するように設計されており、回転型ディスクでは機能しません。 <!-- NOTE: out of date; needs to be re-translated. NuDB is required as of v1.3.1. -->
`type`フィールドは省略できます。省略しない場合は、`NuDB`である _必要があります_ 。[新規: rippled 1.3.1][]
**注意:** 履歴シャーディングを有効にした後にシャードストアーのデータベースタイプを変更する場合は、パスを変更するか、または設定されているパスから既存のデータを削除する必要があります。`rippled`がシャードストアーパスで不適切なデータを検出すると、[起動できない](server-wont-start.html)可能性があります。
**注意:** `rippled`がシャードストアーパスで不適切なデータを検出すると、[起動できない](server-wont-start.html)可能性があります。シャードストアーには新しいフォルダーを使用する必要があります。以前にRocksDBシャードストアー（`rippled` 1.2.x以前）を使用していた場合は、別のパスを使用するか、RocksDBシャードデータを削除します。
詳細は、[rippled.cfgの設定例](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg)の`[shard_db]`の例を参照してください。
@@ -51,4 +51,26 @@ systemctl restart rippled
このフォルダーには、サーバーに保管されている各シャードのフォルダーが番号付きで保存されています。常に、最大で1つのフォルダーに、未完了であることを示す`control.txt`ファイルが保存されています。
<!-- TODO: add download_shard and crawl_shards commands when they get added. -->
[download_shardメソッド][]を使用して、サーバーにアーカイブファイルからシャードをダウンロードしてインポートするように指示できます。
サーバーとそのピアが使用できるシャードのリストを表示するには、[crawl_shardsメソッド][]か[ピアクローラー](peer-crawler.html)を使用します。
## 関連項目
- **コンセプト:**
- [レジャー履歴](ledger-history.html)
- [オンライン削除](online-deletion.html)
- **チュートリアル:**
- [オンライン削除の設定](configure-online-deletion.html)
- [ピアクローラーの設定](configure-the-peer-crawler.html)
- [容量の計画](capacity-planning.html)
- **リファレンス:**
- [download_shardメソッド][]
- [crawl_shardsメソッド][]
- [レジャーデータフォーマット](ledger-data-formats.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

124
content/tutorials/manage-the-rippled-server/configuration/connect-your-rippled-to-the-xrp-test-net.ja.md
View File

@@ -1,54 +1,112 @@
# XRP Test Netへのrippledの接続
# XRPL Altnetへのrippledの接続
Rippleは、XRP Ledgerのテストプラットフォームを提供するため[XRP Test Network](https://ripple.com/build/xrp-test-net/)を開発しました。XRP Test Netの資金は実際の資金ではなく、テスト専用の資金です。本番環境のXRP Ledger Networkに接続する前に、`rippled`サーバーをXRP Test Netに接続して、`rippled`の機能をテストして理解できます。また、XRP Test Netを使用して、作成したコードが`rippled`と正しくやり取りすることを検証できます。
Rippleは[代替となるテスト用および開発用ネットワーク](parallel-networks.html)を作成しており、開発者が最新のXRP Ledgerの非本番バージョン（Testnet）でアプリケーションをテストしたり、最新のベータバージョン（Devnet）で機能をテストして実験したりできるようにしています。 **これらのネットワークで使用する資金は実際の資金ではなく、テスト専用の資金です。** TestnetまたはDevnetの[`rippled`サーバー](the-rippled-server.html)に接続できます。
**注記:** XRP Test Netのレジャーと残高は定期的にリセットされます。
**注記:** XRP TestnetとDevnetのレジャーと残高は定期的にリセットされます。
`rippled`サーバーをXRP Test Netに接続するには、以下の構成を設定します。
`rippled`サーバーをXRP TestnetまたはDevnetに接続するには、以下の構成を設定します。
1. `rippled.cfg`ファイルで以下の手順に従います。
a. 以下のセクションのコメントを解除します。
a. [Testnet](xrp-testnet-faucet.html)に接続するには、以下のセクションのコメントを解除し、次のように追加します。
[ips]
r.altnet.rippletest.net 51235
b. 以下のセクションを次のようにコメントアウトします。
s.altnet.rippletest.net 51235
b. [Devnet](xrp-testnet-faucet.html)に接続するには、以下のセクションのコメントを解除し、次のように追加します。
[ips]
s.devnet.rippletest.net 51235
c. 以下のセクションを次のようにコメントアウトします。
# [ips]
# r.ripple.com 51235
2. `validators.txt`ファイルで以下の手順に従います。
2a. Altnetに接続するための変更
a. 以下のセクションのコメントを解除し、Altnetに接続するようにします。
[validator_list_sites]
https://vl.altnet.rippletest.net
[validator_list_keys]
ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
b. 以下のセクションを次のようにコメントアウトします。
# [validator_list_sites]
# https://vl.ripple.com
#
# [validator_list_keys]
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
2b. Devnetに接続するための変更
a. 以下のセクションをコメントアウトします。
# [validator_list_sites]
# https://vl.altnet.rippletest.net
# [validator_list_keys]
# ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
# [validator_list_sites]
# https://vl.ripple.com
#
# [validator_list_keys]
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
b. 次の信頼できるバリデータをvalidator.txtファイルに追加します。
# Hard-coded List of Devnet Validators
[validators]
n9Mo4QVGnMrRN9jhAxdUFxwvyM4aeE1RvCuEGvMYt31hPspb1E2c
n9MEwP4LSSikUnhZJNQVQxoMCgoRrGm6GGbG46AumH2KrRrdmr6B
n9M1pogKUmueZ2r3E3JnZyM3g6AxkxWPr8Vr3zWtuRLqB7bHETFD
n9MX7LbfHvPkFYgGrJmCyLh8Reu38wsnnxA4TKhxGTZBuxRz3w1U
n94aw2fof4xxd8g3swN2qJCmooHdGv1ajY8Ae42T77nAQhZeYGdd
n9LiE1gpUGws1kFGKCM9rVFNYPVS4QziwkQn281EFXX7TViCp2RC
n9Jq9w1R8UrvV1u2SQqGhSXLroeWNmPNc3AVszRXhpUr1fmbLyhS
a. 以下のセクションのコメントを解除します。
[validator_list_sites]
https://vl.altnet.rippletest.net
[validator_list_keys]
ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
b. 以下のセクションを次のようにコメントアウトします。
# [validator_list_sites]
# https://vl.ripple.com
#
# [validator_list_keys]
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
3. `rippled`を再起動します。
4. `rippled`がXRP Test Netに接続していることを確認するため、サーバーで[server_infoメソッド][]を使用して、その結果をTest Net のパブリックサーバーの結果と比較します。両方のサーバーで`validated_ledger`オブジェクトの`seq`フィールドが同一である必要があります（確認中にこの数が変化した場合は、1～2の差が生じる可能性があります）。
以下のコマンドは、`s.altnet.rippletest.net` にあるTest Net サーバーの最新の検証済みレジャーをチェックします。
4. `rippled`がXRP TestnetまたはDevnetに接続していることを確認するため、サーバーで[server_infoメソッド][]を使用して、その結果をTestnetまたはDevnetの公開サーバーの結果と比較します。両方のサーバーで`validated_ledger`オブジェクトの`seq`フィールドが同一である必要があります（確認中にこの数が変化した場合は、1～2の差が生じる可能性があります）。
以下のコマンドは、`s.altnet.rippletest.net`にあるTestnetサーバーの最新の検証済みレジャーをチェックします。
$ ./rippled --rpc_ip 34.210.87.206:51234 server_info | grep seq
以下のコマンドは、ローカルの `rippled` の最新検証済みレジャーシーケンスをチェックします。
以下のコマンドは、`s.devnet.rippletest.net`にあるDevnetサーバーの最新の検証済みレジャーをチェックします。
$ ./rippled --rpc_ip 34.83.125.234:51234 server_info | grep seq
以下のコマンドは、ローカルの`rippled`の最新検証済みレジャーインデックスをチェックします。
$ ./rippled server_info | grep seq
## 関連項目
- **ツール:**
- [XRP Faucet](xrp-testnet-faucet.html)
- [WebSocket APIツール](websocket-api-tool.html) - 接続オプションで「Testnet公開サーバー」を選択します。
- **コンセプト:**
- [並列ネットワーク](parallel-networks.html)
- [コンセンサスについて](intro-to-consensus.html)
- **チュートリアル:**
- [バリデータとしてのrippledの実行](run-rippled-as-a-validator.html)
- [スタンドアロンモードでの`rippled`のオフラインテスト](use-stand-alone-mode.html)
- `rippled`の[トラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

289
content/tutorials/manage-the-rippled-server/configuration/run-rippled-as-a-validator.ja.md
View File

@@ -1,12 +1,12 @@
# バリデータとしてのrippledの実行
バリデータモードで実行されている`rippled`サーバーは、ストックサーバーが実行するあらゆる処理を実行します。
[バリデータモード](rippled-server-modes.html)で実行されている[`rippled`サーバー](the-rippled-server.html)は、ストックサーバーが実行するあらゆる処理を実行します。
- ピアのネットワークへの接続
- [ピアのネットワーク](consensus-network.html)への接続
- 暗号署名されたトランザクションの中継
- 暗号署名された[トランザクション](transaction-basics.html)の中継
- 共有グローバル台帳全体のローカルコピーの維持
- 完全な共有グローバル[レジャー](ledgers.html)のローカルコピーの維持
バリデータが _特異である_ のは、検証メッセージも発行するという点です。これらのメッセージは、[コンセンサスプロセス](consensus-principles-and-rules.html#コンセンサスの仕組み)の進行中、XRP Ledgerネットワークによる評価の対象となる候補のトランザクションです。
@@ -21,20 +21,20 @@
バリデータ（サーバー）が以下の特質を常に備えるよう努めます。優れたバリデータであることは、`rippled`サーバーの運用者や[https://vl.ripple.com](https://vl.ripple.com)などのバリデータリスト発行者が、バリデータを彼らのUNLに追加する際に、バリデータを信頼する上で後押しになります。
- **可用性**
優れたバリデータは、常に稼働し、提案されるあらゆるレジャーについて検証投票を送信します。100%のアップタイムを実現するよう努めてください。
優れたバリデータは、常に稼働し、提案されるあらゆるレジャーについて検証投票を送信します。100%のアップタイムを実現するよう努めてください。
- **合意**
優れたバリデータの投票は、可能な限り高い頻度で、コンセンサスプロセスの結果と合致します。これに該当しない場合は、バリデータのソフトウェアが最新のものではないか、不具合があるか、意図的な偏りがあることを示唆している可能性があります。常に[最新の`rippled`リリース](https://github.com/ripple/rippled/tree/master)を、修正を加えることなく実行します。新規リリースについて知るために、[`rippled`のリリースを確認](https://github.com/ripple/rippled/releases)してください。
優れたバリデータの投票は、可能な限り高い頻度で、コンセンサスプロセスの結果と合致します。これに該当しない場合は、バリデータのソフトウェアが最新のものではないか、不具合があるか、意図的な偏りがあることを示唆している可能性があります。常に[最新の`rippled`リリース](https://github.com/ripple/rippled/tree/master)を、修正を加えることなく実行します。新規リリースについて知るために、[`rippled`のリリースを確認](https://github.com/ripple/rippled/releases)してください。
- **適時の投票**
優れたバリデータの投票は、コンセンサスラウンドが終了する前に、素早く届きます。適時の投票を維持するには、バリデータが推奨される[システム要件](system-requirements.html)を満たしていることを確認してください。これには、高速のインターネット接続が含まれます。
優れたバリデータの投票は、コンセンサスラウンドが終了する前に、素早く届きます。適時の投票を維持するには、バリデータが推奨される[システム要件](system-requirements.html)を満たしていることを確認してください。これには、高速のインターネット接続が含まれます。
- **身元の確さ**
優れたバリデータには、身元が明確な所有者が存在します。[ドメイン検証](#6-ドメイン検証の提供)を提供することは、その第一歩になります。XRP LedgerネットワークのUNLに、多くの法的な管轄域および地域のさまざまな所有者によって運営されているバリデータが含まれていると理想的です。結果として、信頼できるバリデータの公正な運用が地域特有の事象によって損なわれるおそれが低減されます。
優れたバリデータには、身元が明確な所有者が存在します。[ドメイン検証](#6-ドメイン検証の提供)を提供することは、その第一歩になります。XRP LedgerネットワークのUNLに、多くの法的な管轄域および地域のさまざまな所有者によって運営されているバリデータが含まれていると理想的です。結果として、信頼できるバリデータの公正な運用が地域特有の事象によって損なわれるおそれが低減されます。
Ripple社は、推奨される一連のバリデータを記載した[バリデータリスト](https://github.com/ripple/rippled/blob/develop/cfg/validators-example.txt)を公開しています。本番環境のサーバーでは、このリストを使用することを強くお勧めします。
@@ -42,7 +42,7 @@ Ripple社は、推奨される一連のバリデータを記載した[バリデ
## 2. `rippled`サーバーのインストール
詳細については、[`rippled`のインストール](install-rippled.html)を参照してください。
詳細は、[`rippled`のインストール](install-rippled.html)を参照してください。
@@ -50,42 +50,42 @@ Ripple社は、推奨される一連のバリデータを記載した[バリデ
`rippled`サーバーで検証を有効にすることは、サーバーの`rippled.cfg`ファイルにあるバリデータトークンを提供することを意味します。バリデータキーとトークンを安全に生成して管理するために、`validator-keys`ツール（`rippled` RPMに含まれる）を使用することをお勧めします。
バリデータ（サーバー）**以外の** 場所で、以下の手順に従います。
バリデータ（サーバー）**以外の**場所で、以下の手順に従います。
1. `validator-keys`ツールを`rippled` RPMを通じてまだインストールしていない場合は、手動でビルドして実行します。
`validator-keys`ツールを手動でビルドして実行する方法については、[validator-keys-tool](https://github.com/ripple/validator-keys-tool)を参照してください。
`validator-keys`ツールを手動でビルドして実行する方法については、[validator-keys-tool](https://github.com/ripple/validator-keys-tool)を参照してください。
2. `create_keys`コマンドを使用して、バリデータキーペアを生成します。
$ validator-keys create_keys
Ubuntuでの出力の例:
Ubuntuでの出力の例:
Validator keys stored in /home/my-user/.ripple/validator-keys.json
This file should be stored securely and not shared.
macOSでの出力の例:
macOSでの出力の例:
Validator keys stored in /Users/my-user/.ripple/validator-keys.json
This file should be stored securely and not shared.
**警告:** 生成した`validator-keys.json`キーファイルは、暗号化されたUSBフラッシュドライブなど、安全かつ回復可能なオフラインの場所に保管してください。内容には修正を加えないでください。特に、キーの使用場所となるバリデータにキーファイルを保存しないようにします。バリデータの`secret_key`が悪用された場合は、ただちに[キーを破棄](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#key-revocation)します。
`validator-keys`ツールおよびツールで生成されるキーペアの詳細は、[Validator Keys Tool Guide](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)を参照してください。
**警告:** 生成した`validator-keys.json`キーファイルは、暗号化されたUSBフラッシュドライブなど、安全かつ回復可能なオフラインの場所に保管してください。内容には修正を加えないでください。特に、キーの使用場所となるバリデータにキーファイルを保存しないようにします。バリデータの`secret_key`が悪用された場合は、ただちに[キーを破棄](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#key-revocation)します。
`validator-keys`ツールおよびツールで生成されるキーペアの詳細は、[Validator Keys Tool Guide](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)を参照してください。
3. `create_token`コマンドを使用して、バリデータトークンを生成します。
$ validator-keys create_token --keyfile /PATH/TO/YOUR/validator-keys.json
出力の例:
出力の例:
Update rippled.cfg file with these values:
# validator public key: nHUtNnLVx7odrz5dnfb2xpIgbEeJPbzJWfdicSkGyVw1eE5GpjQr
# validator public key: nHUtNnLVx7odrz5dnfb2xpIgbEeJPbzJWfdicSkGyVw1eE5GpjQr
[validator_token]
eyJ2YWxpZGF0aW9uX3NlY3J|dF9rZXkiOiI5ZWQ0NWY4NjYyNDFjYzE4YTI3NDdiNT
QzODdjMDYyNTkwNzk3MmY0ZTcxOTAyMzFmYWE5Mzc0NTdmYT|kYWY2IiwibWFuaWZl
@@ -99,100 +99,109 @@ Ripple社は、推奨される一連のバリデータを記載した[バリデ
バリデータ（サーバー）で、以下の手順に従います。
1. `[validator_token]`とその値を、バリデータの`rippled.cfg`ファイルに追加します。
以前に、`validator-keys`ツールを使用せずにバリデータを設定している場合は、`[validation_seed]`とその値を`rippled.cfg`ファイルから削除します。これにより、バリデータの公開鍵が変更されます。
以前に、`validator-keys`ツールを使用せずにバリデータを設定している場合は、`[validation_seed]`とその値を`rippled.cfg`ファイルから削除します。これにより、バリデータの公開鍵が変更されます。
2. `rippled`を再起動します。
$ sudo systemctl restart rippled.service
3. `server_info`コマンドを使用してバリデータの情報を取得し、バリデータとして実行されていることを確認します。
$ rippled server_info
- 応答に含まれている`pubkey_validator`の値は、バリデータで使用するために生成した`validator-keys.json`ファイルの`public_key`と一致している必要があります。
- `server_state`の値は、 _**proposing**_ にする必要があります。
- 応答に含まれている`pubkey_validator`の値は、バリデータで使用するために生成した`validator-keys.json`ファイルの`public_key`と一致している必要があります。
- `server_state`の値は、 _**proposing**_ にする必要があります。
**セキュリティのヒント:** `rippled.cfg`ファイルに対する権限をより制限的なものに変更します。Linuxでは、`0600`にすることを推奨します。`chmod 0600 rippled.cfg`を使用して変更できます。
## 4. ネットワークへの接続
バリデータのオペレーターが果たすべき重要な責任の1つは、信頼できる安全な接続によってバリデータがXRP Ledgerネットワークに接続されるようにすることです。ネットワーク上の潜在的に悪意のあるピアに無作為に接続するのではなく、以下のいずれかの方法でネットワークに接続するようにバリデータに指示できます。
このセクションでは、バリデータをXRP Ledgerネットワークに接続するために使用できる3種類の構成について説明します。ユースケースに最適な構成を使用してください。
- [公開ハブ](#公開ハブを使用した接続)
- [プロキシ](#プロキシを使用した接続)
- [検出されたピア](#検出されたピアを使用した接続): ピアツーピアネットワーク内の任意のサーバーに接続します。
これらのいずれかの構成を使用すると、[DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack)攻撃からバリデータを保護するとともに、ネットワークへの信頼できる接続をバリデータに提供する上で役立ちます。
- [プロキシ](#プロキシを使用した接続): ストック`rippled`サーバーを、バリデータとピアツーピアネットワークの他の部分との間のプロキシとして実行します。
- [公開ハブ](#公開ハブを使用した接続): 評価の高い特定の公開サーバーにのみ接続します。
これらのアプローチの違いについては、[ピア接続設定のメリットとデメリット](peer-protocol.html#ピア接続設定のメリットとデメリット)を参照してください。
### 公開ハブを使用した接続
### 検出されたピアを使用した接続
この構成では、ネットワークに接続している1つ以上の公開ハブにバリデータを接続します。適切に運用されている公開ハブには、以下の特徴があります。
この構成では、[検出されたピア](peer-protocol.html#ピアの検出)を使用してバリデータをXRP Ledgerネットワークに接続します。これは`rippled`サーバーのデフォルトの動作です。
- 十分な帯域幅。
- 多数の信頼できるピアとの接続。
- メッセージを確実に中継する能力。
公開ハブに接続することの利点は、安全かつ信頼できる多くのネットワーク接続にアクセスしやすいことです。このような接続は、バリデータの健全性の維持に役立ちます。
公開ハブを使用してバリデータをネットワークに接続するには、バリデータの`rippled.cfg`ファイルで以下の構成を設定します。
1. 以下の`[ips_fixed]`スタンザを記述します。2つの値`r.ripple.com 51235`と`zaphod.alloy.ee 51235`が公開ハブです。このスタンザは、これらの公開ハブとのピア接続を常に維持するよう`rippled`に指示します。
[ips_fixed]
r.ripple.com 51235
zaphod.alloy.ee 51235
他の`rippled`サーバーのIPアドレスをここに記述することもできますが、それらのサーバーに対して以下の事項を期待できる場合に _**限ります**_ 。
- メッセージを検閲することなく中継する。
- オンライン状態を常に維持する。
- サーバーに対するDDoS攻撃を実行しない。
- サーバーをクラッシュさせようとしない。
- 未知の相手にバリデータのIPアドレスを公開しない。
2. 以下の`[peer_private]`スタンザを記述し、`1`に設定します。この設定を有効にすると、バリデータのピアに対して、バリデータのIPアドレスをブロードキャストしないよう指示することになります。また、バリデータに対して、`[ips_fixed]`スタンザで設定されているピアにのみ接続するよう指示することになります。これにより、既知の信頼できるピア`rippled`サーバーに対してのみ、バリデータが接続を確立し、IPアドレスを共有することが保証されます。
**警告:** バリデータのIPアドレスを、その他の方法で公開していないことを確認してください。
[peer_private]
1
`[peer_private]`が有効になっている場合、`rippled`は、`[ips]`スタンザで指定されている接続をすべて無視します。現在`[ips]`スタンザにあるIPアドレスに接続する必要がある場合は、代わりに`[ips_fixed]`スタンザに記述します。ただし、それらのIPアドレスに対して、ステップ1で説明した挙動を期待できる場合に _**限ります**_ 。
_**検出されたピアを使用してバリデータをXRP Ledgerネットワークに接続するには、**_ バリデータの`rippled.cfg`ファイルで`[peer_private]`スタンザを省略するか、それを`0`に設定します。この構成の[サンプルのrippled.cfgファイル](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg)が提供されています。
### プロキシを使用した接続
この構成では、バリデータと発着信ネットワークトラフィックの間でプロキシとして使用するストック`rippled`サーバーを実行します。
この構成は、自社で運用するストック`rippled`サーバーを通じてバリデータをネットワークに接続します。これらのプロキシサーバーは、バリデータと発着信ネットワークトラフィックの間に設置します。
**注記:** これらのサーバーはプロキシとして動作しますが、HTTP(S)トラフィック用のWebプロキシではありません。
_**プロキシを使用してバリデータをXRP Ledgerネットワークに接続するには、次の手順を実行します。**_
この設定の利点は、自社で運用するプロキシサーバーを通じて、安全かつ信頼できる多くのネットワークへの接続の冗長性やアクセス性が高まることです。このような接続は、バリデータの健全性の維持に役立ちます。
1. ストック`rippled`サーバーを設置します。詳細は、[rippledのインストール](install-rippled.html)を参照してください。
2. バリデータとストック`rippled`サーバーを設定して、[クラスター](cluster-rippled-servers.html)内で実行します。
3. バリデータの`rippled.cfg`ファイルで、`[peer_private]`を`1`に設定します。そうすることで、バリデータのIPアドレスが転送されないようにします。詳細は、[プライベートピア](peer-protocol.html#プライベートピア)を参照してください。また、これによりクラスター内でバリデータを実行するよう`[ips_fixed]`スタンザで定義したサーバー以外のサーバーに、バリデータが接続しないようになります。
**警告:** バリデータのIPアドレスを、その他の方法で公開していないことを確認してください。
4. 以下のトラフィックのみを許可するように、バリデータのホストマシンのファイアウォールを構成します。
- 着信トラフィック: 構成したクラスター内にあるストック`rippled`サーバーのIPアドレスが発信元である場合のみ
- 発信トラフィック: 構成したクラスター内にあるストック`rippled`サーバーのIPアドレスおよびポート443経由の<https://vl.ripple.com>が送信先である場合のみ
5. `rippled`を再起動します。
$ sudo systemctl restart rippled.service
6. いずれかのストック`rippled`サーバーにある[ピアクローラー](peer-crawler.html)エンドポイントを使用します。応答には、バリデータが含まれていないはずです。これにより、バリデータの`[peer_private]`構成が機能していることが確認されます。バリデータの`[peer_private]`を有効にした場合の効果の1つは、バリデータのピアによって、ピアクローラーの結果にバリデータが含まれないことです。
$ curl --insecure https://STOCK_SERVER_IP_ADDRESS_HERE:51235/crawl | python3 -m json.tool
<!-- { TODO: Future: add a recommended network architecture diagram to represent the proxy, clustering, and firewall setup: https://ripplelabs.atlassian.net/browse/DOC-2046 }-->
1. `rippled`サーバーで[検証を有効に](#3-rippledサーバーで検証を有効化)します。
2. ストック`rippled`サーバーを設置します。詳細については、[rippledのインストール](install-rippled.html)を参照してください。
### 公開ハブを使用した接続
3. バリデータとストック`rippled`サーバーを設定して、[クラスター](cluster-rippled-servers.html)内で実行します。
この構成では、2つの[公開ハブ](rippled-server-modes.html#公開ハブ)を使用してバリデータをネットワークに接続します。この構成は、[自社で運用しているプロキシを使用した接続](#プロキシを使用した接続)と似ていますが、公開ハブを通じて接続します。
4. バリデータの`rippled.cfg`ファイルで、`[peer_private]`を`1`に設定して、バリデータのIPアドレスが転送されないようにします。詳細については、[プライベートピア](peer-protocol.html#プライベートピア)を参照してください。
_**公開ハブを使用してバリデータをネットワークに接続するには、次の手順を実行します。**_
**警告:** バリデータのIPアドレスを、その他の方法で公開していないことを確認してください。
1. バリデータの`rippled.cfg`ファイルに、次の`[ips_fixed]`スタンザを含めます。2つの値`r.ripple.com 51235`と`zaphod.alloy.ee 51235`がデフォルトの公開ハブです。このスタンザは、これらの公開ハブとのピア接続を常に維持するよう`rippled`に指示します。
[ips_fixed]
r.ripple.com 51235
zaphod.alloy.ee 51235
**注意:** この構成では、デフォルトの公開ハブを使用してバリデータをネットワークに接続します。これらは _デフォルト_ の公開ハブであるため、ビジー状態になってバリデータにネットワークへの接続を提供できない場合があります。この問題を避けるために、接続する公開ハブの数を増やすか、デフォルトでない公開ハブに接続するようにします。
他の`rippled`サーバーのIPアドレスをここに記述することもできますが、それらのサーバーに対して以下の事項を期待できる場合に _**限ります**_ 。
- メッセージを検閲することなく中継する。
- オンライン状態を常に維持する。
- サーバーに対するDDoS攻撃を実行しない。
- サーバーをクラッシュさせようとしない。
- 未知の相手にバリデータのIPアドレスを公開しない。
5. 以下のトラフィックのみを許可するように、バリデータのホストマシンのファイアウォールを構成します。
- 着信トラフィック: 構成したクラスター内にあるストック`rippled`サーバーのIPアドレスが発信元である場合のみ
- 発信トラフィック: 構成したクラスター内にあるストック`rippled`サーバーのIPアドレスおよびポート443経由の<https://vl.ripple.com>が送信先である場合のみ
6. `rippled`を再起動します。
2. また、バリデータの`rippled.cfg`ファイルに、次の`[peer_private]`スタンザを含めて、それを`1`に設定します。それにより、バリデータのピアに対して、バリデータのIPアドレスをブロードキャストしないよう指示することになります。また、バリデータに対して、`[ips_fixed]`スタンザで設定されているピアにのみ接続するよう指示することになります。これにより、既知の信頼できるピア`rippled`サーバーに対してのみ、バリデータが接続を確立し、IPアドレスを共有することが保証されます。
[peer_private]
1
**警告:** バリデータのIPアドレスを、その他の方法で公開していないことを確認してください。
`[peer_private]`が有効になっている場合、`rippled`は、`[ips]`スタンザで指定されている接続をすべて無視します。現在`[ips]`スタンザにあるIPアドレスに接続する必要がある場合は、代わりにそれを`[ips_fixed]`スタンザに記述します。ただし、それらのIPアドレスに対して、ステップ1で説明した確実な挙動を期待できる場合に _**限ります**_ 。
3. `rippled`を再起動します。
$ sudo systemctl restart rippled.service
7. いずれかのストック`rippled`サーバーにある[ピアクローラー](peer-crawler.html)エンドポイントを使用します。応答には、バリデータが含まれていないはずです。これにより、バリデータの`[peer_private]`構成が機能していることが確認されます。バリデータの`[peer_private]`を有効にした場合の効果の1つは、バリデータのピアによって、ピアクローラーの結果にバリデータが含まれないことです。
## 5. ネットワーク接続の確認
@@ -200,14 +209,14 @@ Ripple社は、推奨される一連のバリデータを記載した[バリデ
ここでは、バリデータがXRP Ledgerネットワークへの健全な接続を保持していることを検証する方法をいくつか紹介します。
- [`peers`](peers.html)コマンドを使用して、バリデータに接続しているすべての`rippled`サーバーのリストを取得します。`peers`の配列が`null`である場合、ネットワークへの健全な接続が存在していません。このドキュメントの手順に従ってバリデータを設置した場合、`peers`の配列には、`[ips_fixed]`スタンザで定義されているピアの数と同数のオブジェクトが含まれています。
公開ハブを`[ips_fixed]`スタンザに記述した場合、そのハブがビジーになっているときは、バリデータの接続が拒否されることがあります。この場合、接続の数は、`[ips_fixed]`スタンザで設定した数よりも最終的に少なくなることがあります。初めて拒否された場合、バリデータは接続を再試行します。
ネットワークへの安全かつ信頼できる接続を維持することが困難であり、公開ハブまたはプロキシを使用して接続を設定していない場合、[4. ネットワークへの接続](#4-ネットワークへの接続)を参照してください。このセクションで説明されているいずれかの方法は、バリデータがネットワークへの健全な接続を維持する上で有用となる可能性があります。
公開ハブを`[ips_fixed]`スタンザに記述した場合、そのハブがビジーになっているときは、バリデータの接続が拒否されることがあります。この場合、接続の数は、`[ips_fixed]`スタンザで設定した数よりも最終的に少なくなることがあります。初めて拒否された場合、バリデータは接続を再試行します。
ネットワークへの安全かつ信頼できる接続を維持することが困難であり、公開ハブまたはプロキシを使用して接続を設定していない場合、[4. ネットワークへの接続](#4-ネットワークへの接続)を参照してください。このセクションで説明されているいずれかの方法は、バリデータがネットワークへの健全な接続を維持する上で有用となる可能性があります。
- [`server_info`](server_info.html)コマンドを使用して、バリデータに関するいくつかの基本情報を取得します。`server_state`は、`proposing`に設定されているはずです。`full`または`validating`に設定されている場合もありますが、`proposing`に移行するまでの数分間に限られます。
`server_state`が`proposing`に設定されている時間が大部分を占めていない場合、XRP Ledgerネットワークにバリデータが完全に参加できていないことを示している可能性があります。サーバーの状態および`server_info`エンドポイントを使用してバリデータの問題を診断する方法の詳細は、[`rippled`サーバーの状態](rippled-server-states.html)および[`server_info`の取得](diagnosing-problems.html#server_infoの取得)を参照してください。
`server_state`が`proposing`に設定されている時間が大部分を占めていない場合、XRP Ledgerネットワークにバリデータが完全に参加できていないことを示している可能性があります。サーバーの状態および`server_info`エンドポイントを使用してバリデータの問題を診断する方法の詳細は、[`rippled`サーバーの状態](rippled-server-states.html)および[`server_info`の取得](diagnosing-problems.html#server_infoの取得)を参照してください。
- [`validators`](validators.html)コマンドを使用して、バリデータによって使用される、公開済みかつ信頼できるバリデータの最新リストを取得します。`validator_list_expires`の値が、`never`（無期限）、期限が切れていない、または期限切れ間近のいずれかであることを確認してください。
@@ -225,37 +234,37 @@ Ripple社は、推奨される一連のバリデータを記載した[バリデ
ドメイン検証を提供するには、以下の手順に従います。
1. バリデータと公に関連付ける、所有しているドメインの名前を選択します。そのドメインのポート443で外部に公開されるHTTPSサーバーを実行中であり、そのサーバーのTLS証明書に関連付けられている秘密鍵ファイルへのアクセス権を持っている必要があります。（注記: [TLSの旧称はSSLです](https://en.wikipedia.org/wiki/Transport_Layer_Security)）。
1. バリデータと公に関連付ける、所有しているドメインの名前を選択します。そのドメインのポート443で外部に公開されるHTTPSサーバーを実行中であり、そのサーバーのTLS証明書に関連付けられている秘密鍵ファイルへのアクセス権を持っている必要があります。（注記: [TLSの旧称はSSLです](https://en.wikipedia.org/wiki/Transport_Layer_Security)。）DDoS攻撃への対策として、ドメイン名によってバリデータのIPアドレスが解決されないようにする必要があります。
2. バリデータの公開鍵を公開し、特に他の`rippled`オペレーターに知らせます。例えば、Webサイト、ソーシャルメディア、[XRPChatコミュニティーフォーラム](https://www.xrpchat.com/)、またはプレスリリースでバリデータの公開鍵を公表できます。
3. この[Googleフォーム](https://docs.google.com/forms/d/e/1FAIpQLScszfq7rRLAfArSZtvitCyl-VFA9cNcdnXLFjURsdCQ3gHW7w/viewform)を使用して、自身のバリデータをXRP Chartsの[バリデータレジストリー](https://xrpcharts.ripple.com/#/validators)に登録するための要求を送信します。バリデータをこのレジストリーに登録することは、そのバリデータとドメインを所有していることを示す、別の形での公的な証拠になります。フォームに漏れなく記入するには、以下の情報が必要です。
1. バリデータのサーバーで以下のコマンドを実行して、バリデータの公開鍵を検出します。
$ /opt/ripple/bin/rippled server_info | grep pubkey_validator
返された値を、Googleフォームの**Validator Public Key**フィールドに入力します。
2. WebドメインのTLS秘密鍵を使用して、バリデータの公開鍵に署名します。TLS秘密鍵ファイルをバリデータのサーバーに保存する必要はありません。
$ openssl dgst -sha256 -hex -sign /PATH/TO/YOUR/TLS.key <(echo YOUR_VALIDATOR_PUBLIC_KEY_HERE)
出力の例:
1. バリデータのサーバーで以下のコマンドを実行して、バリデータの公開鍵を検出します。
$ /opt/ripple/bin/rippled server_info | grep pubkey_validator
返された値を、Googleフォームの**Validator Public Key**フィールドに入力します。
2. WebドメインのTLS秘密鍵を使用して、バリデータの公開鍵に署名します。TLS秘密鍵ファイルをバリデータのサーバーに保存する必要はありません。
$ openssl dgst -sha256 -hex -sign /PATH/TO/YOUR/TLS.key <(echo YOUR_VALIDATOR_PUBLIC_KEY_HERE)
出力の例:
4a8b84ac264d18d116856efd2761a76f3f4544a1fbd82b9835bcd0aa67db91c53342a1ab197ab1ec4ae763d8476dd92fb9c24e6d9de37e3594c0af05d0f14fd2a00a7a5369723c019f122956bf3fc6c6b176ed0469c70c864aa07b4bf73042b1c7cf0b2c656aaf20ece5745f54ab0f78fab50ebd599e62401f4b57a4cccdf8b76d26f4490a1c51367e4a36faf860d48dd2f98a6134ebec1a6d92fadf9f89aae67e854f33e1acdcde12cfaf5f5dbf1b6a33833e768edbb9ff374cf4ae2be21dbc73186a5b54cc518f63d6081919e6125f7daf9a1d8e96e3fdbf3b94b089438221f8cfd78fd4fc85c646b288eb6d22771a3ee47fb597d28091e7aff38a1e636b4f
返された値を、Googleフォームの**SSL Signature**フィールドに入力します。
3. [`validator-keys`ツール](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)（`rippled`のRPMに収録）を使用して、ドメイン名に署名します。
$ validator-keys --keyfile /PATH/TO/YOUR/validator-keys.json sign YOUR_DOMAIN_NAME
出力の例:
返された値を、Googleフォームの**SSL Signature**フィールドに入力します。
3. [`validator-keys`ツール](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)（`rippled`のRPMに収録）を使用して、ドメイン名に署名します。
$ validator-keys --keyfile /PATH/TO/YOUR/validator-keys.json sign YOUR_DOMAIN_NAME
出力の例:
E852C2FE725B64F353E19DB463C40B1ABB85959A63B8D09F72C6B6C27F80B6C72ED9D5ED6DC4B8690D1F195E28FF1B00FB7119C3F9831459F3C3DE263B73AC04
返された値を、Googleフォームの**Domain Signature**フィールドに入力します。
返された値を、Googleフォームの**Domain Signature**フィールドに入力します。
4. 記入したGoogleフォームを送信すると、ドメイン検証の成否を通知するメールがXRP Chartsから送信されます。ドメイン検証が成功した場合は、XRP Chartsの[バリデータレジストリー](https://xrpcharts.ripple.com/#/validators)にバリデータとドメインが表示されます。
@@ -268,3 +277,27 @@ Ripple社は、推奨される一連のバリデータを記載した[バリデ
バリデータのマスター秘密鍵が漏えいした場合は、ただちに永続的に破棄する必要があります。
`validator-keys`ツールでバリデータ用に生成したマスターキーペアを破棄する方法については、[Key Revocation](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#key-revocation)を参照してください。
## 関連項目
- **コンセプト:**
- [XRP Ledgerの概要](xrp-ledger-overview.html)
- [コンセンサスネットワーク](consensus-network.html)
- [`rippled`サーバー](the-rippled-server.html)
- **チュートリアル:**
- [rippledサーバーのクラスター化](cluster-rippled-servers.html)
- [`rippled`のインストール](install-rippled.html)
- [容量の計画](capacity-planning.html)
- [XRP Ledgerのビジネス](xrp-ledger-businesses.html)
- **リファレンス:**
- [Validator Keysツールガイド](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)
- [consensus_infoメソッド][]
- [validator_list_sitesメソッド][]
- [validatorsメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

90
content/tutorials/manage-the-rippled-server/configure-peering/configure-a-private-server.ja.md Normal file
View File

@@ -0,0 +1,90 @@
# プライベートサーバーの設定
[プライベートサーバー](peer-protocol.html#プライベートピア)は、オープンなピアツーピアネットワーク内の検出されたピアに直接接続するのではなく、特定の信頼できるピアのみを通じてネットワークに接続する`rippled`サーバーです。この種の構成は、[バリデータ](run-rippled-as-a-validator.html)に一般的に推奨される任意の対策ですが、その他の特定の目的でも役立ちます。
## 前提条件
プライベートサーバーを使用するには、次の前提条件を満たしている必要があります。
- [`rippled`をインストール](install-rippled.html)して最新バージョンにアップデートし、まだ実行していない状態である必要があります。
- 自社で運用している**プロキシ**を通じて接続するか、**公開ハブ**を通じて接続するかを決める必要があります。これらの選択肢の違いについては、[ピアリング構成のメリットとデメリット](peer-protocol.html#ピア接続設定のメリットとデメリット)を参照してください。
- プロキシを使用している場合、`rippled`がインストールされていてプロキシとして使用し実行される別のマシンが必要です。これらのサーバーは、外部のネットワークとプライベートサーバーに接続できる必要があります。
- どちらの構成でも、接続先のピアのIPアドレスとポートを把握しておく必要があります。
## 手順
特定のサーバーをプライベートピアとして設定するには、次の手順を実行します。
1. `rippled`の構成ファイルを編集します。
vim /etc/opt/ripple/rippled.cfg
{% include '_snippets/conf-file-location.md' %}<!--_ -->
2. プライベートピアリングを有効にします。
構成ファイルに以下のスタンザを追加するか、コメントを解除します。
[peer_private]
1
3. 固定数のピアを追加します。
構成ファイルに`[ips_fixed]`スタンザを追加するか、コメントを解除します。このスタンザの各行は、接続先のピアのホスト名またはIPアドレス、1個の空白文字、このピアがピアプロトコル接続を受け付けるポートの順に記載されている必要があります。
例えば、**公開ハブ**を使用して接続する場合は、以下のスタンザを使用できます。
[ips_fixed]
r.ripple.com 51235
zaphod.alloy.ee 51235
サーバーが**プロキシ**を使用して接続している場合は、IPアドレスとポートが、プロキシとして使用している`rippled`サーバーの構成と一致している必要があります。これらの各サーバーについては、ポート番号が、サーバーの構成ファイルに記載されている`protocol = peer`ポート（通常は51235）と一致している必要があります。例えば、構成は次のようになります。
[ips_fixed]
192.168.0.1 51235
192.168.0.2 51235
4. プロキシを使用している場合、プロキシをプライベートピアと互いを含めてクラスター化します。
公開ハブを使用している場合は、このステップをスキップします。
プロキシを使用している場合、プライベートピアを含む[クラスターとしてプロキシを構成](cluster-rippled-servers.html)します。クラスターの各メンバーは、クラスターの_他の_各メンバーをリストにした`[ips_fixed]`スタンザを持っている必要があります。ただし、`[peer_private]`スタンザを持つのは**プライベートサーバーのみ**とします。
各プロキシで`rippled`を再起動します。各プロキシサーバーで、次のようにします。
sudo service systemctl restart rippled
5. プライベートサーバーで`rippled`を起動します。
sudo service systemctl start rippled
6. [peersメソッド][]を使用して、プライベートサーバーが自身のピアに _のみ_ 接続していることを確認します。
応答の`peers`配列に、構成済みのピアのいずれでもない`address`を持つオブジェクトが含まれていてはなりません。含まれている場合は、構成ファイルを再度確認して、プライベートサーバーを再起動します。
## 次のステップ
追加の予防対策として、自身のピアでないサーバーからプライベートサーバーへの着信接続をブロックするようにファイアウォールを設定する必要があります。プロキシサーバーを実行している場合は、ファイヤーウォールを通じてプロキシに[ピアポートを転送](forward-ports-for-peering.html)するようにします。ただし、プライベートピアで**ない**ものに転送します。この設定方法の具体的な手順は、使用するファイアウォールによって異なります。
ファイアウォールがポート80で発信HTTP接続を**ブロックしない**ことを確認します。デフォルトの設定では、このポートを使用して**vl.ripple.com**から最新の推奨バリデータリストをダウンロードします。バリデータリストがないと、サーバーはどのバリデータを信頼してよいかわからず、ネットワークが、いつコンセンサスに至ったかを認識できません。
## 関連項目
- **コンセプト:**
- [ピアプロトコル](peer-protocol.html)
- [コンセンサス](consensus.html)
- [並列ネットワーク](parallel-networks.html)
- **チュートリアル:**
- [ピアクローラーの設定](configure-the-peer-crawler.html)
- **リファレンス:**
- [peersメソッド][]
- [connectメソッド][]
- [fetch_infoメソッド][]
- [ピアクローラー](peer-crawler.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

5
content/tutorials/manage-the-rippled-server/configure-peering/configure-peering.ja.md Normal file
View File

@@ -0,0 +1,5 @@
# ピアリングの設定
XRP Ledgerのピアツーピアプロトコルは、ほとんどの場合、ピア接続を自動的に管理します。場合によっては、サーバーが接続するピアを手動で調整して、サーバーの可用性とネットワークの他の部分との接続性を最大限に高めたいというケースがあります。
同じデータセンター内で複数のサーバーを稼動させている場合は、[クラスター化](cluster-rippled-servers.html)して効率を向上させたいケースがあります。ピアツーピアネットワークのトポロジー内の重要なハブなど、稼動していないが接続を維持したいサーバー用の予約済みピアスロットを使うことができます。他のピアについては、サーバーはピアを自動検出し、その接続を管理しますが、望ましくない動作をするピアをブロックするように手動で介入することもできます。

59
content/tutorials/manage-the-rippled-server/configure-peering/forward-ports-for-peering.ja.md Normal file
View File

@@ -0,0 +1,59 @@
# ピアリングのポート転送
XRP Ledgerのピアツーピアネットワーク内にあるサーバーは、[ピアプロトコル](peer-protocol.html)を介して通信します。セキュリティとネットワークの他の部分との接続を両立させるために、ファイアウォールを使用して、サーバーをほとんどのポートから保護し、ピアプロトコルポートだけを開放するか転送するようにする必要があります。
`rippled`サーバーの稼動中に、[server_infoメソッド][]を実行すると、いくつのピアがあるか確認することができます。`info`オブジェクトの`peers`フィールドは、サーバーに現在接続しているピアの数を示します。この数が10または11の場合、通常はファイアウォールが着信接続をブロックしていることを示します。
ファイアウォールが着信ピア接続をブロックしていると思われるためピアが10個しかないことを示している`server_info`の結果の例（一部省略）は次のとおりです。
```json
$ ./rippled server_info
Loading: "/etc/opt/ripple/rippled.cfg"
2019-Dec-23 22:15:09.343961928 HTTPClient:NFO Connecting to 127.0.0.1:5005
{
"result" : {
"info" : {
...（省略）...
"load_factor" : 1,
"peer_disconnects" : "0",
"peer_disconnects_resources" : "0",
"peers" : 10,
"pubkey_node" : "n9KUjqxCr5FKThSNXdzb7oqN8rYwScB2dUnNqxQxbEA17JkaWy5x",
"pubkey_validator" : "n9KM73uq5BM3Fc6cxG3k5TruvbLc8Ffq17JZBmWC4uP4csL4rFST",
"published_ledger" : "none",
"server_state" : "connected",
...（省略）...
},
"status" : "success"
}
}
```
着信接続を許可するために、ピアプロトコルポートを転送するようにファイアウォールを設定します。ピアプロトコルポートは、デフォルトの構成ファイルでは**ポート51235**で提供されます。ポートの転送の手順はファイアウォールによって異なります。例えば、Red Hat Enterprise Linuxで`firewalld`ソフトウェアファイアウォールを使用している場合は、[`firewall-cmd`ツールを使用](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-port_forwarding)して、TCPトラフィックを次のように転送します。
```sh
$ sudo firewall-cmd --add-forward-port=port=51235:proto=tcp:toport=51235
```
その他のソフトウェアファイアウォールとハードウェアファイアウォールについては、メーカー公式のドキュメントを参照してください。
## 関連項目
- **コンセプト:**
- [ピアプロトコル](peer-protocol.html)
- [`rippled`サーバー](the-rippled-server.html)
- **チュートリアル:**
- [容量の計画](capacity-planning.html)
- [`rippled`サーバーのトラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [connectメソッド][]
- [peersメソッド][]
- [printメソッド][]
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

72
content/tutorials/manage-the-rippled-server/configure-peering/manually-connect-to-a-specific-peer.ja.md Normal file
View File

@@ -0,0 +1,72 @@
# 特定のピアへの手動接続
サーバーをXRP Ledgerネットワーク内の特定の[ピア](peer-protocol.html)に手動で接続するには、次の手順を実行します。
**ヒント:** サーバーが起動時にこのサーバーに自動的に接続して、以降も接続を維持するようにするには、そのピアに対して[ピアリザベーション](use-a-peer-reservation.html)を設定することができます。
## 前提条件
- 接続先のピアのIPアドレスを把握しておく必要があります。
- 接続先のピアがXRP Ledger[ピアプロトコル](peer-protocol.html)に使用するポートを把握しておく必要があります。デフォルトでは、ポート51235です。
- サーバーからピアへのネットワーク接続を用意する必要があります。例えば、ピアサーバーは[ファイアウォールを通じて適切なポートを転送する](forward-ports-for-peering.html)必要があります。
- ピアサーバーに使用可能なピアスロットがある必要があります。ピアがすでにピアの最大数に達している場合、ピアサーバーのオペレーターに依頼して、サーバーの[ピアリザベーション](use-a-peer-reservation.html)を追加してもらいます。
## 手順
接続するには、[connectメソッド][]を使用します。例:
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```
{
"command": "connect",
"ip": "169.54.2.151",
"port": 51235
}
```
*JSON-RPC*
```
{
"method": "connect",
"params": [
{
"ip": "169.54.2.151",
"port": 51235
}
]
}
```
*コマンドライン*
```
rippled connect 169.54.2.151 51235
```
<!-- MULTICODE_BLOCK_END -->
## 関連項目
- **コンセプト:**
- [ピアプロトコル](peer-protocol.html)
- [`rippled`サーバー](the-rippled-server.html)
- **チュートリアル:**
- [容量の計画](capacity-planning.html)
- [`rippled`サーバーのトラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [connectメソッド][]
- [peersメソッド][]
- [printメソッド][]
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

48
content/tutorials/manage-the-rippled-server/configure-peering/set-max-number-of-peers.ja.md Normal file
View File

@@ -0,0 +1,48 @@
# ピアの最大数の設定
`rippled`サーバーには、接続先の[ピア](peer-protocol.html)の数を定める設定可能なソフト最大数があります。ピアのデフォルトの最大数は**21**です。
**注記:** 内部的に、サーバーは受信ピアと送信ピアのおおよそのクォータを生成します。[固定ピアやピアリザベーション](peer-protocol.html#固定ピアとピアリザベーション)を使用している場合、あるいは[connectメソッド][]を使用して追加のピアに手動で接続している場合は、このソフト最大数を超える可能性があります。
サーバーが許可するピアの最大数を変更するには、以下の手順を実行します。
1. `rippled`の構成ファイルを編集します。
$ vim /etc/opt/ripple/rippled.cfg
{% include '_snippets/conf-file-location.md' %}<!--_ -->
2. 構成ファイルで、`[peers_max]`スタンザのコメントを解除して編集するか、まだない場合は追加します。
[peers_max]
30
スタンザの内容は、許可するピアの合計数を示す整数のみである必要があります。デフォルトでは、サーバーは受信ピアが約85%、送信ピアが約15%という比率を維持するように試みますが、送信ピアの最小数が10であるため、68未満の値にしても、サーバーが行う送信ピア接続の数は増えません。
`[peers_max]`値を10未満にした場合でも、サーバーはハードコーディングされた最小数である10台の送信ピアを許可するため、ネットワークとの接続を維持できます。すべての送信ピア接続をブロックするには、[サーバーをプライベートピアとして設定](run-rippled-as-a-validator.html#プロキシを使用した接続)します。
**注意:** 接続先のピアサーバーが増えると、`rippled`サーバーが使用するネットワーク帯域幅も増えます。`rippled`サーバーに良好なネットワーク接続があり、使用する帯域幅のコストを許容できる場合にのみ、ピアサーバーの数に大きな値を設定してください。
3. `rippled`サーバーを再起動します。
$ sudo systemctl restart rippled.service
## 関連項目
- **コンセプト:**
- [ピアプロトコル](peer-protocol.html)
- [`rippled`サーバー](the-rippled-server.html)
- **チュートリアル:**
- [容量の計画](capacity-planning.html)
- [`rippled`サーバーのトラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [connectメソッド][]
- [peersメソッド][]
- [printメソッド][]
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

178
content/tutorials/manage-the-rippled-server/configure-peering/use-a-peer-reservation.ja.md Normal file
View File

@@ -0,0 +1,178 @@
# ピアリザベーションの使用
[ピアリザベーション][]を使用すると、`rippled`サーバーが予約とマッチしたピアからの通信を常に受け入れるように設定できます。このページでは、ピアリザベーションを使用して2台のサーバー間のピアツーピア通信を、各サーバーの管理者の協力のもと一貫して維持する方法について説明します。
ピアリザベーションは、2台のサーバーが異なる組織によって運用されていて、着信接続を受信するサーバーが、多くのピアを持つ[ハブサーバー](rippled-server-modes.html#公開ハブ)である場合に特に便利です。分かりやすいように、これらの手順では次の用語を使用します。
- **ストックサーバー**は発信接続を行うサーバーです。このサーバーは、ハブサーバー上のピアリザベーションを _使用_ します。
- **ハブサーバー**は着信接続を受信するサーバーです。管理者は、このサーバーにピアリザベーションを _追加_ します。
ただし、一方または両方のサーバーがハブ、バリデータ、ストックサーバーのいずれあっても、これらの手順を使用してピアリザベーションを設定できます。また、よりビジーな状態にあるサーバーから発信接続をする場合にもピアリザベーションを使用できますが、以下のプロセスではそのような構成については説明しません。
## 前提条件
これらの手順を実行するには、次の前提条件を満たしている必要があります。
- 両方のサーバーの管理者が`rippled`を[インストール](install-rippled.html)して実行している。
- 両方のサーバーの管理者が協力することに合意し、連絡が取り合える。秘密情報を共有する必要はないため、パブリックな通信チャネルを使用してもかまいません。
- ハブサーバーが着信ピア接続を受信できる。ファイアウォールをそのように設定する手順については、[ピアリングのポート転送](forward-ports-for-peering.html)を参照してください。
- 両方のサーバーが、同じ[XRP Ledgerネットワーク](parallel-networks.html)（本番XRP Ledger、Testnet、Devnetなど）と同期するように設定されている。
## 手順
ピアリザベーションを使用するには、以下の手順に従います。
### 1.（ストックサーバー）永続ノードキーペアを設定する
ストックサーバーの管理者が、以下の手順を実行します。
永続ノードキーペア値をすでにサーバーに設定している場合は、[ステップ2: ノード公開鍵をピアの管理者に連絡する](#2-communicate-the-stock-servers-node-public-key)に進んでください。（例えば、各サーバーの永続ノードキーペアは[サーバークラスターの設定](cluster-rippled-servers.html)の一環として設定します。）
**ヒント:** 永続ノードキーペアの設定は省略可能ですが、この設定をしておけば、サーバーのデータベースの消去や新規マシンへの移行が必要となった場合にピア接続の設定を容易に維持することができます。永続ノードキーペアを設定しない場合は、[server_infoメソッド][]の応答の`pubkey_node`フィールドに表示される、サーバーが自動生成したノード公開鍵を使用できます。
1. [validation_createメソッド][]を使用して新しいランダムキーペアを生成します。（`secret`値を省略します。）
例:
rippled validation_create
Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"status" : "success",
"validation_key" : "FAWN JAVA JADE HEAL VARY HER REEL SHAW GAIL ARCH BEN IRMA",
"validation_public_key" : "n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG",
"validation_seed" : "ssZkdwURFMBXenJPbrpE14b6noJSu"
}
}
`validation_seed`（ノードシード値）と`validation_public_key`値（ノード公開鍵）を保存します。
2. `rippled`の構成ファイルを編集します。
vim /etc/opt/ripple/rippled.cfg
{% include '_snippets/conf-file-location.md' %}<!--_ -->
3. 前のステップで生成した`validation_seed`値を使用して、`[node_seed]`スタンザを追加します。
例:
[node_seed]
ssZkdwURFMBXenJPbrpE14b6noJSu
**警告:** すべてのサーバーの`[node_seed]`値が一意である必要があります。構成ファイルを別のサーバーにコピーする場合は、`[node_seed]`値を削除するか、変更してください。`[node_seed]`は公開しないようにします。不正使用者がこの値にアクセスできた場合、それを使用してサーバーを偽装し、XRP Ledgerのピアツーピア通信を行う可能性があります。
4. `rippled`サーバーを再起動します。
systemctl restart rippled
### 2.ストックサーバーのノード公開鍵を連絡する
ストックサーバーの管理者が、ハブサーバーの管理者にストックサーバーのノード公開鍵を伝えます。（ステップ1の`validation_public_key`を使用します。）ハブサーバーの管理者はこの値を以降のステップで使用する必要があります。
### 3.（ハブサーバー）ピアリザベーションを追加する
ハブサーバーの管理者が、以下の手順を実行します。
[peer_reservations_addメソッド][]を使用し、前のステップで入手したノード公開鍵を使用して予約を追加します。例:
```sh
$ rippled peer_reservations_add n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG "Description here"
Loading: "/etc/opt/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result": {
"status": "success"
}
}
```
**ヒント:** 説明はオプションのフィールドです。この予約は誰のためにしたものかを人間が読み取れる形式のメモを追加できます。
### 4.ハブサーバーの現在のIPアドレスとピアポートを連絡する
ハブサーバーの管理者は、サーバーの現在のIPアドレスとピアポートをストックサーバーの管理者に伝える必要があります。ハブサーバーが、ネットワークアドレス変換（NAT）を行なうファイアウォールの内側にある場合は、サーバーの _外部_ IPアドレスを使用します。デフォルトの構成ファイルは、ピアプロトコルにポート51235を使用します。
### 5.（ストックサーバー）ピアサーバーに接続する
ストックサーバーの管理者が、以下の手順を実行します。
[connectメソッド][]を使用して、サーバーをハブサーバーに接続します。例:
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```
{
"command": "connect",
"ip": "169.54.2.151",
"port": 51235
}
```
*JSON-RPC*
```
{
"method": "connect",
"params": [
{
"ip": "169.54.2.151",
"port": 51235
}
]
}
```
*コマンドライン*
```
rippled connect 169.54.2.151 51235
```
<!-- MULTICODE_BLOCK_END -->
ハブサーバーの管理者が上記の手順に従ってピアリザベーションを設定した場合、自動的に接続され、可能な限り接続が維持されます。
## 次のステップ
サーバーの管理者は、サーバーに設定された他のピアへの予約を管理できます。（他のサーバーからの予約は確認できません。）次のことを実行できます。
- [peer_reservations_addメソッド][]を使用して、ピアリザベーションの追加や説明の更新を行う。
- [peer_reservations_listメソッド][]を使用して、予約先のサーバーを確認する。
- [peer_reservations_delメソッド][]を使用して、予約を削除する。
- [peersメソッド][]を使用して、現在接続しているピアと使用している帯域幅の量を確認する。
**ヒント:** 不正なピアからの接続を即座に切断するAPIメソッドはありませんが、`firewalld`などのソフトウェアファイアウォールを使用すれば、不正なピアからのサーバーへの接続をブロックできます。例については、コミュニティーによって作成された[rbhスクリプト](https://github.com/gnanderson/rbh)を参照してください。
## 関連項目
- **コンセプト:**
- [ピアプロトコル](peer-protocol.html)
- [コンセンサス](consensus.html)
- [並列ネットワーク](parallel-networks.html)
- **チュートリアル:**
- [容量の計画](capacity-planning.html)
- [`rippled`のトラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [peersメソッド][]
- [peer_reservations_addメソッド][]
- [peer_reservations_delメソッド][]
- [peer_reservations_listメソッド][]
- [connectメソッド][]
- [fetch_infoメソッド][]
- [ピアクローラー](peer-crawler.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

163
content/tutorials/manage-the-rippled-server/installation/build-run-rippled-macos.ja.md
View File

@@ -1,113 +1,117 @@
# macOSでのrippledの構築と実行
現時点において、Rippleでは`rippled`の本番環境にmacOSの使用を推奨していません。本番環境には、最高レベルの品質管理とテストを経た、[Ubuntuプラットフォーム](install-rippled-on-ubuntu-with-alien.html)のご使用をご検討ください。
[`rippled`](the-rippled-server.html)の本番環境にmacOSプラットフォームを使用することは推奨されていません。本番環境には、最高レベルの品質管理とテストを経た、[Ubuntuプラットフォーム](install-rippled-on-ubuntu-with-alien.html)のご使用をご検討ください。
しかしながら、macOSは多くの開発やテストの作業に適しています。 `rippled` は、10.13 High SierraまでのmacOSでテスト済みです。
しかしながら、macOSは多くの開発やテストの作業に適しています。`rippled`は、10.13 High SierraまでのmacOSでテスト済みです。
開発目的の場合は、`sudo`を使用するのではなく、自身のユーザーとして`rippled`を実行することをお勧めします。
開発目的の場合は、`sudo`を使用するのではなく、非管理者ユーザーとして`rippled`を実行します。
1. [Xcode](https://developer.apple.com/download/)をインストールします。
0. Xcodeコマンドラインツールをインストールします。
$ xcode-select --install
0. [Homebrew](https://brew.sh/)をインストールします。
$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
0. Homebrewをアップデートします。
$ brew update
0. Homebrewを使用して依存関係をインストールします。
$ brew install git cmake pkg-config protobuf openssl ninja
0. Boost 1.71.0をインストールします。 `rippled` 1.4.0はBoost 1.70以上と互換性を持ちます。
0. Boost 1.70.0以降をインストールします。`rippled`1.4.0はBoost 1.70.0以降と互換性があります。HomebrewのリポジトリにあるBoostの最新バージョンでは不十分であるため、Boostを手動でインストールする必要があります。（次の例では、本書執筆時点の最新バージョンであるBoost 1.71.0を使用しています。）
1. [Boost 1.71.0](https://dl.bintray.com/boostorg/release/1.71.0/source/boost_1_71_0.tar.bz2)をダウンロードします。
2. フォルダに抽出します。場所をメモしておいてください。
3. ターミナルで以下を実行します。
cd /LOCATION/OF/YOUR/BOOST/DIRECTORY
./bootstrap.sh
./b2 cxxflags="-std=c++14"
1. [Boost 1.71.0](https://dl.bintray.com/boostorg/release/1.71.0/source/boost_1_71_0.tar.bz2)をダウンロードします。
2. フォルダに抽出します。場所をメモしておいてください。
3. ターミナルで以下を実行します。
cd /LOCATION/OF/YOUR/BOOST/DIRECTORY
./bootstrap.sh
./b2 cxxflags="-std=c++14"
0. `BOOST_ROOT`環境変数が、Boostのインストールで作成されたディレクトリーを指すようにします。Boostのインストールディレクトリーを見つけるには、`brew info boost`を使用します。この環境変数を`.bash_profile`ファイルに追加すると、ログイン時に自動的に設定されます。例えば、次のようにします。
export BOOST_ROOT=/Users/my_user/boost_1_71_0
0. 前のステップで`.bash_profile`ファイルをアップデートした場合には、それを読み込みます。例:
0. `BOOST_ROOT`環境が、Boostのインストールで作成されたディレクトリーを指すようにします。
1. Boostディレクトリーを確認するには、Boostを手動でインストールした場合は`pwd`、Homebrewを使用してインストールした場合は`brew --prefix boost`を使用します。
2. 以下のコードをBoostディレクトリーの場所に編集して実行し、Boost環境変数が`.bash_profile`ファイルに追加されるようにします。そうすることで、ログイン時にこの環境変数が自動的に設定されます。
$ echo $"export BOOST_ROOT=/Users/my_user/boost_1_71_0" >> ~/.bash_profile
0. 前のステップで`.bash_profile`ファイルをアップデートした場合には、新しいターミナルウィンドウでそれを読み込みます。例:
$ source .bash_profile
0. 希望の場所に`rippled`ソースコードをクローンし、`rippled`ディレクトリーにアクセスします。これを行うには、Git（Homebrewを使用して前にインストール済み）とGitHubを設定する必要があります。例えば、GitHubアカウントを作成し、SSHキーを設定します。詳細は、[Set up git](https://help.github.com/articles/set-up-git/)を参照してください。
$ git clone git@github.com:ripple/rippled.git
$ cd rippled
0. デフォルトでは、クローンを実行すると`develop`ブランチに移動します。開発作業をしていて、未テストの機能の最新セットを使用したい場合にはこのブランチを使用します。
最新の安定したリリースを使用したい場合には、`master`ブランチをチェックアウトします。
$ git checkout master
最新のリリース候補をテストしたい場合には、`release`ブランチをチェックアウトします。
$ git checkout release
または、[GitHub](https://github.com/ripple/rippled/releases)にリストされたタグ付きのリリースをチェックアウトすることもできます。
最新の安定したリリースを使用したい場合には、`master`ブランチをチェックアウトします。
$ git checkout master
最新のリリース候補をテストしたい場合には、`release`ブランチをチェックアウトします。
$ git checkout release
または、[GitHub](https://github.com/ripple/rippled/releases)にリストされたタグ付きのリリースをチェックアウトすることもできます。
0. クローンしたばかりの`rippled`ディレクトリー内にビルドディレクトリーを作成し、そこにアクセスします。例:
$ mkdir my_build
$ cd my_build
$ mkdir my_build
$ cd my_build
0. `rippled`を構築します。ハードウェアの仕様にもよりますが、これには約5分ほどかかります。
$ cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug ..
`CMAKE_BUILD_TYPE`を`Debug`または`Release`ビルドタイプに設定できます。標準的な4つの[`CMAKE_BUILD_TYPE`](https://cmake.org/cmake/help/v3.0/variable/CMAKE_BUILD_TYPE.html)の値がすべてサポートされています。
$ cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug ..
`CMAKE_BUILD_TYPE`を`Debug`または`Release`ビルドタイプに設定できます。標準的な4つの[`CMAKE_BUILD_TYPE`](https://cmake.org/cmake/help/v3.0/variable/CMAKE_BUILD_TYPE.html)の値がすべてサポートされています。
0. CMakeを使用してビルドを実行します。ハードウェアの仕様にもよりますが、これには約10分ほどかかります。
$ cmake --build .-- -j 4
**ヒント:** この例では、`-j`パラメーターが`4`に設定されています。これにより、4つのプロセスを使用し、並行してビルドします。使用する最適なプロセス数は、お使いのハードウェアで使用可能なCPUコア数によって異なります。`sysctl -n hw.ncpu`を使用して、CPUのコア数を調べてください。
$ cmake --build .-- -j 4
**ヒント:** この例では、`-j`パラメーターが`4`に設定されています。これにより、4つのプロセスを使用し、並行してビルドします。使用する最適なプロセス数は、お使いのハードウェアで使用可能なCPUコア数によって異なります。`sysctl -n hw.ncpu`を使用して、CPUのコア数を調べてください。
0. サーバー実行可能ファイルに組み込まれたユニットテストを実行します。ハードウェアの仕様にもよりますが、これには約5分ほどかかります。（省略可能ですが、推奨します）
$ ./rippled --unittest
$ ./rippled --unittest
0. `rippled` は、`rippled.cfg`構成ファイルの実行を必要とします。`rippled/cfg`に、サンプル構成ファイルの`rippled-example.cfg`があります。このファイルをコピーし、`rippled`を非ルートユーザーとして実行できる場所に`rippled.cfg`という名前で保存します。`rippled`ディレクトリーにアクセスして、以下を実行します。
$ mkdir -p $HOME/.config/ripple
$ cp cfg/rippled-example.cfg $HOME/.config/ripple/rippled.cfg
0. `rippled`は、`rippled.cfg`構成ファイルの実行を必要とします。`rippled/cfg`に、サンプル構成ファイルの`rippled-example.cfg`があります。このファイルをコピーし、`rippled`を非ルートユーザーとして実行できる場所に`rippled.cfg`という名前で保存します。`rippled`ディレクトリーにアクセスして、以下を実行します。
$ mkdir -p $HOME/.config/ripple
$ cp cfg/rippled-example.cfg $HOME/.config/ripple/rippled.cfg
0. `rippled.cfg`を編集し、必要なファイルパスを設定します。`rippled`を実行するユーザーは、ここで指定するすべてのパスへの書き込み権限を持っている必要があります。
* `[node_db]`パスを、台帳データベースを保存する場所に設定します。
* `[database_path]`パスを、その他のデータベースデータを保存する場所に設定します。（この場所には、構成データを持つSQLiteデータベースも含まれ、通常、`[node_db]`パスフィールドの1つ上のレベルになります。）
* `[debug_logfile]`を`rippled`がログ情報を書き込めるパスに設定します。
`rippled`を正常に起動するために必要な構成はこれだけです。その他の構成はすべて省略可能であり、作業サーバーをセットアップしてから調整することもできます。詳細は、[Additional Configurations](#その他の構成)を参照してください。
* `[node_db]`パスを、台帳データベースを保存する場所に設定します。
* `[database_path]`パスを、その他のデータベースデータを保存する場所に設定します。（この場所には、構成データを持つSQLiteデータベースも含まれ、通常、`[node_db]`パスフィールドの1つ上のレベルになります。）
* `[debug_logfile]`を`rippled`がログ情報を書き込めるパスに設定します。
`rippled`を正常に起動するために必要な構成はこれだけです。その他の構成はすべて省略可能であり、作業サーバーをセットアップしてから調整することもできます。詳細については、[追加構成](#additional-configuration)を参照してください。
0. `rippled` は、`validators.txt`ファイルの実行を必要とします。`rippled/cfg/`に、サンプルバリデータファイルの`validators-example.txt`があります。このファイルをコピーし、`rippled.cfg`ファイルと同じフォルダーに`validators.txt`という名前で保存します。`rippled`ディレクトリーにアクセスして、以下を実行します。
$ cp cfg/validators-example.txt $HOME/.config/ripple/validators.txt
**警告:** Rippleは、安全を第一に考えて分散プランをデザインしました。特にRippleから勧められない限り、移行中に`validators.txt`ファイルを変更しないでください。小さな変更であっても、バリデータの設定に変更を加えると、サーバーがネットワークから分岐し、古い、不完全、または正しくないデータについて報告する原因となることがあります。そのようなデータを使用すると、経費の無駄になります。
0. `rippled`は、`validators.txt`ファイルの実行を必要とします。`rippled/cfg/`に、サンプルバリデータファイルの`validators-example.txt`があります。このファイルをコピーし、`rippled.cfg`ファイルと同じフォルダーに`validators.txt`という名前で保存します。`rippled`ディレクトリーにアクセスして、以下を実行します。
$ cp cfg/validators-example.txt $HOME/.config/ripple/validators.txt
**警告:** Rippleは、安全を第一に考えて分散プランをデザインしました。特にRippleから勧められない限り、移行中に`validators.txt`ファイルを変更しないでください。小さな変更であっても、バリデータの設定に変更を加えると、サーバーがネットワークから分岐し、古い、不完全、または正しくないデータについて報告する原因となることがあります。そのようなデータを使用すると、経費の無駄になります。
0. ビルドディレクトリー（`my_build`など）にアクセスし、`rippled`サービスを開始します。
$ ./rippled
以下は、ターミナルに表示される内容の抜粋です。
$ ./rippled
以下は、ターミナルに表示される内容の抜粋です。
```
2018-Oct-26 18:21:39.593738 JobQueue:NFO Auto-tuning to 6 validation/transaction/proposal threads.
@@ -157,7 +161,7 @@
2018-Oct-26 18:23:03.034750 InboundLedger:WRN Want: 8DFAD21AD3090DE5D6F7592B3821C3DA77A72287705B4CF98DC0F84D5DD2BDF8
```
`rippled`ログメッセージの詳細については、[ログメッセージについて](understanding-log-messages.html)を参照してください。
`rippled`ログメッセージの詳細は、[ログメッセージについて](understanding-log-messages.html)を参照してください。
## 次のステップ
@@ -165,6 +169,21 @@
## 関連項目
- [Ubuntu Linuxでrippledをインストール](install-rippled-on-ubuntu-with-alien.html)（本番環境用の、Ubuntu上の事前構築済みバイナリー）
- [Ubuntuでの`rippled`の構築と実行](build-run-rippled-ubuntu.html)（Ubuntuで`rippled`を自分でコンパイル）
- [その他のプラットフォーム用のコンパイル手順](https://github.com/ripple/rippled/tree/develop/Builds)
- **コンセプト:**
- [`rippled`サーバー](the-rippled-server.html)
- [コンセンサスについて](intro-to-consensus.html)
- **チュートリアル:**
- [Ubuntu Linuxでrippledをインストール](install-rippled-on-ubuntu.html)（本番環境用の、Ubuntu上の事前構築済みバイナリーをインストール）
- [rippledの構成](configure-rippled.html)
- [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
- [rippled APIの使用開始](get-started-with-the-rippled-api.html)
- **リファレンス:**
- [rippled APIリファレンス](rippled-api.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

195
content/tutorials/manage-the-rippled-server/installation/build-run-rippled-ubuntu.ja.md
View File

@@ -1,6 +1,6 @@
# Ubuntuでのrippledの構築と実行
`rippled` は、XRP Ledgerを管理するコアのピアツーピアサーバーです。`rippled`サーバーは、ピアのネットワークに接続し、暗号で署名された取引を中継し、共有のグローバル台帳の完全なローカルコピーを維持します。
`rippled`は、XRP Ledgerを管理するコアのピアツーピアサーバーです。`rippled`サーバーは、ピアのネットワークに接続し、暗号で署名された取引を中継し、共有のグローバル台帳の完全なローカルコピーを維持します。
`rippled`の概要については、[Operating rippled Servers](install-rippled.html)を参照してください。
@@ -18,102 +18,105 @@
次の手順では、UbuntuのAPT（Advanced Packaging Tool）を使用し、`rippled`の構築と実行に必要なソフトウェアをインストールします。
1. `apt-get`でインストールまたはアップグレードできるパッケージのリストを更新します。
sudo apt-get update
2. 現在インストールされているパッケージをアップグレードします。
sudo apt-get -y upgrade
3. 依存関係をインストールします。
sudo apt-get -y install git pkg-config protobuf-compiler libprotobuf-dev libssl-dev wget
4. CMakeをインストールします。
`rippled`のバージョン1.4.0は、CMake 3.9.0以降を必要とします。このチュートリアルでは、執筆時の最新バージョンだったCMake 3.13.3を使用しました。
CMake 3.9.0以降をすでにインストールしてある場合には、このステップはスキップできます。
CMake 3.13.3をインストールするには、以下を実行します。
`rippled`のバージョン1.4.0は、CMake 3.9.0以降を必要とします。このチュートリアルでは、執筆時の最新バージョンだったCMake 3.13.3を使用しました。
CMake 3.9.0以降をすでにインストールしてある場合には、このステップはスキップできます。
CMake 3.13.3をインストールするには、以下を実行します。
wget https://github.com/Kitware/CMake/releases/download/v3.13.3/cmake-3.13.3-Linux-x86_64.sh
sudo sh cmake-3.13.3-Linux-x86_64.sh --prefix=/usr/local --exclude-subdir
`cmake --version`を使用し、正常にインストールされたことを確認します。
`cmake --version`を使用し、正常にインストールされたことを確認します。
5. Boostをコンパイルします。
`rippled` 1.4.0はBoost 1.70以上と互換性を持ちます。Ubuntu（18.04も16.04も）のソフトウェアリポジトリに、Boostバージョン1.70.0がないため、自分でコンパイルする必要があります。
以前に`rippled`用にBoost 1.71.0をインストールしていて、`BOOST_ROOT`環境変数を構成した場合には、このステップはスキップできます。
1. Boost 1.71.0をダウンロードします。
wget https://dl.bintray.com/boostorg/release/1.71.0/source/boost_1_71_0.tar.gz
2. `boost_1_71_0.tar.gz`を抽出します。
tar xvzf boost_1_71_0.tar.gz
3. 新しい`boost_1_71_0`ディレクトリーに移動します。
cd boost_1_71_0
4. 使用するBoost.Buildシステムを準備します。
./bootstrap.sh
5. 個別にコンパイルされたBoostライブラリを構築します。ハードウェアの仕様にもよりますが、これには約10分かかります。
./b2 -j 4
**ヒント:** この例では、4つのプロセスを並行して構築します。使用する最適なプロセス数は、お使いのハードウェアで使用可能なCPUコア数によって異なります。`cat /proc/cpuinfo`を使用して、ハードウェアプロセッサーに関する情報を取得できます。
6. `BOOST_ROOT`環境変数を、新しい`boost_1_71_0`ディレクトリーを参照するように設定します。ログイン時に自動的に設定されるようにするため、この環境変数を、シェル用の`.profile`またはそれに相当するファイルに入れることをお勧めします。ファイルに次の行を追加します。
export BOOST_ROOT=/home/my_user/boost_1_71_0
7. 更新した`.profile`ファイルを読み込みます。例:
source ~/.profile
`rippled`のバージョン1.4.0は、Boostバージョン1.70.0以降を必要とします。Ubuntu 18.04（または16.04）ソフトウェアリポジトリにBoostバージョン1.70.0以降がないため、自分でコンパイルする必要があります。（次の例では、執筆時点の最新バージョンであるBoost 1.71.0を使用しています。）
以前に`rippled`用にBoost 1.71.0をインストールしていて、`BOOST_ROOT`環境変数を構成した場合には、このステップはスキップできます。
1. Boost 1.71.0をダウンロードします。
wget https://dl.bintray.com/boostorg/release/1.71.0/source/boost_1_71_0.tar.gz
2. `boost_1_71_0.tar.gz`を抽出します。
tar xvzf boost_1_71_0.tar.gz
3. 新しい`boost_1_71_0`ディレクトリーに移動します。
cd boost_1_71_0
4. 使用するBoost.Buildシステムを準備します。
./bootstrap.sh
5. 個別にコンパイルされたBoostライブラリを構築します。ハードウェアの仕様にもよりますが、これには約10分かかります。
./b2 -j 4
**ヒント:** この例では、4つのプロセスを並行して構築します。使用する最適なプロセス数は、お使いのハードウェアで使用可能なCPUコア数によって異なります。`cat /proc/cpuinfo`を使用して、ハードウェアプロセッサーに関する情報を取得できます。
6. `BOOST_ROOT`環境変数を、新しい`boost_1_71_0`ディレクトリーを参照するように設定します。ログイン時に自動的に設定されるようにするため、この環境変数を、シェル用の`.profile`またはそれに相当するファイルに入れることをお勧めします。ファイルに次の行を追加します。
export BOOST_ROOT=/home/my_user/boost_1_71_0
7. 更新した`.profile`ファイルを読み込みます。例:
source ~/.profile
6. 作業ディレクトリーから、`rippled`ソースコードを取得します。`master`ブランチに最新のリリースバージョンがあります。
git clone https://github.com/ripple/rippled.git
cd rippled
git checkout master
7. コミットログを調べ、正しいバージョンをコンパイルしていることを確認します。最新のコミットは、よく知られるRipple開発者によって署名され、バージョン番号が最新のリリースバージョンに設定されています。例:
$ git log -1
commit 06c371544acc3b488b9d9c057cee4e51f6bef7a2
Author: Nik Bougalis <nikb@bougalis.net>
Date: Mon Nov 25 22:58:03 2019 -0800
Set version to 1.4.0
commit e1adbd7ddd5dfa9f2a9791aa3c0fcc1fdb4e8236
Author: Manoj doshi <mdoshi@ripple.com>
Date: Wed Jul 24 15:21:56 2019 -0700
Set version to 1.3.1
8. 以前に`rippled`を構築したことがある場合、または（そしてもっと重要なのは）構築しようとして失敗したことがある場合には、クリーンな状態から開始するために、次のステップに移る前に`my_build/`ディレクトリー（またはユーザーが付けた名前）を削除する必要があります。このディレクトリーを削除しないと、セグメンテーションエラー（segfault）が原因で`rippled`実行可能ファイルがクラッシュするなど、予期しない動作が発生することがあります。
`rippled`1.0.0以上を構築するのが初めての場合には、`my_build/`ディレクトリーはないため、次のステップに進むことができます。
`rippled` 1.0.0以上を構築するのが初めての場合には、`my_build/`ディレクトリーはないため、次のステップに進むことができます。
9. CMakeを使用して、ソースコードから`rippled`バイナリー実行可能ファイルを構築します。その結果、`my_build`ディレクトリーに`rippled`バイナリー実行可能ファイルが構築されます。
1. ビルドシステムを生成します。ビルドは、ソースツリールートとは別のディレクトリーで実行します。この例では、`rippled`のサブディレクトリーである`my_build`ディレクトリーを使用します。
mkdir my_build
cd my_build
cmake ..
**ヒント:** デフォルトのビルドには、本番環境では有用ではないものの、開発環境に便利なデバッグ記号が含まれています。`rippled`を本番環境用サーバーで使用するには、`cmake`コマンドの実行時に`-DCMAKE_BUILD_TYPE=Release`フラグを追加します。
2. `rippled`のバイナリー実行可能ファイルを構築します。ハードウェアの仕様にもよりますが、これには約30分かかります。
cmake --build .
1. ビルドシステムを生成します。ビルドは、ソースツリールートとは別のディレクトリーで実行します。この例では、`rippled`のサブディレクトリーである`my_build`ディレクトリーを使用します。
mkdir my_build
cd my_build
cmake ..
**ヒント:** デフォルトのビルドには、本番環境では有用ではないものの、開発環境に便利なデバッグ記号が含まれています。`rippled`を本番環境用サーバーで使用するには、`cmake`コマンドの実行時に`-DCMAKE_BUILD_TYPE=Release`フラグを追加します。
2. `rippled`のバイナリー実行可能ファイルを構築します。ハードウェアの仕様にもよりますが、これには約30分かかります。
cmake --build .
10. _（省略可能）_`rippled`ユニットテストを実行します。テストエラーがない場合には、`rippled`実行可能ファイルがほぼ確実に正しくコンパイルされています。
./rippled -u
@@ -122,23 +125,23 @@
`rippled`を正常に起動させるために必要な以下の構成を行います。その他の構成はすべて省略可能であり、作業サーバーをセットアップしてから調整することもできます。
1. `rippled`フォルダーに移動して、サンプル構成ファイルのコピーを作成します。構成ファイルをこの場所に保存すると、`rippled`を非ルートユーザーとして実行できます（推奨）。
mkdir -p ~/.config/ripple
cp cfg/rippled-example.cfg ~/.config/ripple/rippled.cfg
2. 構成ファイルを編集し、必要なファイルパスを設定します。`rippled`を実行するユーザーは、ここで指定するすべてのパスへの書き込み権限を持っている必要があります。
1. `[node_db]`のパスを、台帳データベースを保存する場所に設定します。
2. `[database_path]`を、その他のデータベースデータを保存する場所に設定します。（この場所には、構成データを持つSQLiteデータベースも含まれ、通常、`[node_db]`パスフィールドの1つ上のレベルになります。）
3. `[debug_logfile]`を`rippled`がロギング情報を書き込めるパスに設定します。
1. `[node_db]`のパスを、台帳データベースを保存する場所に設定します。
2. `[database_path]`を、その他のデータベースデータを保存する場所に設定します。（この場所には、構成データを持つSQLiteデータベースも含まれ、通常、`[node_db]`パスフィールドの1つ上のレベルになります。）
3. `[debug_logfile]`を`rippled`がログ情報を書き込めるパスに設定します。
3. サンプルの`validators.txt`ファイルを`rippled.cfg`と同じフォルダーに保存します。
cp cfg/validators-example.txt ~/.config/ripple/validators.txt
**警告:** Rippleは、安全を第一に考えて[分散プラン](https://ripple.com/dev-blog/decentralization-strategy-update/)をデザインしました。特にRippleから勧められない限り、移行中に`validators.txt`ファイルを変更*しない*でください。小さな変更であっても、バリデータの設定に変更を加えると、サーバーがネットワークから分岐し、古い、不完全、または正しくないデータについて報告する原因となることがあります。そのようなデータを使用すると、経費の無駄になります。
**警告:** Rippleは、安全を第一に考えて[分散プラン](https://xrpl.org/blog/2017/decent-strategy-update.html)をデザインしました。特にRippleから勧められない限り、移行中に`validators.txt`ファイルを変更*しない*でください。小さな変更であっても、バリデータの設定に変更を加えると、サーバーがネットワークから分岐し、古い、不完全、または正しくないデータについて報告する原因となることがあります。そのようなデータを使用すると、経費の無駄になります。
## 3. `rippled`の実行
@@ -193,10 +196,10 @@ Watchdog: Launching child 1
2018-Jun-06 00:52:33.379747629 LedgerConsensus:WRN {"accepted":true,"account_hash":"CC1F1EC08E76BC9FE843BBF9C6068C5B73192E6957B9CC1174DCB2B94DD2025A","close_flags":0,"close_time":581561550,"close_time_human":"2018-Jun-06 00:52:30.000000000","close_time_resolution":30,"closed":true,"hash":"94354A7FECAB638C29BBC79B18CFDBDC05E4FF72647AD62F072DB4D23A5E0317","ledger_hash":"94354A7FECAB638C29BBC79B18CFDBDC05E4FF72647AD62F072DB4D23A5E0317","ledger_index":"3","parent_close_time":581561490,"parent_hash":"80BF92A69F65F5C543E962DF4B41715546FDD97FC6988028E5ACBB46654756CA","seqNum":"3","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
...
2018-Jun-06 00:53:50.568965045 LedgerConsensus:WRN {"accepted":true,"account_hash":"A79E6754544F9C8FC74870C95A39CED1D45CC1206DDA4C113E51F9DB6DDB0E76","close_flags":0,"close_time":581561630,"close_time_human":"2018-Jun-06 00:53:50.000000000","close_time_resolution":10,"closed":true,"hash":"6294118F39F5F2B8349E7CC6D4D5931011622E78DD4E34D91372651E9F453E2F","ledger_hash":"6294118F39F5F2B8349E7CC6D4D5931011622E78DD4E34D91372651E9F453E2F","ledger_index":"29","parent_close_time":581561623,"parent_hash":"5F57870CE5160D6B53271955F26E3BE63696D1127B91BC7943F9A199B313CB85","seqNum":"29","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
2018-Jun-06 0:53:50.569776678 LedgerConsensus:WRN Need consensus ledger 6A0DE66550B6BA9636E3F8FDB71C2E924D182A1835E4143B2170DAA1D33CAE8D
2018-Jun-06 0:53:51.576778862 NetworkOPs:WRN We are not running on the consensus ledger
2018-Jun-06 00:53:50.569776678 LedgerConsensus:WRN Need consensus ledger 6A0DE66550B6BA9636E3F8FDB71C2E924D182A1835E4143B2170DAA1D33CAE8D
2018-Jun-06 00:53:51.576778862 NetworkOPs:WRN We are not running on the consensus ledger
2018-Jun-06 00:53:53.576524564 LedgerConsensus:WRN View of consensus changed during establish status=establish, mode=wrongLedger
2018-Jun-06 0:53:53.576783663 LedgerConsensus:WRN 6A0DE66550B6BA9636E3F8FDB71C2E924D182A1835E4143B2170DAA1D33CAE8D to 1CB9C9A1C27403CBAB9DFCFA61E1F915059DFE4FA93524537B885CC190DB5C6B
2018-Jun-06 00:53:53.576783663 LedgerConsensus:WRN 6A0DE66550B6BA9636E3F8FDB71C2E924D182A1835E4143B2170DAA1D33CAE8D to 1CB9C9A1C27403CBAB9DFCFA61E1F915059DFE4FA93524537B885CC190DB5C6B
2018-Jun-06 00:53:53.577079124 LedgerConsensus:WRN {"accepted":true,"account_hash":"5CAB3E4F5F2AC1A764106D7CC0729E6E7D1F7F93C65B7D8CB04C8DE2FC2C1305","close_flags":0,"close_time":581561631,"close_time_human":"2018-Jun-06 00:53:51.000000000","close_time_resolution":10,"closed":true,"hash":"201E147BD195CE3C56B0C0B8DF58386FC7BFF450E1E5B286A29AB856926D5F79","ledger_hash":"201E147BD195CE3C56B0C0B8DF58386FC7BFF450E1E5B286A29AB856926D5F79","ledger_index":"30","parent_close_time":581561630,"parent_hash":"6294118F39F5F2B8349E7CC6D4D5931011622E78DD4E34D91372651E9F453E2F","seqNum":"30","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
```
@@ -205,8 +208,32 @@ Watchdog: Launching child 1
* これでストック`rippled`サーバーを実行できたので、次に検証サーバーとして実行してみましょう。検証サーバーの詳細について、そして検証サーバーを実行する理由については、[rippledのセットアップチュートリアル](install-rippled.html)を参照してください。
* `rippled` APIを使用して`rippled`サーバーと通信する方法については、[`rippled` API reference](rippled-api.html)を参照してください。
* `rippled` APIを使用して`rippled`サーバーと通信する方法については、[`rippled` APIリファレンス](rippled-api.html)を参照してください。
* 開発のベストプラクティスとして、`rippled` `.deb`ファイルを構築することをお勧めします。詳細は、_Ubuntu Packaging Guide_ の[Packaging New Software](http://packaging.ubuntu.com/html/packaging-new-software.html)を参照してください。
* 開発のベストプラクティスとして、`rippled` `.deb`パッケージをビルドすることをお勧めします。CMakeビルドのdebパッケージターゲットを使用して、ソースツリーから直接`deb`パッケージをビルドできます。ビルドマシンには[Dockerをインストール](https://docs.docker.com/install/#supported-platforms)している必要があります。このプロセスを完了するのに1時間以上かかる場合があります。`deb`パッケージをビルドするには、以下の手順に従います。
mkdir -p build/pkg && cd build/pkg
cmake -Dpackages_only=ON ../..
cmake --build . --target dpkg
* また、`systemd`をインストールすることもできます。詳細については、[systemd for Upstart Users](https://wiki.ubuntu.com/SystemdForUpstartUsers)を参照してください。[公式の`rippled`システムユニットファイル](https://github.com/ripple/rippled-package-builder/blob/staging/rpm-builder/rippled.service)をそのまま使用するか、ニーズに合わせてファイルを編集して使用できます。
* また、`systemd`をインストールすることもできます。詳細は、[systemd for Upstart Users](https://wiki.ubuntu.com/SystemdForUpstartUsers)を参照してください。[公式の`rippled`システムユニットファイル](https://github.com/ripple/rippled/blob/master/Builds/containers/shared/rippled.service)をそのまま使用するか、ニーズに合わせてファイルを編集して使用できます。
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](the-rippled-server.html)
- [コンセンサスについて](intro-to-consensus.html)
- **チュートリアル:**
- [rippledの構成](configure-rippled.html)
- [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
- [rippled APIの使用開始](get-started-with-the-rippled-api.html)
- **リファレンス:**
- [rippled APIリファレンス](rippled-api.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

54
content/tutorials/manage-the-rippled-server/installation/install-rippled-on-centos-rhel-with-yum.ja.md
View File

@@ -13,19 +13,37 @@
## インストール手順
1. Ripple RPMリポジトリをインストールします。
$ cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
[ripple-stable]
name=XRP Ledger Packages
baseurl=https://repos.ripple.com/repos/rippled-rpm/stable/
enabled=1
gpgcheck=0
gpgkey=https://repos.ripple.com/repos/rippled-rpm/stable/repodata/repomd.xml.key
repo_gpgcheck=1
REPOFILE
$ sudo rpm -Uvh https://mirrors.ripple.com/ripple-repo-el7.rpm
2. 最新のrepoのアップデートを取得します。
$ sudo yum -y update
2. `rippled`ソフトウェアパッケージをインストールします。
3. 新しい`rippled`パッケージをインストールします。
$ sudo yum install rippled
バージョン1.3.1では、構成ファイル（`rippled.cfg`および`validators.txt`）を変更する必要はありません。このアップデート手順では、既存の構成ファイルが現在のまま残ります。
$ sudo yum install --enablerepo=ripple-stable rippled
3. システム起動時に開始するように、`rippled`サービスを設定します。
4. systemdユニットファイルを再度読み込みます。
$ sudo systemctl daemon-reload
5. 起動時に開始するように、`rippled`サービスを設定します。
$ sudo systemctl enable rippled.service
4. `rippled`サービスを開始します。
6. `rippled`サービスを開始します。
$ sudo systemctl start rippled.service
@@ -33,9 +51,23 @@
{% include '_snippets/post-rippled-install.md' %}<!--_ -->
## 関連項目
- [CentOS/Red Hatでの自動更新](update-rippled-automatically-on-centos-rhel.html)
- [Ubuntu Linuxでrippledをインストール](install-rippled-on-ubuntu-with-alien.html)（Ubuntu上の事前構築済みバイナリー）
- [Ubuntuでの'rippled'の構築と実行](build-run-rippled-ubuntu.html)（Ubuntuで`rippled`を自分でコンパイル）
- [その他のプラットフォーム用のコンパイル手順](https://github.com/ripple/rippled/tree/develop/Builds)
- **コンセプト:**
- [`rippled`サーバー](the-rippled-server.html)
- [コンセンサスについて](intro-to-consensus.html)
- **チュートリアル:**
- [rippledの構成](configure-rippled.html)
- [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
- [rippled APIの使用開始](get-started-with-the-rippled-api.html)
- **リファレンス:**
- [rippled APIリファレンス](rippled-api.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

104
content/tutorials/manage-the-rippled-server/installation/install-rippled-on-ubuntu.ja.md Normal file
View File

@@ -0,0 +1,104 @@
# UbuntuまたはDebian Linuxへのインストール
このページでは、[`apt`](https://help.ubuntu.com/lts/serverguide/apt.html)ユーティリティを使用して、**Ubuntu Linux 16.04以降**または**Debian 9（Stretch）** に`rippled`の安定した最新バージョンをインストールする場合の推奨手順を説明します。
以下の手順では、Rippleによってコンパイルされたバイナリーをインストールします。
## 前提条件
`rippled`をインストールする前に、[システム要件](system-requirements.html)を満たす必要があります。
## インストール手順
1. リポジトリを更新します。
$ sudo apt -y update
2. ユーティリティをインストールします。
$ sudo apt -y install apt-transport-https ca-certificates wget gnupg
3. Rippleのパッケージ署名用のGPGキーを、信頼できるキーのリストに追加します。
$ wget -q -O - "https://repos.ripple.com/repos/api/gpg/key/public" | \
sudo apt-key add -
4. 追加したキーのフィンガープリントを確認します。
$ apt-key finger
出力に、次のようなRipple用のエントリーが含まれています。
pub rsa3072 2019-02-14 [SC] [expires: 2021-02-13]
C001 0EC2 05B3 5A33 10DC 90DE 395F 97FF CCAF D9A2
uid [ unknown] TechOps Team at Ripple <techops+rippled@ripple.com>
sub rsa3072 2019-02-14 [E] [expires: 2021-02-13]
特に、フィンガープリントが一致することを確認してください。（上記の例では、フィンガープリントは2行目の`C001`で始まる部分です。）
5. 使用しているオペレーティングシステムのバージョンに対応する適切なRippleリポジトリを追加します。
$ echo "deb https://repos.ripple.com/repos/rippled-deb bionic stable" | \
sudo tee -a /etc/apt/sources.list.d/ripple.list
上記の例は、**Ubuntu 18.04 Bionic Beaver**に適切です。その他のオペレーティングシステムについては、`bionic`という単語を次のいずれかに置き換えます。
- **Ubuntu 16.04 Xenial Xerus**の場合は`xenial`
- **Debian 9 Stretch**の場合は`stretch`
`rippled`の開発バージョンまたはプレリリースバージョンにアクセスするには、`stable`ではなく次のいずれかを使用します。
- `unstable` - プレインストールビルド（[`release`ブランチ](https://github.com/ripple/rippled/tree/release)）
- `nightly` - 実験/開発ビルド（[`develop`ブランチ](https://github.com/ripple/rippled/tree/develop)）
**警告:** 安定版ではないナイトリービルドはいつの時点でも壊れる可能性があります。これらのビルドを本番環境のサーバーに使用しないでください。
6. Rippleリポジトリを取得します。
$ sudo apt -y update
7. `rippled`ソフトウェアパッケージをインストールします。
$ sudo apt -y install rippled
8. `rippled`サービスのステータスをチェックします。
$ systemctl status rippled.service
`rippled`サービスが自動的に開始します。開始しない場合は、手動で開始できます。
$ sudo systemctl start rippled.service
起動時に自動で起動するようにするには、以下の手順に従います。
$ sudo systemctl enable rippled.service
## 次のステップ
{% include '_snippets/post-rippled-install.md' %}
<!--_ -->
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](the-rippled-server.html)
- [コンセンサスについて](intro-to-consensus.html)
- **チュートリアル:**
- [rippledの構成](configure-rippled.html)
- [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
- [rippled APIの使用開始](get-started-with-the-rippled-api.html)
- **リファレンス:**
- [rippled APIリファレンス](rippled-api.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

106
content/tutorials/manage-the-rippled-server/installation/rippled-1-3-migration-instructions.ja.md Normal file
View File

@@ -0,0 +1,106 @@
# rippled v1.3.xへの移行手順
このドキュメントでは、`rippled` 1.2.4以前のバージョンから`rippled` v1.3以降に移行するプロセスについて説明します。`rippled`のインストールプロセスがバージョン1.3では変更されたため、この移行プロセスは必須です。
このドキュメントでは、サポートされるプラットフォームでアップグレードするための移行手順について説明します。
- [CentOSまたはRed Hat Enterprise Linux（RHEL）](#centosまたはred-hat-enterprise-linuxrhelでの移行)
- [Ubuntu Linux](#ubuntu-linuxでの移行)
その他のプラットフォームについては、ソースからコンパイルするためのアップデート手順を参照してください。（[Ubuntu](build-run-rippled-ubuntu.html)、[macOS](build-run-rippled-macos.html)、または[Windows](https://github.com/ripple/rippled/tree/develop/Builds/VisualStudio2017)）
## CentOSまたはRed Hat Enterprise Linux（RHEL）での移行
Rippleの公式RPMリポジトリとそれを使用するための手順が変更されました。[自動更新](update-rippled-automatically-on-linux.html)を有効にしている場合は、システムで移行が自動的に実行されます。以前のリポジトリから新しいリポジトリに手動で移行するには、以下の手順を実行します。
1. `rippled`サーバーを停止します。
$ sudo systemctl stop rippled.service
2. 以前のRippleリポジトリパッケージを削除します。
$ sudo rpm -e ripple-repo
`rippled-repo`パッケージは、現在**廃止予定**です。このパッケージはバージョン1.3.1に対応するために、最後にもう一度だけ更新されました。今後は、リポジトリに変更があれば、`ripple.repo`ファイルに手動で変更を加える必要があります。
3. Rippleの新しいyumリポジトリを追加します。
$ cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
[ripple-stable]
name=XRP Ledger Packages
baseurl=https://repos.ripple.com/repos/rippled-rpm/stable/
enabled=1
gpgcheck=0
gpgkey=https://repos.ripple.com/repos/rippled-rpm/stable/repodata/repomd.xml.key
repo_gpgcheck=1
REPOFILE
4. 新しい`rippled`パッケージをインストールします。
$ sudo yum install rippled
バージョン1.3.1では、構成ファイル（`rippled.cfg`および`validators.txt`）を変更する必要はありません。このアップデート手順では、既存の構成ファイルが現在のまま残ります。
5. systemdユニットファイルを再度読み込みます。
$ sudo systemctl daemon-reload
6. `rippled`サービスを開始します。
$ sudo systemctl start rippled.service
**警告:** [自動更新](update-rippled-automatically-on-linux.html)を使用している場合、この移行プロセスを実行した後も自動更新が続きます。ただし、**`ripple-repo`パッケージは、現在は廃止予定**です。そのため、今後は、Rippleのリポジトリへの変更があれば、各自がrepoファイルを手動で更新する必要があります。
## Ubuntu Linuxでの移行
バージョン1.3より前では、Ubuntu Linuxに`rippled`をインストールする方法として、Alienを使用してRPMパッケージをインストールする方法がサポートされていました。`rippled`v1.3.1から、RippleはUbuntuおよびDebian Linux向けのネイティブパッケージを提供しており、これが推奨のインストール方法となります。すでにRPMパッケージをインストールしている場合は、[インストール手順](install-rippled-on-ubuntu.html)を実行して、パッケージをアップグレードし、ネイティブAPT（`.deb`）パッケージに切り替えます。
構成ファイル（`/opt/ripple/etc/rippled.cfg`および`/opt/ripple/etc/validators.txt`）に変更を加えている場合は、インストール中に`apt`から、構成ファイルをパッケージからの最新バージョンで上書きするかどうかを尋ねられる場合があります。バージョン1.3では、構成ファイルに変更を加える必要はありません。そのため、既存の構成ファイルはそのまま維持できます。
1.3用のネイティブAPTパッケージをインストールした後で、サービスを再読み込み/再起動する必要があります。
1. systemdユニットファイルを再度読み込みます。
$ sudo systemctl daemon-reload
2. `rippled`サービスを再起動します。
$ sudo systemctl restart rippled.service
他のパッケージ用にAlienを使用する必要がなくなった場合は、必要に応じて、次の手順でAlienとその依存関係をアンインストールできます。
1. Alienをアンインストールします。
$ sudo apt -y remove alien
2. 使用していない依存関係をアンインストールします。
$ sudo apt -y autoremove
### 自動更新
`rippled` v1.3パッケージには、UbuntuおよびDebian Linuxで動作する最新のauto-updateスクリプトが含まれています。詳細は、[Linuxでの`rippled`の自動更新](update-rippled-automatically-on-linux.html)を参照してください。
## 関連項目
- **[`rippled` v1.3.1リリースノート](https://github.com/ripple/rippled/releases/1.3.1)**
- **コンセプト:**
- [`rippled`サーバー](the-rippled-server.html)
- [コンセンサスについて](intro-to-consensus.html)
- **チュートリアル:**
- [Linuxでの自動更新](update-rippled-automatically-on-linux.html)
- [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
- [rippled APIの使用開始](get-started-with-the-rippled-api.html)
- **リファレンス:**
- [rippled APIリファレンス](rippled-api.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

32
content/tutorials/manage-the-rippled-server/installation/system-requirements.ja.md
View File

@@ -5,14 +5,15 @@
ネットワークに参加するための費用を抑えるため、`rippled`サーバーは一般製品のハードウェア上で快適に実行できる必要があります。Rippleでは、現時点で以下の最小要件を推奨します。
- オペレーティングシステム:
- 本番環境: CentOSまたはRedHat Enterprise Linux（最新リリース）、またはUbuntu （16.04以降）をサポート
- 本番環境: CentOSまたはRedHat Enterprise Linux（最新リリース）、Ubuntu（16.04以降）、Debian（9.x）をサポート
- 開発環境: Mac OS X、Windows（64ビット）、またはほとんどのLinuxディストリビューション
- CPU: 64ビットx86_64、2つ以上のコア
- CPU: 64ビット x86_64、2つ以上のコア
- ディスク: データベースパーティション用に最低50GB。SSDを強く推奨（最低でも1000IOPS、それよりも多いことが望ましい）
- RAM: 8GB以上
作業負荷によっては、Amazon EC2の`m3.large` VMサイズが適切な場合があります。高速のネットワーク接続が望ましいです。サーバーのクライアント処理負荷が増加すると、必要なリソースも増加します。
## 推奨される仕様
企業の本番環境で最良のパフォーマンスを実現するため、Rippleでは、以下の仕様のベアメタルで`rippled`を実行することを推奨しています。
@@ -21,10 +22,31 @@
- CPU: Intel Xeon 3以上、GHzプロセッサー、4コア、ハイパースレッディング有効
- ディスク: SSD（7000回以上の書き込み/秒、10,000回以上の読み取り/秒）
- RAM:
- テスト用: 8GB以上
- 本番環境用: 32GB
- テスト用: 8GB以上
- 本番環境用: 32GB
- ネットワーク: ホスト上にギガビットネットワークインターフェイスを備える企業データセンターネットワーク
## システム時刻
`rippled`サーバーは、正確な時刻が維持されていることを前提としています。`ntpd`や`chrony`などのデーモンで、ネットワークタイムプロトコル（NTP）を使用してシステムの時刻を同期することを推奨します。
## 関連項目
実稼働向けの推奨仕様および計画について詳しくは、[容量の計画](capacity-planning.html)を参照してください。
- **コンセプト:**
- [`rippled`サーバー](the-rippled-server.html)
- [コンセンサスについて](intro-to-consensus.html)
- **チュートリアル:**
- [容量の計画](capacity-planning.html) - 本番環境向けの推奨仕様および計画についての詳細情報
- [`rippled`のインストール](install-rippled.html)
- [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [rippled APIリファレンス](rippled-api.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

37
content/tutorials/manage-the-rippled-server/installation/update-rippled-automatically-on-linux.ja.md Normal file
View File

@@ -0,0 +1,37 @@
# Linuxでの自動更新
Linuxでは、`rippled`が1回限りの`cron`構成を使用して最新バージョンに自動的にアップグレードされるように設定できます。可能であれば自動更新を有効にしておくことが推奨されます。
以下の手順では、`rippled`が[`yum`リポジトリから（CentOS/RedHat）](install-rippled-on-centos-rhel-with-yum.html)、または[`apt`（Ubuntu/Debian）を使用して](install-rippled-on-ubuntu.html)インストールされていることを前提としています。
自動更新を設定するには、以下の手順に従います。
1. `/opt/ripple/etc/update-rippled-cron`が存在することを確認します。存在しない場合は、（[CentOS/Red Hat](update-rippled-manually-on-centos-rhel.html)または[Ubuntu/Debian](update-rippled-manually-on-ubuntu.html)を）手動で更新します。
2. `cron.d`フォルダーに、`/opt/ripple/etc/update-rippled-cron`構成ファイルへのsymlinkを作成します。
$ sudo ln -s /opt/ripple/etc/update-rippled-cron /etc/cron.d/
このcron構成は、インストール済みの`rippled`パッケージを新版のリリース後1時間以内に更新するためのスクリプトを実行します。同時に更新を実行しているすべてのサーバーが停止する可能性を抑えるため、このスクリプトはランダムな分数（最大で59）で更新を遅延して行います。
**注意:** 将来的には、Rippleのリポジトリが変更された場合に、更新を検索するスクリプトが実行されるURLの手動更新が必要となることがあります。必要な変更についての最新情報は、[XRP Ledgerブログ](/blog/)または[ripple-serverメーリングリスト](https://groups.google.com/forum/#!forum/ripple-server)でお知らせします。
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](the-rippled-server.html)
- [コンセンサスについて](intro-to-consensus.html)
- **チュートリアル:**
- [容量の計画](capacity-planning.html)
- [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [rippled APIリファレンス](rippled-api.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

41
content/tutorials/manage-the-rippled-server/installation/update-rippled-manually-on-centos-rhel.ja.md Normal file
View File

@@ -0,0 +1,41 @@
# CentOS/Red Hatでの手動更新
このページでは、CentOSまたはRed Hat Enterprise Linuxで最新リリースの`rippled`に手動で更新する手順を説明します。可能であれば手動更新ではなく[自動更新](update-rippled-automatically-on-linux.html)を設定することが推奨されます。
以下の手順は、[`rippled`がすでに`yum`リポジトリからインストール](install-rippled-on-centos-rhel-with-yum.html)されていることを前提としています。
**ヒント:** これらの手順をすべて一度に実行するには、`rippled`パッケージに含まれている`/opt/ripple/bin/update-rippled.sh`スクリプトを実行します。このスクリプトは`sudo`ユーザーとして実行する必要があります。
手動で更新するには、以下の手順を実行します。
1. 最新の`rippled`パッケージをダウンロードしてインストールします。
$ sudo yum update rippled
2. `systemd`ユニットファイルを再度読み込みます。
$ sudo systemctl daemon-reload
3. `rippled`サービスを再起動します。
$ sudo service rippled restart
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](the-rippled-server.html)
- [コンセンサスについて](intro-to-consensus.html)
- **チュートリアル:**
- [`rippled` v1.3.xへの移行手順](rippled-1-3-migration-instructions.html) <!-- Note: remove when versions older than v1.3 are basically extinct -->
- [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [rippled APIリファレンス](rippled-api.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

45
content/tutorials/manage-the-rippled-server/installation/update-rippled-manually-on-ubuntu.ja.md Normal file
View File

@@ -0,0 +1,45 @@
# UbuntuまたはDebianでの手動更新
このページでは、Ubuntu Linuxで最新リリースの`rippled`に手動で更新する手順を説明します。以下の手順は、[`rippled`がすでにネイティブパッケージを使用してインストール](install-rippled-on-ubuntu.html)されていることを前提としています。可能であれば手動更新ではなく[自動更新](update-rippled-automatically-on-linux.html)を設定することが推奨されます。
**注意:** Ubuntu Linuxで`rippled` 1.2.xから1.3.1以降にアップグレードするには、[1.3.1への移行手順](rippled-1-3-migration-instructions.html)に従う必要があります。以下の手順は、バージョン1.3.1以降で提供されているネイティブAPTパッケージがインストール済みであることを前提としています。
**ヒント:** これらの手順をすべて一度に実行するには、`rippled`パッケージに含まれている`/opt/ripple/bin/update-rippled.sh`スクリプトを実行します。`rippled`バージョン1.3.1以降、このスクリプトはUbuntuおよびDebianと互換性があります。このスクリプトは`sudo`ユーザーとして実行する必要があります。
手動で更新するには、以下の手順を実行します。
1. リポジトリを更新します。
$ sudo apt -y update
2. `rippled`パッケージをアップグレードします。
$ sudo apt -y upgrade rippled
3. `systemd`ユニットファイルを再度読み込みます。
$ sudo systemctl daemon-reload
4. `rippled`サービスを再起動します。
$ sudo service rippled restart
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](the-rippled-server.html)
- [コンセンサスについて](intro-to-consensus.html)
- **チュートリアル:**
- [`rippled` v1.3.xへの移行手順](rippled-1-3-migration-instructions.html) <!-- Note: remove when versions older than v1.3 are basically extinct -->
- [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [rippled APIリファレンス](rippled-api.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

34
content/tutorials/manage-the-rippled-server/stand-alone-mode/load-a-saved-ledger-in-stand-alone-mode.ja.md
View File

@@ -1,8 +1,10 @@
# スタンドアロンモードでの保存済みレジャーの読み込み
`rippled`サーバーが以前にXRP Ledgerピアツーピアネットワーク（本番環境ネットワークまたは[Test Net](parallel-networks.html)）と同期されている場合は、ディスクに保存されたレジャーバージョンから開始できます。
以前にディスクに保存していた[履歴レジャーバージョン](ledgers.html)を使用して、`rippled`サーバーを[スタンドアロンモード](rippled-server-modes.html)で起動できます。例えば、以前に`rippled`サーバーをXRP Ledgerのピアツーピアネットワーク（[本番Mainnet、Testnet、Devnetなど](parallel-networks.html)）と同期していた場合は、過去にサーバーで使用できていた任意のレジャーバージョンを読み込むことができます。
## 1.`rippled`を通常の方法で起動します。
履歴レジャーバージョンを読み込むことにより、レジャーを「リプレイ」して、トランザクションがネットワークのルールに従って処理されていたか検証したり、異なる[Amendment](amendments.html)を有効にした場合のトランザクションセットの処理の結果を比較したりすることができます。万が一、[XRP Ledgerのコンセンサスメカニズムに対する攻撃](consensus-protections.html)が発生して共有レジャーの状態に悪影響が及んでも、このプロセスを始めることで、バリデータのコンセンサスを以前の良好だったネットワークの状態に「ロールバック」できる可能性があります。
## 1. `rippled`を通常の方法で起動します。
既存のレジャーを読み込むには、最初にネットワークから当該のレジャーを取得する必要があります。`rippled`をオンラインモードで通常の方法で起動します。
@@ -10,7 +12,7 @@
rippled --conf=/path/to/rippled.cfg
```
## 2.`rippled`が同期されるまで待ちます。
## 2. `rippled`が同期されるまで待ちます。
[server_infoメソッド][]を使用して、ネットワークに対するサーバーの状態を確認します。`server_state`に以下のいずれかの値が示される場合は、サーバーは同期しています。
@@ -20,7 +22,7 @@ rippled --conf=/path/to/rippled.cfg
詳細は、[考えられるサーバーの状態](rippled-server-states.html)を参照してください。
## 3.（省略可）特定のレジャーバージョンを取得します。
## 3. （省略可）特定のレジャーバージョンを取得します。
最新レジャーのみを必要とする場合は、このステップをスキップできます。
@@ -28,7 +30,7 @@ rippled --conf=/path/to/rippled.cfg
特定の履歴レジャーバージョンをリプレイする場合は、リプレイするレジャーバージョンとその直前のレジャーバージョンの両方を取得する必要があります。（前のレジャーバージョンにより、リプレイするレジャーバージョンに記述されている変更を適用する初期状態が設定されます。）
## 4.`rippled`をシャットダウンします。
## 4. `rippled`をシャットダウンします。
[stopメソッド][]を使用します。
@@ -36,7 +38,7 @@ rippled --conf=/path/to/rippled.cfg
rippled stop --conf=/path/to/rippled.cfg
```
## 5.スタンドアロンモードで`rippled`を起動します。
## 5. スタンドアロンモードで`rippled`を起動します。
最新のレジャーバージョンを読み込むには、`-a`オプションと`--load`オプションを指定してサーバーを起動します。
@@ -50,9 +52,9 @@ rippled -a --load --conf=/path/to/rippled.cfg
rippled -a --load --ledger 19860944 --conf=/path/to/rippled.cfg
```
スタンドアロンモードで`rippled`を起動するときに使用できるオプションについての詳細は、[コマンドラインの使用リファレンスの「スタンドアロンモードのオプション」](commandline-usage.html#スタンドアロンモードのオプション)を参照してください。
スタンドアロンモードで`rippled`を起動するときに使用可能なオプションについての詳細は、[コマンドラインの使用: スタンドアロンモードのオプション ](commandline-usage.html#スタンドアロンモードのオプション)を参照してください。
## 6.レジャーを手動で進めます。
## 6. レジャーを手動で進めます。
スタンドアロンモードで`--ledger`を使用してレジャーを読み込むと、読み込まれたレジャーが現行のオープンレジャーになるので、[レジャーを手動で進める](advance-the-ledger-in-stand-alone-mode.html)必要があります。
@@ -60,7 +62,21 @@ rippled -a --load --ledger 19860944 --conf=/path/to/rippled.cfg
rippled ledger_accept --conf=/path/to/rippled.cfg
```
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](the-rippled-server.html)
- [`rippled`サーバーのモード](rippled-server-modes.html)
- [コンセンサスについて](intro-to-consensus.html)
- [Amendment](amendments.html)
- **リファレンス:**
- [ledger_acceptメソッド][]
- [server_infoメソッド][]
- [`rippled`コマンドラインの使用](commandline-usage.html)
- **ユースケース:**
- [`rippled`へのコードの提供](contribute-code-to-rippled.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% include '_snippets/rippled_versions.md' %}

95
content/tutorials/manage-the-rippled-server/troubleshooting/diagnosing-problems.ja.md
View File

@@ -14,29 +14,71 @@
rippled server_info
```
このコマンドに対する応答には大量の情報が含まれています。これについては、[server_infoメソッド][]で説明します。
トラブルシューティングで最も重要なフィールドは以下のとおりです（最も一般的に使われるものから順に説明します）。
このコマンドに対する応答には大量の情報が含まれています。これについては、[server_infoメソッド][]で説明します。トラブルシューティングで最も重要なフィールドは以下のとおりです（最も一般的に使われるものから順に説明します）。
- **`server_state`** - ほとんどの場合、このフィールドには`proposing`（[バリデータとして設定されている](run-rippled-as-a-validator.html)サーバーの場合）または `full`（バリデータではないサーバーの場合）が表示されます。値が`connected`の場合は、サーバーはピアツーピアネットワークの他の部分と通信できますが、共有レジャーの状態を追跡するのに十分なデータがありません。通常、レジャーの残りの部分の状態を同期するには起動後5～15分かかります。
- サーバーが数時間にわたり`connected`状態である場合、または`full`あるいは`proposing`状態になってから`connected`状態に戻る場合は通常、サーバーがネットワークの他の部分よりも遅れています。最も一般的なボトルネックはディスクI/O、ネットワーク帯域幅、RAMです。
- **`server_state`** - ほとんどの場合、このフィールドには`proposing`（[バリデータとして設定されている](run-rippled-as-a-validator.html)サーバーの場合）または`full`（バリデータではないサーバーの場合）が表示されます。値が`connected`の場合は、サーバーはピアツーピアネットワークの他の部分と通信できますが、共有レジャーの状態を追跡するのに十分なデータがありません。通常、レジャーの残りの部分の状態を同期するには起動後約5～15分かかります。
- サーバーが数時間にわたり`connected`状態である場合、または`full`あるいは`proposing`状態になってから`connected`状態に戻る場合は通常、サーバーがネットワークの他の部分よりも遅れています。最も一般的なボトルネックはディスクI/O、ネットワーク帯域幅、RAMです。
- 例えば、以下のサーバー状態情報は、正常なサーバーで同期が3分以内に完了しており（`disconnected`、`connected`、`syncing`の状態に分かれている）、現在は完全に同期された`proposing`状態が約90分間続いていることを示しています。
$ ./rippled server_info
Loading: "/etc/opt/ripple/rippled.cfg"
2020-Jan-03 22:49:32.834134358 HTTPClient:NFO Connecting to 127.0.0.1:5005
{
"result" : {
"info" : {
...（省略）...
"server_state" : "proposing",
"server_state_duration_us" : "5183282365",
"state_accounting" : {
"connected" : {
"duration_us" : "126164786",
"transitions" : 1
},
"disconnected" : {
"duration_us" : "2111321",
"transitions" : 1
},
"full" : {
"duration_us" : "5183282365",
"transitions" : 1
},
"syncing" : {
"duration_us" : "5545604",
"transitions" : 1
},
"tracking" : {
"duration_us" : "0",
"transitions" : 1
}
},
...（省略）...
}
}
}
サーバーが同じ状態間で複数の`transitions`を示している場合、サーバーが同期状態を維持できなかったことを示します。`full`または`proposing`状態でない場合、サーバーはまだネットワークに同期されていません。長期の間には、インターネット接続が不安定になってサーバーの同期が時々失われる場合があります。そのためこれが問題になるのは、同期されていない時間がアップタイムのかなりの部分を占める場合のみです。アップタイムが約24時間経過した後に、`full`または`proposing`状態だった時間がサーバーの合計実行時間の99%に満たない場合、不安定になっている原因を調査することをお勧めします。
- 同期の問題をデバッグする際の参考として、[サーバーが同期しない](server-doesnt-sync.html)を参照してください。
- **`complete_ledgers`** - このフィールドは、サーバーに完全なレジャーデータが保管されている[レジャーインデックス](basic-data-types.html#レジャーインデックス)を示します。通常、正常なサーバーには連続した最新のレジャーのセット（`"12133424-12133858"`など）があります。
- 連続していない完全なレジャーのセット（`"11845721-12133420,12133424-12133858"`など）がある場合、サーバーで断続的な障害が発生したか、またはネットワークの他の部分との同期が一時的にできなかった可能性があります。このようなケースの最も一般的な原因は、ディスクI/Oまたはネットワーク帯域幅の不足です。
- 通常、`rippled`サーバーはピアから最新のレジャー履歴をダウンロードします。レジャー履歴のギャップが数時間以上続く場合は、欠落データを所有しているピアに接続されていない可能性があります。この状況が発生した場合は、構成ファイルに次のスタンザを追加して再起動すれば、完全な履歴が保管されているRippleのパブリックサーバーの1つにサーバーを強制的にピア接続できます。
[ips_fixed]
s2.ripple.com 51235
- 連続していない完全なレジャーのセット（`"11845721-12133420,12133424-12133858"`など）がある場合、サーバーで断続的な障害が発生したか、またはネットワークの他の部分との同期が一時的にできなかった可能性があります。このようなケースの最も一般的な原因は、ディスクI/Oまたはネットワーク帯域幅の不足です。
- 通常、`rippled`サーバーはピアから最新のレジャー履歴をダウンロードします。レジャー履歴のギャップが数時間以上続く場合は、欠落データを所有しているピアに接続されていない可能性があります。この状況が発生した場合は、構成ファイルに次のスタンザを追加して再起動すれば、完全な履歴が保管されているRippleのパブリックサーバーの1つにサーバーを強制的にピア接続できます。
[ips_fixed]
s2.ripple.com 51235
- **`amendment_blocked`** - このフィールドは通常`server_info`応答では省略されます。このフィールドの値が`true`の場合は、ネットワークにより承認された[Amendment](amendments.html)がサーバーに導入されていません。ほとんどの場合は、最新バージョンに[rippledを更新する](install-rippled.html)ことで修正できます。また[featureメソッド][]を使用して、現在有効なAmendment ID、サーバーでサポートされているAmendment ID、サーバーでサポートされていないAmendment IDを確認することもできます。
- **`peers`** - このフィールドは、サーバーが接続しているXRP Ledgerピアツーピアネットワーク内のその他のサーバーの数を示します。特定のピアのみに接続するように明示的に構成されているサーバーを除き、正常なサーバーでは通常5～50ピアと表示されます。
- ピアの数が0の場合、サーバーがネットワークに接続できないか、またはシステムクロックが正しくない可能性があります。（サーバーのクロックを同期するため、すべてのサーバーで[NTP](http://www.ntp.org/)デーモンを実行することが推奨されます。）
- ピアの数が10の場合、`rippled`が[NAT](https://en.wikipedia.org/wiki/Network_address_translation)を使用したルーター経由での着信接続を受信できていない可能性があります。接続を改善するには、ルーターのファイアウォールがピアツーピア接続に使用するポート（[デフォルトでは](https://github.com/ripple/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/cfg/rippled-example.cfg#L1065)ポート51235）を転送するように設定します。
- ピアの数が0の場合、サーバーがネットワークに接続できないか、またはシステムクロックが正しくない可能性があります。（サーバーのクロックを同期するため、すべてのサーバーで[NTP](http://www.ntp.org/)デーモンを実行することが推奨されます。）
- ピアの数が10の場合、`rippled`が[NAT](https://en.wikipedia.org/wiki/Network_address_translation)を使用したルーター経由での着信接続を受信できていない可能性があります。接続を改善するには、ルーターのファイアウォールがピアツーピア接続に使用するポート（[デフォルトでは](https://github.com/ripple/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/cfg/rippled-example.cfg#L1065)ポート51235）を転送するように設定します。
### サーバーから応答がない場合
@@ -44,10 +86,10 @@ rippled server_info
```json
{
"error" : "internal",
"error_code" : 71,
"error_message" : "Internal error.",
"error_what" : "no response from server"
"error" : "internal",
"error_code" : 71,
"error_message" : "Internal error.",
"error_what" : "no response from server"
}
```
@@ -57,7 +99,6 @@ rippled server_info
- サーバーに接続するために異なる[パラメーターを`rippled`コマンドラインクライアントに](commandline-usage.html#クライアントモードのオプション)渡す必要があります。
- `rippled`サーバーがJSON-RPC接続を受け入れるように構成されていない可能性があります。
## サーバーログの確認
[デフォルトでは](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg#L1139-L1142)`rippled`はサーバーのデバッグログを`/var/log/rippled/debug.log`ファイルに書き込みます。このデバッグログの位置は、サーバーの構成ファイルにより異なる可能性があります。`rippled`サービスを（`systemctl`または`service`を使用して開始するのではなく）直接開始した場合、デフォルトではログメッセージはコンソールにも出力されます。
@@ -68,7 +109,19 @@ rippled server_info
さまざまな種類のログメッセージに関する詳しい説明については、[ログメッセージについて](understanding-log-messages.html)を参照してください。
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](the-rippled-server.html)
- [Amendment](amendments.html)
- **チュートリアル:**
- [容量の計画](capacity-planning.html)
- [rippledの構成](configure-rippled.html)
- **リファレンス:**
- [rippled APIリファレンス](rippled-api.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [log_levelメソッド][]
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

109
content/tutorials/manage-the-rippled-server/troubleshooting/server-doesnt-sync.ja.md Normal file
View File

@@ -0,0 +1,109 @@
# rippledサーバーが同期しない
このページでは、[`rippled`サーバー](the-rippled-server.html)が正常に起動したのに、ネットワークに完全に接続できずに[「connected」状態](rippled-server-states.html)のままになっている場合の原因について説明します。（サーバーが起動中または起動直後にクラッシュした場合は、[サーバーが起動しない](server-wont-start.html)を参照してください。）
以下の手順では、サポートされているプラットフォームに[`rippled`がインストール](install-rippled.html)されていることを前提としています。
## 通常の同期動作
ネットワークとの同期は、通常はおよそ5分から15分で完了します。その間に、サーバーは次のようなさまざまなことを行います。
- 推奨バリデータリストを読み込み（通常は`vl.ripple.com`から）、信頼できるバリデータを判断します。
- [ピアサーバーを検出](peer-protocol.html#ピア発見)して接続します。
- ピアから最新のレジャーの[ヘッダー](ledger-header.html)と完全な[状態情報](ledgers.html#ツリーの形式)をダウンロードし、それを使用してレジャーデータの内部データベースを構築します。
- 信頼できるバリデータをリッスンして、最近検証されたレジャーハッシュを見つけます。
- 新たにブロードキャストされたトランザクションを収集し、それを進行中のレジャーに適用します。
サーバーがこれらのタスクを行うときにネットワークに同調して対応できなかった場合は、サーバーはネットワークと同期しない状態になります。
## 最初のステップ: 再起動
多くの同期の問題は、サーバーを再起動することで解決できます。最初に同期が失敗した原因がどのようなものであっても、2回目では成功する場合があります。
[server_infoメソッド][]で[`server_state`](rippled-server-states.html)が`proposing`または`full`以外の状態であると示され、`server_state_duration_us`が`900000000`（15分のマイクロ秒表記）より大きい場合は、`rippled`サービスをシャットダウンしてから数秒間待ち、再起動してください。場合によっては、マシン全体を再起動します。
問題が解決しない場合は、このページに記載されている他の原因を確認してください。いずれも当てはまらないと思われる場合は、[`rippled`リポジトリに問題を登録](https://github.com/ripple/rippled/issues)し、「Syncing issue」ラベルを追加します。
## 同期の問題のよくある原因
同期の問題の原因として最もよくあるのは、[システム要件](system-requirements.html)を満たしていないことです。要件を満たせない主な原因は次の3つです。
- **低速なディスク。** 安定して高速な性能を発揮するソリッドステートディスク（SSD）が必要です。AWSなどのクラウドプロバイダーはディスク性能を保証しておらず、ハードウェアを共有する他のユーザーの影響を受ける可能性があります。
- **不十分なRAM。** メモリー要件はさまざまな要因に大きく左右されます。例えば、ネットワークの負荷やXRP Ledgerがどのように使われるかなど、予測しづらい要因もあるため、念のため最小システム要件よりも大きいメモリーを用意することをお勧めします。
- **品質の悪いネットワーク接続。** ネットワーク要件は、主にXRP Ledgerをユーザーがどのよう使うかによって左右されますが、接続が低速または不安定な場合、XRP Ledgerに追加された新しいトランザクションやデータとの同期がとれなくなる可能性があります。
同期の問題が解消されない場合は、サーバーがシステム要件を満たしているかもう一度確認してください。サーバーの使用方法によっては、「最小」要件よりも高い「推奨」要件を満たす必要があります。「推奨」要件を満たしていても、まだ同期ができない場合は、このページの他の原因を試してみてください。
## バリデータリストを読み込めない
デフォルトの構成では、`vl.ripple.com`から受信した推奨バリデータリストを使用します。このリストは、Rippleの暗号鍵ペアで署名されており、有効期限が組み込まれています。サーバーが何らかの理由でリストを`vl.ripple.com`からダウンロードできない場合、サーバーは信頼できるバリデータのセットを選択せず、有効として宣言できるレジャーを決定できません。（[Testnetや別の並列ネットワーク](parallel-networks.html)に接続している場合、サーバーは代わりにそのネットワークの信頼できるバリデータのリストを使用します。）
[server_infoメソッド][]応答の`validator_list`ブロックは、バリデータリストの有効期限などのステータスを示します。リストがあるが期限切れである場合、サーバーは以前はそのバリデータリストのサイトに接続できていたものの、その後接続できなくなった可能性があります。その場合、現在のリストはサーバーがそれより新しいリストをダウンロードできなかったために期限切れとなった可能性があります。
また、[validator_list_sitesメソッド][]を使用して、より詳細な情報を取得することもできます。応答内のバリデータサイトオブジェクトに`last_refresh_status`および`last_refresh_time`フィールドがない場合、サーバーからバリデータリストのサイトへの接続に問題があることを示しています。ファイアウォールの設定をチェックして、ポート80（HTTP）または443（HTTPS）の発信トラフィックをブロックしていないことを確認してください。また、DNSがバリデータリストのサイトのドメインを解決できることも確認してください。
<!-- TODO: create a tutorial for how to sideload a validator list from file and link it here -->
## 十分な数のピアがない
サーバーが十分な数の[ピアサーバー](peer-protocol.html)に接続していない場合、サーバーは十分なデータをダウンロードできず、ネットワークが新しいトランザクションを処理するときに同期がとれなくなる可能性があります。この問題は、ネットワーク接続の信頼性が低い場合や、十分な数の信頼できる固定ピアを追加せずにサーバーを[プライベートサーバー](peer-protocol.html#プライベートピア)として構成している場合に起こる可能性があります。
[peersメソッド][]を使用して、サーバーの現在のピアについての情報を取得します。ピアの数が10または11の場合、ファイアウォールが着信ピア接続をブロックしていることを示しています。[ポートフォワーディングを設定](forward-ports-for-peering.html)して、より多くの着信接続を許可します。サーバーがプライベートサーバーとして構成されている場合は、構成ファイルの`[ips_fixed]`スタンザの内容と構文を再度確認し、可能であればプロキシと公開ハブをさらに追加します。
## データベースの破損
まれに、`rippled`サーバーの内部データベースに保存されているデータが破損していることで同期の問題が発生する場合があります。サーバーが稼動中でなければ、ほとんどの場合、サーバーのデータベースを安全に削除できます。データの破損は、ディスクにコピーまたは書き込みするときに起こった一時的なハードウェア障害や、より深刻なディスク障害、別のプロセスがクラッシュしてディスクの誤った部分に書き込んだなど、さまざまな問題の結果として起こる可能性があります。
テストとして、十分な空き容量があれば、サーバーのデータベースへのパスを一時的に変更することで、現行のレジャーをダウンロードし直して、別の設定を保存できます。
**注記:** データベースのパスを変更した場合、サーバーはサーバーの現在の[ノードキーペア][]や[ピアリザベーション](peer-protocol.html#固定ピアとピアリザベーション)など、保存されている一部の設定を読み込めません。データベースのパスを変更することでサーバーの同期の問題が解決した場合は、これらの設定の一部を再作成することをお勧めします。
1. `rippled`サーバーが稼働中の場合は停止します。
$ sudo systemctl stop rippled
2. 新しいデータベースを格納するための新しい空のフォルダーを作成します。
$ mkdir /var/lib/rippled/db_new/
$ mkdir /var/lib/rippled/db_new/nudb
3. 新しいパスを使用するように構成ファイルを編集します。`[node_db]`スタンザの`path`フィールド**と**`[database_path]`スタンザの値を変更します。
[node_db]
type=NuDB
path=/var/lib/rippled/db_new/nudb
[database_path]
/var/lib/rippled/db_new
{% include '_snippets/conf-file-location.md' %}<!--_ -->
4. `rippled`サーバーを再起動します。
$ sudo systemctl start rippled
新しいデータベースを使用してサーバーが同期に成功したら、以前のデータベースを格納していたフォルダーを削除できます。また、ハードウェア障害、特にディスクとRAMの障害を確認することもお勧めします。
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](the-rippled-server.html)
- [ピアプロトコル](peer-protocol.html)
- [技術に関するよくある質問](technical-faq.html)
- **チュートリアル:**
- [ログメッセージについて](understanding-log-messages.html)
- [容量の計画](capacity-planning.html)
- **リファレンス:**
- [rippled APIリファレンス](rippled-api.html)
- [peersメソッド][]
- [server_infoメソッド][]
- [validator_list_sitesメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

89
content/tutorials/manage-the-rippled-server/troubleshooting/server-wont-start.ja.md
View File

@@ -1,46 +1,45 @@
# rippledサーバーが起動しない
このページでは、`rippled`サーバーが起動しない際に考えられる原因とその修正方法を説明します。
このページでは、[`rippled`サーバー](the-rippled-server.html)が起動しない際に考えられる原因とその修正方法を説明します。
以下の手順では、サポートされているプラットフォームに[`rippled`がインストール](install-rippled.html)されていることを前提としています。
## ファイル記述子の制限
一部のLinuxバリアントでは、`rippled`を実行しようとすると以下のようなエラーメッセージが出力されることがあります。
```テキスト
```text
WARNING: There are only 1024 file descriptors (soft limit) available, which
limit the number of simultaneous connections.
```
これは、セキュリティの点からシステムで1つのプロセスが開くことができるファイルの数に制限があるが、その制限が`rippled`にとっては少なすぎる場合に発生します。この問題を修正するには、**ルートアクセス権限が必要です**。以下の手順に従い、`rippled`が開くことができるファイルの数を増やします。
1. 次の行を`/etc/security/limits.conf` ファイルの終わりに追加します。
1. 次の行を`/etc/security/limits.conf`ファイルの終わりに追加します。
* soft nofile 65536
* hard nofile 65536
2. [開くことができるファイルの数のハード制限](https://ss64.com/bash/ulimit.html)が現在`65536`であることを確認します。
ulimit -Hn
このコマンドの出力は`65536`になるはずです。
このコマンドの出力は`65536`になるはずです。
3. `rippled`をもう一度起動します。
systemctl start rippled
4. それでも`rippled`が起動しない場合は、`/etc/sysctl.conf`を開き、以下のカーネルレベル設定を付加します。
fs.file-max = 65536
## /etc/opt/ripple/rippled.cfgを開くことができない
`rippled` が起動時にクラッシュし、以下のようなエラーが出力される場合は、`rippled`が構成ファイルを読み取ることができません。
`rippled`が起動時にクラッシュし、以下のようなエラーが出力される場合は、`rippled`が構成ファイルを読み取ることができません。
```テキスト
```text
Loading: "/etc/opt/ripple/rippled.cfg"
Failed to open '"/etc/opt/ripple/rippled.cfg"'.
Terminating thread rippled: main: unhandled St13runtime_error 'Can not create "/var/opt/ripple"'
@@ -52,16 +51,16 @@ Aborted (core dumped)
- 構成ファイル（デフォルトのロケーションは`/etc/opt/ripple/rippled.cfg`）が存在しており、`rippled`プロセスを実行するユーザー（通常は`rippled`）にこのファイルの読み取り権限があることを確認します。
- `rippled`ユーザーが読み取ることができる構成ファイルを`$HOME/.config/ripple/rippled.cfg`に作成します（`$HOME`は`rippled`ユーザーのホームディレクトリを指しています）。
**ヒント:** `rippled`リポジトリには、RPMのインストール時にデフォルトの構成として提供される[`rippled.cfg`サンプルファイル](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg)が含まれています。このファイルがない場合は、上記のリンク先からコピーできます。
**ヒント:**`rippled`リポジトリには、RPMのインストール時にデフォルトの構成として提供される[`rippled.cfg`サンプルファイル](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg)が含まれています。このファイルがない場合は、上記のリンク先からコピーできます。
- `--conf` [コマンドラインオプション](commandline-usage.html)を使用して、使用する構成ファイルのパスを指定します。
- `--conf`[コマンドラインオプション](commandline-usage.html)を使用して、使用する構成ファイルのパスを指定します。
## バリデータファイルを開くことができない
`rippled`が起動時にクラッシュし、以下のようなエラーが出力される場合は、`rippled`はプライマリ構成ファイルを読み取ることはできても、この構成ファイルに指定されている別のバリデータ構成ファイル（通常は`validators.txt`）を読み取ることができません。
```テキスト
```text
Loading: "/home/rippled/.config/ripple/rippled.cfg"
Terminating thread rippled: main: unhandled St13runtime_error 'The file specified in [validators_file] does not exist: /home/rippled/.config/ripple/validators.txt'
Aborted (core dumped)
@@ -70,19 +69,19 @@ Aborted (core dumped)
考えられる解決策:
- `[validators.txt]`ファイルが存在し、`rippled`ユーザーにこのファイルの読み取り権限があることを確認します。
**ヒント:**`rippled`リポジトリには、RPMのインストール時にデフォルトの構成として提供される[`validators.txt`サンプルファイル](https://github.com/ripple/rippled/blob/master/cfg/validators-example.txt)が含まれています。このファイルがない場合は、上記のリンク先からコピーできます。
**ヒント:** `rippled`リポジトリには、RPMのインストール時にデフォルトの構成として提供される[`validators.txt`サンプルファイル](https://github.com/ripple/rippled/blob/master/cfg/validators-example.txt)が含まれています。このファイルがない場合は、上記のリンク先からコピーできます。
- `rippled.cfg`ファイルを編集し、`[validators_file]`設定を変更して、`validators.txt`ファイル（またはこれに相当するファイル）の正しいパスを指定します。ファイル名の前後に余分な空白があるかどうかを確認します。
- `rippled.cfg`ファイルを編集し、`[validators_file]`設定を削除します。バリデータ設定を`rippled.cfg`ファイルに直接追加します。例:
[validator_list_sites]
https://vl.ripple.com
[validator_list_keys]
ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
## データベースパスを作成できない
@@ -111,8 +110,8 @@ Aborted (core dumped)
```text
2018-Aug-21 23:06:38.675117810 SHAMapStore:ERR state db error:
writableDbExists false archiveDbExists false
writableDb '/var/lib/rippled/db/rocksdb/rippledb.11a9' archiveDb '/var/lib/rippled/db/rocksdb/rippledb.2d73'
writableDbExists false archiveDbExists false
writableDb '/var/lib/rippled/db/rocksdb/rippledb.11a9' archiveDb '/var/lib/rippled/db/rocksdb/rippledb.2d73'
To resume operation, make backups of and remove the files matching /var/lib/rippled/db/state* and contents of the directory /var/lib/rippled/db/rocksdb
@@ -149,7 +148,7 @@ path=/var/lib/rippled/custom_nudb_path
以下のようなエラーメッセージが出力される場合、`rippled.cfg`ファイルの`[ledger_history]`と`online_delete`に矛盾する値が指定されています。
```テキスト
```text
Terminating thread rippled: main: unhandled St13runtime_error 'online_delete must not be less than ledger_history (currently 3000)
```
@@ -162,7 +161,7 @@ Terminating thread rippled: main: unhandled St13runtime_error 'online_delete mus
以下のようなエラーが出力される場合は、`rippled.cfg`ファイルの`node_size`設定の値が誤っています。
```テキスト
```text
Terminating thread rippled: main: unhandled N5beast14BadLexicalCastE 'std::bad_cast'
```
@@ -173,23 +172,43 @@ Terminating thread rippled: main: unhandled N5beast14BadLexicalCastE 'std::bad_c
以下のようなエラーが出力される場合は、`rippled.cfg`の[履歴シャーディング](history-sharding.html)の設定が不完全です。
```テキスト
```text
Terminating thread rippled: main: unhandled St13runtime_error 'shard path missing'
```
設定に`[shard_db]`スタンザが含まれている場合、このスタンザには`path`フィールドが指定されている必要があります。このフィールドは、`rippled`がシャードストアーのデータを書き込むことができるディレクトリを指しています。このエラーが発生する場合は、`path`フィールドが欠落しているか、誤った位置に指定されています。構成ファイルで余分な空白やスペルミスがないかどうかを確認し、[シャード設定の例](configure-history-sharding.html#2-rippledcfgの編集)と比較してください。
## サポート対象外のシャードストアータイプ: RocksDB
## ShardStoreがRocksDBを開くかまたは作成することができない
RocksDBは、[履歴シャーディング](history-sharding.html)のバックエンドとしてサポートされなくなりました。RocksDBシャードストアーを定義している既存の構成がある場合は、サーバーが起動に失敗します。[新規: rippled 1.3.1][]
[履歴シャーディング](history-sharding.html)を有効にし、その後設定を変更してNuDBではなくRocksDBを使用するように設定した場合、サーバーは既存のNuDBデータをRocksDBデータとして読み取ろうとし、起動に失敗します。この場合、サーバーは以下のようなエラーを書き込みます。
この場合、log startupコマンドの直後にプロセスが終了し、出力ログの早い段階で次のようなメッセージが表示されます。
```テキスト
ShardStore:ERR shard 504 error: Unable to open/create RocksDB: Invalid argument: /var/lib/rippled/db/shards/504: does not exist (create_if_missing is false)
```text
ShardStore:ERR Unsupported shard store type: RocksDB
```
この問題を修正するには、以下のいずれかを行います。
- 設定されているフォルダーから既存のシャードデータを移動する。
- ディスク上のシャードストアーの位置を変更するため、`rippled.cfg`ファイルの`[shard_db]`スタンザの`path`を変更する。
- NuDBを使用するようにシャードストアーを変更する。
この問題を修正するには、以下のいずれかを行ってからサーバーを再起動します。
- 代わりにNuDBを使用するようにシャードストアーを変更します。
- 履歴シャーディングを無効にします。
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](the-rippled-server.html)
- [技術に関するよくある質問](technical-faq.html)
- **チュートリアル:**
- [ログメッセージについて](understanding-log-messages.html)
- [容量の計画](capacity-planning.html)
- **リファレンス:**
- [rippled APIリファレンス](rippled-api.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

197
content/tutorials/manage-the-rippled-server/troubleshooting/understanding-log-messages.ja.md
View File

@@ -1,6 +1,6 @@
# ログメッセージについて
以下のセクションでは、`rippled`サーバーのデバッグログに出力される最も一般的なログメッセージタイプとその解釈を説明します。
以下のセクションでは、[`rippled`サーバー](the-rippled-server.html)のデバッグログに出力される最も一般的なログメッセージタイプとその解釈を説明します。
これは、`rippled`の[問題を診断する](diagnosing-problems.html)上で重要なステップです。
@@ -27,11 +27,26 @@ Terminating thread rippled: main: unhandled St13runtime_error
上記のいずれにも該当しない場合は、その問題をセキュリティ上重要なバグとしてRippleに報告してください。Rippleでクラッシュを再現できる場合は、報奨を受領できる可能性があります。詳細は<https://ripple.com/bug-bounty/>を参照してください。
## Already validated sequence at or past
以下のようなログメッセージが出力される場合は、サーバーが異なるレジャーインデックスの検証を順不同で受信しています。
```text
2018-Aug-28 22:55:58.316094260 Validations:WRN Val for 2137ACEFC0D137EFA1D84C2524A39032802E4B74F93C130A289CD87C9C565011 trusted/full from nHUeUNSn3zce2xQZWNghQvd9WRH6FWEnCBKYVJu2vAizMxnXegfJ signing key n9KcRZYHLU9rhGVwB9e4wEMYsxXvUfgFxtmX25pc1QPNgweqzQf5 already validated sequence at or past 12133663 src=1
```
この種類のメッセージが時折発生しても通常は問題ありません。この種類のメッセージが同じ送信バリデータで頻繁に発生する場合は、以下のような問題がある可能性があります（可能性の高いものから順に示しています）。
- メッセージを書き込むサーバーにネットワークの問題がある。
- メッセージに表示されているバリデータにネットワークの問題がある。
- メッセージに表示されているバリデータが悪意のある振る舞いをしている。
## Connection reset by peer
以下のメッセージは、ピア`rippled`サーバーによって接続が閉じられたことを示します。
```テキスト
```text
2018-Aug-28 22:55:41.738765510 Peer:WRN [012] onReadMessage: Connection reset by peer
```
@@ -43,28 +58,44 @@ Terminating thread rippled: main: unhandled St13runtime_error
- サーバーからの要求でピアに過剰な負担がかかり、ピアがサーバーをドロップした。
## No hash for fetch pack
## InboundLedger 11 timeouts for ledger
以下のようなメッセージは、[履歴シャーディング](history-sharding.html)のために履歴レジャーをダウンロードする際に、`rippled` v1.1.0以前のバグが原因で発生します。
```テキスト
2018-Aug-28 22:56:21.397076850 LedgerMaster:ERR No hash for fetch pack.Missing Index 7159808
```text
InboundLedger:WRN 11 timeouts for ledger 8265938
```
これらは安全に無視できます。
これは、サーバーがそのピアに対して特定のレジャーデータを要求する際に問題が発生していることを示しています。[レジャーインデックス](basic-data-types.html#レジャーインデックス)が、[server_infoメソッド][]により報告される最新の検証済みレジャーのインデックスよりもかなり小さい場合は、サーバーが[履歴シャード](history-sharding.html)のダウンロード中である可能性があります。
これは厳密には問題ではありませんが、レジャー履歴を迅速に取得したい場合は、`[ips_fixed]`構成スタンザを追加または編集してからサーバーを再起動することで、すべての履歴が記録されたピアに接続するように`rippled`を構成できます。たとえば、すべての履歴が記録されたRippleのサーバーに常に接続するには、以下のようにします。
```
[ips_fixed]
s2.ripple.com 51235
```
## InboundLedger Want hash
以下のようなログメッセージは、サーバーが他のサーバーにレジャーデータを要求していることを示しています。
```text
InboundLedger:WRN Want: 5AE53B5E39E6388DBACD0959E5F5A0FCAF0E0DCBA45D9AB15120E8CDD21E019B
```
これは、サーバーの同期中、埋め戻し中、[履歴シャード](history-sharding.html)のダウンロード中は正常です。
## LoadMonitor:WRN Job
以下のようなメッセージは、機能の実行に時間がかかっている場合（この例では11秒以上）に出力されます。
```テキスト
```text
2018-Aug-28 22:56:36.180827973 LoadMonitor:WRN Job: gotFetchPack run: 11566ms wait: 0ms
```
以下のようなメッセージは、ジョブの実行待機に時間がかかっている場合（この例でも11秒以上）に出力されます。
```テキスト
```text
2018-Aug-28 22:56:36.180970431 LoadMonitor:WRN Job: processLedgerData run: 0ms wait: 11566ms
2018-Aug-28 22:56:36.181053831 LoadMonitor:WRN Job: AcquisitionDone run: 0ms wait: 11566ms
2018-Aug-28 22:56:36.181110594 LoadMonitor:WRN Job: processLedgerData run: 0ms wait: 11566ms
@@ -89,89 +120,107 @@ type=RocksDB
```
## View of consensus changed during open
## No hash for fetch pack
以下のようなログメッセージが出力される場合は、サーバーがネットワークの他の部分と同期していません。
以下のようなメッセージは、[履歴シャーディング](history-sharding.html)のために履歴レジャーをダウンロードする際に、`rippled` v1.1.0以前のバグが原因で発生します。
```テキスト
2018-Aug-28 22:56:22.368460130 LedgerConsensus:WRN View of consensus changed during open status=open, mode=proposing
2018-Aug-28 22:56:22.368468202 LedgerConsensus:WRN 96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661 to 00B1E512EF558F2FD9A0A6C263B3D922297F26A55AEB56A009341A22895B516E
2018-Aug-28 22:56:22.368499966 LedgerConsensus:WRN {"accepted":true,"account_hash":"89A821400087101F1BF2D2B912C6A9F2788CC715590E8FA5710F2D10BF5E3C03","close_flags":0,"close_time":588812130,"close_time_human":"2018-Aug-28 22:55:30.000000000","close_time_resolution":30,"closed":true,"hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_index":"3","parent_close_time":588812070,"parent_hash":"5F5CB224644F080BC8E1CC10E126D62E9D7F9BE1C64AD0565881E99E3F64688A","seqNum":"3","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
```text
2018-Aug-28 22:56:21.397076850 LedgerMaster:ERR No hash for fetch pack. Missing Index 7159808
```
サーバー起動後の最初の5～15分間に、サーバーがネットワークの他の部分と同期せず、このようなメッセージが出力されることは特に異常な動作ではありません。サーバー起動後かなり経過してからこれらのメッセージが書き込まれる場合は、問題が発生している可能性があります。一般的な原因としては、信頼性の低いネットワーク接続や不十分なハードウェアスペックなどが考えられます。また、同じハードウェアで実行されている他のプロセスがリソースをめぐって`rippled`と競合している場合にも発生する可能性があります。（`rippled`とリソースをめぐって競合する可能性のある他のプロセスの例としては、スケジュール済みバックアップ、ウィルススキャナー、定期的なデータベースクリーナーなどがあります。）
## Already validated sequence at or past
以下のようなログメッセージが出力される場合は、サーバーが異なるレジャーシーケンスの検証を順不同で受信しています。
```テキスト
2018-Aug-28 22:55:58.316094260 Validations:WRN Val for 2137ACEFC0D137EFA1D84C2524A39032802E4B74F93C130A289CD87C9C565011 trusted/full from nHUeUNSn3zce2xQZWNghQvd9WRH6FWEnCBKYVJu2vAizMxnXegfJ signing key n9KcRZYHLU9rhGVwB9e4wEMYsxXvUfgFxtmX25pc1QPNgweqzQf5 already validated sequence at or past 12133663 src=1
```
この種類のメッセージが時折発生しても通常は問題ありません。この種類のメッセージが同じ送信バリデータで頻繁に発生する場合は、以下のような問題がある可能性があります（可能性の高いものから順に示しています）。
- メッセージを書き込むサーバーにネットワークの問題がある。
- メッセージに表示されているバリデータにネットワークの問題がある。
- メッセージに表示されているバリデータが悪意のある振る舞いをしている。
## Unable to determine hash of ancestor
以下のようなログメッセージは、サーバーがピアからの検証メッセージを認識するけれども、サーバーが基盤としている親レジャーバージョンを認識しない場合に発生します。これは、サーバーがネットワークと同期している場合には正常です。
```テキスト
2018-Aug-28 22:56:22.256065549 Validations:WRN Unable to determine hash of ancestor seq=3 from ledger hash=00B1E512EF558F2FD9A0A6C263B3D922297F26A55AEB56A009341A22895B516E seq=12133675
```
サーバー起動後の5～15分以外の時点でこのメッセージが頻繁に発生する場合は、問題が発生している可能性があります。
## InboundLedger Want hash
以下のようなログメッセージは、サーバーが他のサーバーにレジャーデータを要求していることを示しています。
```テキスト
InboundLedger:WRN Want: 5AE53B5E39E6388DBACD0959E5F5A0FCAF0E0DCBA45D9AB15120E8CDD21E019B
```
これは、サーバーの同期中、埋め戻し中、[履歴シャード](history-sharding.html)のダウンロード中は正常です。
## InboundLedger 11 timeouts for ledger
```テキスト
InboundLedger:WRN 11 timeouts for ledger 8265938
```
これは、サーバーがそのピアに対して特定のレジャーデータを要求する際に問題が発生していることを示しています。[レジャーインデックス](basic-data-types.html#レジャーインデックス)が、[server_infoメソッド][]により報告される最新の検証済みレジャーのインデックスよりもかなり小さい場合は、サーバーが[履歴シャード](history-sharding.html)のダウンロード中である可能性があります。
これは厳密には問題ではありませんが、レジャー履歴を迅速に取得したい場合は、`[ips_fixed]`構成スタンザを追加または編集してからサーバーを再起動することで、すべての履歴が記録されたピアに接続するように`rippled`を構成できます。たとえば、すべての履歴が記録されたRippleのサーバーに常に接続するには、以下のようにします。
```
[ips_fixed]
s2.ripple.com 51235
```
これらは安全に無視できます。
## Potential Censorship
XRP Ledgerが取引検閲の可能性を検出すると、以下のようなログメッセージが出力されます。ログメッセージと取引検閲検出機能の詳細については、[取引検閲の検知](transaction-censorship-detection.html)を参照してください。
XRP Ledgerが取引検閲の可能性を検出すると、以下のようなログメッセージが出力されます。ログメッセージと取引検閲検出機能の詳細は、[取引検閲の検知](transaction-censorship-detection.html)を参照してください。
**警告メッセージ**
```テキスト
```text
LedgerConsensus:WRN Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851545.
```
**エラーメッセージ**
```テキスト
LedgerConsensus:ERR Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851605.Additional warnings suppressed.
```text
LedgerConsensus:ERR Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851605. Additional warnings suppressed.
```
## シャード: No such file or directory
`rippled` 1.3.1のバグが原因で、[履歴シャーディング](history-sharding.html)を有効にしたときに次のようなログメッセージが書き込まれることがあります。
```text
ShardStore:ERR shard 1804: No such file or directory
ShardStore:ERR shard 354: No such file or directory
ShardStore:ERR shard 408: No such file or directory
ShardStore:ERR shard 2927: No such file or directory
ShardStore:ERR shard 2731: No such file or directory
ShardStore:ERR shard 2236: No such file or directory
```
これは、サーバーが新しい履歴シャードの取得を開始しようとしたものの、シャードを格納するための新しいディレクトリーを作成できなかったことを示します。このバグにより、rippled 1.3.1は新しいシャードを取得できません。[修正は近日リリース予定](https://github.com/ripple/rippled/pull/3014)です。
このエラーは、上記のバグのほかに、`rippled`が**起動後**に基となるファイルシステムに書き込めなくなった場合にも起こります。考えられる原因は次のとおりです。
- ストレージメディアのハードウェア障害
- ファイルシステムがアンマウントされた
- シャードフォルダーが削除された
**ヒント:** 一般的に、サービスが停止している場合は、`rippled`のデータベースファイルを削除しても安全ですが、サーバーの稼働中には決してデータベースファイルを削除しないでください。
## Unable to determine hash of ancestor
以下のようなログメッセージは、サーバーがピアからの検証メッセージを認識するけれども、サーバーが基盤としている親レジャーバージョンを認識しない場合に発生します。これは、サーバーがネットワークの他の部分と同期していない場合に発生することがあります。
```text
2018-Aug-28 22:56:22.256065549 Validations:WRN Unable to determine hash of ancestor seq=3 from ledger hash=00B1E512EF558F2FD9A0A6C263B3D922297F26A55AEB56A009341A22895B516E seq=12133675
```
{% include '_snippets/unsynced_warning_logs.md' %}
<!--_ -->
## View of consensus changed during open
以下のようなログメッセージが出力される場合は、サーバーがネットワークの他の部分と同期していません。
```text
2018-Aug-28 22:56:22.368460130 LedgerConsensus:WRN View of consensus changed during open status=open, mode=proposing
2018-Aug-28 22:56:22.368468202 LedgerConsensus:WRN 96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661 to 00B1E512EF558F2FD9A0A6C263B3D922297F26A55AEB56A009341A22895B516E
2018-Aug-28 22:56:22.368499966 LedgerConsensus:WRN {"accepted":true,"account_hash":"89A821400087101F1BF2D2B912C6A9F2788CC715590E8FA5710F2D10BF5E3C03","close_flags":0,"close_time":588812130,"close_time_human":"2018-Aug-28 22:55:30.000000000","close_time_resolution":30,"closed":true,"hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_index":"3","parent_close_time":588812070,"parent_hash":"5F5CB224644F080BC8E1CC10E126D62E9D7F9BE1C64AD0565881E99E3F64688A","seqNum":"3","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
```
{% include '_snippets/unsynced_warning_logs.md' %}
<!--_ -->
## We are not running on the consensus ledger
```text
NetworkOPs:WRN We are not running on the consensus ledger
```
{% include '_snippets/unsynced_warning_logs.md' %}
<!--_ -->
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](the-rippled-server.html)
- [技術に関するよくある質問](technical-faq.html)
- **チュートリアル:**
- [問題の診断](diagnosing-problems.html)
- [容量の計画](capacity-planning.html)
- **リファレンス:**
- [rippled APIリファレンス](rippled-api.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}