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

Information Architecture v3 (#1934)

Browse Source 
* Update look up escrows to remove redundant info about lookups via sender/destination. Modify cancel expired escrow for brevity.

* Cancel escrow: fix notes

* Add draft of updated cancel-escrow.js.

* Update intro to escrows.

* Add Escrow Tutorial

* Minor corrections

* Fix headings, add HTML

* Update escrow docs

This commit re-creates f205a92db2 with
some adjustments:

- Omit the accidentally-created dir full of junk
- Fix some typos and one mistake in the Escrow limitations section
- Add a table to the EscrowCreate ref to clarify valid combos of fields.

* Concept info from send-a-time-held-escrow added to escrow.md

* IA: Move "Consensus Network" files

This re-creates some work from the original commit 56fffe0b9f

* Rewrite escrows article (re-created)

This commit re-creates relevant work from the following commits:

9a4a588f2b Update escrow.md context info
e1b017dc83 Remove references to using escrow for interledger payments.

* IA: Move "XRPL servers" files

This re-creates some work from original commit 7611979abf

* IA: move "production readiness" files.

Re-creates work from the following commit:

692438693a  Move tutorials to concepts

* New intro articles

Original commit: 56fffe0b9f

* IA: Reorg account concepts

Re-creates some work from original commit 56fffe0b9f

* IA: reorg transaction concepts

Original commits:
9d4eff9940  WIP - reorg accounts
7611979abf  WIP dir. reorg

* IA: reorg consensus concepts

Original commit: 56fffe0b9f

* IA: Reorg ledger docs

Original commit: 56fffe0b9f

- Rephrased some details of the section

* IA: rename issuing/operational addresses page

Original commit: 56fffe0b9f

* Moving use cases

* Fleshing out Use Cases

Note, the dactyl-config.yml file has not been fully updated.

* Clean up checks conceptual info.

* Remove redundant checks use case section

Original commit: 3c29e9c05e

* IA: move Dex under tokens

Original commit: d08b3ba7d7

* Touch up stablecoin issuer use case (#1856)

* Consolidate stablecoin use case

* Stablecoin issuer: cleanup progress through sending

* Stablecoin issuer: reorg second half

(Note: the dactyl-config.yml is not fully reconciled yet)

* Move rippled and clio tutorials into infrastructure

* Remove link to checks amendement.

* Add note to account_objects.md about commandline interface type field.

* Merge expiration case with lifecycle section.

* Interoperability Use Cases

* Add graphics to intro

* Move escrow use cases to dedicated page.

* Update use case page intros and corresponding concept info.

* Clarify meaning of direct XRP payments.

* Intro link updates

* Payment use cases

* Remove some unnecessary links in transactions section

Original commit: e6fcf4a4dc

* Link cleanup in Tokens section

Original commit: 9588dd5e70

* Touch up 'Configure Peering' section

Original commit: fc8f0990b8

* Clean up links in accounts section

Original commit: 3da5fde7a8

* Add NFT mkt use case

* p2p payments: edits to Wallets

* Clean up payments use cases

* Refine history description

* IA: use case cleanup

* IA: reconcile servers, ledgers sections

* IA: reconcile payment types, tx, tokens

* IA: reconcile accounts section

* IA: reconcile infra

* IA: Fix most broken links

* Full Docs Index: omit from sidebar

* IA: fix up most broken links

* fix Absolute path link to internal content

* Quick updates to Software Ecosystem

* Remove some absolute links to internal resources

* Fix remaining broken links in JA target

* Contributing: tweak formatting

* Tutorials: fix some minor issues

* remove interop use cases

* remove intro image and personal references to dennis

* alphabetize-transaction-nav

* Remove unused files

* Add QS escrow tutorials

* IA: move ledgers, consensus protocol files around

* IA: update nav for new page hierarchy

* reordering of topics under new networks and servers top-nav

* Move "Naming" to "What is XRP?"

* Update dactyl-config.yml

Remove xrp.md from the TOC.

* Update list-xrp-as-an-exchange.md

Update link to what-is-xrp

* Update list-xrp-as-an-exchange.ja.md

Change link to what-is-xrp

* Update currency-formats.md

Change link to what-is-xrp

* Update currency-formats.ja.md

Change link to what-is-xrp

* Update cancel-an-expired-escrow.md

Change link to what-is-xrp

* Update paymentchannelfund.md

Change link to what-is-xml

* Update look-up-escrows.md

Change link to what-is-xrp

* Update tokens.md

change link to what-is-xrp

* Update use-payment-channels.md

* Update send-a-time-held-escrow.md

Update link to what-is-xml

* fix broken links

* Update parallel-networks.md

Change link to what-is-xml

* Update parallel-networks.ja.md

* Update invariant-checking.md

Remove link to xrp.html

* Update invariant-checking.ja.md

Remove link to xrp.html

* Update transaction-cost.md

Change link to what-is-xrp

* Update transaction-cost.ja.md

Change link to what-is-xrp

* Update send-a-conditionally-held-escrow.md

Change link to what-is-xrp

* Update stablecoin-issuer.md

Change link to what-is-xrp

* Update tokens.ja.md

Change link to what-is-xml

* Update autobridging.ja.md

Change link to what-is-xrp

* Update currency-formats.md

update text

* reorganize infrastructure nav section

* Update currency-formats.md

Try removing link altogether.

* Update currency-formats.ja.md

Remove link to what-is-xrp.html

* move commandline usage topic to infrastructure

* initial intro rewrite

* minor update to language

* IA.v3: rm Production Readiness

* Delete xrp.md

* Update xrp link in snippet

* Add redirect for old xrp.html URL

* Small edits to 'What is XRP?' article

* Add missing imgs

* XRP - copy edit per @DennisDawson

* restructure tutorials nav and pages

* fix broken links

* more broken link fixes

* Algo trading: 1st draft

* Algo trading: notes on taxes

* Algo trading: edits per review

* algo trading: fix broken link

* Ledger structure: rewrite for accuracy and clarity

* Update links to removed 'tree format' header

* Ledger Structure: Update diagrams

* Re-gen CSS for ledger structure changes

* Ledger structure: edits per review

* IA.v3: fix broken NFT links introduced by rebase

* Desktop Wallet (py): update little stuff

* Update some capacity/storage details

* contribute doc nav update

* fix image link in create diagram page

* IAv3: Fix 'Ledgers' blurb

* Update full history requirements with details from community members

* add reviewer suggestions

* Edits per @trippled review

* Apply suggestions from peer review

Co-authored-by: oeggert <117319296+oeggert@users.noreply.github.com>

* FH: reword file size limit note per review

* Update software ecosystem

* updates per review

* Minor tweaks to graphics

* fixTypos

* Update content/concepts/introduction/software-ecosystem.md

Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>

* Update content/concepts/introduction/software-ecosystem.md

Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>

* [JA] update AccountDelete cost

* custom transactors doc

* add doc to dactyl config

* [JA] fix NonFungibleTokensV1_1 amendment status

* [JA] update NFTokenOffer page

* Remove old, unused XRP article (#2039)

* add reviewer suggestions

* Add tooling to check for file/nav consistency

- From the repo top, run tool/check_file_consistency.py to look for
  Markdown files that exist in the "content/" directory but aren't used
  in the documentation.
- New "enforce_filenames" filter prints a warning to console when
  building, if a file's path and filename don't match expectations
  based on its place in the nav and top heading.

* File consistency checker: correctly handle filenames starting in _

* Remove unused old 'get started' and associated code

* Create Resources section & reorg some files

- Rename some files/folders based on their place in the nav
- Move a bunch of non-documentation stuff, and docs on contributing code
  and/or docs to the new "Resources" section.
- Known issue: nav spills into a second row on page widths between
  993px-1110px. To be fixed in a later CSS update, maybe along with
  making the Resources dropdown multi-column.

* Fix #2078 code tab bug

CSS not built yet, to reduce merge conflicts. Won't have any effect
until that happens.

* fix Transaction JSON

* [JA] translate contributing contents

* fix contributing-to-documentation parent

* fix contribute-code blurb

* Top nav: add cols for Resources, fix broken links

* CSS: fix top nav overflows

* Fix broken link from redirect not in JA target

* Top nav: add Infra to article types

* Update contrib info & rename intro file

* [ja] Update link to suggested first page to translate

* [ja] fix contribute docs organization

* Run private network with docker tutorial (#2065)

* [NO-ISSUE] Run private network with docker tutorial

Adds a tutorial page in the Infrastructure section on how to run a private XRPL network with Docker.

Please let me know if you think this is a useful page to include for developers, whether the steps are clear or not, and if you have suggestions on what can be added to it.

* Add minor link fixes and Japanese target

* Apply suggestions from code review

Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>

* Add link to ripple-docker-testnet setup scripts in See Also section

* Update repo URL

---------

Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>

* add intro gfx (#2036)

* add intro gfx

* Move graphic up

* Update some graphics with their revised versions

* Add updated version of the custodial vs non-custodial graphic

---------

Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>
Co-authored-by: Amarantha Kulkarni <akulkarni@ripple.com>

* Update to reflect current UNL publishers

* [ja] update contributing

Co-authored-by: tequ <git@tequ.dev>

* Incorporate feedback on "What is XRP" page. (#2099)

* Add trademark info for XRP

* Revert section to previous state

* Fix broken link (#2101)

---------

Co-authored-by: Oliver Eggert <oeggert@ripple.com>
Co-authored-by: ddawson <dennis.s.dawson@gmail.com>
Co-authored-by: Maria Shodunke <mshodunke@ripple.com>
Co-authored-by: tequ <git@tequ.dev>
Co-authored-by: oeggert <117319296+oeggert@users.noreply.github.com>
Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>
Co-authored-by: develoQ <develoQ.jp@gmail.com>
Co-authored-by: Maria Shodunke <maria-robobug@users.noreply.github.com>
Co-authored-by: Amarantha Kulkarni <akulkarni@ripple.com>
This commit is contained in:
Rome Reginelli
2023-09-01 12:40:18 -07:00
committed by GitHub
parent 31a068e6ae
commit b51bcb4ea3
445 changed files with 9020 additions and 4411 deletions
Download Patch File Download Diff File Expand all files Collapse all files

106
content/infrastructure/rippled/configuration/configure-advisory-deletion.ja.md Normal file
View File

@@ -0,0 +1,106 @@
---
html: configure-advisory-deletion.html
parent: data-retention.html
blurb: 指示による削除を使用して、新しい履歴ができたときではなく、スケジュールで古いレジャー履歴を削除します。
labels:
- コアサーバー
- データ保持
---
# 指示による削除の設定
デフォルトの構成ファイルは、新しいレジャーバージョンが利用可能になると`rippled`が古いXRP Ledgerの履歴を自動的に削除するように設定されています。サーバーがピーク時にハードウェアリソースの大部分を使用する場合は、オフピーク時に実行するようスケジュールされたコマンドからの指示があった場合にのみ、レジャーを削除するようにサーバーを設定できます。これにより、オンライン削除がサーバーのパフォーマンスに及ぼす影響はほとんどなくなります。
## 前提条件
このチュートリアルでは、ご使用のサーバーが以下の条件を満たしていることを前提としています。
- サポートされているオペレーティングシステムを使用している。Ubuntu Linux、Red Hat Enterprise Linux（RHEL）、CentOS
- `rippled`サーバーがすでに[インストール](install-rippled.html)されており、[オンライン削除](online-deletion.html)が有効になっている。
デフォルトの構成ファイルは、レジャーバージョンが2000個を超えるとオンライン削除を実行するよう設定されています。
- `cron`デーモンがインストールされており、実行されている。
Ubuntu Linuxではデフォルトで`cron`デーモンが実行されます。
RHELまたはCentOSでは、以下の`cronie`パッケージをインストールできます。
$ sudo yum install cronie
- 選択した量の履歴をレジャーストアーに保管するのに十分なディスク容量がサーバーにある。
各種設定で必要なストレージの容量についての詳細は、[容量計画](capacity-planning.html)を参照してください。指示による削除が有効な場合、削除が実行されるまでにサーバーに蓄積可能な履歴の最大数は、`online_delete`設定で設定したレジャーバージョン数と、オンライン削除の指示の間隔を**加算**したものに相当します。
- サーバーの使用率が最も低い時間帯を把握している。
## 設定手順
日次スケジュールで指示による削除は以下の手順で設定します。
1. `rippled`の構成ファイルの`[node_db]`スタンザで`advisory_delete`を有効にします。
[node_db]
# Other settings unchanged ...
online_delete=2000
advisory_delete=1
- 指示された場合にのみオンライン削除を実行するには、`advisory_delete`を`1`に設定します。（`0`に設定すると、新しいレジャーバージョンが使用可能になると自動的にオンライン削除が実行されます。）
- `online_delete`を、オンライン削除の実行後に維持するレジャーバージョンの最小数に設定します。オンライン削除が実行されるまでに蓄積される履歴は、この値よりも多くなります。
{% include '_snippets/conf-file-location.md' %}<!--_ -->
2. サーバーに対してオンライン削除を指示する[can_deleteメソッド][]の実行をテストします。
このコマンドの実行には[`rippled`コマンドラインインターフェイス](get-started-using-http-websocket-apis.html#コマンドライン)を使用できます。例:
$ rippled --conf=/etc/opt/ripple/rippled.cfg can_delete now
応答は、サーバーがそのレジャーストアーから削除するレジャーインデックスの最大値を示します。たとえば、以下のメッセージはレジャーインデックス43633667以下のレジャーバージョンを削除できることを示します。
{
"result": {
"can_delete": 43633667,
"status": "success"
}
}
サーバー内の _新しい_ 検証済みレジャーバージョンの数が、`online_delete`の設定以上となった場合にのみ、レジャーバージョンが削除されます。
3. 前のステップでテストした`can_delete`メソッドを、予定した時刻に実行するように`cron`デーモンを設定します。
`cron` 設定を編集します。
$ crontab -e
以下の例では、サーバー時刻で毎日1:05 AMにサーバーが削除を実行するように設定されています。
5 1 * * * rippled --conf /etc/opt/ripple/rippled.cfg can_delete now
サーバーで設定されているタイムゾーンに基づいてコマンドが実行されるようにスケジュールしてください。
**ヒント:**`advisory_delete`を無効にしている場合は、`cron`ジョブをオンラインで実行するようにスケジュールする必要はありません。この場合、サーバーの最も古いレジャーバージョンと現行の検証済みレジャーバージョンの差が`online_delete`の値以上である場合に、`rippled`によりオンライン削除が実行されます。
4. `rippled`サービスを起動（または再起動）します。
$ sudo systemctl restart rippled
5. [server_infoメソッド][]を使用してサーバーの`complete_ledgers`範囲を定期的に調べ、レジャーがスケジュール通りに削除されていることを確認します。
オンライン削除の実行後には`complete_ledgers`の最小レジャーインデックスが増加します。
サーバーの使用率の状況と、一度に削除する履歴の量によっては、削除が完了するまでに数分間かかることがあります。
## トラブルシューティング
オンライン削除の設定後にオンライン削除が実行されていないようである場合は、以下を試してください。
- `cron`ジョブを設定したユーザーに、コマンドラインクライアントとして`rippled`サーバーを実行できる権限があることを確認します。
- cronジョブの構文とこのジョブの実行予定時刻を確認します。
- `rippled`実行可能ファイルが`cron`設定で指定したパスで使用可能であることを確認します。必要に応じて実行可能ファイルの絶対パス（`/opt/ripple/bin/rippled`など）を指定します。
- `rippled`ログで、`SHAMapStore::WRN`で始まるメッセージを調べます。このメッセージが出力されている場合、サーバーがネットワークと同期していない状態になったために[オンライン削除が中断されている](online-deletion.html#オンライン削除の中断)可能性があります。
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

121
content/infrastructure/rippled/configuration/configure-advisory-deletion.md Normal file
View File

@@ -0,0 +1,121 @@
---
html: configure-advisory-deletion.html
parent: data-retention.html
blurb: Use advisory deletion to delete older ledger history on a schedule rather than as new history becomes available.
labels:
- Core Server
- Data Retention
---
# Configure Advisory Deletion
The default config file sets [`rippled`](xrpl-servers.html) to automatically delete outdated [history](ledger-history.html) of XRP Ledger state and transactions as new ledger versions become available. If your server uses most of its hardware resources during peak hours, you can configure the server to delete ledgers only when prompted by a command scheduled to run during off-peak hours, so that online deletion is less likely to impact [server performance](capacity-planning.html).
## Prerequisites
This tutorial assumes your server meets the following prerequisites:
- You are on a supported operating system: Ubuntu Linux, Red Hat Enterprise Linux (RHEL), or CentOS.
- The `rippled` server is already [installed](install-rippled.html) and [online deletion](online-deletion.html) is enabled.
The default config file enables online deletion after 2000 ledger versions.
- A `cron` daemon is installed and running.
Ubuntu Linux runs a `cron` daemon by default.
On RHEL or CentOS, you can install the `cronie` package:
$ sudo yum install cronie
- Your server has enough disk space to store your chosen amount of history in its ledger store.
See [Capacity Planning](capacity-planning.html) for details of how much storage is required for different configurations. With advisory deletion enabled, the maximum history a server may accumulate before deletion is equal to the number of ledger versions configured in the `online_delete` setting **plus** the amount of time between online deletion prompts.
- You know which hours are least busy for your server.
## Configuration Steps
To configure advisory deletion with a daily schedule, perform the following steps:
1. Enable `advisory_delete` in the `[node_db]` stanza of your `rippled`'s config file.
[node_db]
# Other settings unchanged ...
online_delete=2000
advisory_delete=1
- Set `advisory_delete` to `1` to run online deletion only when prompted. (Set it to `0` to run online deletion automatically as new ledger versions become available.)
- Set `online_delete` to the minimum number of ledger versions to keep after running online deletion. The server accumulates more history than this until online deletion runs.
{% include '_snippets/conf-file-location.md' %}<!--_ -->
2. Test running the [can_delete method][] to prompt the server to run online deletion.
You can use the [`rippled` commandline interface](get-started-using-http-websocket-apis.html#commandline) to run this command. For example:
$ rippled --conf=/etc/opt/ripple/rippled.cfg can_delete now
The response indicates the maximum ledger index that the server may delete from its ledger store. For example, the following message indicates that ledger versions up to and including ledger index 43633667 can be deleted:
{
"result": {
"can_delete": 43633667,
"status": "success"
}
}
The server only deletes those ledger versions if the number of _newer_ validated ledger versions it has is equal to or greater than the `online_delete` setting.
3. Configure your `cron` daemon to run the `can_delete` method you tested in the previous step at a scheduled time.
Edit your `cron` configuration:
$ crontab -e
The following example sets the server to run deletion at 1:05 AM server time daily:
5 1 * * * rippled --conf /etc/opt/ripple/rippled.cfg can_delete now
Be sure that you schedule the command to run based on your server's configured time zone.
**Tip:** You do not need to schedule a `cron` job to run online deletion if you have `advisory_delete` disabled. In that case, `rippled` runs online deletion automatically when the difference between the server's oldest and current validated ledger versions is at least the value of `online_delete`.
4. Start (or restart) the `rippled` service.
$ sudo systemctl restart rippled
5. Periodically check your server's `complete_ledgers` range using the [server_info method][] to confirm that ledgers are being deleted as scheduled.
The lowest ledger index in `complete_ledgers` should increase after online deletion.
Deletion may take several minutes to complete when it runs, depending on how busy your server is and how much history you delete at a time.
## Troubleshooting
If online deletion does not seem to be running after configuring it, try the following:
- Check that the user who configured the `cron` job has permissions to run the `rippled` server as a commandline client.
- Check the syntax of your `cron` job and the time when it is supposed to run.
- Check that the `rippled` executable is available at the path specified in your `cron` configuration. If necessary, specify the absolute path to the executable, such as `/opt/ripple/bin/rippled`.
- Check your `rippled` logs for messages that begin with `SHAMapStore::WRN`. This can indicate that [online deletion is being interrupted](online-deletion.html#interrupting-online-deletion) because your server fell out of sync with the network.
## See Also
- **Concepts:**
- [Ledger History](ledger-history.html)
- [Online Deletion](online-deletion.html)
- **Tutorials:**
- [Configure Online Deletion](configure-online-deletion.html)
- [Diagnosing Problems with rippled](diagnosing-problems.html)
- [Understanding Log Messages](understanding-log-messages.html)
- **References:**
- [server_info method][]
- [can_delete method][]
- [logrotate method][]
- [Ledger Data Formats](ledger-data-formats.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

74
content/infrastructure/rippled/configuration/configure-amendment-voting.ja.md Normal file
View File

@@ -0,0 +1,74 @@
---
html: configure-amendment-voting.html
parent: configure-rippled.html
blurb: プロトコル修正に伴うサーバーの投票を設定する。
labels:
- コアサーバー
- ブロックチェーン
---
# 修正投票機能の設定
バリデーターとして設定されたサーバーは、[feature method][]を使ってXRP Ledgerプロトコルの[修正案(amendments)](amendments.html)に投票することができます。(この方法には[管理者アクセス](get-started-using-http-websocket-apis.html#管理者アクセス権限)が必要です).
例えば、「SHAMapV2」Amendmentに反対票を投じるには、以下のコマンドを実行します。
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```json
{
"id": "any_id_here",
"command": "feature",
"feature": "SHAMapV2",
"vetoed": true
}
```
*JSON-RPC*
```json
{
"method": "feature",
"params": [
{
"feature": "SHAMapV2",
"vetoed": true
}
]
}
```
*コマンドライン*
```sh
rippled feature SHAMapV2 reject
```
<!-- MULTICODE_BLOCK_END -->
**注記:** Amendmentの省略名は大文字と小文字が区別されます。また、AmendmentのIDを16進数で指定することもできますが、この場合は大文字と小文字が区別されません。
## 設定ファイルを使用する
もし、修正票の設定に設定ファイルを使いたい場合は、`[rpc_startup]` 節に行を追加して、起動時に各明示票のために自動的にコマンドを実行させることができます。例えば
```
[rpc_startup]
{ "command": "feature", "feature": "SHAMapV2", "vetoed": true }
```
変更を有効にするには、必ずサーバーを再起動してください。
**注意事項:** `[rpc_startup]` 節にあるコマンドは、サーバが起動するたびに実行され、サーバが動作している間に構成された投票設定を上書きすることができます。
## 関連項目
- [Amendment](amendments.html)
- [既知のAmendment](known-amendments.html)
- [feature メソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

74
content/infrastructure/rippled/configuration/configure-amendment-voting.md Normal file
View File

@@ -0,0 +1,74 @@
---
html: configure-amendment-voting.html
parent: configure-rippled.html
blurb: Set your server's votes on protocol amendments.
labels:
- Core Server
- Blockchain
---
# Configure Amendment Voting
Servers configured as validators can vote on [amendments](amendments.html) to the XRP Ledger protocol using the [feature method][]. (This method requires [admin access](get-started-using-http-websocket-apis.html#admin-access).)
For example, to vote against the "SHAMapV2" amendment, run the following command:
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```json
{
"id": "any_id_here",
"command": "feature",
"feature": "SHAMapV2",
"vetoed": true
}
```
*JSON-RPC*
```json
{
"method": "feature",
"params": [
{
"feature": "SHAMapV2",
"vetoed": true
}
]
}
```
*Commandline*
```sh
rippled feature SHAMapV2 reject
```
<!-- MULTICODE_BLOCK_END -->
**Note:** The short name of the amendment is case-sensitive. You can also use an amendment's ID as hexadecimal, which is not case sensitive.
## Using the Config File
If you prefer to use the config file to configure amendment voting, you can add a line to the `[rpc_startup]` stanza to run the command automatically on startup for each explicit vote. For example:
```
[rpc_startup]
{ "command": "feature", "feature": "SHAMapV2", "vetoed": true }
```
Be sure to restart your server for changes to take effect.
**Caution:** Any commands in the `[rpc_startup]` stanza run each time the server starts up, which can override voting settings you configured while the server was running.
## See Also
- [Amendments](amendments.html)
- [Known Amendments](known-amendments.html)
- [feature method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

100
content/infrastructure/rippled/configuration/configure-full-history.ja.md Normal file
View File

@@ -0,0 +1,100 @@
---
html: configure-full-history.html
parent: data-retention.html
blurb: 完全履歴サーバーは、運用のコストは高いものの、XRP Ledgerでこれまでに発生したすべてのトランザクションの記録を提供します。
labels:
- コアサーバー
- データ保持
---
# 全履歴の設定
デフォルトの構成では、新しいレジャーバージョンが利用可能になると`rippled`サーバーが古いXRP Ledger状態とトランザクションの履歴を自動的に削除するように設定されています。ほとんどのサーバーでは現在の状態を把握してトランザクションを処理するのに古い履歴は不要なため、この設定で十分です。ただし、一部のサーバーが可能な限り多くのXRP Ledgerの履歴を提供する場合、これはネットワークにとって有用であることがあります。
## 警告
全履歴の保存にはコストがかかります。2018年12月11日の時点では、XRP Ledgerの全履歴が専有するディスク容量は約**9テラバイト**にのぼります。適切なサーバーパフォーマンスのためには、全履歴を高速なソリッドステートディスクドライブに保存する必要があります。このような大量のソリッドステートストレージは安価ではなく、また保管する必要のある履歴の合計量は毎日約12 GBずつ増加します。
ピアツーピアネットワークから全履歴を取得するには非常に長い時間がかかり（数か月）、また古い履歴を取得し、かつレジャーの新たな進展を常に把握するには、システムリソースとネットワークリソースを十分に備えたサーバーが必要となります。レジャー履歴の取得を迅速に開始するため、すでに大量の履歴をダウンロードしている別のサーバーオペレーターを探すこともできます。このようなオペレーターは、データベースダンプを提供できるか、または少なくとも、履歴の取得に十分な時間、あなたのサーバーをオペレーターのサーバーに明示的にピア接続することができます。サーバーはファイルからレジャー履歴を読み込み、インポートする履歴レジャーの整合性を検証できます。
ネットワークへの参加、トランザクションの検証、またはネットワークの現在の状態の確認には、全履歴を記録するサーバーは必要ありません。全履歴が有用となるのは、過去に発生したトランザクションの結果や、過去の特定の時点におけるレジャーの状態を確認する場合だけです。このような情報を取得するには、必要とする履歴を保持している他のサーバーを利用する必要があります。
全履歴は保管せずにXRP Ledgerネットワークの履歴の保管に参加したい場合には、[履歴シャーディングを構成](configure-history-sharding.html)すれば、レジャー履歴のグループをランダムに選択して保管できます。
## 構成手順
サーバーが全履歴を取得して保管するように構成するには、以下の手順を実行します。
1. `rippled`サーバーが稼働中の場合は停止します。
$ sudo systemctl stop rippled
0. サーバーの構成ファイルで`[node_db]`スタンザの`online_delete`設定と`advisory_delete`設定を削除（またはコメントアウト）し、タイプをまだ`NuDB`に変更していない場合は変更します。
[node_db]
type=NuDB
path=/var/lib/rippled/db/nudb
#online_delete=2000
#advisory_delete=0
全履歴が記録されるサーバーでは、レジャーストアーにNuDBを使用します。これは、データベースがこれほど大きいと、RocksDBでは非常に大量のRAMが必要になるためです。詳細は、[容量の計画](capacity-planning.html)を参照してください。パフォーマンス関連の構成オプション`open_files`、`filter_bits`、`cache_mb`、`file_size_mb`、および`file_size_mult`は、RocksDBのみに適用されるオプションであるため、デフォルトの`[node_db]`スタンザから削除できます。
**注意:** RocksDBで履歴をすでにダウンロードしている場合は、NuDBへ切り替えるときに構成ファイルでデータベースのパスを変更するか、またはそのデータを削除する必要があります。`[node_db]`スタンザの`path`設定**および**`[database_path]`（SQLiteデータベース）設定の両方を変更する必要があります。このようにしないと、サーバーの[起動が失敗する](server-wont-start.html#状態dbエラー)可能性があります。
{% include '_snippets/conf-file-location.md' %}<!--_ -->
0. サーバーの構成ファイルで`[ledger_history]`スタンザを`full`に設定します。
[ledger_history]
full
0. 全履歴が保管されている1台以上のサーバーと明示的にピア接続するように、サーバーの構成ファイルで`[ips_fixed]`スタンザを設定します。
[ips_fixed]
169.55.164.20
50.22.123.215
サーバーのダイレクトピアの1つが使用可能な履歴データを保持している場合に限り、サーバーはピアツーピアネットワークから履歴データをダウンロードできます。全履歴をダウンロードする最も容易な方法は、すでに全履歴を保管しているサーバーとピア接続することです。
**ヒント:** Rippleは、すべての履歴が記録されるサーバーのプールを公開しています。これらのサーバーのIPアドレスを取得するには、ドメイン`s2.ripple.com`を数回解決します。これらのサーバーは公開サービスとして提供されているため、他のサーバーとのピア接続での可用性は限られており、またこれらのサーバーを悪用するとブロックされる可能性があることに注意してください。
0. 全履歴が記録されている別のサーバーからのデータベースダンプがあり、このダンプをベースとして利用できる場合は、サーバーの構成ファイルで`[import_db]`スタンザがインポート対象データを指し示すように設定します。（それ以外の場合はこのステップをスキップします。）
[import_db]
type=NuDB
path=/tmp/full_history_dump/
0. 以前に稼働していた`rippled`からの既存のデータベースファイルがサーバーにある場合は、そのデータベースファイルを削除します。
オンライン削除を無効にすると、サーバーはオンライン削除が有効であった間にダウンロードしたデータをすべて無視するため、ディスク容量を空けることができます。次に例を示します。
rm -r /var/lib/rippled/db/*
**警告:** フォルダーを削除する前に、保持したいファイルがそのフォルダーに含まれていないことを確認してください。通常は安全に`rippled`サーバーのデータベースファイルをすべて削除できますが、この操作は、設定されているデータベースフォルダーが`rippled`のデータベース以外には使用されていない場合にのみ行ってください。
0. `rippled`サーバーを起動し、インポート可能なデータベースダンプがある場合にはインポートします。
`[Import_db]`で構成されている読み取り対象データベースダンプがある場合は、`--import` [コマンドラインオプション](commandline-usage.html#デーモンモードのオプション)を指定してサーバーを明示的に起動します。
$ /opt/ripple/bin/rippled --conf /etc/opt/ripple/rippled.cfg --import
大量のデータベースダンプのインポートには数分から数時間かかることがあります。インポート中はサーバーは完全には起動せず、ネットワークと同期しません。インポートの状況を確認するには、サーバーログを参照してください。
データベースダンプをインポートしない場合は、サーバーを通常の方法で起動します。
$ sudo systemctl start rippled
0. `[import_db]`スタンザをサーバーの構成ファイルに追加した場合は、インポートの完了後にそのスタンザを削除してください。
このようにしないと、次回の再起動時にサーバーが同じデータを再びインポートしようとします。
0. [server_infoメソッド][]を使用して、サーバーの利用可能な履歴を監視します。
`complete_ledgers`フィールドに表示される利用可能なレジャーの範囲は、時間の経過とともに増加します。
本番環境のXRP Ledgerの履歴で最も古い利用可能なレジャーバージョンは、レジャーインデックス**32570**です。レジャー履歴の最初の約2週間分は、当時のサーバーのバグが原因で失われています。Test Netやその他のチェーンでは通常、履歴の最初のバージョンはレジャーインデックス**1**です。
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

117
content/infrastructure/rippled/configuration/configure-full-history.md Normal file
View File

@@ -0,0 +1,117 @@
---
html: configure-full-history.html
parent: data-retention.html
blurb: Full history servers provide a record of every transaction ever to occur in the XRP Ledger, although they are expensive to run.
labels:
- Core Server
- Data Retention
---
# Configure Full History
In its default configuration, the `rippled` server automatically deletes outdated history of XRP Ledger state and transactions as new ledger versions become available. This is enough for most servers, which do not need older history to know the current state and process transactions. However, it can be useful for the network if some servers provide as much history of the XRP Ledger as possible.
## Warnings
Storing full history is expensive. As of 2023-07-19, the full history of the XRP Ledger occupies approximately **26 terabytes** of disk space, which must be entirely stored on fast solid state disk drives for proper server performance. Such a large amount of solid state storage is not cheap, and the total amount of history you must store increases by approximately 12 GB per day.
Additionally, storing full history in NuDB requires single files that are larger than the 16 TB limit of ext4 filesystems, which is the default on many Linux distributions. You must use a filesystem with a larger single-file limit, such as XFS (recommended) or ZFS.
Acquiring full history from the peer-to-peer network takes a long time (several months) and requires that your server has enough system and network resources to acquire older history while keeping up with new ledger progress. To get a faster start on acquiring ledger history, you may want to find another server operator who has a large amount of history already downloaded, who can give you a database dump or at least allow your server to explicitly peer with theirs for a long time to acquire history. The server can load ledger history from a file and verify the integrity of the historical ledgers it imports.
You do not need a full history server to participate in the network, validate transactions, or know the current state of the network. Full history is only useful for knowing the outcome of transactions that occurred in the past, or the state of the ledger at a given time in the past. To get such information, you must rely on other servers having the history you need.
If you want to contribute to storing the history of the XRP Ledger network without storing the full history, you can [configure history sharding](configure-history-sharding.html) to store randomly-selected chunks of ledger history instead.
## Configuration Steps
To configure your server to acquire and store full history, complete the following steps:
1. Stop the `rippled` server if it is running.
$ sudo systemctl stop rippled
0. Remove (or comment out) the `online_delete` and `advisory_delete` settings from the `[node_db]` stanza of your server's config file, and change the type to `NuDB` if you haven't already:
[node_db]
type=NuDB
path=/var/lib/rippled/db/nudb
#online_delete=2000
#advisory_delete=0
On a full-history server, you should use NuDB for the ledger store, because RocksDB requires too much RAM when the database is that large. For more information, see [Capacity Planning](capacity-planning.html). You can remove the following performance-related configuration options from the default `[node_db]` stanza, because they only apply to RocksDB: `open_files`, `filter_bits`, `cache_mb`, `file_size_mb`, and `file_size_mult.`
**Caution:** If you have any history already downloaded with RocksDB, you must either delete that data or change the paths to the databases in the config file when you switch to NuDB. You must change both the `path` field of the `[node_db]` stanza **and** the `[database_path]` (SQLite database) setting. Otherwise, the server may [fail to start](server-wont-start.html#state-db-error).
{% include '_snippets/conf-file-location.md' %}<!--_ -->
0. Set the `[ledger_history]` stanza of your server's config file to `full`:
[ledger_history]
full
0. Set the `[ips_fixed]` stanza of your server's config file to explicitly peer with at least one server that has full history available.
[ips_fixed]
169.55.164.20 51235
50.22.123.215 51235
Your server can only download historical data from the peer-to-peer network if one its direct peers has the data available. The easiest way to ensure you can download full history is to peer with a server that already has full history.
**Tip:** Ripple makes a pool of full history servers publicly available. You can resolve the domain `s2.ripple.com` a few times to get the IP addresses of these servers. Ripple offers these servers as a public service, so be aware that their availability to peer with other servers is limited and you may be blocked if you abuse them.
0. If you have a database dump from another full-history server to use as a basis, set the `[import_db]` stanza of your server's config file to point to the data to be imported. (Otherwise, skip this step.)
[import_db]
type=NuDB
path=/tmp/full_history_dump/
0. Remove your server's existing database files, if you have any from previously running `rippled`.
After disabling online deletion, the server ignores any data that was downloaded while online deletion was enabled, so you may as well clear up the disk space. For example:
rm -r /var/lib/rippled/db/*
**Warning:** Be sure that you have not put any files you want to keep in the folder before you delete it. It is generally safe to delete all of a `rippled` server's database files, but you should only do this if the configured database folder is not used for anything other than `rippled`'s databases.
0. Start the `rippled` server, importing the database dump if you have one available:
If you have a database dump to load configured in `[import_db]`, start the server explicitly and include the `--import` [commandline option](commandline-usage.html#daemon-mode-options):
$ /opt/ripple/bin/rippled --conf /etc/opt/ripple/rippled.cfg --import
Importing a large database dump may take several minutes or even hours. During this time, the server is not fully started and synced with the network. Watch the server logs to see the status of the import.
If you are not importing a database dump, start the server normally:
$ sudo systemctl start rippled
0. If you added an `[import_db]` stanza to your server's config file, remove it after the import completes.
Otherwise, your server may try to import the same data again the next time it is restarted.
0. Monitor your server's available history with the [server_info method][].
The range of available ledgers reported in the `complete_ledgers` field should increase over time.
The earliest available ledger version in the production XRP Ledger's history is ledger index **32570**. The first two weeks or so of ledger history was lost due to a bug in the server at the time. [Test nets and other chains](parallel-networks.html) generally have history going back to ledger index **1**.
## See Also
- **Concepts:**
- [Ledger History](ledger-history.html)
- [rippled Server Modes](rippled-server-modes.html)
- **Tutorials:**
- [Capacity Planning](capacity-planning.html), particularly [Disk Space](capacity-planning.html#disk-space)
- [Configure Online Deletion](configure-online-deletion.html)
- [Diagnosing Problems with rippled](diagnosing-problems.html)
- [Understanding Log Messages](understanding-log-messages.html)
- **References:**
- [server_info method][]
- [can_delete method][]
- [Ledger Data Formats](ledger-data-formats.html)
- [rippled Commandline Usage Reference](commandline-usage.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

56
content/infrastructure/rippled/configuration/configure-grpc.md Normal file
View File

@@ -0,0 +1,56 @@
---
html: configure-grpc.html
parent: configure-rippled.html
blurb: Enable and configure the gRPC API.
labels:
- Core Server
---
# Configure gRPC
The `rippled` server has a limited [gRPC API](https://grpc.io/) which [P2P mode servers](rippled-server-modes.html) can provide. Reporting mode servers use this API to retrieve data about the latest validated ledgers and transactions. You can enable the gRPC API on your server with a new configuration stanza.
**Caution:** gRPC support is intended specifically for providing data to reporting mode servers from P2P mode servers. Breaking changes to the gRPC API may occur without warning or it may be removed entirely in future versions of the server.
## Prerequisites
To enable gRPC, you must meet the following prerequisites:
- You must have [installed rippled](install-rippled.html).
- Your server must be able to bind to the port you choose.
## Steps
To enable gRPC on your server, complete the following steps:
1. Ensure the `[port_grpc]` stanza is in your `rippled` config file.
[port_grpc]
port = 50051
ip = 127.0.0.1
- `port` defines the port the server listens on for gRPC connections from client applications. The recommended port is `50051`.
- `ip` defines which interfaces the server listens on. `127.0.0.1` limits connections to the local loopback network (same machine) and is enabled by default. Changing the value to `0.0.0.0` listens on all available network interfaces.
{% include '_snippets/conf-file-location.md' %}
2. Start (or restart) the `rippled` service.
sudo systemctl restart rippled
## See Also
- **Concepts:**
- [XRP Ledger Overview](xrp-ledger-overview.html)
- [`rippled` Server Modes](rippled-server-modes.html)
- **Tutorials:**
- [Get Started Using HTTP / WebSocket APIs](get-started-using-http-websocket-apis.html)
- [Reliable Transaction Submission](reliable-transaction-submission.html)
- [Manage the rippled Server](manage-the-rippled-server.html)
- **References:**
- [HTTP / WebSocket API Reference](http-websocket-apis.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

84
content/infrastructure/rippled/configuration/configure-history-sharding.ja.md Normal file
View File

@@ -0,0 +1,84 @@
---
html: configure-history-sharding.html
parent: data-retention.html
blurb: 履歴XRPレジャーデータのシャードを保存するようにサーバーを設定します。
labels:
- データ保持
- コアサーバー
---
# 履歴シャーディングの設定
[履歴シャーディング](history-sharding.html)では、各サーバーで完全な履歴を保管することなく、履歴XRP Ledgerデータを保存できます。デフォルトでは`rippled`サーバーは履歴シャードを保管しません。
**ヒント:** バリデータおよび`rippled`追跡（またはストック）サーバーの両方で履歴シャードを保管するように設定できます。ただし`rippled`バリデータサーバーの経費を抑えるために、バリデータサーバーでシャードを保管するように設定 _しない_ ことが推奨されます。バリデータを実行していて、XRP Ledger履歴を保管したい場合は、履歴シャーディングを有効にして別の`rippled`サーバーを実行することが推奨されます。
レジャー履歴のシャードを保管できるよう`rippled`を設定するには、以下の手順を実行します。
## 1. シャードストアーに割り当てる容量を決めます。
履歴シャードを保管できるように`rippled`サーバーを設定する前に、履歴シャードストアーに割り当てるディスク容量を決定する必要があります。これはまた、デフォルトのレジャーストアーに保持する履歴の量にも影響します。シャードストアーのサイズを設定する際には、以下の点を考慮してください。
- レジャーストアー（`[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`サーバーに必要なファイルハンドル数、およびメモリーキャッシュ使用率は、シャードのサイズの影響を直接受けます。
## 2. rippled.cfgの編集
`rippled.cfg`ファイルを編集し、`[shard_db]`スタンザを追加します。
{% include '_snippets/conf-file-location.md' %}<!--_ -->
以下のスニペットに、`[shard_db]`スタンザの例を示します。
```
[shard_db]
type=NuDB
path=/var/lib/rippled/db/shards/nudb
max_size_gb=50
```
`type`フィールドは省略できます。省略しない場合は、`NuDB`である _必要があります_ 。[新規: rippled 1.3.1][]
**注意:** `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]`の例を参照してください。
## 3. サーバーの再起動
```
systemctl restart rippled
```
## 4. シャードのダウンロードの待機
サーバーはネットワークと同期すると、履歴シャードのダウンロードを自動的に開始し、シャードストアーの空き容量を埋めます。ダウンロード対象のシャードを確認するには、シャードストアーを設定したフォルダー内に作成されるフォルダーを確認します。（これは`rippled.cfg`ファイルの`[shard_db]`スタンザの`path`フィールドによって定義されます。）
このフォルダーには、サーバーに保管されている各シャードのフォルダーが番号付きで保存されています。常に、最大で1つのフォルダーに、未完了であることを示す`control.txt`ファイルが保存されています。
[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' %}

91
content/infrastructure/rippled/configuration/configure-history-sharding.md Normal file
View File

@@ -0,0 +1,91 @@
---
html: configure-history-sharding.html
parent: data-retention.html
blurb: Set up a server to contribute to preserving shards of historical XRP Ledger data.
labels:
- Data Retention
- Core Server
---
# Configure History Sharding
[History Sharding](history-sharding.html) lets servers contribute to preserving historical XRP Ledger data without each server needing to store the full history. By default, `rippled` servers do not store history shards.
**Tip:** While both validator and tracking (or stock) `rippled` servers can be configured to store history shards, Ripple recommends _not_ configuring validator `rippled` servers to store shards, to reduce overhead on those servers. If you run a validator and want to contribute to storing XRP Ledger history, Ripple recommends you run a separate `rippled` server with history sharding enabled.
To configure your `rippled` to store shards of ledger history, complete the following steps:
## 1. Determine how many shards to maintain
Before you configure your `rippled` server to store history shards, you must decide how many history shards you want to keep, which is mostly determined by how much disk space is available for the shard store. This also affects how much history you keep in the default ledger store. You should consider the following when deciding what size to configure your shard store:
- The ledger store (defined by the `[node_db]` stanza) is separate from the history shard store. The ledger store is required for all servers, and always contains a range of recent history, defined by how many ledgers to keep available in the `online_delete` parameter. (The default configuration stores the most recent 2000 ledgers.)
- If you keep at least 2<sup>15</sup> ledgers (32768) in the ledger store, you can efficiently import chunks of recent history from the ledger store into the shard store.
- The history shard store (defined by the `[shard_db]` stanza) is only required for storing history shards. The configuration stanza should be omitted from servers that do not store history shards. The total number of shards stored is defined by the `max_historical_shards` parameter; the server attempts to store no more than this many complete shards. The history shard store _MUST_ be stored on a solid-state disk or similar fast media. Traditional spinning hard disks are insufficient.
- A shard consists of 2<sup>14</sup> ledgers (16384) and occupies approximately 200 MB to 4 GB based on the age of the shard. Older shards are smaller because there was less activity in the XRP Ledger at the time.
- The history shard store and the ledger store _MUST_ be stored at different file paths. You can configure the ledger store and history store to be on different disks or partitions if desired.
- It is possible but redundant to hold full ledger history in both the ledger store and the history shard store.
- The time to acquire a shard, number of file handles needed by the `rippled` server, and memory cache usage is directly affected by the size of the shard.
- You can specify additional paths to store older history shards by providing a `[historical_shard_paths]` stanza. These paths may be on different, slower disks because they hold data that is used less often. The most recent two shards (the ones with the largest ledger indexes) are always stored in the path specified in the `[shard_db]` stanza. [New in: rippled 1.7.0][]
## 2. Edit rippled.cfg
<!-- SPELLING_IGNORE: cfg -->
Edit your `rippled.cfg` file to add a `[shard_db]` stanza and optionally a `[historical_shard_paths]` stanza.
{% include '_snippets/conf-file-location.md' %}<!--_ -->
The following snippet shows an example of a `[shard_db]` stanza:
```
[shard_db]
path=/var/lib/rippled/db/shards/nudb
max_historical_shards=12
# Optional paths for shards other than the newest 2
[historical_shard_paths]
/mnt/disk1
/mnt/disk2
```
The `type` field of `[shard_db]` can be omitted. If present, it _MUST_ be `NuDB`. [New in: rippled 1.3.1][]
**Caution:** If `rippled` detects the wrong type of data in the shard store path, it may [fail to start](server-wont-start.html). You should use a new folder for the shard store. If you previously used a RocksDB shard store (`rippled` 1.2.x and lower), use a different path or delete the RocksDB shard data.
For more information, reference the `[shard_db]` example in the [rippled.cfg configuration example](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg).
## 3. Restart the server
```
systemctl restart rippled
```
## 4. Wait for shards to download
After your server syncs to the network, it automatically starts downloading history shards to fill the available space in the shard store. You can see which shards are being downloaded by looking at which folders are created in the folder where you configured your shard store. (This is defined by the `path` field of the `[shard_db]` stanza in the `rippled.cfg` file.)
This folder should contain a numbered folder for each shard your server has. At any given time, up to one folder may contain a `control.txt` file, indicating it is incomplete.
You can instruct your server to download and import a shard from an archive file using the [download_shard method][].
To list the shards your server and its peers have available, you can use the [crawl_shards method][] or the [Peer Crawler](peer-crawler.html).
## See Also
- **Concepts:**
- [Ledger History](ledger-history.html)
- [Online Deletion](online-deletion.html)
- **Tutorials:**
- [Configure Online Deletion](configure-online-deletion.html)
- [Configure the Peer Crawler](configure-the-peer-crawler.html)
- [Capacity Planning](capacity-planning.html)
- **References:**
- [download_shard method][]
- [crawl_shards method][]
- [Ledger Data Formats](ledger-data-formats.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

83
content/infrastructure/rippled/configuration/configure-online-deletion.ja.md Normal file
View File

@@ -0,0 +1,83 @@
---
html: configure-online-deletion.html
parent: data-retention.html
blurb: サーバーでどこまで古いトランザクション履歴を保持するかを設定します。
labels:
- データ保持
- コアサーバー
---
# オンライン削除の設定
`rippled`サーバーのデフォルトの構成では、最新2000個のレジャーバージョンよりも古い[履歴が削除され](online-deletion.html)、レジャー履歴は約15分間維持されます（現行のレジャー毎の間隔に基づく）。このページでは、削除までに`rippled`サーバーに保管される履歴の量を設定する方法を説明します。
## 前提条件
このチュートリアルでは、ご使用のサーバーが以下の条件を満たしていることを前提としています。
- サポートされているオペレーティングシステムを使用している。Ubuntu Linux、Red Hat Enterprise Linux（RHEL）、CentOS
- `rippled`サーバーがすでに[インストール](install-rippled.html)されており、[オンライン削除](online-deletion.html)が有効になっている。
推奨されるプラットフォームのインストール手順に従えば、オンライン削除はデフォルトで有効となります。
- 選択した量の履歴をレジャーストアーに保管するのに[十分なディスク容量](capacity-planning.html)がサーバーにある。
## 構成手順
サーバーに保管する履歴の量を変更するには、以下の手順を実行します。
1. 保管する履歴に相当するレジャーバージョンの数を決定します。
新しいレジャーバージョンは通常3～4秒間隔で検証されます。このため、レジャーバージョンの数は、保管する期間におおむね対応しています。各種構成で必要なストレージの容量についての詳細は、[容量計画](capacity-planning.html)を参照してください。
オンライン削除は、履歴の削除 _後_ に維持するレジャーバージョンの数に基づいておこなわれるので、設定した維持するレジャー数の2倍を保管するのに十分なディスク容量が必要です。
0. `rippled`の構成ファイルで`[node_db]` スタンザの`online_delete`フィールドを編集します。
[node_db]
# Other settings unchanged ...
online_delete=2000
advisory_delete=0
`online_delete`を、オンライン削除の実行後に維持するレジャーバージョンの最小数に設定します。自動削除が設定されている場合（デフォルト）、サーバーは通常、この数の約2倍のレジャーバージョンが蓄積されると削除を実行します。
{% include '_snippets/conf-file-location.md' %}<!--_ -->
0. `rippled`サービスを起動（または再起動）します。
$ sudo systemctl restart rippled
0. サーバーがネットワークと同期するまで待ちます。
ネットワークとシステムの能力と、サーバーがオフラインになっていた期間に応じて、完全な同期が完了するまでには5～15分かかります。
サーバーとネットワークの同期が完了すると、[server_infoメソッド][]が再び開き、`server_state`の値として`"full"`、`"proposing"`、`"validating"`のいずれかが報告されます。
0. [server_infoメソッド][]を使用してサーバーの`complete_ledgers`範囲を定期的に調べ、レジャーが削除されていることを確認します。
オンライン削除実行後の`complete_ledgers`範囲には、古いレジャーが使用できなくなったことが反映されます。サーバーに履歴が蓄積されるにつれ、使用可能なレジャーの総数が徐々に増加します。この数が設定した`online_delete`値の2倍に達し、オンライン削除が実行されるとレジャーの総数は減少します。
0. `rippled`ログで、`SHAMapStore::WRN`で始まるメッセージを確認します。このメッセージが出力されている場合、サーバーがネットワークと同期していない状態になったために[オンライン削除が中断されている](online-deletion.html#オンライン削除の中断)可能性があります。
この状況が定期的に発生する場合は、サーバーのスペックが不十分で、オンライン削除の実行中にレジャーを最新状態に維持できていない可能性があります。同じハードウェア上の他のサービス（スケジュール済みバックアップやセキュリティスキャンなど）と`rippled`サーバーがリソースをめぐって競合していないことを確認してください。以下のいずれかの操作を実行できます。
- システムスペックを強化する。推奨事項については、[システム要件](system-requirements.html)を参照してください。
- 設定を変更し、保管する履歴の量を減らす。（このチュートリアルのステップ2）
- サーバーの[`node_size`パラメーター](capacity-planning.html)を変更する。
- レジャーストアーに[RocksDBの代わりにNuDB](capacity-planning.html)を使用する。
- [指示による削除を使用してオンライン削除をスケジュールする](configure-advisory-deletion.html)。
## 関連項目
- [オンライン削除](online-deletion.html)
- [指示による削除の設定](configure-advisory-deletion.html)
- [履歴シャーディングの設定](configure-history-sharding.html)
- [完全な履歴の設定](configure-full-history.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

90
content/infrastructure/rippled/configuration/configure-online-deletion.md Normal file
View File

@@ -0,0 +1,90 @@
---
html: configure-online-deletion.html
parent: data-retention.html
blurb: Configure how far back your server should store transaction history.
labels:
- Core Server
- Data Retention
---
# Configure Online Deletion
In its default configuration, [the `rippled` server](xrpl-servers.html) [deletes history](online-deletion.html) older than the most recent 2000 [ledger versions](ledgers.html), keeping approximately 15 minutes of [ledger history](ledger-history.html) (based on the current rate between ledgers). This page describes how to configure the amount of history your `rippled` server stores before deleting.
## Prerequisites
This tutorial assumes your server meets the following prerequisites:
- You are on a supported operating system: Ubuntu Linux, Red Hat Enterprise Linux (RHEL), or CentOS.
- The `rippled` server is already [installed](install-rippled.html) and [online deletion](online-deletion.html) is enabled.
If you followed the installation instructions for a recommended platform, online deletion is enabled by default.
- Your server has [enough disk space](capacity-planning.html#disk-space) to store your chosen amount of history in its ledger store.
## Configuration Steps
To change the amount of history your server stores, perform the following steps:
1. Decide how many ledger versions' worth of history to store.
New ledger versions are usually validated 3 to 4 seconds apart, so the number of ledger versions corresponds roughly to the amount of time you want to store. See [Capacity Planning](capacity-planning.html) for details of how much storage is required for different configurations.
Online deletion is based on how many ledger versions to keep _after_ deleting history, so you should have enough disk space to store twice as many ledgers as you set it to keep.
0. In your `rippled`'s config file, edit the `online_delete` field of the `[node_db]` stanza.
[node_db]
# Other settings unchanged ...
online_delete=2000
advisory_delete=0
Set `online_delete` to the minimum number of ledger versions to keep after running online deletion. With automatic deletion (the default), the server typically runs deletion when it has accumulated about twice this many ledger versions.
{% include '_snippets/conf-file-location.md' %}<!--_ -->
0. Start (or restart) the `rippled` service.
$ sudo systemctl restart rippled
0. Wait for your server to sync to the network.
Depending on your network and system capabilities and how long your server was offline, it may take between 5 and 15 minutes to fully sync.
When your server is synced with the network, the [server_info method][] reports a `server_state` value of `"full"`, `"proposing"`, or `"validating"`.
0. Periodically check your server's `complete_ledgers` range using the [server_info method][] to confirm that ledgers are being deleted.
After online deletion runs, the `complete_ledgers` range reflects that older ledgers are no longer available. As your server accumulates history, the total number of ledgers available should slowly increase to twice the `online_delete` value you configured, then decrease when online deletion runs.
0. Monitor your `rippled` logs for messages that begin with `SHAMapStore::WRN`. This can indicate that [online deletion is being interrupted](online-deletion.html#interrupting-online-deletion) because your server fell out of sync with the network.
If this happens regularly, your server may not have sufficient specifications to keep up with the ledger while running online deletion. Check that other services on the same hardware (such as scheduled backups or security scans) aren't competing with the `rippled` server for resources. You may want to try any of the following:
- Increase your system specs. See [System Requirements](system-requirements.html) for recommendations.
- Change your configuration to store less history. (Step 2 of this tutorial)
- Change your server's [`node_size` parameter](capacity-planning.html).
- Use [NuDB instead of RocksDB](capacity-planning.html) for the ledger store.
- [Schedule online deletion using Advisory Deletion](configure-advisory-deletion.html).
## See Also
- **Concepts:**
- [Ledger History](ledger-history.html)
- [Online Deletion](online-deletion.html)
- **Tutorials:**
- [Configure Advisory Deletion](configure-advisory-deletion.html)
- [Configure History Sharding](configure-history-sharding.html)
- [Capacity Planning](capacity-planning.html)
- **References:**
- [server_info method][]
- [Ledger Data Formats](ledger-data-formats.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

66
content/infrastructure/rippled/configuration/configure-statsd.md Normal file
View File

@@ -0,0 +1,66 @@
---
html: configure-statsd.html
parent: configure-rippled.html
blurb: Monitor your rippled server with StatsD metrics.
labels:
- Core Server
---
# Configure StatsD
`rippled` can export health and behavioral information about itself in [StatsD](https://github.com/statsd/statsd) format. Those metrics can be consumed and visualized through [`rippledmon`](https://github.com/ripple/rippledmon) or any other collector that accepts StatsD formatted metrics.
## Configuration Steps
To enable StatsD on your `rippled` server, perform the following steps:
1. Set up a `rippledmon` instance on another machine to receive and aggregate stats.
$ git clone https://github.com/ripple/rippledmon.git
$ cd rippledmon
$ docker-compose up
Make sure [Docker](https://docs.docker.com/) and [Docker Compose](https://docs.docker.com/compose/install/) are installed on your machine when performing the steps above. For more information about configuring `rippledmon`, see the [`rippledmon` repository](https://github.com/ripple/rippledmon).
0. Add the `[insight]` stanza to your `rippled`'s config file.
[insight]
server=statsd
address=192.0.2.0:8125
prefix=my_rippled
- For the `address`, use the IP address and port where `rippledmon` is listening. By default, this port is 8125.
- For the `prefix`, choose a name that identifies the `rippled` server you are configuring. The prefix must not include whitespace, colons ":", or the vertical bar "|". The prefix appears on all of the StatsD metrics exported from this server.
{% include '_snippets/conf-file-location.md' %}<!--_ -->
0. Restart the `rippled` service.
$ sudo systemctl restart rippled
0. Check that the metrics are being exported:
$ tcpdump -i en0 | grep UDP
Replace `en0` with the appropriate network interface for your machine. For a complete list of the interfaces on your machine use `$ tcpdump -D`.
Sample Output:
00:41:53.066333 IP 192.0.2.2.63409 > 192.0.2.0.8125: UDP, length 196
You should periodically see messages indicating outbound traffic to the configured address and port of your `rippledmon` instance.
For descriptions of each StatsD metric, see the [`rippledmon` repository](https://github.com/ripple/rippledmon).
## See Also
- **Concepts:**
- [XRP Ledger Overview](xrp-ledger-overview.html)
- [The `rippled` Server](xrpl-servers.html)
- **Tutorials:**
- [Install `rippled`](install-rippled.html)
- [Capacity Planning](capacity-planning.html)
- **References:**
- [server_info method](server_info.html)
- [print method](print.html)

114
content/infrastructure/rippled/configuration/connect-your-rippled-to-the-xrp-test-net.ja.md Normal file
View File

@@ -0,0 +1,114 @@
---
html: connect-your-rippled-to-the-xrp-test-net.html
parent: configure-rippled.html
blurb: rippledサーバーをTest Netに接続して、模造の資金を使って新しい機能を試したり、機能をテストしたりします。
labels:
- コアサーバー
- ブロックチェーン
- 開発
---
# XRPL Altnetへのrippledの接続
Rippleは[代替となるテスト用および開発用ネットワーク](parallel-networks.html)を作成しており、開発者が最新のXRP Ledgerの非本番バージョン（Testnet）でアプリケーションをテストしたり、最新のベータバージョン（Devnet）で機能をテストして実験したりできるようにしています。 **これらのネットワークで使用する資金は実際の資金ではなく、テスト専用の資金です。** TestnetまたはDevnetの[`rippled`サーバー](xrpl-servers.html)に接続できます。
**注記:** XRP TestnetとDevnetのレジャーと残高は定期的にリセットされます。
`rippled`サーバーをXRP TestnetまたはDevnetに接続するには、以下の構成を設定します。
1. `rippled.cfg`ファイルで以下の手順に従います。
a. [Testnet](xrp-testnet-faucet.html)に接続するには、以下のセクションのコメントを解除し、次のように追加します。
[ips]
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ファイルに追加します。
[validator_list_sites]
https://vl.devnet.rippletest.net/index.json
[validator_list_keys]
EDDF2F53DFEC79358F7BE76BC884AC31048CFF6E2A00C628EAE06DB7750A247B12
3. `rippled`を再起動します。
4. `rippled`がXRP TestnetまたはDevnetに接続していることを確認するため、サーバーで[server_infoメソッド][]を使用して、その結果をTestnetまたはDevnetの公開サーバーの結果と比較します。両方のサーバーで`validated_ledger`オブジェクトの`seq`フィールドが同一である必要があります（確認中にこの数が変化した場合は、1～2の差が生じる可能性があります）。
以下のコマンドは、ローカルの`rippled`の最新検証済みレジャーインデックスをチェックします。
$ ./rippled server_info | grep seq
[WebSocket Toolのserver_info](websocket-api-tool.html#server_info)でネットワークのレジャーインデックスをチェックします。
## 関連項目
- **ツール:**
- [XRP Faucet](xrp-testnet-faucet.html)
- [WebSocket APIツール](websocket-api-tool.html) - 接続オプションで「Testnet公開サーバー」を選択します。
- **コンセプト:**
- [並列ネットワーク](parallel-networks.html)
- [コンセンサスについて](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' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

234
content/infrastructure/rippled/configuration/connect-your-rippled-to-the-xrp-test-net.md Normal file
View File

@@ -0,0 +1,234 @@
---
html: connect-your-rippled-to-the-xrp-test-net.html
parent: configure-rippled.html
blurb: Connect your rippled server to the test net to try out new features or test functionality with fake money.
labels:
- Core Server
- Blockchain
- Development
---
# Connect Your rippled to a Parallel Network
Various [alternative test and development networks](parallel-networks.html) exist for developers to test their apps or experiment with features without risking real money. **The funds used on these networks are not real funds and are intended for testing only.** You can connect your [`rippled` server](xrpl-servers.html) to any of these test networks.
**Caution:** On test networks with new and experimental features, you may need to run a pre-production release of the server to sync with the network. See the [Parallel Networks Page](parallel-networks.html) for information on what code version each network needs.
## Steps
To connect your `rippled` server to the XRP Testnet or Devnet, complete these steps. You can also use these steps to switch back to the production Mainnet after being on the Testnet or Devnet.
## 1. Configure your server to connect to the right hub.
Edit your `rippled.cfg` file.
{% include '_snippets/conf-file-location.md' %}
<!--{_ }-->
1. Set an `[ips]` stanza with the hub for the network you want to connect to:
<!-- MULTICODE_BLOCK_START -->
*Testnet*
[ips]
s.altnet.rippletest.net 51235
*Devnet*
[ips]
s.devnet.rippletest.net 51235
*Mainnet*
# No [ips] stanza. Use the default hubs to connect to Mainnet.
*AMM-Devnet*
[ips]
amm.devnet.rippletest.net 51235
<!-- MULTICODE_BLOCK_END -->
2. Comment out the previous `[ips]` stanza, if there is one:
# [ips]
# r.ripple.com 51235
# zaphod.alloy.ee 51235
# sahyadri.isrdc.in 51235
3. Add a `[network_id]` stanza with the appropriate value:
<!-- MULTICODE_BLOCK_START -->
*Testnet*
[network_id]
testnet
*Devnet*
[network_id]
devnet
*Mainnet*
[network_id]
main
*AMM-Devnet*
[network_id]
25
<!-- MULTICODE_BLOCK_END -->
For custom networks, everyone who connects to the network should use a value unique to that network. When creating a new network, choose a network ID at random from the integers 11 to 4,294,967,295.
**Note:** This setting helps your server find peers who are on the same network, but it is not a hard control on what network your server follows. The UNL / trusted validator settings (in the next step) are what actually define what network the server follows.
## 2. Set your trusted validator list.
Edit your `validators.txt` file. This file is located in the same folder as your `rippled.cfg` file and defines which validators your server trusts not to collude.
1. Uncomment or add the `[validator_list_sites]` and `[validator_list_keys]` stanzas for the network you want to connect to:
<!-- MULTICODE_BLOCK_START -->
*Testnet*
[validator_list_sites]
https://vl.altnet.rippletest.net
[validator_list_keys]
ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
*Devnet*
[validator_list_sites]
https://vl.devnet.rippletest.net
[validator_list_keys]
EDDF2F53DFEC79358F7BE76BC884AC31048CFF6E2A00C628EAE06DB7750A247B12
*Mainnet*
[validator_list_sites]
https://vl.ripple.com
[validator_list_keys]
ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
*AMM-Devnet*
[validator_list_sites]
http://vlamm.devnet.rippletest.net/
[validator_list_keys]
03553F67DC5A6FE0EBFE1B3B4742833D14AF7C65E79E5760EC76EC56EAFD254CE9
<!-- MULTICODE_BLOCK_END -->
**Tip:** Preview packages might come with the necessary stanzas pre-configured, but check them just in case.
1. Comment out any previous `[validator_list_sites]`, `[validator_list_keys]`, or `[validators]` stanzas.
For example:
# [validator_list_sites]
# https://vl.ripple.com
#
# [validator_list_keys]
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
# Old hard-coded List of Devnet Validators
# [validators]
# n9Mo4QVGnMrRN9jhAxdUFxwvyM4aeE1RvCuEGvMYt31hPspb1E2c
# n9MEwP4LSSikUnhZJNQVQxoMCgoRrGm6GGbG46AumH2KrRrdmr6B
# n9M1pogKUmueZ2r3E3JnZyM3g6AxkxWPr8Vr3zWtuRLqB7bHETFD
# n9MX7LbfHvPkFYgGrJmCyLh8Reu38wsnnxA4TKhxGTZBuxRz3w1U
# n94aw2fof4xxd8g3swN2qJCmooHdGv1ajY8Ae42T77nAQhZeYGdd
# n9LiE1gpUGws1kFGKCM9rVFNYPVS4QziwkQn281EFXX7TViCp2RC
# n9Jq9w1R8UrvV1u2SQqGhSXLroeWNmPNc3AVszRXhpUr1fmbLyhS
## 3. Enable (or Disable) Features
For some test networks using experimental features, you must also forcefully enable the appropriate feature in the config file. For other networks, you should not use the `[features]` stanza. Add or modify the `[features]` stanza of your config file as follows:
<!-- MULTICODE_BLOCK_START -->
_Testnet_
```
# [features]
# Delete or comment out. Don't force-enable features on Testnet.
```
_Devnet_
```
# [features]
# Delete or comment out. Don't force-enable features on Devnet.
```
_Mainnet_
```
# [features]
# Delete or comment out. Don't force-enable features on Mainnet.
```
_AMM-Devnet_
```
[features]
AMM
```
<!-- MULTICODE_BLOCK_END -->
**Warning:** Do not use the `[features]` stanza when connecting to Mainnet or Testnet. Forcefully enabling different features than the rest of the network could cause your server to diverge from the network.
## 4. Restart the server.
```sh
$ sudo systemctl restart rippled
```
## 5. Verify that your server syncs.
It takes about 5 to 15 minutes to sync to the network after a restart. After your server is synced, the [server_info method][] shows a `validated_ledger` object based on the network you are connected to.
To confirm that your `rippled` is connected to the right network, compare the results from your server to [a public server][public servers] on the Testnet or Devnet. The `seq` field of the `validated_ledger` object should be the same on both servers (possibly off by one or two, if it changed as you were checking).
The following example shows how to check your server's latest validated ledger from the commandline:
```sh
rippled server_info | grep seq
```
You can use [server_info in the WebSocket Tool](websocket-api-tool.html#server_info) to look up the latest ledger index (`seq`) on the intended network.
## See Also
- **Tools:**
- [XRP Faucets](xrp-testnet-faucet.html)
- [WebSocket API Tool](websocket-api-tool.html) - Select 'Testnet Public Server' or 'Devnet Public Server' in the connection options.
- **Concepts:**
- [Parallel Networks](parallel-networks.html)
- [Consensus](consensus.html)
- **Tutorials:**
- [Run rippled as a Validator](run-rippled-as-a-validator.html)
- [Test `rippled` Offline in Stand-Alone Mode](use-stand-alone-mode.html)
- [Troubleshooting `rippled`](troubleshoot-the-rippled-server.html)
- **References:**
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

44
content/infrastructure/rippled/configuration/enable-public-signing.ja.md Normal file
View File

@@ -0,0 +1,44 @@
---
html: enable-public-signing.html
parent: configure-rippled.html
blurb: 他の人があなたのサーバーを使ってトランザクションに署名できるようにします。（非推奨）
labels:
- コアサーバー
- セキュリティ
---
# パブリック署名の有効化
[新規: rippled 1.1.0][]デフォルトでは、`rippled`の署名メソッドは管理者接続に限定されています。v1.1.0以前のバージョンの`rippled`のように、署名メソッドをパブリックAPIメソッドとして使用できるようにするには、構成を変更することで、これを使用できるようにします。
これにより、サーバーが「パブリック」[JSON-RPC接続およびWebSocket接続](get-started-using-http-websocket-apis.html)を受け入れる場合は、これらのパブリック接続で以下のメソッドが使用できるようになります。
- [sign][signメソッド]
- [sign_for][sign_forメソッド]
- [submit][submitメソッド](in "sign-and-submit" mode)
これらのメソッドを使用するにあたり、管理者接続からパブリック署名を有効にする必要は**ありません**。
**注意:** パブリック署名を有効にすることは推奨されません。[wallet_proposeメソッド][]と同様に、署名コマンドでは管理レベルの権限を必要とするアクションは実行されませんが、署名コマンドを管理者接続に制限することにより、ユーザーが安全ではない通信経由で、またはユーザーの管理下にないサーバーとの間でシークレットキーを無責任に送受信することを防止します。
パブリック署名を有効にするには、以下の手順を実行します。
1. `rippled`の構成ファイルを編集します。
vim /etc/opt/ripple/rippled.cfg
{% include '_snippets/conf-file-location.md' %}<!--_ -->
2. 以下のスタンザを構成ファイルに追加し、変更を保存します。
[signing_support]
true
3. `rippled`サーバーを再起動します。
systemctl restart rippled
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

58
content/infrastructure/rippled/configuration/enable-public-signing.md Normal file
View File

@@ -0,0 +1,58 @@
---
html: enable-public-signing.html
parent: configure-rippled.html
blurb: Allow others to use your server to sign transactions. (Not recommended)
labels:
- Core Server
- Security
---
# Enable Public Signing
By default, the signing methods for [`rippled`](xrpl-servers.html) are limited to [administrative connections](admin-api-methods.html). If you want to allow signing methods to be used as public API methods (like with versions of `rippled` before v1.1.0), you can enable it with a configuration change. [New in: rippled 1.1.0][]
This enables the following methods to be used on "public" [JSON-RPC and WebSocket connections](get-started-using-http-websocket-apis.html), if your server accepts them:
- [sign][sign method]
- [sign_for][sign_for method]
- [submit][submit method] (in "sign-and-submit" mode)
You **do not** need to enable public signing to use these methods from an admin connection.
**Caution:** Ripple does not recommend enabling public signing. Like the [wallet_propose method][], the signing commands do not perform any actions that would require administrative-level permissions, but restricting them to admin connections protects users from irresponsibly sending or receiving secret keys over unsecured communications, or to servers they do not control.
To enable public signing, perform the following steps:
1. Edit your `rippled`'s config file.
vim /etc/opt/ripple/rippled.cfg
{% include '_snippets/conf-file-location.md' %}<!--_ -->
2. Add the following stanza to your config file, and save the changes:
[signing_support]
true
3. Restart your `rippled` server:
systemctl restart rippled
## See Also
- **Concepts:**
- [Transactions](transactions.html)
- [Cryptographic Keys](cryptographic-keys.html)
- **Tutorials:**
- [Set Up Secure Signing](secure-signing.html)
- [Get Started Using HTTP / WebSocket APIs](get-started-using-http-websocket-apis.html)
- [Get Started Using JavaScript](get-started-using-javascript.html)
- **References:**
- [sign method][]
- [sign_for method][]
- [submit method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

55
content/infrastructure/rippled/configuration/run-rippled-as-a-stock-server.md Normal file
View File

@@ -0,0 +1,55 @@
---
html: run-rippled-as-a-stock-server.html
parent: server-modes.html
blurb: A multipurpose configuration for anyone integrating XRP.
labels:
- Core Server
---
# Run rippled as a Stock Server
A stock server is a multipurpose configuration for `rippled`. With a stock server, you can submit transactions to the XRP Ledger, access ledger history, and use the latest [tools](software-ecosystem.html) to integrate with XRP and the XRP Ledger. You can connect client applications to the XRP Ledger using this server.
A stock server does all of the following:
- Connects to a [network of peers](peer-protocol.html)
- Relays cryptographically signed [transactions](transactions.html)
- Maintains a local copy of the complete shared global [ledger](ledgers.html)
To participate in the [consensus process](consensus.html) as a validator, [run rippled as a validator](run-rippled-as-a-validator.html) instead.
## Install and run `rippled`
The default package installation installs a stock server with a small amount of transaction history. For installation steps, see [Install `rippled`](install-rippled.html).
After installation, you can adjust how much history your server stores at a time. For steps on how to do this, see [Configure Online Deletion](configure-online-deletion.html).
## Troubleshooting
For more information, see [Troubleshooting `rippled`](troubleshoot-the-rippled-server.html)
## See Also
- **Concepts:**
- [XRP Ledger Overview](xrp-ledger-overview.html)
- [The `rippled` Server](xrpl-servers.html)
- **Tutorials:**
- [Cluster rippled Servers](cluster-rippled-servers.html)
- [Install `rippled`](install-rippled.html)
- [Capacity Planning](capacity-planning.html)
- **References:**
- [Validator Keys Tool Guide](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)
- [consensus_info method][]
- [validator_list_sites method][]
- [validators method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

311
content/infrastructure/rippled/configuration/run-rippled-as-a-validator.ja.md Normal file
View File

@@ -0,0 +1,311 @@
---
html: run-rippled-as-a-validator.html
parent: server-modes.html
blurb: サーバーがコンセンサスレジャーで投票できるようにします。
labels:
- コアサーバー
- ブロックチェーン
top_nav_grouping: 人気ページ
top_nav_name: UNLに参加しよう
---
# バリデータとしてのrippledの実行
[バリデータモード](rippled-server-modes.html)で実行されている[`rippled`サーバー](xrpl-servers.html)は、ストックサーバーが実行するあらゆる処理を実行します。
- [ピアのネットワーク](peer-protocol.html)への接続
- 暗号署名された[トランザクション](transactions.html)の中継
- 完全な共有グローバル[レジャー](ledgers.html)のローカルコピーの維持
バリデータが _特異である_ のは、検証メッセージも発行するという点です。これらのメッセージは、[コンセンサスプロセス](consensus-principles-and-rules.html#コンセンサスの仕組み)の進行中、XRP Ledgerネットワークによる評価の対象となる候補のトランザクションです。
ただし、単に検証メッセージを発行するだけで、バリデータにコンセンサスプロセスでの発言権が自動的に付与されるわけではありません。他のサーバーがバリデータ（モードのサーバー）を彼らのユニークノードリスト（UNL）に追加しない限り、彼らは（バリデータモードのサーバーからの）検証メッセージを無視します。バリデータがUNLに含まれている場合、 _信頼できる_ バリデータであり、その提案は、信頼する側のサーバーによってコンセンサスプロセスで検討されます。
バリデータが _信頼できる_ バリデータではない場合も、ネットワークの全体的な健全性に関して、重要な役割を果たすことに変わりはありません。これらのバリデータは、信頼できるバリデータを評価するための基準の確立を支援します。例えば、信頼できるバリデータが、UNLに含まれていない多数のバリデータに対して異議を唱えている場合、問題があることを示しているおそれがあります。
## 1. 優れたバリデータの特徴の理解
バリデータ（サーバー）が以下の特質を常に備えるよう努めます。優れたバリデータであることは、`rippled`サーバーの運用者や[https://vl.ripple.com](https://vl.ripple.com)などのバリデータリスト発行者が、バリデータを彼らのUNLに追加する際に、バリデータを信頼する上で後押しになります。
- **可用性**
優れたバリデータは、常に稼働し、提案されるあらゆるレジャーについて検証投票を送信します。100%のアップタイムを実現するよう努めてください。
- **合意**
優れたバリデータの投票は、可能な限り高い頻度で、コンセンサスプロセスの結果と合致します。これに該当しない場合は、バリデータのソフトウェアが最新のものではないか、不具合があるか、意図的な偏りがあることを示唆している可能性があります。常に[最新の`rippled`リリース](https://github.com/ripple/rippled/tree/master)を、修正を加えることなく実行します。新規リリースについて知るために、[`rippled`のリリースを確認](https://github.com/ripple/rippled/releases)してください。
- **適時の投票**
優れたバリデータの投票は、コンセンサスラウンドが終了する前に、素早く届きます。適時の投票を維持するには、バリデータが推奨される[システム要件](system-requirements.html)を満たしていることを確認してください。これには、高速のインターネット接続が含まれます。
- **身元の確さ**
優れたバリデータには、身元が明確な所有者が存在します。[ドメイン検証](#6-ドメイン検証の提供)を提供することは、その第一歩になります。XRP LedgerネットワークのUNLに、多くの法的な管轄域および地域のさまざまな所有者によって運営されているバリデータが含まれていると理想的です。結果として、信頼できるバリデータの公正な運用が地域特有の事象によって損なわれるおそれが低減されます。
Ripple社は、推奨される一連のバリデータを記載した[バリデータリスト](https://github.com/ripple/rippled/blob/develop/cfg/validators-example.txt)を公開しています。本番環境のサーバーでは、このリストを使用することを強くお勧めします。
## 2. `rippled`サーバーのインストール
詳細は、[`rippled`のインストール](install-rippled.html)を参照してください。
## 3. `rippled`サーバーで検証を有効化
`rippled`サーバーで検証を有効にすることは、サーバーの`rippled.cfg`ファイルにあるバリデータトークンを提供することを意味します。バリデータキーとトークンを安全に生成して管理するために、`validator-keys`ツール（`rippled` RPMに含まれる）を使用することをお勧めします。
バリデータ（サーバー）**以外の**場所で、以下の手順に従います。
1. `validator-keys`ツールを`rippled` RPMを通じてまだインストールしていない場合は、手動でビルドして実行します。
`validator-keys`ツールを手動でビルドして実行する方法については、[validator-keys-tool](https://github.com/ripple/validator-keys-tool)を参照してください。
2. `create_keys`コマンドを使用して、バリデータキーペアを生成します。
$ validator-keys create_keys
Ubuntuでの出力の例:
Validator keys stored in /home/my-user/.ripple/validator-keys.json
This file should be stored securely and not shared.
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)を参照してください。
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_token]
eyJ2YWxpZGF0aW9uX3NlY3J|dF9rZXkiOiI5ZWQ0NWY4NjYyNDFjYzE4YTI3NDdiNT
QzODdjMDYyNTkwNzk3MmY0ZTcxOTAyMzFmYWE5Mzc0NTdmYT|kYWY2IiwibWFuaWZl
c3QiOiJKQUFBQUFGeEllMUZ0d21pbXZHdEgyaUNjTUpxQzlnVkZLaWxHZncxL3ZDeE
hYWExwbGMyR25NaEFrRTFhZ3FYeEJ3RHdEYklENk9NU1l1TTBGREFscEFnTms4U0tG
bjdNTzJmZGtjd1JRSWhBT25ndTlzQUtxWFlvdUorbDJWMFcrc0FPa1ZCK1pSUzZQU2
hsSkFmVXNYZkFpQnNWSkdlc2FhZE9KYy9hQVpva1MxdnltR21WcmxIUEtXWDNZeXd1
NmluOEhBU1FLUHVnQkQ2N2tNYVJGR3ZtcEFUSGxHS0pkdkRGbFdQWXk1QXFEZWRGdj
VUSmEydzBpMjFlcTNNWXl3TFZKWm5GT3I3QzBrdzJBaVR6U0NqSXpkaXRROD0ifQ==
バリデータ（サーバー）で、以下の手順に従います。
1. `[validator_token]`とその値を、バリデータの`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**_ にする必要があります。
**セキュリティのヒント:** `rippled.cfg`ファイルに対する権限をより制限的なものに変更します。Linuxでは、`0600`にすることを推奨します。`chmod 0600 rippled.cfg`を使用して変更できます。
## 4. ネットワークへの接続
このセクションでは、バリデータをXRP Ledgerネットワークに接続するために使用できる3種類の構成について説明します。ユースケースに最適な構成を使用してください。
- [検出されたピア](#検出されたピアを使用した接続): ピアツーピアネットワーク内の任意のサーバーに接続します。
- [プロキシ](#プロキシを使用した接続): ストック`rippled`サーバーを、バリデータとピアツーピアネットワークの他の部分との間のプロキシとして実行します。
- [公開ハブ](#公開ハブを使用した接続): 評価の高い特定の公開サーバーにのみ接続します。
これらのアプローチの違いについては、[ピア接続設定のメリットとデメリット](peer-protocol.html#ピア接続設定のメリットとデメリット)を参照してください。
### 検出されたピアを使用した接続
この構成では、[検出されたピア](peer-protocol.html#ピアの検出)を使用してバリデータをXRP Ledgerネットワークに接続します。これは`rippled`サーバーのデフォルトの動作です。
_**検出されたピアを使用してバリデータをXRP Ledgerネットワークに接続するには、**_ バリデータの`rippled.cfg`ファイルで`[peer_private]`スタンザを省略するか、それを`0`に設定します。この構成の[サンプルのrippled.cfgファイル](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg)が提供されています。
### プロキシを使用した接続
この構成は、自社で運用するストック`rippled`サーバーを通じてバリデータをネットワークに接続します。これらのプロキシサーバーは、バリデータと発着信ネットワークトラフィックの間に設置します。
_**プロキシを使用してバリデータを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 }-->
### 公開ハブを使用した接続
この構成では、2つの[公開ハブ](rippled-server-modes.html#公開ハブ)を使用してバリデータをネットワークに接続します。この構成は、[自社で運用しているプロキシを使用した接続](#プロキシを使用した接続)と似ていますが、公開ハブを通じて接続します。
_**公開ハブを使用してバリデータをネットワークに接続するには、次の手順を実行します。**_
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アドレスを公開しない。
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
## 5. ネットワーク接続の確認
ここでは、バリデータがXRP Ledgerネットワークへの健全な接続を保持していることを検証する方法をいくつか紹介します。
- [`peers`](peers.html)コマンドを使用して、バリデータに接続しているすべての`rippled`サーバーのリストを取得します。`peers`の配列が`null`である場合、ネットワークへの健全な接続が存在していません。このドキュメントの手順に従ってバリデータを設置した場合、`peers`の配列には、`[ips_fixed]`スタンザで定義されているピアの数と同数のオブジェクトが含まれています。
公開ハブを`[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の取得)を参照してください。
- [`validators`](validators.html)コマンドを使用して、バリデータによって使用される、公開済みかつ信頼できるバリデータの最新リストを取得します。`validator_list_expires`の値が、`never`（無期限）、期限が切れていない、または期限切れ間近のいずれかであることを確認してください。
## 6. ドメイン検証の提供
検証リスト発行者およびXRP Ledgerネットワーク内のその他の参加者がバリデータの運用元を把握しやすいようにするには、バリデータのドメイン検証を提供します。ドメイン検証とは、ハイレベルでは双方向リンクを指します。
- ドメインを使用して、バリデータキーの所有権を主張します。
- バリデータキーを使用して、ドメインの所有権を主張します。
このリンクを作成すると、バリデータキーとドメインの両方を所有しているという確固たる証拠が確立されます。この証拠を提供することは、[優れたバリデータであること](#1-優れたバリデータの特徴の理解)の側面の1つにすぎません。
ドメイン検証を提供するには、以下の手順に従います。
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)
出力の例:
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
出力の例:
E852C2FE725B64F353E19DB463C40B1ABB85959A63B8D09F72C6B6C27F80B6C72ED9D5ED6DC4B8690D1F195E28FF1B00FB7119C3F9831459F3C3DE263B73AC04
返された値を、Googleフォームの**Domain Signature**フィールドに入力します。
4. 記入したGoogleフォームを送信すると、ドメイン検証の成否を通知するメールがXRP Chartsから送信されます。ドメイン検証が成功した場合は、XRP Chartsの[バリデータレジストリー](https://xrpcharts.ripple.com/#/validators)にバリデータとドメインが表示されます。
<!--{ ***TODO: For the future - add a new section or separate document: "Operating a Trusted Validator" -- things that you need to be aware of once your validator has been added to a UNL and is participating in consensus. We should tell the user what to expect once they are listed in a UNL. How to tell if your validator is participating in the consensus process? How to tell if something isn't right with your validator - warning signs that they should look out for? How to tell if your validator has fallen out of agreement - what is the acceptable vs unacceptable threshold? Maybe provide a script that will alert them when something is going wrong.*** }-->
## バリデータキーの破棄
バリデータのマスター秘密鍵が漏えいした場合は、ただちに永続的に破棄する必要があります。
`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)
- [`rippled`サーバー](xrpl-servers.html)
- **チュートリアル:**
- [rippledサーバーのクラスター化](cluster-rippled-servers.html)
- [`rippled`のインストール](install-rippled.html)
- [容量の計画](capacity-planning.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' %}

285
content/infrastructure/rippled/configuration/run-rippled-as-a-validator.md Normal file
View File

@@ -0,0 +1,285 @@
---
html: run-rippled-as-a-validator.html
parent: server-modes.html
blurb: Have your server vote on the consensus ledger.
labels:
- Core Server
- Blockchain
top_nav_grouping: Popular Pages
top_nav_name: Join UNL
---
# Run rippled as a Validator
A [`rippled` server](xrpl-servers.html) running in [validator mode](rippled-server-modes.html) does everything a stock server does:
- Connects to a [network of peers](peer-protocol.html)
- Relays cryptographically signed [transactions](transactions.html)
- Maintains a local copy of the complete shared global [ledger](ledgers.html)
What makes a validator _different_ is that it also issues validation messages, which are sets of candidate transactions for evaluation by the XRP Ledger network during the [consensus process](consensus-principles-and-rules.html#how-consensus-works).
Issuing validation messages does not automatically give your validator a say in the consensus process, so the system is not vulnerable to a [Sybil attack](https://en.wikipedia.org/wiki/Sybil_attack). Other servers ignore your validation messages unless they add your validator to their Unique Node List (UNL). If your validator is included in a UNL, it is a _trusted_ validator and its proposals are considered in the consensus process by the servers that trust it.
Even if your validator isn't a _trusted_ validator, it stills plays an important role in the overall health of the network. These validators help set the standard that trusted validators are measured against. For example, if a trusted validator is disagreeing with a lot of these validators that aren't listed in UNLs, that might indicate a problem.
**Warning:** Validators should not be accessible to the public. Do not allow public WebSocket access to your validator server or any other form of public access.
## 1. Understand the traits of a good validator
Strive to have your validator embody the following properties. Being a good validator helps `rippled` server operators and validator list publishers (such as https://vl.ripple.com and https://vl.xrplf.org) trust your validator before adding it to their UNLs.
- **Available**
A good validator is always running and submitting validation votes for every proposed ledger. Strive for 100% uptime.
- **In agreement**
A good validator's votes match the outcome of the consensus process as often as possible. To do otherwise could indicate that your validator's software is outdated, buggy, or intentionally biased. Always run the [latest `rippled` release](https://github.com/XRPLF/rippled/tree/release) without modifications. [Watch `rippled` releases](https://github.com/XRPLF/rippled/releases) and subscribe to the [Google Group](https://groups.google.com/g/ripple-server) to be notified of new releases.
- **Issuing prompt votes**
A good validator's votes arrive quickly and not after a consensus round has already finished. To keep your votes on time, make sure your validator meets the recommended [system requirements](system-requirements.html), which include a fast internet connection.
It is possible to submit new transactions and query data using a validator, but heavy loads of API queries may make the validator less reliable at keeping up with consensus. If your API needs are light enough, then you can use a server for both purposes. Ideally, a validator should be dedicated to participating in consensus.
- **Identified**
A good validator has a clearly identified owner. Providing [domain verification](#6-provide-domain-verification) is a good start. Ideally, XRP Ledger network UNLs include validators run by different owners in multiple legal jurisdictions and geographic areas. This reduces the chance that any localized events could interfere with the impartial operations of trusted validators. <!-- STYLE_OVERRIDE: clearly -->
It is strongly recommended that operators use the list providers that are present in this [example file](https://github.com/XRPLF/rippled/blob/develop/cfg/validators-example.txt).
## 2. Install a `rippled` server
For more information, see [Install `rippled`](install-rippled.html).
## 3. Enable validation on your `rippled` server
Enabling validation on your `rippled` server means providing a validator token in your server's `rippled.cfg` file. You can use the `validator-keys` tool (included in `rippled` packages) to securely generate and manage your validator keys and tokens.
In a secure location **not** on your validator:
1. Manually build and run the `validator-keys` tool, if you don't already have it installed via a `rippled` RPM.
For information about manually building and running the `validator-keys` tool, see [validator-keys-tool](https://github.com/ripple/validator-keys-tool).
2. Generate a validator key pair using the `create_keys` command.
$ validator-keys create_keys
Sample output on Ubuntu:
Validator keys stored in /home/my-user/.ripple/validator-keys.json
This file should be stored securely and not shared.
Sample output on macOS:
Validator keys stored in /Users/my-user/.ripple/validator-keys.json
This file should be stored securely and not shared.
**Warning:** Store the generated `validator-keys.json` key file in a secure, offline, and recoverable location, such as an encrypted USB flash drive. Do not store keys on the validator where you intend to use the keys. If your `secret_key` is compromised, [revoke the key](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#key-revocation) immediately. Do not modify the contents of `validator-keys.json`, except to update the backup after generating a new token. If you generate more than one token from the same backup without updating, the network ignores the later tokens because they use the same `token_sequence` number.
For more information about the `validator-keys` tool and the key pairs it generates, see the [Validator Keys Tool Guide](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md).
3. Generate a validator token using the `create_token` command.
$ validator-keys create_token --keyfile /PATH/TO/YOUR/validator-keys.json
Sample output:
Update rippled.cfg file with these values:
# validator public key: nHUtNnLVx7odrz5dnfb2xpIgbEeJPbzJWfdicSkGyVw1eE5GpjQr
[validator_token]
eyJ2YWxpZGF0aW9uX3NlY3J|dF9rZXkiOiI5ZWQ0NWY4NjYyNDFjYzE4YTI3NDdiNT
QzODdjMDYyNTkwNzk3MmY0ZTcxOTAyMzFmYWE5Mzc0NTdmYT|kYWY2IiwibWFuaWZl
c3QiOiJKQUFBQUFGeEllMUZ0d21pbXZHdEgyaUNjTUpxQzlnVkZLaWxHZncxL3ZDeE
hYWExwbGMyR25NaEFrRTFhZ3FYeEJ3RHdEYklENk9NU1l1TTBGREFscEFnTms4U0tG
bjdNTzJmZGtjd1JRSWhBT25ndTlzQUtxWFlvdUorbDJWMFcrc0FPa1ZCK1pSUzZQU2
hsSkFmVXNYZkFpQnNWSkdlc2FhZE9KYy9hQVpva1MxdnltR21WcmxIUEtXWDNZeXd1
NmluOEhBU1FLUHVnQkQ2N2tNYVJGR3ZtcEFUSGxHS0pkdkRGbFdQWXk1QXFEZWRGdj
VUSmEydzBpMjFlcTNNWXl3TFZKWm5GT3I3QzBrdzJBaVR6U0NqSXpkaXRROD0ifQ==
On your validator:
1. Add `[validator_token]` and its value to your validator's `rippled.cfg` file.
If you previously configured your validator without the `validator-keys` tool, delete `[validation_seed]` and its value from your `rippled.cfg` file. This changes your validator public key.
2. Restart `rippled`.
$ sudo systemctl restart rippled.service
3. Use the `server_info` command to get information about your validator to verify that it is running as a validator.
$ rippled server_info
- The `pubkey_validator` value in the response should match the `public_key` in the `validator-keys.json` file that you generated for use with your validator.
- The `server_state` value should be _**proposing**_.
**Security Tip:** Change the permissions on your `rippled.cfg` file to be more restrictive. On Linux it is recommended to be `0600`. You can do this with `chmod 0600 rippled.cfg`
## 4. Connect to the network
This section describes three different configurations you can use to connect your validator to the XRP Ledger network. Use the configuration that best suits your use case.
- [Discovered peers](#connect-using-discovered-peers): Connect to any servers in the peer-to-peer network.
- [Proxies](#connect-using-proxies): Run stock `rippled` servers as proxies between your validator and the rest of the peer-to-peer network.
- [Public hubs](#connect-using-public-hubs): Connect only to specific public servers with a high reputation.
For a comparison of these approaches, see [Pros and Cons of Peering Configurations](peer-protocol.html#pros-and-cons-of-peering-configurations).
### Connect using discovered peers
This configuration connects your validator to the XRP Ledger network using [discovered peers](peer-protocol.html#peer-discovery). This is the default behavior for `rippled` servers.
_**To connect your validator to the XRP Ledger network using discovered peers,**_ omit the `[peer_private]` stanza or set it to `0` in your validator's `rippled.cfg` file. The [example `rippled.cfg` file](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg) is delivered with this configuration.
### Connect using proxies
This configuration connects your validator to the network through stock `rippled` servers that you run yourself. These proxy servers sit between your validator and inbound and outbound network traffic.
_**To connect your validator to the XRP Ledger network using proxies:**_
1. Set up stock `rippled` servers. For more information, see [Install rippled](install-rippled.html).
2. Configure your validator and stock `rippled` servers to run in a [cluster](cluster-rippled-servers.html).
3. In your validator's `rippled.cfg` file, set `[peer_private]` to `1`. This prevents your validator's IP address from being forwarded. For more information, see [Private Peers](peer-protocol.html#private-peers). It also prevents your validator from connecting to servers other than those defined in the `[ips_fixed]` stanza you defined to run your validator in a cluster.
**Warning:** Be sure that you don't publish your validator's IP address in other ways.
4. Configure your validator host machine's firewall to allow the following traffic only:
- Inbound traffic: Only from IP addresses of the stock `rippled` servers in the cluster you configured.
- Outbound traffic: Only to the IP addresses of the stock `rippled` servers in the cluster you configured and to your UNL list providers through port 443.
5. Restart `rippled`.
$ sudo systemctl restart rippled.service
6. Use the [Peer Crawler](peer-crawler.html) endpoint on one of your stock `rippled` servers. The response should not include your validator. This verifies that your validator's `[peer_private]` configuration is working. One of the effects of enabling `[peer_private]` on your validator is that your validator's peers do not include it in their Peer Crawler results.
$ 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 }-->
### Connect using public hubs
This configuration connects your validator to the network using three [public hubs](rippled-server-modes.html#public-hubs). This configuration is similar to [connecting using proxies you run yourself](#connect-using-proxies), but instead you connect through public hubs.
_**To connect your validator to the network using public hubs:**_
1. In your validator's `rippled.cfg` file, include the following `[ips_fixed]` stanza. The three values, `r.ripple.com 51235`, `zaphod.alloy.ee 51235` and `sahyadri.isrdc.in 51235`, are default public hubs. This stanza tells `rippled` to always attempt to maintain peer connections with these public hubs.
[ips_fixed]
r.ripple.com 51235
zaphod.alloy.ee 51235
sahyadri.isrdc.in 51235
**Caution:** This configuration connects your validator to the network using default public hubs. Because these are the _default_ public hubs, they may sometimes be too busy to provide your validator with a connection to the network. To help avoid this issue, connect to more public hubs and, even better, connect to non-default public hubs.
You can include the IP addresses of other `rippled` servers here, but _**only**_ if you can expect them to:
- Relay messages without censoring.
- Stay online consistently.
- Not DDoS you.
- Not try to crash your server.
- Not publish your IP address to strangers.
2. Also in your validator's `rippled.cfg` file, include the following `[peer_private]` stanza and set it to `1`. This instructs your validator’s peers not to broadcast your validator’s IP address. This setting also instructs your validator to connect to only the peers configured in your `[ips_fixed]` stanza. This ensures that your validator connects to and shares its IP with only peer `rippled` servers you know and trust.
[peer_private]
1
**Warning:** Be sure that you don't publish your validator's IP address in other ways.
With `[peer_private]` enabled, `rippled` ignores any connections suggested by the `[ips]` stanza. If you need to connect to an IP currently in your `[ips]` stanza, put it in the `[ips_fixed]` stanza instead, but _**only**_ if you can expect them to behave responsibly as described in step 1.
3. Restart `rippled`.
$ sudo systemctl restart rippled.service
## 5. Verify your network connection
Here are some methods you can use to verify that your validator has a healthy connection to the XRP Ledger network:
- Use the [`peers`](peers.html) command to return a list of all `rippled` servers currently connected to your validator. If the `peers` array is `null`, you don’t have a healthy connection to the network. If you've set up your validator using the instructions in this document, the `peers` array should include the same number of objects as the number of peers defined in your `[ips_fixed]` stanza.
If you listed a public hub in your `[ips_fixed]` stanza and it is busy, it may reject your validator's connection. In this case, you may end up with fewer connections than configured in your `[ips_fixed]` stanza. Your validator retries the connection if it's initially rejected.
If you are having trouble maintaining a reliable and safe connection to the network and haven't set up connections using public hubs or proxies, see [4. Connect to the network](#4-connect-to-the-network). Using one of the methods described in the section may help your validator remain healthily connected to the network.
- Use the [`server_info`](server_info.html) command to return some basic information about your validator. The `server_state` should be set to `proposing`. It may also be set to `full` or `validating`, but only for a few minutes before moving into `proposing`.
If the `server_state` does not spend the majority of its time set to `proposing`, it may be a sign that your validator is unable to fully participate in the XRP Ledger network. For more information about server states and using the `server_info` endpoint to diagnose issues with your validator, see [`rippled` Server States](rippled-server-states.html) and [Get the `server_info`](diagnosing-problems.html#get-the-server_info).
- Use the [`validators`](validators.html) command to return the current list of published and trusted validators used by the validator. Ensure that the `validator_list_expires` value is either `never` or not expired or about to expire.
## 6. Provide domain verification
To help validation list publishers and other participants in the XRP Ledger network understand who runs your validator, provide domain verification for your validator. At a high level, domain verification is a two-way link:
- Use your domain to claim ownership of a validator key.
- Use your validator key to claim ownership of a domain.
Creating this link establishes strong evidence that you own both the validator key and the domain. Providing this evidence is one aspect of [being a good validator](#1-understand-the-traits-of-a-good-validator).
To provide domain verification:
1. Choose a domain name you own that you want to be publicly associated with your validator. As a precaution against DDoS attempts, your domain name should not resolve to the ip address of your validator.
2. Serve an [`xrp-ledger.toml`](xrp-ledger-toml.html) file at your domain, and complete the [domain verification](xrp-ledger-toml.html#domain-verification) steps. Once you have completed these steps, your validator should be visible to the livenet [explorer](https://livenet.xrpl.org/network/validators) or any other site that monitors the validator network and supports decetralized domain verification.
3. Share your validator's public key with the public, especially other `rippled` operators. For example, you can share your validator's public key on your website, on social media, in the [XRPChat community forum](https://www.xrpchat.com/), or in a press release.
## Revoke validator keys
If your validator's master private key is compromised, you must revoke it immediately and permanently.
For information about how to revoke a master key pair you generated for your validator using the `validator-keys` tool, see [Key Revocation](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#key-revocation).
## See Also
- **Concepts:**
- [XRP Ledger Overview](xrp-ledger-overview.html)
- [The `rippled` Server](xrpl-servers.html)
- **Tutorials:**
- [Cluster rippled Servers](cluster-rippled-servers.html)
- [Install `rippled`](install-rippled.html)
- [Capacity Planning](capacity-planning.html)
- **References:**
- [Validator Keys Tool Guide](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)
- [consensus_info method][]
- [validator_list_sites method][]
- [validators method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

62
content/infrastructure/rippled/configuration/run-rippled-as-a-wallet-server.ja.md Normal file
View File

@@ -0,0 +1,62 @@
---
html: run-rippled-as-a-stock-server.html
parent: server-modes.html
blurb: XRPを統合する人のための汎用的な構成。
labels:
- コアサーバー
---
# ウォレットサーバーとしてrippledを実行する
ウォレットサーバーは `rippled` のための汎用的な構成です。ウォレットサーバーを利用することで、XRP Ledger へのトランザクションの送信、レジャーの履歴へのアクセス、XRP と統合するための最新の [ツール](software-ecosystem.html) を利用することができます。
ウォレットサーバーは、次のすべてのことを行います。
- [ピアネットワーク](peer-protocol.html)に接続
- 暗号署名された[トランザクション](transactions.html)を中継
- 完全な共有グローバル[レジャー](ledgers.html)のローカルコピーを維持
- [コンセンサスプロセス](consensus.html)にバリデーターとして参加
## 1. `rippled` のインストール
詳しくは、[`rippled` のインストール](install-rippled.html) を参照してください。
## 2. ウォレットサーバーでのバリデーションを有効にする
詳しくは、[rippledサーバーで検証を有効化](run-rippled-as-a-validator.html#3-enable-validation-on-your-rippled-server) を参照してください。
**注意:** バリデーターは、一般にアクセスできないようにする必要があります。ウォレットサーバーへのWebSocketアクセスなど、一般からのアクセスを許可しないでください。
## 3. ドメイン検証の提供
詳しくは、[ドメイン検証の提供](run-rippled-as-a-validator.html#6-provide-domain-verification)をご覧ください。
## トラブルシューティング
詳しくは、[`rippled`のトラブルシューティング](troubleshoot-the-rippled-server.html) を参照してください。
## 関連項目
- **コンセプト:**
- [XRP Ledgerの概要](xrp-ledger-overview.html)
- [`rippled`サーバー](xrpl-servers.html)
- **チュートリアル:**
- [rippledサーバーのクラスター化](cluster-rippled-servers.html)
- [`rippled`のインストール](install-rippled.html)
- [容量の計画](capacity-planning.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' %}

26
content/infrastructure/rippled/configuration/test-amendments.md Normal file
View File

@@ -0,0 +1,26 @@
---
html: test-amendments.html
parent: configure-rippled.html
blurb: You can test proposed amendments before they're enabled on the network.
labels:
- Blockchain
---
# Test Amendments
You can test how `rippled` behaves before proposed amendments are fully enabled on the production network. Since other members of the consensus network won't have the feature enabled, run your server in stand-alone mode.
**Caution:** This is intended for development purposes only.
To forcibly enable a feature, add a `[features]` stanza with amendment short names to your `rippled.cfg` file. Each amendment needs its own line.
<!-- MULTICODE_BLOCK_START -->
_Example_
```
[features]
MultiSign
TrustSetAuth
```
<!-- MULTICODE_BLOCK_END -->