ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-12-05 08:48:11 +00:00
Code Issues Packages Projects Releases Wiki Activity

[JA] replaceサーバー to サーバ

Browse Source
This commit is contained in:
tequ
2024-03-26 17:15:54 +09:00
parent ad498f60e1
commit 47a9338242
191 changed files with 1083 additions and 1082 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
@i18n/ja/docs/infrastructure/configuration/server-modes/run-rippled-as-a-stock-server.md
View File

@@ -4,14 +4,14 @@ parent: server-modes.html
seo:
description: XRPを統合する人のための汎用的な構成。
labels:
- コアサーバー
- コアサーバ
---
# ウォレットサーバーとしてのrippledの実行
# ウォレットサーバとしてのrippledの実行
ストックサーバは`rippled`用の汎用的な設定です。ストックサーバを利用することで、XRP Ledgerにトランザクションを送信したり、レジャーの履歴にアクセスしたり、XRPやXRP Ledgerと統合するための最新の[ツール](../../../introduction/software-ecosystem.md)を利用したりすることができます。このサーバを使って、クライアントアプリケーションをXRP Ledgerに接続することができます。
ウォレットサーバーは、次のすべてのことを行います。
ウォレットサーバは、次のすべてのことを行います。
- [ピアネットワーク](../../../concepts/networks-and-servers/peer-protocol.md)に接続
@@ -25,9 +25,9 @@ labels:
## `rippled`のインストールと実行
デフォルトのパッケージインストールでは、取引履歴の少ないストックサーバーがインストールされます。インストール手順については、[`rippled`のインストール](../../installation/index.md)をご覧ください。
デフォルトのパッケージインストールでは、取引履歴の少ないストックサーバがインストールされます。インストール手順については、[`rippled`のインストール](../../installation/index.md)をご覧ください。
インストール後、サーバーが一度に保存する履歴の量を調整することができます。この方法については、[オンライン削除の設定](../data-retention/configure-online-deletion.md)をご覧ください。
インストール後、サーバが一度に保存する履歴の量を調整することができます。この方法については、[オンライン削除の設定](../data-retention/configure-online-deletion.md)をご覧ください。
## トラブルシューティング

64
@i18n/ja/docs/infrastructure/configuration/server-modes/run-rippled-as-a-validator.md
View File

@@ -2,16 +2,16 @@
html: run-rippled-as-a-validator.html
parent: server-modes.html
seo:
description: サーバーがコンセンサスレジャーで投票できるようにします。
description: サーバがコンセンサスレジャーで投票できるようにします。
labels:
- コアサーバー
- コアサーバ
- ブロックチェーン
top_nav_grouping: 人気ページ
top_nav_name: UNLに参加しよう
---
# バリデータとしてのrippledの実行
[バリデータモード](../../../concepts/networks-and-servers/rippled-server-modes.md)で実行されている[`rippled`サーバー](../../../concepts/networks-and-servers/index.md)は、ストックサーバーが実行するあらゆる処理を実行します。
[バリデータモード](../../../concepts/networks-and-servers/rippled-server-modes.md)で実行されている[`rippled`サーバ](../../../concepts/networks-and-servers/index.md)は、ストックサーバが実行するあらゆる処理を実行します。
- [ピアのネットワーク](../../../concepts/networks-and-servers/peer-protocol.md)への接続
@@ -21,7 +21,7 @@ top_nav_name: UNLに参加しよう
バリデータが _特異である_ のは、検証メッセージも発行するという点です。これらのメッセージは、[コンセンサスプロセス](../../../concepts/consensus-protocol/consensus-principles-and-rules.md#コンセンサスの仕組み)の進行中、XRP Ledgerネットワークによる評価の対象となる候補のトランザクションです。
ただし、単に検証メッセージを発行するだけで、バリデータにコンセンサスプロセスでの発言権が自動的に付与されるわけではありません。他のサーバーがバリデータ（モードのサーバー）を彼らのユニークノードリスト（UNL）に追加しない限り、彼らは（バリデータモードのサーバーからの）検証メッセージを無視します。バリデータがUNLに含まれている場合、 _信頼できる_ バリデータであり、その提案は、信頼する側のサーバーによってコンセンサスプロセスで検討されます。
ただし、単に検証メッセージを発行するだけで、バリデータにコンセンサスプロセスでの発言権が自動的に付与されるわけではありません。他のサーバがバリデータ（モードのサーバ）を彼らのユニークノードリスト（UNL）に追加しない限り、彼らは（バリデータモードのサーバからの）検証メッセージを無視します。バリデータがUNLに含まれている場合、 _信頼できる_ バリデータであり、その提案は、信頼する側のサーバによってコンセンサスプロセスで検討されます。
バリデータが _信頼できる_ バリデータではない場合も、ネットワークの全体的な健全性に関して、重要な役割を果たすことに変わりはありません。これらのバリデータは、信頼できるバリデータを評価するための基準の確立を支援します。例えば、信頼できるバリデータが、UNLに含まれていない多数のバリデータに対して異議を唱えている場合、問題があることを示しているおそれがあります。
@@ -31,7 +31,7 @@ top_nav_name: UNLに参加しよう
## 1. 優れたバリデータの特徴の理解
バリデータ（サーバー）が以下の特質を常に備えるよう努めます。優れたバリデータであることは、`rippled`サーバーの運用者やバリデータリスト発行者(https://vl.ripple.com や https://vl.xrplf.orgなど)が、バリデータを彼らのUNLに追加する際に、バリデータを信頼する上で後押しになります。
バリデータ（サーバ）が以下の特質を常に備えるよう努めます。優れたバリデータであることは、`rippled`サーバの運用者やバリデータリスト発行者(https://vl.ripple.com や https://vl.xrplf.orgなど)が、バリデータを彼らのUNLに追加する際に、バリデータを信頼する上で後押しになります。
- **可用性**
@@ -55,17 +55,17 @@ top_nav_name: UNLに参加しよう
## 2. `rippled`サーバーのインストール
## 2. `rippled`サーバのインストール
詳細は、[`rippled`のインストール](../../installation/index.md)を参照してください。
## 3. `rippled`サーバーで検証を有効化
## 3. `rippled`サーバで検証を有効化
`rippled`サーバーで検証を有効にすることは、サーバーの`rippled.cfg`ファイルにあるバリデータトークンを提供することを意味します。バリデータキーとトークンを安全に生成して管理するために、`validator-keys`ツール（`rippled` RPMに含まれる）を使用することをお勧めします。
`rippled`サーバで検証を有効にすることは、サーバの`rippled.cfg`ファイルにあるバリデータトークンを提供することを意味します。バリデータキーとトークンを安全に生成して管理するために、`validator-keys`ツール（`rippled` RPMに含まれる）を使用することをお勧めします。
バリデータ（サーバー）**以外の**場所で、以下の手順に従います。
バリデータ（サーバ）**以外の**場所で、以下の手順に従います。
1. `validator-keys`ツールを`rippled` RPMを通じてまだインストールしていない場合は、手動でビルドして実行します。
@@ -121,7 +121,7 @@ top_nav_name: UNLに参加しよう
VUSmEydzBpMjFlcTNNWXl3TFZKWm5GT3I3QzBrdzJBaVR6U0NqSXpkaXRROD0ifQ==
```
バリデータ（サーバー）で、以下の手順に従います。
バリデータ（サーバ）で、以下の手順に従います。
1. `[validator_token]`とその値を、バリデータの`rippled.cfg`ファイルに追加します。
@@ -149,41 +149,41 @@ top_nav_name: UNLに参加しよう
このセクションでは、バリデータをXRP Ledgerネットワークに接続するために使用できる3種類の構成について説明します。ユースケースに最適な構成を使用してください。
- [検出されたピア](#検出されたピアを使用した接続): ピアツーピアネットワーク内の任意のサーバーに接続します。
- [検出されたピア](#検出されたピアを使用した接続): ピアツーピアネットワーク内の任意のサーバに接続します。
- [プロキシ](#プロキシを使用した接続): ストック`rippled`サーバーを、バリデータとピアツーピアネットワークの他の部分との間のプロキシとして実行します。
- [プロキシ](#プロキシを使用した接続): ストック`rippled`サーバを、バリデータとピアツーピアネットワークの他の部分との間のプロキシとして実行します。
- [公開ハブ](#公開ハブを使用した接続): 評価の高い特定の公開サーバーにのみ接続します。
- [公開ハブ](#公開ハブを使用した接続): 評価の高い特定の公開サーバにのみ接続します。
これらのアプローチの違いについては、[ピア接続設定のメリットとデメリット](../../../concepts/networks-and-servers/peer-protocol.md#ピア接続設定のメリットとデメリット)を参照してください。
### 検出されたピアを使用した接続
この構成では、[検出されたピア](../../../concepts/networks-and-servers/peer-protocol.md#ピアの検出)を使用してバリデータをXRP Ledgerネットワークに接続します。これは`rippled`サーバーのデフォルトの動作です。
この構成では、[検出されたピア](../../../concepts/networks-and-servers/peer-protocol.md#ピアの検出)を使用してバリデータをXRP Ledgerネットワークに接続します。これは`rippled`サーバのデフォルトの動作です。
_**検出されたピアを使用してバリデータをXRP Ledgerネットワークに接続するには、**_ バリデータの`rippled.cfg`ファイルで`[peer_private]`スタンザを省略するか、それを`0`に設定します。この構成の[サンプルのrippled.cfgファイル](https://github.com/XRPLF/rippled/blob/develop/cfg/rippled-example.cfg)が提供されています。
### プロキシを使用した接続
この構成は、自社で運用するストック`rippled`サーバーを通じてバリデータをネットワークに接続します。これらのプロキシサーバーは、バリデータと発着信ネットワークトラフィックの間に設置します。
この構成は、自社で運用するストック`rippled`サーバを通じてバリデータをネットワークに接続します。これらのプロキシサーバは、バリデータと発着信ネットワークトラフィックの間に設置します。
_**プロキシを使用してバリデータをXRP Ledgerネットワークに接続するには、次の手順を実行します。**_
1. ストック`rippled`サーバーを設置します。詳細は、[rippledのインストール](../../installation/index.md)を参照してください。
1. ストック`rippled`サーバを設置します。詳細は、[rippledのインストール](../../installation/index.md)を参照してください。
2. バリデータとストック`rippled`サーバーを設定して、[クラスター](../peering/cluster-rippled-servers.md)内で実行します。
2. バリデータとストック`rippled`サーバを設定して、[クラスター](../peering/cluster-rippled-servers.md)内で実行します。
3. バリデータの`rippled.cfg`ファイルで、`[peer_private]`を`1`に設定します。そうすることで、バリデータのIPアドレスが転送されないようにします。詳細は、[プライベートピア](../../../concepts/networks-and-servers/peer-protocol.md#プライベートピア)を参照してください。また、これによりクラスター内でバリデータを実行するよう`[ips_fixed]`スタンザで定義したサーバー以外のサーバーに、バリデータが接続しないようになります。
3. バリデータの`rippled.cfg`ファイルで、`[peer_private]`を`1`に設定します。そうすることで、バリデータのIPアドレスが転送されないようにします。詳細は、[プライベートピア](../../../concepts/networks-and-servers/peer-protocol.md#プライベートピア)を参照してください。また、これによりクラスター内でバリデータを実行するよう`[ips_fixed]`スタンザで定義したサーバ以外のサーバに、バリデータが接続しないようになります。
**警告:** バリデータのIPアドレスを、その他の方法で公開していないことを確認してください。
4. 以下のトラフィックのみを許可するように、バリデータのホストマシンのファイアウォールを構成します。
- 着信トラフィック: 構成したクラスター内にあるストック`rippled`サーバーのIPアドレスが発信元である場合のみ
- 着信トラフィック: 構成したクラスター内にあるストック`rippled`サーバのIPアドレスが発信元である場合のみ
- 発信トラフィック: 構成したクラスター内にあるストック`rippled`サーバーのIPアドレスおよびポート443経由の<https://vl.ripple.com>が送信先である場合のみ
- 発信トラフィック: 構成したクラスター内にあるストック`rippled`サーバのIPアドレスおよびポート443経由の<https://vl.ripple.com>が送信先である場合のみ
5. `rippled`を再起動します。
@@ -191,7 +191,7 @@ _**プロキシを使用してバリデータをXRP Ledgerネットワークに
$ sudo systemctl restart rippled.service
```
6. いずれかのストック`rippled`サーバーにある[ピアクローラー](../../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)エンドポイントを使用します。レスポンスには、バリデータが含まれていないはずです。これにより、バリデータの`[peer_private]`構成が機能していることが確認されます。バリデータの`[peer_private]`を有効にした場合の効果の1つは、バリデータのピアによって、ピアクローラーの結果にバリデータが含まれないことです。
6. いずれかのストック`rippled`サーバにある[ピアクローラー](../../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)エンドポイントを使用します。レスポンスには、バリデータが含まれていないはずです。これにより、バリデータの`[peer_private]`構成が機能していることが確認されます。バリデータの`[peer_private]`を有効にした場合の効果の1つは、バリデータのピアによって、ピアクローラーの結果にバリデータが含まれないことです。
```
$ curl --insecure https://STOCK_SERVER_IP_ADDRESS_HERE:51235/crawl | python3 -m json.tool
@@ -216,15 +216,15 @@ _**公開ハブを使用してバリデータをネットワークに接続す
**注意:** この構成では、デフォルトの公開ハブを使用してバリデータをネットワークに接続します。これらは _デフォルト_ の公開ハブであるため、ビジー状態になってバリデータにネットワークへの接続を提供できない場合があります。この問題を避けるために、接続する公開ハブの数を増やすか、デフォルトでない公開ハブに接続するようにします。
他の`rippled`サーバーのIPアドレスをここに記述することもできますが、それらのサーバーに対して以下の事項を期待できる場合に _**限ります**_ 。
他の`rippled`サーバのIPアドレスをここに記述することもできますが、それらのサーバに対して以下の事項を期待できる場合に _**限ります**_ 。
- メッセージを検閲することなく中継する。
- オンライン状態を常に維持する。
- サーバーに対するDDoS攻撃を実行しない。
- サーバーをクラッシュさせようとしない。
- サーバに対するDDoS攻撃を実行しない。
- サーバをクラッシュさせようとしない。
- 未知の相手にバリデータのIPアドレスを公開しない。
2. また、バリデータの`rippled.cfg`ファイルに、次の`[peer_private]`スタンザを含めて、それを`1`に設定します。それにより、バリデータのピアに対して、バリデータのIPアドレスをブロードキャストしないよう指示することになります。また、バリデータに対して、`[ips_fixed]`スタンザで設定されているピアにのみ接続するよう指示することになります。これにより、既知の信頼できるピア`rippled`サーバーに対してのみ、バリデータが接続を確立し、IPアドレスを共有することが保証されます。
2. また、バリデータの`rippled.cfg`ファイルに、次の`[peer_private]`スタンザを含めて、それを`1`に設定します。それにより、バリデータのピアに対して、バリデータのIPアドレスをブロードキャストしないよう指示することになります。また、バリデータに対して、`[ips_fixed]`スタンザで設定されているピアにのみ接続するよう指示することになります。これにより、既知の信頼できるピア`rippled`サーバに対してのみ、バリデータが接続を確立し、IPアドレスを共有することが保証されます。
```
[peer_private]
@@ -247,7 +247,7 @@ _**公開ハブを使用してバリデータをネットワークに接続す
ここでは、バリデータがXRP Ledgerネットワークへの健全な接続を保持していることを検証する方法をいくつか紹介します。
- [`peers`](../../../references/http-websocket-apis/admin-api-methods/peer-management-methods/peers.md)コマンドを使用して、バリデータに接続しているすべての`rippled`サーバーのリストを取得します。`peers`の配列が`null`である場合、ネットワークへの健全な接続が存在していません。このドキュメントの手順に従ってバリデータを設置した場合、`peers`の配列には、`[ips_fixed]`スタンザで定義されているピアの数と同数のオブジェクトが含まれています。
- [`peers`](../../../references/http-websocket-apis/admin-api-methods/peer-management-methods/peers.md)コマンドを使用して、バリデータに接続しているすべての`rippled`サーバのリストを取得します。`peers`の配列が`null`である場合、ネットワークへの健全な接続が存在していません。このドキュメントの手順に従ってバリデータを設置した場合、`peers`の配列には、`[ips_fixed]`スタンザで定義されているピアの数と同数のオブジェクトが含まれています。
公開ハブを`[ips_fixed]`スタンザに記述した場合、そのハブがビジーになっているときは、バリデータの接続が拒否されることがあります。この場合、接続の数は、`[ips_fixed]`スタンザで設定した数よりも最終的に少なくなることがあります。初めて拒否された場合、バリデータは接続を再試行します。
@@ -255,7 +255,7 @@ _**公開ハブを使用してバリデータをネットワークに接続す
- [`server_info`](../../../references/http-websocket-apis/public-api-methods/server-info-methods/server_info.md)コマンドを使用して、バリデータに関するいくつかの基本情報を取得します。`server_state`は、`proposing`に設定されているはずです。`full`または`validating`に設定されている場合もありますが、`proposing`に移行するまでの数分間に限られます。
`server_state`が`proposing`に設定されている時間が大部分を占めていない場合、XRP Ledgerネットワークにバリデータが完全に参加できていないことを示している可能性があります。サーバーの状態および`server_info`エンドポイントを使用してバリデータの問題を診断する方法の詳細は、[`rippled`サーバーの状態](../../../references/http-websocket-apis/api-conventions/rippled-server-states.md)および[`server_info`の取得](../../troubleshooting/diagnosing-problems.md#server_infoの取得)を参照してください。
`server_state`が`proposing`に設定されている時間が大部分を占めていない場合、XRP Ledgerネットワークにバリデータが完全に参加できていないことを示している可能性があります。サーバの状態および`server_info`エンドポイントを使用してバリデータの問題を診断する方法の詳細は、[`rippled`サーバの状態](../../../references/http-websocket-apis/api-conventions/rippled-server-states.md)および[`server_info`の取得](../../troubleshooting/diagnosing-problems.md#server_infoの取得)を参照してください。
- [`validators`](../../../references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/validators.md)コマンドを使用して、バリデータによって使用される、公開済みかつ信頼できるバリデータの最新リストを取得します。`validator_list_expires`の値が、`never`（無期限）、期限が切れていない、または期限切れ間近のいずれかであることを確認してください。
@@ -273,13 +273,13 @@ _**公開ハブを使用してバリデータをネットワークに接続す
ドメイン検証を提供するには、以下の手順に従います。
1. バリデータと公に関連付ける、所有しているドメインの名前を選択します。そのドメインのポート443で外部に公開されるHTTPSサーバーを実行中であり、そのサーバーのTLS証明書に関連付けられている秘密鍵ファイルへのアクセス権を持っている必要があります。（注記: [TLSの旧称はSSLです](https://en.wikipedia.org/wiki/Transport_Layer_Security)。）DDoS攻撃への対策として、ドメイン名によってバリデータのIPアドレスが解決されないようにする必要があります。
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. バリデータのサーバーで以下のコマンドを実行して、バリデータの公開鍵を検出します。
1. バリデータのサーバで以下のコマンドを実行して、バリデータの公開鍵を検出します。
$ /opt/ripple/bin/rippled server_info | grep pubkey_validator
@@ -287,7 +287,7 @@ _**公開ハブを使用してバリデータをネットワークに接続す
返された値を、Googleフォームの**Validator Public Key**フィールドに入力します。
```
2. WebドメインのTLS秘密鍵を使用して、バリデータの公開鍵に署名します。TLS秘密鍵ファイルをバリデータのサーバーに保存する必要はありません。
2. WebドメインのTLS秘密鍵を使用して、バリデータの公開鍵に署名します。TLS秘密鍵ファイルをバリデータのサーバに保存する必要はありません。
$ openssl dgst -sha256 -hex -sign /PATH/TO/YOUR/TLS.key <(echo YOUR_VALIDATOR_PUBLIC_KEY_HERE)
@@ -328,9 +328,9 @@ _**公開ハブを使用してバリデータをネットワークに接続す
- **コンセプト:**
- [XRP Ledgerの概要](/about/)
- [`rippled`サーバー](../../../concepts/networks-and-servers/index.md)
- [`rippled`サーバ](../../../concepts/networks-and-servers/index.md)
- **チュートリアル:**
- [rippledサーバーのクラスター化](../peering/cluster-rippled-servers.md)
- [rippledサーバのクラスター化](../peering/cluster-rippled-servers.md)
- [`rippled`のインストール](../../installation/index.md)
- [容量の計画](../../installation/capacity-planning.md)
- **リファレンス:**