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

Migrate content syntax via script

Browse Source 
The changes in this commit were auto-generated by running

tool/migrate.sh

Following this commit, the Dactyl build no longer works but the Redocly
build (mostly) should.
This commit is contained in:
mDuo13
2024-01-31 16:09:41 -08:00
parent 96121303b2
commit 554a3732d4
898 changed files with 19879 additions and 18631 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
content/infrastructure/commandline-usage.md
View File

@@ -65,10 +65,10 @@ Daemon mode is the default mode of operation for `rippled`. In addition to the [
| `--import` | Before fully starting, import ledger data from another `rippled` server's ledger store. Requires a valid `[import_db]` stanza in the config file. |
| `--newnodeid` | Generate a random node identity for the server. |
| `--nodeid {VALUE}` | Specify a node identity. `{VALUE}` can also be a parameter associated with the container or hardware running the server, such as `$HOSTNAME`. |
| `--nodetoshard` | Before fully starting, copy any complete [history shards](history-sharding.html) from the ledger store into the shard store, up to the shard store's configured maximum disk space. Uses large amounts of CPU and I/O. Caution: this command copies data (instead of moving it), so you must have enough disk space to store the data in both the shard store and the ledger store. <!--{# Task for writing a tutorial to use this: DOC-1639 #}--> |
| `--quorum {QUORUM}` | This option is intended for starting [test networks](parallel-networks.html). Override the minimum quorum for validation by requiring an agreement of `{QUORUM}` trusted validators. By default, the quorum for validation is automatically set to a safe number of trusted validators based on how many there are. If some validators are not online, this option can allow progress with a lower than normal quorum. **Warning:** If you set the quorum manually, it may be too low to prevent your server from diverging from the rest of the network. Only use this option if you have a deep understanding of consensus and have a need to use a non-standard configuration. |
| `--nodetoshard` | Before fully starting, copy any complete [history shards](configuration/data-retention/history-sharding.md) from the ledger store into the shard store, up to the shard store's configured maximum disk space. Uses large amounts of CPU and I/O. Caution: this command copies data (instead of moving it), so you must have enough disk space to store the data in both the shard store and the ledger store. <!--{# Task for writing a tutorial to use this: DOC-1639 #}--> |
| `--quorum {QUORUM}` | This option is intended for starting [test networks](../concepts/networks-and-servers/parallel-networks.md). Override the minimum quorum for validation by requiring an agreement of `{QUORUM}` trusted validators. By default, the quorum for validation is automatically set to a safe number of trusted validators based on how many there are. If some validators are not online, this option can allow progress with a lower than normal quorum. **Warning:** If you set the quorum manually, it may be too low to prevent your server from diverging from the rest of the network. Only use this option if you have a deep understanding of consensus and have a need to use a non-standard configuration. |
The following option has been removed: `--validateShards`. [Removed in: rippled 1.7.0][]
The following option has been removed: `--validateShards`. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.7.0" %}Removed in: rippled 1.7.0{% /badge %}
## Stand-Alone Mode Options
@@ -76,7 +76,7 @@ The following option has been removed: `--validateShards`. [Removed in: rippled
rippled --standalone [OPTIONS]
rippled -a [OPTIONS]
```
Run in [stand-alone mode](rippled-server-modes.html). In this mode, `rippled` does not connect to the network or perform consensus. (Otherwise, `rippled` runs in daemon mode.)
Run in [stand-alone mode](../concepts/networks-and-servers/rippled-server-modes.md). In this mode, `rippled` does not connect to the network or perform consensus. (Otherwise, `rippled` runs in daemon mode.)
## Initial Ledger Options
@@ -85,11 +85,11 @@ The following options determine which ledger to load first when starting up. The
| Option | Description |
|:----------------------|:-----------------------------------------------------|
| `--ledger {LEDGER}` | Load the ledger version identified by `{LEDGER}` (either a ledger hash or a ledger index) as the initial ledger. The specified ledger version must be in the server's ledger store. |
| `--ledgerfile {FILE}` | Load the ledger version from the specified `{FILE}`, which must contain a complete ledger in JSON format. For an example of such a file, see the provided [`ledger-file.json`]({{target.github_forkurl}}/blob/{{target.github_branch}}/content/_api-examples/rippled-cli/ledger-file.json). |
| `--ledgerfile {FILE}` | Load the ledger version from the specified `{FILE}`, which must contain a complete ledger in JSON format. For an example of such a file, see the provided {% repo-link path="content/_api-examples/rippled-cli/ledger-file.json" %}`ledger-file.json`{% /repo-link %}. |
| `--load` | Use only the ledger store on disk when loading the initial ledger. |
| `--net` | Use only data from the network when loading the initial ledger. |
| `--replay` | Use with `--ledger` to replay a specific ledger. Your server must have the ledger in question and its direct ancestor already in the ledger store. Using the previous ledger as a base, the server processes all the transactions in the specified ledger, resulting in a re-creation of the specified ledger. With a debugger, you can add breakpoints to analyze specific transaction processing logic. |
| `--start` | Start with a new genesis ledger that has known amendments enabled, based on their default votes. This makes the functionality of those amendments available right away, instead of needing to wait two weeks for the [Amendment Process](amendments.html). See also: [Start a New Genesis Ledger in Stand-Alone Mode](start-a-new-genesis-ledger-in-stand-alone-mode.html). |
| `--start` | Start with a new genesis ledger that has known amendments enabled, based on their default votes. This makes the functionality of those amendments available right away, instead of needing to wait two weeks for the [Amendment Process](../concepts/networks-and-servers/amendments.md). See also: [Start a New Genesis Ledger in Stand-Alone Mode](testing-and-auditing/start-a-new-genesis-ledger-in-stand-alone-mode.md). |
| `--valid` | Consider the initial ledger a valid network ledger even before fully syncing with the network. This can be used for starting networks or rolling back an entire network to a known previous state, as long as 80% of that network's validators load the same ledger at around the same time. |
## Client Mode Options
@@ -100,7 +100,7 @@ rippled [OPTIONS] -- {COMMAND} {COMMAND_PARAMETERS}
In client mode, the `rippled` executable acts as a client to another `rippled` service. (The service may be the same executable running in a separate process locally, or it could be a `rippled` server on another server.)
To run in client mode, provide the [commandline syntax](request-formatting.html#commandline-format) for one of the [`rippled` API](http-websocket-apis.html) methods.
To run in client mode, provide the [commandline syntax](../references/http-websocket-apis/api-conventions/request-formatting.md#commandline-format) for one of the [`rippled` API](../references/http-websocket-apis/index.md) methods.
Besides the individual commands, client mode accepts the [Generic Options](#generic-options) and the following options:
@@ -138,7 +138,7 @@ While running unit tests, you can specify the [Generic Options](#generic-options
| Option | Short Version | Description |
|:-----------------------------------|:--------------|:------------------------|
| `--unittest-ipv6` | | Use [IPv6](https://en.wikipedia.org/wiki/IPv6) to connect to the local server when running unit tests. If not provided, unit tests use IPv4 instead. [New in: rippled 1.1.0][] |
| `--unittest-ipv6` | | Use [IPv6](https://en.wikipedia.org/wiki/IPv6) to connect to the local server when running unit tests. If not provided, unit tests use IPv4 instead. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.1.0" %}New in: rippled 1.1.0{% /badge %} |
| `--unittest-jobs {NUMBER_OF_JOBS}` | | Use the specified number of processes to run unit tests. This can finish running tests faster on multi-core systems. The `{NUMBER_OF_JOBS}` should be a positive integer indicating the number of processes to use. |
| `--unittest-log` | | Allow unit tests to write to logs even if `--quiet` is specified. (No effect otherwise.) |
| `--quiet` | `-q` | Print fewer diagnostic messages when running unit tests. |
@@ -182,8 +182,4 @@ Certain manual unit tests accept an argument. You can provide the argument with
|:------------------------|:---------------------------------------------------|
| `--unittest-arg {ARG}` | Provide the argument `{ARG}` to the unit test(s) currently being run. Each unit test that accepts arguments defines its own argument format. |
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

27
content/infrastructure/configuration/configure-amendment-voting.md
View File

@@ -8,14 +8,13 @@ labels:
---
# 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).)
Servers configured as validators can vote on [amendments](../../concepts/networks-and-servers/amendments.md) to the XRP Ledger protocol using the [feature method][]. (This method requires [admin access](../../tutorials/get-started/get-started-using-http-websocket-apis.md#admin-access).)
For example, to vote against the "SHAMapV2" amendment, run the following command:
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
{% tabs %}
{% tab label="WebSocket" %}
```json
{
"id": "any_id_here",
@@ -24,9 +23,9 @@ For example, to vote against the "SHAMapV2" amendment, run the following command
"vetoed": true
}
```
{% /tab %}
*JSON-RPC*
{% tab label="JSON-RPC" %}
```json
{
"method": "feature",
@@ -38,14 +37,15 @@ For example, to vote against the "SHAMapV2" amendment, run the following command
]
}
```
{% /tab %}
*Commandline*
{% tab label="Commandline" %}
```sh
rippled feature SHAMapV2 reject
```
{% /tab %}
<!-- MULTICODE_BLOCK_END -->
{% /tabs %}
**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.
@@ -64,11 +64,8 @@ Be sure to restart your server for changes to take effect.
## See Also
- [Amendments](amendments.html)
- [Known Amendments](known-amendments.html)
- [Amendments](../../concepts/networks-and-servers/amendments.md)
- [Known Amendments](../../resources/known-amendments.md)
- [feature method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

35
content/infrastructure/configuration/configure-grpc.md
View File

@@ -7,7 +7,7 @@ labels:
---
# 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.
The `rippled` server has a limited [gRPC API](https://grpc.io/) which [P2P mode servers](../../concepts/networks-and-servers/rippled-server-modes.md) 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.
@@ -15,7 +15,7 @@ The `rippled` server has a limited [gRPC API](https://grpc.io/) which [P2P mode
To enable gRPC, you must meet the following prerequisites:
- You must have [installed rippled](install-rippled.html).
- You must have [installed rippled](../installation/index.md).
- Your server must be able to bind to the port you choose.
@@ -25,32 +25,33 @@ 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_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' %}
{% partial file="/_snippets/conf-file-location.md" /%}
2. Start (or restart) the `rippled` service.
sudo systemctl restart rippled
```
sudo systemctl restart rippled
```
## See Also
- **Concepts:**
- [XRP Ledger Overview](xrp-ledger-overview.html)
- [`rippled` Server Modes](rippled-server-modes.html)
- [XRP Ledger Overview](/about/)
- [`rippled` Server Modes](../../concepts/networks-and-servers/rippled-server-modes.md)
- **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)
- [Get Started Using HTTP / WebSocket APIs](../../tutorials/get-started/get-started-using-http-websocket-apis.md)
- [Reliable Transaction Submission](../../concepts/transactions/reliable-transaction-submission.md)
- [Manage the rippled Server](../installation/install-rippled-on-ubuntu.md)
- **References:**
- [HTTP / WebSocket API Reference](http-websocket-apis.html)
- [HTTP / WebSocket API Reference](../../references/http-websocket-apis/index.md)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

44
content/infrastructure/configuration/configure-statsd.md
View File

@@ -15,37 +15,47 @@ 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
```
$ 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
```
[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' %}<!--_ -->
{% partial file="/_snippets/conf-file-location.md" /%}
0. Restart the `rippled` service.
$ sudo systemctl restart rippled
```
$ sudo systemctl restart rippled
```
0. Check that the metrics are being exported:
$ tcpdump -i en0 | grep UDP
```
$ 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
```
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.
@@ -56,11 +66,11 @@ For descriptions of each StatsD metric, see the [`rippledmon` repository](https:
## See Also
- **Concepts:**
- [XRP Ledger Overview](xrp-ledger-overview.html)
- [The `rippled` Server](xrpl-servers.html)
- [XRP Ledger Overview](/about/)
- [The `rippled` Server](../../concepts/networks-and-servers/index.md)
- **Tutorials:**
- [Install `rippled`](install-rippled.html)
- [Capacity Planning](capacity-planning.html)
- [Install `rippled`](../installation/index.md)
- [Capacity Planning](../installation/capacity-planning.md)
- **References:**
- [server_info method](server_info.html)
- [print method](print.html)
- [server_info method](../../references/http-websocket-apis/public-api-methods/server-info-methods/server_info.md)
- [print method](../../references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/print.md)

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

@@ -9,9 +9,9 @@ labels:
---
# 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.
Various [alternative test and development networks](../../concepts/networks-and-servers/parallel-networks.md) 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](../../concepts/networks-and-servers/index.md) 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.
**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](../../concepts/networks-and-servers/parallel-networks.md) for information on what code version each network needs.
## Steps
@@ -21,66 +21,68 @@ To connect your `rippled` server to the XRP Testnet or Devnet, complete these st
Edit your `rippled.cfg` file.
{% include '_snippets/conf-file-location.md' %}
{% partial file="/_snippets/conf-file-location.md" /%}
<!--{_ }-->
1. Set an `[ips]` stanza with the hub for the network you want to connect to:
<!-- MULTICODE_BLOCK_START -->
{% tabs %}
*Testnet*
```{% label="Testnet" %}
[ips]
s.altnet.rippletest.net 51235
```
[ips]
s.altnet.rippletest.net 51235
```{% label="Devnet" %}
[ips]
s.devnet.rippletest.net 51235
```
*Devnet*
```{% label="Mainnet" %}
# No [ips] stanza. Use the default hubs to connect to Mainnet.
```
[ips]
s.devnet.rippletest.net 51235
```{% label="Sidechain-Devnet" %}
[ips]
sidechain-net2.devnet.rippletest.net 51235
```
*Mainnet*
# No [ips] stanza. Use the default hubs to connect to Mainnet.
*Sidechain-Devnet*
[ips]
sidechain-net2.devnet.rippletest.net 51235
<!-- MULTICODE_BLOCK_END -->
{% /tabs %}
2. Comment out the previous `[ips]` stanza, if there is one:
# [ips]
# r.ripple.com 51235
# zaphod.alloy.ee 51235
# sahyadri.isrdc.in 51235
```
# [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 -->
{% tabs %}
*Testnet*
```{% label="Testnet" %}
[network_id]
testnet
```
[network_id]
testnet
```{% label="Devnet" %}
[network_id]
devnet
```
*Devnet*
```{% label="Mainnet" %}
[network_id]
main
```
[network_id]
devnet
```{% label="Sidechain-Devnet" %}
[network_id]
262
```
*Mainnet*
[network_id]
main
*Sidechain-Devnet*
[network_id]
262
<!-- MULTICODE_BLOCK_END -->
{% /tabs %}
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.
@@ -92,42 +94,41 @@ Edit your `validators.txt` file. This file is located in the same folder as your
1. Uncomment or add the `[validator_list_sites]` and `[validator_list_keys]` stanzas for the network you want to connect to:
<!-- MULTICODE_BLOCK_START -->
{% tabs %}
*Testnet*
```{% label="Testnet" %}
[validator_list_sites]
https://vl.altnet.rippletest.net
[validator_list_sites]
https://vl.altnet.rippletest.net
[validator_list_keys]
ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
```
[validator_list_keys]
ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
```{% label="Devnet" %}
[validator_list_sites]
https://vl.devnet.rippletest.net
*Devnet*
[validator_list_keys]
EDDF2F53DFEC79358F7BE76BC884AC31048CFF6E2A00C628EAE06DB7750A247B12
```
[validator_list_sites]
https://vl.devnet.rippletest.net
```{% label="Mainnet" %}
[validator_list_sites]
https://vl.ripple.com
[validator_list_keys]
EDDF2F53DFEC79358F7BE76BC884AC31048CFF6E2A00C628EAE06DB7750A247B12
[validator_list_keys]
ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
```
```{% label="Sidechain-Devnet" %}
[validator_list_sites]
https://vlsidechain-net2.devnet.rippletest.net
*Mainnet*
[validator_list_keys]
EDA5504C7133743FADA46342229B4E9CBBE1CF9BCA19D16633574F7CBB72F79569
```
[validator_list_sites]
https://vl.ripple.com
[validator_list_keys]
ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
*Sidechain-Devnet*
[validator_list_sites]
https://vlsidechain-net2.devnet.rippletest.net
[validator_list_keys]
EDA5504C7133743FADA46342229B4E9CBBE1CF9BCA19D16633574F7CBB72F79569
<!-- MULTICODE_BLOCK_END -->
{% /tabs %}
**Tip:** Preview packages might come with the necessary stanzas pre-configured, but check them just in case.
@@ -135,57 +136,59 @@ Edit your `validators.txt` file. This file is located in the same folder as your
For example:
# [validator_list_sites]
# https://vl.ripple.com
#
# [validator_list_keys]
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
```
# [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
# 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_
{% tabs %}
{% tab label="Testnet" %}
```
# [features]
# Delete or comment out. Don't force-enable features on Testnet.
```
{% /tab %}
_Devnet_
{% tab label="Devnet" %}
```
# [features]
# Delete or comment out. Don't force-enable features on Devnet.
```
{% /tab %}
_Mainnet_
{% tab label="Mainnet" %}
```
# [features]
# Delete or comment out. Don't force-enable features on Mainnet.
```
{% /tab %}
_Sidechain-Devnet_
{% tab label="Sidechain-Devnet" %}
```
[features]
XChainBridge
```
{% /tab %}
<!-- MULTICODE_BLOCK_END -->
{% /tabs %}
**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.
@@ -207,28 +210,23 @@ The following example shows how to check your server's latest validated ledger f
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.
You can use [server_info in the WebSocket Tool](/resources/dev-tools/websocket-api-tool#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.
- [XRP Faucets](/resources/dev-tools/xrp-faucets)
- [WebSocket API Tool](/resources/dev-tools/websocket-api-tool) - Select 'Testnet Public Server' or 'Devnet Public Server' in the connection options.
- **Concepts:**
- [Parallel Networks](parallel-networks.html)
- [Consensus](consensus.html)
- [Parallel Networks](../../concepts/networks-and-servers/parallel-networks.md)
- [Consensus](../../concepts/consensus-protocol/index.md)
- **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)
- [Run rippled as a Validator](server-modes/run-rippled-as-a-validator.md)
- [Test `rippled` Offline in Stand-Alone Mode](../testing-and-auditing/index.md)
- [Troubleshooting `rippled`](../troubleshooting/index.md)
- **References:**
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

73
content/infrastructure/configuration/data-retention/configure-advisory-deletion.md
View File

@@ -8,7 +8,7 @@ labels:
---
# 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).
The default config file sets [`rippled`](../../../concepts/networks-and-servers/index.md) to automatically delete outdated [history](../../../concepts/networks-and-servers/ledger-history.md) 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](../../installation/capacity-planning.md).
## Prerequisites
@@ -16,7 +16,7 @@ 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 `rippled` server is already [installed](../../installation/index.md) and [online deletion](online-deletion.md) is enabled.
The default config file enables online deletion after 2000 ledger versions.
@@ -26,11 +26,13 @@ This tutorial assumes your server meets the following prerequisites:
On RHEL or CentOS, you can install the `cronie` package:
$ sudo yum install cronie
```
$ 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.
See [Capacity Planning](../../installation/capacity-planning.md) 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.
@@ -40,30 +42,36 @@ To configure advisory deletion with a daily schedule, perform the following step
1. Enable `advisory_delete` in the `[node_db]` stanza of your `rippled`'s config file.
[node_db]
# Other settings unchanged ...
online_delete=300000
advisory_delete=1
```
[node_db]
# Other settings unchanged ...
online_delete=300000
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' %}<!--_ -->
{% partial file="/_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:
You can use the [`rippled` commandline interface](../../../tutorials/get-started/get-started-using-http-websocket-apis.md#commandline) to run this command. For example:
$ rippled --conf=/etc/opt/ripple/rippled.cfg can_delete now
```
$ 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"
}
}
```
{
"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.
@@ -71,11 +79,15 @@ To configure advisory deletion with a daily schedule, perform the following step
Edit your `cron` configuration:
$ crontab -e
```
$ 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
```
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.
@@ -83,7 +95,9 @@ To configure advisory deletion with a daily schedule, perform the following step
4. Start (or restart) the `rippled` service.
$ sudo systemctl restart rippled
```
$ 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.
@@ -98,24 +112,21 @@ If online deletion does not seem to be running after configuring it, try the fol
- 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.
- Check your `rippled` logs for messages that begin with `SHAMapStore::WRN`. This can indicate that [online deletion is being interrupted](online-deletion.md#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)
- [Ledger History](../../../concepts/networks-and-servers/ledger-history.md)
- [Online Deletion](online-deletion.md)
- **Tutorials:**
- [Configure Online Deletion](configure-online-deletion.html)
- [Diagnosing Problems with rippled](diagnosing-problems.html)
- [Understanding Log Messages](understanding-log-messages.html)
- [Configure Online Deletion](configure-online-deletion.md)
- [Diagnosing Problems with rippled](../../troubleshooting/diagnosing-problems.md)
- [Understanding Log Messages](../../troubleshooting/understanding-log-messages.md)
- **References:**
- [server_info method][]
- [can_delete method][]
- [logrotate method][]
- [Ledger Data Formats](ledger-data-formats.html)
- [Ledger Data Formats](../../../references/protocol/ledger-data/index.md)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

83
content/infrastructure/configuration/data-retention/configure-full-history.md
View File

@@ -20,7 +20,7 @@ Acquiring full history from the peer-to-peer network takes a long time (several
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.
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.md) to store randomly-selected chunks of ledger history instead.
## Configuration Steps
@@ -28,32 +28,40 @@ To configure your server to acquire and store full history, complete the followi
1. Stop the `rippled` server if it is running.
$ sudo systemctl stop rippled
```
$ 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=300000
#advisory_delete=0
```
[node_db]
type=NuDB
path=/var/lib/rippled/db/nudb
#online_delete=300000
#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.`
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](../../installation/capacity-planning.md). 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).
**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](../../troubleshooting/server-wont-start.md#state-db-error).
{% include '_snippets/conf-file-location.md' %}<!--_ -->
{% partial file="/_snippets/conf-file-location.md" /%}
0. Set the `[ledger_history]` stanza of your server's config file to `full`:
[ledger_history]
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
```
[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.
@@ -61,29 +69,37 @@ To configure your server to acquire and store full history, complete the followi
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/
```
[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/*
```
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):
If you have a database dump to load configured in `[import_db]`, start the server explicitly and include the `--import` [commandline option](../../commandline-usage.md#daemon-mode-options):
$ /opt/ripple/bin/rippled --conf /etc/opt/ripple/rippled.cfg --import
```
$ /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
```
$ sudo systemctl start rippled
```
0. If you added an `[import_db]` stanza to your server's config file, remove it after the import completes.
@@ -93,25 +109,22 @@ To configure your server to acquire and store full history, complete the followi
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**.
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](../../../concepts/networks-and-servers/parallel-networks.md) generally have history going back to ledger index **1**.
## See Also
- **Concepts:**
- [Ledger History](ledger-history.html)
- [rippled Server Modes](rippled-server-modes.html)
- [Ledger History](../../../concepts/networks-and-servers/ledger-history.md)
- [rippled Server Modes](../../../concepts/networks-and-servers/rippled-server-modes.md)
- **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)
- [Capacity Planning](../../installation/capacity-planning.md), particularly [Disk Space](../../installation/capacity-planning.md#disk-space)
- [Configure Online Deletion](configure-online-deletion.md)
- [Diagnosing Problems with rippled](../../troubleshooting/diagnosing-problems.md)
- [Understanding Log Messages](../../troubleshooting/understanding-log-messages.md)
- **References:**
- [server_info method][]
- [can_delete method][]
- [Ledger Data Formats](ledger-data-formats.html)
- [rippled Commandline Usage Reference](commandline-usage.html)
- [Ledger Data Formats](../../../references/protocol/ledger-data/index.md)
- [rippled Commandline Usage Reference](../../commandline-usage.md)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

29
content/infrastructure/configuration/data-retention/configure-history-sharding.md
View File

@@ -8,7 +8,7 @@ labels:
---
# 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.
[History Sharding](history-sharding.md) 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.
@@ -25,7 +25,7 @@ Before you configure your `rippled` server to store history shards, you must dec
- 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][]
- 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. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.7.0" %}New in: rippled 1.7.0{% /badge %}
## 2. Edit rippled.cfg
@@ -33,7 +33,7 @@ Before you configure your `rippled` server to store history shards, you must dec
Edit your `rippled.cfg` file to add a `[shard_db]` stanza and optionally a `[historical_shard_paths]` stanza.
{% include '_snippets/conf-file-location.md' %}<!--_ -->
{% partial file="/_snippets/conf-file-location.md" /%}
The following snippet shows an example of a `[shard_db]` stanza:
@@ -48,9 +48,9 @@ max_historical_shards=12
/mnt/disk2
```
The `type` field of `[shard_db]` can be omitted. If present, it _MUST_ be `NuDB`. [New in: rippled 1.3.1][]
The `type` field of `[shard_db]` can be omitted. If present, it _MUST_ be `NuDB`. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.3.1" %}New in: rippled 1.3.1{% /badge %}
**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.
**Caution:** If `rippled` detects the wrong type of data in the shard store path, it may [fail to start](../../troubleshooting/server-wont-start.md). 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/XRPLF/rippled/blob/master/cfg/rippled-example.cfg).
@@ -68,24 +68,21 @@ This folder should contain a numbered folder for each shard your server has. At
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).
To list the shards your server and its peers have available, you can use the [crawl_shards method][] or the [Peer Crawler](../../../references/http-websocket-apis/peer-port-methods/peer-crawler.md).
## See Also
- **Concepts:**
- [Ledger History](ledger-history.html)
- [Online Deletion](online-deletion.html)
- [Ledger History](../../../concepts/networks-and-servers/ledger-history.md)
- [Online Deletion](online-deletion.md)
- **Tutorials:**
- [Configure Online Deletion](configure-online-deletion.html)
- [Configure the Peer Crawler](configure-the-peer-crawler.html)
- [Capacity Planning](capacity-planning.html)
- [Configure Online Deletion](configure-online-deletion.md)
- [Configure the Peer Crawler](../peering/configure-the-peer-crawler.md)
- [Capacity Planning](../../installation/capacity-planning.md)
- **References:**
- [download_shard method][]
- [crawl_shards method][]
- [Ledger Data Formats](ledger-data-formats.html)
- [Ledger Data Formats](../../../references/protocol/ledger-data/index.md)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

53
content/infrastructure/configuration/data-retention/configure-online-deletion.md
View File

@@ -8,7 +8,7 @@ labels:
---
# 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.
In its default configuration, [the `rippled` server](../../../concepts/networks-and-servers/index.md) [deletes history](online-deletion.md) older than the most recent 2000 [ledger versions](../../../concepts/ledgers/index.md), keeping approximately 15 minutes of [ledger history](../../../concepts/networks-and-servers/ledger-history.md) (based on the current rate between ledgers). This page describes how to configure the amount of history your `rippled` server stores before deleting.
## Prerequisites
@@ -16,11 +16,11 @@ 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 `rippled` server is already [installed](../../installation/index.md) and [online deletion](online-deletion.md) 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.
- Your server has [enough disk space](../../installation/capacity-planning.md#disk-space) to store your chosen amount of history in its ledger store.
## Configuration Steps
@@ -29,24 +29,28 @@ 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.
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](../../installation/capacity-planning.md) 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=300000
advisory_delete=0
```
[node_db]
# Other settings unchanged ...
online_delete=300000
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' %}<!--_ -->
{% partial file="/_snippets/conf-file-location.md" /%}
0. Start (or restart) the `rippled` service.
$ sudo systemctl restart rippled
```
$ sudo systemctl restart rippled
```
0. Wait for your server to sync to the network.
@@ -58,33 +62,28 @@ To change the amount of history your server stores, perform the following steps:
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.
0. Monitor your `rippled` logs for messages that begin with `SHAMapStore::WRN`. This can indicate that [online deletion is being interrupted](online-deletion.md#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.
- Increase your system specs. See [System Requirements](../../installation/system-requirements.md) 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).
- Change your server's [`node_size` parameter](../../installation/capacity-planning.md).
- Use [NuDB instead of RocksDB](../../installation/capacity-planning.md) for the ledger store.
- [Schedule online deletion using Advisory Deletion](configure-advisory-deletion.md).
## See Also
- **Concepts:**
- [Ledger History](ledger-history.html)
- [Online Deletion](online-deletion.html)
- [Ledger History](../../../concepts/networks-and-servers/ledger-history.md)
- [Online Deletion](online-deletion.md)
- **Tutorials:**
- [Configure Advisory Deletion](configure-advisory-deletion.html)
- [Configure History Sharding](configure-history-sharding.html)
- [Capacity Planning](capacity-planning.html)
- [Configure Advisory Deletion](configure-advisory-deletion.md)
- [Configure History Sharding](configure-history-sharding.md)
- [Capacity Planning](../../installation/capacity-planning.md)
- **References:**
- [server_info method][]
- [Ledger Data Formats](ledger-data-formats.html)
- [Ledger Data Formats](../../../references/protocol/ledger-data/index.md)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

26
content/infrastructure/configuration/data-retention/history-sharding.md
View File

@@ -8,13 +8,13 @@ labels:
---
# History Sharding
[Introduced in: rippled 0.90.0][]
{% badge href="https://github.com/XRPLF/rippled/releases/tag/0.90.0" %}Introduced in: rippled 0.90.0{% /badge %}
As XRP Ledger servers run, they naturally produce a database containing data about the ledgers they built or acquired during network runtime. Each server stores that ledger data in its _ledger store_, but [online deletion](online-deletion.html) removes old ledgers' data automatically over time. History sharding provides a separate storage system for older ledger history so that the network can divide up the work of recording the entire (multiple terabyte) history of the XRP Ledger.
As XRP Ledger servers run, they naturally produce a database containing data about the ledgers they built or acquired during network runtime. Each server stores that ledger data in its _ledger store_, but [online deletion](online-deletion.md) removes old ledgers' data automatically over time. History sharding provides a separate storage system for older ledger history so that the network can divide up the work of recording the entire (multiple terabyte) history of the XRP Ledger.
Historical sharding distributes the transaction history of the XRP Ledger into segments, called shards, across servers in the XRP Ledger network. A shard is a range of ledgers. A server uses mostly the same format for ledgers in both the ledger store and the shard store, but the two stores are separate.
[![XRP Ledger Network: Ledger Store and Shard Store Diagram](img/xrp-ledger-network-ledger-store-and-shard-store.png)](img/xrp-ledger-network-ledger-store-and-shard-store.png)
[![XRP Ledger Network: Ledger Store and Shard Store Diagram](/img/xrp-ledger-network-ledger-store-and-shard-store.png)](/img/xrp-ledger-network-ledger-store-and-shard-store.png)
<!-- Diagram source: https://docs.google.com/presentation/d/1mg2jZQwgfLCIhOU8Mr5aOiYpIgbIgk3ymBoDb2hh7_s/edit#slide=id.g417450e8da_0_316 -->
@@ -30,25 +30,21 @@ The server selects and downloads additional shards until it reaches the maximum
The history of all ledgers is shared by servers agreeing to keep particular ranges of historical ledgers. This makes it possible for servers to confirm that they have all the data they agreed to maintain, and produce "proof trees" or "ledger deltas" which shows how each ledger in the blockchain's history was the result of applying transactions to the previous state. Since servers that are configured with history sharding randomly select the shards that they store, the entire history of all closed ledgers is stored in a normal distribution curve, increasing the probability that the XRP Ledger Network evenly maintains the history.
History shards are recorded in a deterministic format, so that any two servers assembling the same shard produce the exact same binary data no matter what order they acquired the data and where they got it from. This makes it possible to compare checksums or cryptographic hashes of the shard data to verify the integrity of the data, and it is possible to share and import history shards through other formats. (For example, you could download shard data using Bittorrent or acquire physical media with the shard data pre-loaded on it, and verify that it matches the data that can be downloaded from the network.) [New in: rippled 1.8.1][]
History shards are recorded in a deterministic format, so that any two servers assembling the same shard produce the exact same binary data no matter what order they acquired the data and where they got it from. This makes it possible to compare checksums or cryptographic hashes of the shard data to verify the integrity of the data, and it is possible to share and import history shards through other formats. (For example, you could download shard data using Bittorrent or acquire physical media with the shard data pre-loaded on it, and verify that it matches the data that can be downloaded from the network.) {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.8.1" %}New in: rippled 1.8.1{% /badge %}
## See Also
- **Concepts:**
- [Ledgers](ledgers.html)
- [Consensus](consensus.html)
- [Ledgers](../../../concepts/ledgers/index.md)
- [Consensus](../../../concepts/consensus-protocol/index.md)
- **Tutorials:**
- [Capacity Planning](capacity-planning.html)
- [Configure `rippled`](configure-rippled.html)
- [Configure History Sharding](configure-history-sharding.html)
- [Capacity Planning](../../installation/capacity-planning.md)
- [Configure `rippled`](../index.md)
- [Configure History Sharding](configure-history-sharding.md)
- **References:**
- [crawl_shards method][]
- [download_shard method][]
- [Peer Crawler](peer-crawler.html)
- [Peer Crawler](../../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

8
content/infrastructure/configuration/data-retention/index.md
View File

@@ -1,9 +1,13 @@
---
html: data-retention.html
parent: configure-rippled.html
template: pagetype-category.html.jinja
metadata:
indexPage: true
blurb: Control how much data your server should keep and when it should remove old data.
---
# Data Retention
Control how much data your server should keep and when it should remove old data, including old versions of the ledger state and past transactions.
Control how much data your server should keep and when it should remove old data, including old versions of the ledger state and past transactions.
{% child-pages /%}

40
content/infrastructure/configuration/data-retention/online-deletion.md
View File

@@ -9,18 +9,18 @@ labels:
# Online Deletion
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/misc/SHAMapStoreImp.cpp "Source")
The online deletion feature lets the `rippled` server delete the server's local copy of old ledger versions to keep disk usage from rapidly growing over time. The default config file sets online deletion to run automatically, but online deletion can also be configured to run only when prompted. [New in: rippled 0.27.0][]
The online deletion feature lets the `rippled` server delete the server's local copy of old ledger versions to keep disk usage from rapidly growing over time. The default config file sets online deletion to run automatically, but online deletion can also be configured to run only when prompted. {% badge href="https://github.com/XRPLF/rippled/releases/tag/0.27.0" %}New in: rippled 0.27.0{% /badge %}
The server always keeps the complete _current_ state of the ledger, with all the balances and settings it contains. The deleted data includes older transactions and versions of the ledger state that are older than the stored history.
The default config file sets the `rippled` server to keep the most recent 2000 ledger versions and automatically delete older data.
**Tip:** Even with online deletion, the amount of disk space required to store the same time span's worth of ledger data increases over time, because the size of individual ledger versions tends to grow over time. This growth is very slow in comparison to the accumulation of data that occurs without deleting old ledgers. For more information on disk space needs, see [Capacity Planning](capacity-planning.html).
**Tip:** Even with online deletion, the amount of disk space required to store the same time span's worth of ledger data increases over time, because the size of individual ledger versions tends to grow over time. This growth is very slow in comparison to the accumulation of data that occurs without deleting old ledgers. For more information on disk space needs, see [Capacity Planning](../../installation/capacity-planning.md).
## Background
The `rippled` server stores [ledger history](ledger-history.html) in its _ledger store_. This data accumulates over time.
The `rippled` server stores [ledger history](../../../concepts/networks-and-servers/ledger-history.md) in its _ledger store_. This data accumulates over time.
Inside the ledger store, ledger data is "de-duplicated". In other words, data that doesn't change from version to version is only stored once. The records themselves in the ledger store do not indicate which ledger version(s) contain them; part of the work of online deletion is identifying which records are only used by outdated ledger versions. This process is time consuming and affects the disk I/O and application cache, so the server cannot delete old data every time it closes a new ledger.
@@ -29,7 +29,7 @@ Inside the ledger store, ledger data is "de-duplicated". In other words, data th
The online deletion settings configure how many ledger versions the `rippled` server should keep available in the ledger store at a time. However, the specified number is a guideline, not a hard rule:
- The server never deletes data more recent than the configured number of ledger versions, but it may have less than that amount available if it has not been running for long enough or if it lost sync with the network at any time. (The server attempts to backfill at least some history; see [fetching history](ledger-history.html#fetching-history) for details.)
- The server never deletes data more recent than the configured number of ledger versions, but it may have less than that amount available if it has not been running for long enough or if it lost sync with the network at any time. (The server attempts to backfill at least some history; see [fetching history](../../../concepts/networks-and-servers/ledger-history.md#fetching-history) for details.)
- The server may store up to slightly over twice the configured number of ledger versions if online deletion is set to run automatically. (Each time it runs, it reduces the number of stored ledger versions to approximately the configured number.)
If online deletion is delayed because the server is busy, ledger versions can continue to accumulate. When functioning normally, online deletion begins when the server has twice the configured number of ledger versions, but it may not complete until after several more ledger versions have accumulated.
@@ -55,7 +55,7 @@ The server only counts validated ledger versions when deciding how far back it c
### Interrupting Online Deletion
Online deletion automatically stops if the [server state](rippled-server-states.html) becomes less than `full`. If this happens, the server writes a log message with the prefix `SHAMapStore::WRN`. The server attempts to start online deletion again after the next validated ledger version after becoming fully synced.
Online deletion automatically stops if the [server state](../../../references/http-websocket-apis/api-conventions/rippled-server-states.md) becomes less than `full`. If this happens, the server writes a log message with the prefix `SHAMapStore::WRN`. The server attempts to start online deletion again after the next validated ledger version after becoming fully synced.
If you stop the server or it crashes while online deletion is running, online deletion resumes after the server is restarted and the server becomes fully synced.
@@ -68,7 +68,7 @@ The following settings relate to online deletion:
- **`online_delete`** - Specify how many validated ledger versions to keep. The server periodically deletes any ledger versions that are older than this number. If not specified, no ledgers are deleted.
The default config file specifies 2000 for this value. This cannot be less than 256, because some events like [Fee Voting](fee-voting.html) and the [Amendment Process](amendments.html#amendment-process) update only every 256 ledgers.
The default config file specifies 2000 for this value. This cannot be less than 256, because some events like [Fee Voting](../../../concepts/consensus-protocol/fee-voting.md) and the [Amendment Process](../../../concepts/networks-and-servers/amendments.md#amendment-process) update only every 256 ledgers.
**Caution:** If you run `rippled` with `online_delete` disabled, then later enable `online_delete` and restart the server, the server disregards but does not delete existing ledger history that your server already downloaded while `online_delete` was disabled. To save disk space, delete your existing history before re-starting the server after changing the `online_delete` setting.
@@ -78,7 +78,7 @@ The following settings relate to online deletion:
The following diagram shows the relationship between `online_delete` and `ledger_history` settings:
{{ include_svg("img/online_delete-vs-ledger_history.svg", "Ledgers older than `online_delete` are automatically deleted. Ledgers newer than `ledger_history` are backfilled. Ledgers in between are kept if available but not backfilled") }}
[{% inline-svg file="/img/online_delete-vs-ledger_history.svg" /%}](/img/online_delete-vs-ledger_history.svg "Ledgers older than `online_delete` are automatically deleted. Ledgers newer than `ledger_history` are backfilled. Ledgers in between are kept if available but not backfilled")
- **`advisory_delete`** - If enabled, online deletion is not scheduled automatically. Instead, an administrator must manually trigger online deletion. Use the value `0` for disabled or `1` for enabled.
@@ -92,9 +92,9 @@ The following settings relate to online deletion:
The following diagram shows how `fetch_depth` works:
{{ include_svg("img/fetch_depth.svg", "Ledger versions older than fetch_depth are not served to peers") }}
[{% inline-svg file="/img/fetch_depth.svg" /%}](/img/fetch_depth.svg "Ledger versions older than fetch_depth are not served to peers")
For estimates of how much disk space is required to store different amounts of history, see [Capacity Planning](capacity-planning.html#disk-space).
For estimates of how much disk space is required to store different amounts of history, see [Capacity Planning](../../installation/capacity-planning.md#disk-space).
### Advisory Deletion
@@ -118,15 +118,15 @@ When it comes time for online deletion, the server first walks through the oldes
## See Also
- **Concepts:**
- [Ledgers](ledgers.html)
- [Consensus](consensus.html)
- [Ledgers](../../../concepts/ledgers/index.md)
- [Consensus](../../../concepts/consensus-protocol/index.md)
- **Tutorials:**
- [Capacity Planning](capacity-planning.html)
- [Configure `rippled`](configure-rippled.html)
- [Configure Online Deletion](configure-online-deletion.html)
- [Configure Advisory Deletion](configure-advisory-deletion.html)
- [Configure History Sharding](configure-history-sharding.html)
- [Configure Full History](configure-full-history.html)
- [Capacity Planning](../../installation/capacity-planning.md)
- [Configure `rippled`](../index.md)
- [Configure Online Deletion](configure-online-deletion.md)
- [Configure Advisory Deletion](configure-advisory-deletion.md)
- [Configure History Sharding](configure-history-sharding.md)
- [Configure Full History](configure-full-history.md)
- **References:**
- [ledger method][]
- [server_info method][]
@@ -134,8 +134,4 @@ When it comes time for online deletion, the server first walks through the oldes
- [can_delete method][]
- [ledger_cleaner method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

36
content/infrastructure/configuration/enable-public-signing.md
View File

@@ -8,9 +8,9 @@ labels:
---
# 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][]
By default, the signing methods for [`rippled`](../../concepts/networks-and-servers/index.md) are limited to [administrative connections](../../references/http-websocket-apis/admin-api-methods/index.md). 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. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.1.0" %}New in: rippled 1.1.0{% /badge %}
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:
This enables the following methods to be used on "public" [JSON-RPC and WebSocket connections](../../tutorials/get-started/get-started-using-http-websocket-apis.md), if your server accepts them:
- [sign][sign method]
- [sign_for][sign_for method]
@@ -24,35 +24,37 @@ To enable public signing, perform the following steps:
1. Edit your `rippled`'s config file.
vim /etc/opt/ripple/rippled.cfg
```
vim /etc/opt/ripple/rippled.cfg
```
{% include '_snippets/conf-file-location.md' %}<!--_ -->
{% partial file="/_snippets/conf-file-location.md" /%}
2. Add the following stanza to your config file, and save the changes:
[signing_support]
true
```
[signing_support]
true
```
3. Restart your `rippled` server:
systemctl restart rippled
```
systemctl restart rippled
```
## See Also
- **Concepts:**
- [Transactions](transactions.html)
- [Cryptographic Keys](cryptographic-keys.html)
- [Transactions](../../concepts/transactions/index.md)
- [Cryptographic Keys](../../concepts/accounts/cryptographic-keys.md)
- **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)
- [Set Up Secure Signing](../../concepts/transactions/secure-signing.md)
- [Get Started Using HTTP / WebSocket APIs](../../tutorials/get-started/get-started-using-http-websocket-apis.md)
- [Get Started Using JavaScript](../../tutorials/get-started/get-started-using-javascript.md)
- **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' %}
{% raw-partial file="/_snippets/common-links.md" /%}

8
content/infrastructure/configuration/index.md
View File

@@ -1,9 +1,13 @@
---
html: configure-rippled.html
parent: infrastructure.html
template: pagetype-category.html.jinja
metadata:
indexPage: true
blurb: Customize the configuration of an XRP Ledger server.
---
# Configuration
Customize the configuration of an XRP Ledger server.
Customize the configuration of an XRP Ledger server.
{% child-pages /%}

103
content/infrastructure/configuration/peering/cluster-rippled-servers.md
View File

@@ -7,7 +7,7 @@ labels:
---
# Cluster rippled Servers
If you run multiple [`rippled` servers](xrpl-servers.html) in the same data center, you can configure them in a [cluster](clustering.html) to maximize efficiency. To configure clustering:
If you run multiple [`rippled` servers](../../../concepts/networks-and-servers/index.md) in the same data center, you can configure them in a [cluster](../../../concepts/networks-and-servers/clustering.md) to maximize efficiency. To configure clustering:
1. For each of your servers, note the IP address of the server.
@@ -15,18 +15,20 @@ If you run multiple [`rippled` servers](xrpl-servers.html) in the same data cent
For example, using the commandline interface:
$ rippled validation_create
```
$ rippled validation_create
Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"status" : "success",
"validation_key" : "FAWN JAVA JADE HEAL VARY HER REEL SHAW GAIL ARCH BEN IRMA",
"validation_public_key" : "n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG",
"validation_seed" : "ssZkdwURFMBXenJPbrpE14b6noJSu"
}
}
Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"status" : "success",
"validation_key" : "FAWN JAVA JADE HEAL VARY HER REEL SHAW GAIL ARCH BEN IRMA",
"validation_public_key" : "n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG",
"validation_seed" : "ssZkdwURFMBXenJPbrpE14b6noJSu"
}
}
```
Save the `validation_seed` and `validation_public_key` parameters from each response somewhere secure.
@@ -34,9 +36,11 @@ If you run multiple [`rippled` servers](xrpl-servers.html) in the same data cent
1. In the `[ips_fixed]` section, list the IP address and port of each _other_ member of the cluster. For each of those servers, the port number should match the `protocol = peer` port (usually 51235) from that server's `rippled.cfg`. For example:
[ips_fixed]
192.168.0.1 51235
192.168.0.2 51235
```
[ips_fixed]
192.168.0.1 51235
192.168.0.2 51235
```
This defines specific peer servers to which this server should always attempt to maintain a direct peer-to-peer connection.
@@ -44,61 +48,66 @@ If you run multiple [`rippled` servers](xrpl-servers.html) in the same data cent
2. In the `[node_seed]` section, set the server's node seed to one of the `validation_seed` values you generated using the [validation_create method][] in step 2. Each server must use a unique node seed. For example:
[node_seed]
ssZkdwURFMBXenJPbrpE14b6noJSu
```
[node_seed]
ssZkdwURFMBXenJPbrpE14b6noJSu
```
This defines the key pair the server uses to sign peer-to-peer communications, excluding validation messages.
3. In the `[cluster_nodes]` section, set the members of the server's cluster, identified by their `validation_public_key` values. Each server should list the public keys of all _other_ members of the cluster here. Optionally, add a custom name for each server. For example:
[cluster_nodes]
n9McNsnzzXQPbg96PEUrrQ6z3wrvgtU4M7c97tncMpSoDzaQvPar keynes
n94UE1ukbq6pfZY9j54sv2A1UrEeHZXLbns3xK5CzU9NbNREytaa friedman
```
[cluster_nodes]
n9McNsnzzXQPbg96PEUrrQ6z3wrvgtU4M7c97tncMpSoDzaQvPar keynes
n94UE1ukbq6pfZY9j54sv2A1UrEeHZXLbns3xK5CzU9NbNREytaa friedman
```
This defines the key pairs the server uses to recognize members of its cluster.
4. After saving the config file, restart `rippled` on each server.
# systemctl restart rippled
```
# systemctl restart rippled
```
5. To confirm that each server is now a member of the cluster, use the [peers method][]. The `cluster` field should list the public keys and (if configured) the custom names for each server.
For example, using the commandline interface:
$ rippled peers
```
$ rippled peers
Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"cluster" : {
"n9McNsnzzXQPbg96PEUrrQ6z3wrvgtU4M7c97tncMpSoDzaQvPar": {
"tag": "keynes",
"age": 1
},
"n94UE1ukbq6pfZY9j54sv2A1UrEeHZXLbns3xK5CzU9NbNREytaa": {
"tag": "friedman",
"age": 1
}
Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"cluster" : {
"n9McNsnzzXQPbg96PEUrrQ6z3wrvgtU4M7c97tncMpSoDzaQvPar": {
"tag": "keynes",
"age": 1
},
"peers" : [
... (omitted) ...
],
"status" : "success"
}
}
"n94UE1ukbq6pfZY9j54sv2A1UrEeHZXLbns3xK5CzU9NbNREytaa": {
"tag": "friedman",
"age": 1
}
},
"peers" : [
... (omitted) ...
],
"status" : "success"
}
}
```
## See Also
- **Concepts:**
- [Peer Protocol](peer-protocol.html)
- [Peer Protocol](../../../concepts/networks-and-servers/peer-protocol.md)
- **Tutorials:**
- [Install rippled](install-rippled.html)
- [Install rippled](../../installation/index.md)
- **References:**
- [validation_create method][]
- [peers method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

62
content/infrastructure/configuration/peering/configure-a-private-server.md
View File

@@ -8,14 +8,14 @@ labels:
---
# Configure a Private Server
A [private server](peer-protocol.html#private-peers) is a `rippled` server that connects to the network only through specific, trusted peers instead of connecting directly to discovered peers in the open peer-to-peer network. This kind of configuration is an optional precaution most commonly recommended for [validators](run-rippled-as-a-validator.html), but it can be useful for other specific purposes.
A [private server](../../../concepts/networks-and-servers/peer-protocol.md#private-peers) is a `rippled` server that connects to the network only through specific, trusted peers instead of connecting directly to discovered peers in the open peer-to-peer network. This kind of configuration is an optional precaution most commonly recommended for [validators](../server-modes/run-rippled-as-a-validator.md), but it can be useful for other specific purposes.
## Prerequisites
To use a private server, you must meet the following requirements:
- You must have [`rippled` installed](install-rippled.html) and updated to the latest version, but not running yet.
- You must decide whether to connect through **proxies** you run yourself, or through **public hubs**. For a comparison of these options, see [Pros and Cons of Peering Configurations](peer-protocol.html#pros-and-cons-of-peering-configurations).
- You must have [`rippled` installed](../../installation/index.md) and updated to the latest version, but not running yet.
- You must decide whether to connect through **proxies** you run yourself, or through **public hubs**. For a comparison of these options, see [Pros and Cons of Peering Configurations](../../../concepts/networks-and-servers/peer-protocol.md#pros-and-cons-of-peering-configurations).
- If you are using proxies, you must have additional machines with `rippled` installed and running to use as the proxies. These servers must be able to connect to the outside network and to your private server.
- For either configuration, you must know the IP addresses and ports of the peers you intend to connect to.
@@ -25,16 +25,20 @@ To set up a specific server as a private peer, complete the following steps:
1. Edit your `rippled`'s config file.
vim /etc/opt/ripple/rippled.cfg
```
vim /etc/opt/ripple/rippled.cfg
```
{% include '_snippets/conf-file-location.md' %}<!--_ -->
{% partial file="/_snippets/conf-file-location.md" /%}
2. Enable private peering.
Add or uncomment the following stanza in your config file:
[peer_private]
1
```
[peer_private]
1
```
3. Add fixed peers.
@@ -42,15 +46,19 @@ To set up a specific server as a private peer, complete the following steps:
For example, to connect using **public hubs**, you could use the following stanza:
[ips_fixed]
r.ripple.com 51235
zaphod.alloy.ee 51235
```
[ips_fixed]
r.ripple.com 51235
zaphod.alloy.ee 51235
```
If your server connects using **proxies**, the IP addresses and ports should match the configurations of the `rippled` servers you are using as proxies. For each of those servers, the port number should match the `protocol = peer` port in that server's config file (usually 51235). For example, your configuration might look like this:
[ips_fixed]
192.168.0.1 51235
192.168.0.2 51235
```
[ips_fixed]
192.168.0.1 51235
192.168.0.2 51235
```
**Note:** If you omit the port number, the server uses port 2459, the IANA-assigned port for the XRP Ledger protocol.
@@ -58,15 +66,19 @@ To set up a specific server as a private peer, complete the following steps:
If you are using public hubs, skip this step.
If you are using proxies, [configure the proxies as a cluster](cluster-rippled-servers.html) that includes your private peer. Each member of the cluster should have an `[ips_fixed]` stanza that lists each _other_ member of the cluster. However, **only the private server** should have a `[peer_private]` stanza.
If you are using proxies, [configure the proxies as a cluster](cluster-rippled-servers.md) that includes your private peer. Each member of the cluster should have an `[ips_fixed]` stanza that lists each _other_ member of the cluster. However, **only the private server** should have a `[peer_private]` stanza.
Restart `rippled` on the proxies one-by-one. On each proxy server:
sudo service systemctl restart rippled
```
sudo service systemctl restart rippled
```
5. Start `rippled` on the private server.
sudo service systemctl start rippled
```
sudo service systemctl start rippled
```
6. Use the [peers method][] to confirm that your private server is connected _only_ to its peers.
@@ -75,26 +87,22 @@ To set up a specific server as a private peer, complete the following steps:
## Next Steps
As an additional precaution, you should configure your firewall to block incoming connections to your private server from servers that are not your specific peers. If you are running proxy servers, [forward peer ports](forward-ports-for-peering.html) through your firewall to the proxies, but **not** to the private peer. The exact details of how to configure this depend on what firewall you use.
As an additional precaution, you should configure your firewall to block incoming connections to your private server from servers that are not your specific peers. If you are running proxy servers, [forward peer ports](forward-ports-for-peering.md) through your firewall to the proxies, but **not** to the private peer. The exact details of how to configure this depend on what firewall you use.
Be sure the firewall **does not block** outgoing HTTP connections on port 80. The default configuration uses this port to download the latest recommended validator list from **vl.ripple.com**. Without a validator list, the server does not know which validators to trust and cannot recognize when the network reaches a consensus.
## See Also
- **Concepts:**
- [Peer Protocol](peer-protocol.html)
- [Consensus](consensus.html)
- [Parallel Networks](parallel-networks.html)
- [Peer Protocol](../../../concepts/networks-and-servers/peer-protocol.md)
- [Consensus](../../../concepts/consensus-protocol/index.md)
- [Parallel Networks](../../../concepts/networks-and-servers/parallel-networks.md)
- **Tutorials:**
- [Configure the Peer Crawler](configure-the-peer-crawler.html)
- [Configure the Peer Crawler](configure-the-peer-crawler.md)
- **References:**
- [peers method][]
- [connect method][]
- [fetch_info method][]
- [Peer Crawler](peer-crawler.html)
- [Peer Crawler](../../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

53
content/infrastructure/configuration/peering/configure-the-peer-crawler.md
View File

@@ -8,7 +8,7 @@ labels:
---
# Configure the Peer Crawler
By default, [`rippled` servers](xrpl-servers.html) provide statistics publicly to anyone who asks using the [peer crawler API](peer-crawler.html), to make it easier to track the health and topology of [the XRP Ledger's peer-to-peer network](peer-protocol.html). You can configure your server to provide more or less information, or to reject peer crawler requests entirely.
By default, [`rippled` servers](../../../concepts/networks-and-servers/index.md) provide statistics publicly to anyone who asks using the [peer crawler API](../../../references/http-websocket-apis/peer-port-methods/peer-crawler.md), to make it easier to track the health and topology of [the XRP Ledger's peer-to-peer network](../../../concepts/networks-and-servers/peer-protocol.md). You can configure your server to provide more or less information, or to reject peer crawler requests entirely.
This document contains steps for two options:
@@ -21,23 +21,29 @@ To configure how much information your server provides in response to peer crawl
1. Edit your `rippled`'s config file.
vim /etc/opt/ripple/rippled.cfg
```
vim /etc/opt/ripple/rippled.cfg
```
{% include '_snippets/conf-file-location.md' %}<!--_ -->
{% partial file="/_snippets/conf-file-location.md" /%}
2. Add or update the `[crawl]` stanza in your config file, and save the changes:
[crawl]
overlay = 1
server = 1
counts = 0
unl = 1
```
[crawl]
overlay = 1
server = 1
counts = 0
unl = 1
```
The fields in this stanza control which fields the server returns in the [peer crawler response](peer-crawler.html#response-format). The names of the config fields match the fields of the API response. A setting with a value of `1` means to include the field in the response. A value of `0` means to omit that field from the response. This example shows the default values for each setting.
The fields in this stanza control which fields the server returns in the [peer crawler response](../../../references/http-websocket-apis/peer-port-methods/peer-crawler.md#response-format). The names of the config fields match the fields of the API response. A setting with a value of `1` means to include the field in the response. A value of `0` means to omit that field from the response. This example shows the default values for each setting.
3. After saving the changes to the config file, restart your `rippled` server to apply the updated configuration:
systemctl restart rippled
```
systemctl restart rippled
```
## Disable the Peer Crawler
@@ -46,34 +52,37 @@ To disable the peer crawler API on your server, so it does not respond to peer c
1. Edit your `rippled`'s config file.
vim /etc/opt/ripple/rippled.cfg
```
vim /etc/opt/ripple/rippled.cfg
```
{% include '_snippets/conf-file-location.md' %}<!--_ -->
{% partial file="/_snippets/conf-file-location.md" /%}
2. Add or update the `[crawl]` stanza in your config file, and save the changes:
[crawl]
0
```
[crawl]
0
```
Remove or comment out all other contents of the crawl stanza.
3. After saving the changes to the config file, restart your `rippled` server to apply the updated configuration:
systemctl restart rippled
```
systemctl restart rippled
```
## See Also
- **Concepts:**
- [Peer Protocol](peer-protocol.html)
- [Peer Protocol](../../../concepts/networks-and-servers/peer-protocol.md)
- **Tutorials:**
- [Manage the rippled Server](manage-the-rippled-server.html)
- [Manage the rippled Server](../../installation/install-rippled-on-ubuntu.md)
- **References:**
- [server_info method][]
- [peers method][]
- [Peer Crawler](peer-crawler.html)
- [Peer Crawler](../../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

13
content/infrastructure/configuration/peering/enable-link-compression.md
View File

@@ -7,7 +7,7 @@ labels:
---
# Enable Link Compression
The `rippled` server can save bandwidth by compressing its [peer-to-peer communications](peer-protocol.html), at a cost of greater CPU usage. If you enable link compression, the server automatically compresses communications with peer servers that also have link compression enabled.
The `rippled` server can save bandwidth by compressing its [peer-to-peer communications](../../../concepts/networks-and-servers/peer-protocol.md), at a cost of greater CPU usage. If you enable link compression, the server automatically compresses communications with peer servers that also have link compression enabled.
## Steps
@@ -19,7 +19,7 @@ To enable link compression on your server, complete the following steps:
$ vim /etc/opt/ripple/rippled.cfg
```
{% include '_snippets/conf-file-location.md' %}<!--_ -->
{% partial file="/_snippets/conf-file-location.md" /%}
### 2. In the config file, add or uncomment the `[compression]` stanza.
@@ -42,10 +42,7 @@ After the restart, your server automatically uses link compression with other pe
## See Also
- [Capacity Planning](capacity-planning.html)
- [Peer Protocol](peer-protocol.html)
- [Capacity Planning](../../installation/capacity-planning.md)
- [Peer Protocol](../../../concepts/networks-and-servers/peer-protocol.md)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

15
content/infrastructure/configuration/peering/forward-ports-for-peering.md
View File

@@ -7,7 +7,7 @@ labels:
---
# Forward Ports for Peering
Servers in the XRP Ledger peer-to-peer network communicate over the [peer protocol](peer-protocol.html). For the best combination of security and connectivity to the rest of the network, you should use a firewall to protect your server from most ports, but open or forward the peer protocol port.
Servers in the XRP Ledger peer-to-peer network communicate over the [peer protocol](../../../concepts/networks-and-servers/peer-protocol.md). For the best combination of security and connectivity to the rest of the network, you should use a firewall to protect your server from most ports, but open or forward the peer protocol port.
While your `rippled` server is running, you can check to see how many peers you have by running the [server_info method][]. The `peers` field of the `info` object shows how many peers are currently connected to your server. If this number is exactly 10 or 11, that usually means your firewall is blocking incoming connections.
@@ -67,18 +67,15 @@ If you are using a hosting service with a virtual firewall (for example, [AWS Se
## See Also
- **Concepts:**
- [Peer Protocol](peer-protocol.html)
- [The `rippled` Server](xrpl-servers.html)
- [Peer Protocol](../../../concepts/networks-and-servers/peer-protocol.md)
- [The `rippled` Server](../../../concepts/networks-and-servers/index.md)
- **Tutorials:**
- [Capacity Planning](capacity-planning.html)
- [Troubleshoot the `rippled` Server](troubleshoot-the-rippled-server.html)
- [Capacity Planning](../../installation/capacity-planning.md)
- [Troubleshoot the `rippled` Server](../../troubleshooting/index.md)
- **References:**
- [connect method][]
- [peers method][]
- [print method][]
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

8
content/infrastructure/configuration/peering/index.md
View File

@@ -2,7 +2,8 @@
html: configure-peering.html
name: Peering
parent: configure-rippled.html
template: pagetype-category.html.jinja
metadata:
indexPage: true
blurb: Configure how your server connects to the peer-to-peer network.
labels:
- Core Server
@@ -11,4 +12,7 @@ labels:
The XRP Ledger's peer-to-peer protocol automatically manages peer connections in most cases. In some cases, you may want to manually adjust which peers your server connects to, to maximize your server's availability and connectivity with the rest of the network.
If you run multiple servers in the same datacenter, you may want [to cluster them](cluster-rippled-servers.html) to improve efficiency. You can use reserved peer slots for servers you don't run but want to stay connected to, such as important hubs in the topology of the peer-to-peer network. For other peers, the server can automatically find peers and manage its connections, although you may occasionally want to intervene to block a peer that's behaving undesirably.
If you run multiple servers in the same datacenter, you may want [to cluster them](cluster-rippled-servers.md) to improve efficiency. You can use reserved peer slots for servers you don't run but want to stay connected to, such as important hubs in the topology of the peer-to-peer network. For other peers, the server can automatically find peers and manage its connections, although you may occasionally want to intervene to block a peer that's behaving undesirably.
{% child-pages /%}

40
content/infrastructure/configuration/peering/manually-connect-to-a-specific-peer.md
View File

@@ -7,26 +7,25 @@ labels:
---
# Manually Connect to a Specific Peer
Use these steps to manually connect your server to a specific [peer](peer-protocol.html) in the XRP Ledger network.
Use these steps to manually connect your server to a specific [peer](../../../concepts/networks-and-servers/peer-protocol.md) in the XRP Ledger network.
**Tip:** If you want to make sure your server automatically connects to this server on startup and remains connected later, you may want to configure a [peer reservation](use-a-peer-reservation.html) for that peer.
**Tip:** If you want to make sure your server automatically connects to this server on startup and remains connected later, you may want to configure a [peer reservation](use-a-peer-reservation.md) for that peer.
## Prerequisites
- You must know the IP address of the peer you want to connect to.
- You must know what port the peer you want to connect to uses for the XRP Ledger [peer protocol](peer-protocol.html). The default config file uses port 51235.
- You must have a network connection from your server to the peer. For example, the peer server must [forward the appropriate port through its firewall](forward-ports-for-peering.html).
- The peer server must have available peer slots. If the peer is already at its maximum number of peers, you can ask the peer server's operator to add a [peer reservation](use-a-peer-reservation.html) for your server.
- You must know what port the peer you want to connect to uses for the XRP Ledger [peer protocol](../../../concepts/networks-and-servers/peer-protocol.md). The default config file uses port 51235.
- You must have a network connection from your server to the peer. For example, the peer server must [forward the appropriate port through its firewall](forward-ports-for-peering.md).
- The peer server must have available peer slots. If the peer is already at its maximum number of peers, you can ask the peer server's operator to add a [peer reservation](use-a-peer-reservation.md) for your server.
## Steps
To connect, use the [connect method][]. For example:
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
{% tabs %}
{% tab label="WebSocket" %}
```
{
"command": "connect",
@@ -34,9 +33,9 @@ To connect, use the [connect method][]. For example:
"port": 51235
}
```
{% /tab %}
*JSON-RPC*
{% tab label="JSON-RPC" %}
```
{
"method": "connect",
@@ -48,32 +47,29 @@ To connect, use the [connect method][]. For example:
]
}
```
{% /tab %}
*Commandline*
{% tab label="Commandline" %}
```
rippled connect 169.54.2.151 51235
```
{% /tab %}
<!-- MULTICODE_BLOCK_END -->
{% /tabs %}
## See Also
- **Concepts:**
- [Peer Protocol](peer-protocol.html)
- [The `rippled` Server](xrpl-servers.html)
- [Peer Protocol](../../../concepts/networks-and-servers/peer-protocol.md)
- [The `rippled` Server](../../../concepts/networks-and-servers/index.md)
- **Tutorials:**
- [Capacity Planning](capacity-planning.html)
- [Troubleshoot the `rippled` Server](troubleshoot-the-rippled-server.html)
- [Capacity Planning](../../installation/capacity-planning.md)
- [Troubleshoot the `rippled` Server](../../troubleshooting/index.md)
- **References:**
- [connect method][]
- [peers method][]
- [print method][]
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

35
content/infrastructure/configuration/peering/set-max-number-of-peers.md
View File

@@ -7,49 +7,52 @@ labels:
---
# Set Maximum Number of Peers
The `rippled` server has a configurable soft maximum number of [peers](peer-protocol.html) to connect to. The default maximum number of peers is **21**.
The `rippled` server has a configurable soft maximum number of [peers](../../../concepts/networks-and-servers/peer-protocol.md) to connect to. The default maximum number of peers is **21**.
**Note:** Internally, the server generates approximate quotas of incoming and outgoing peers. You can potentially go over the soft maximum if you are using [fixed peers, peer reservations](peer-protocol.html#fixed-peers-and-peer-reservations), or if you manually connect to additional peers using the [connect method][].
**Note:** Internally, the server generates approximate quotas of incoming and outgoing peers. You can potentially go over the soft maximum if you are using [fixed peers, peer reservations](../../../concepts/networks-and-servers/peer-protocol.md#fixed-peers-and-peer-reservations), or if you manually connect to additional peers using the [connect method][].
To change the maximum number of peers your server allows, complete the following steps:
1. Edit your `rippled`'s config file.
$ vim /etc/opt/ripple/rippled.cfg
```
$ vim /etc/opt/ripple/rippled.cfg
```
{% include '_snippets/conf-file-location.md' %}<!--_ -->
{% partial file="/_snippets/conf-file-location.md" /%}
2. In the config file, uncomment and edit the `[peers_max]` stanza, or add one if you don't have one already:
[peers_max]
30
```
[peers_max]
30
```
The only content of the stanza should be an integer indicating the total number of peers to allow. By default, the server attempts to maintain a ratio of about 85% incoming and 15% outgoing peers, but with a minimum of 10 outgoing peers, so any value less than 68 won't increase the number of outgoing peer connections your server makes.
If the `[peers_max]` value is less than 10, the server still allows a hardcoded minimum of 10 outgoing peers so that it can maintain connectivity with the network. To block all outgoing peer connections, [configure the server as a private peer](run-rippled-as-a-validator.html#connect-using-proxies) instead.
If the `[peers_max]` value is less than 10, the server still allows a hardcoded minimum of 10 outgoing peers so that it can maintain connectivity with the network. To block all outgoing peer connections, [configure the server as a private peer](../server-modes/run-rippled-as-a-validator.md#connect-using-proxies) instead.
**Caution:** The more peer servers you are connected to, the more network bandwidth your `rippled` server uses. You should only configure large numbers of peer servers if your `rippled` server has a good network connection and you can afford the costs you may incur for the bandwidth it uses.
3. Restart the `rippled` server.
$ sudo systemctl restart rippled.service
```
$ sudo systemctl restart rippled.service
```
## See Also
- **Concepts:**
- [Peer Protocol](peer-protocol.html)
- [The `rippled` Server](xrpl-servers.html)
- [Peer Protocol](../../../concepts/networks-and-servers/peer-protocol.md)
- [The `rippled` Server](../../../concepts/networks-and-servers/index.md)
- **Tutorials:**
- [Capacity Planning](capacity-planning.html)
- [Troubleshoot the `rippled` Server](troubleshoot-the-rippled-server.html)
- [Capacity Planning](../../installation/capacity-planning.md)
- [Troubleshoot the `rippled` Server](../../troubleshooting/index.md)
- **References:**
- [connect method][]
- [peers method][]
- [print method][]
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

85
content/infrastructure/configuration/peering/use-a-peer-reservation.md
View File

@@ -9,7 +9,7 @@ labels:
A [peer reservation][] is a setting that makes a `rippled` server always accept connections from a peer matching the reservation. This page describes how to use peer reservations to keep a consistent peer-to-peer connection between two servers, with the cooperation of the administrators of both servers.
Peer reservations are most useful when the two servers are run by different parties, and the server that receives the incoming connection is a [hub server](rippled-server-modes.html#public-hubs) with many peers. For clarity, these instructions use the following terms:
Peer reservations are most useful when the two servers are run by different parties, and the server that receives the incoming connection is a [hub server](../../../concepts/networks-and-servers/rippled-server-modes.md#public-hubs) with many peers. For clarity, these instructions use the following terms:
- The server making the outgoing connection is the **stock server**. This server _uses_ the peer reservation on the hub server.
- The server receiving the incoming connection is the **hub server**. The administrator _adds_ the peer reservation to this server.
@@ -20,10 +20,10 @@ However, you can use these instructions to set up a peer reservation regardless
To complete these steps, you must meet the following prerequisites:
- The administrators both servers must have `rippled` [installed](install-rippled.html) and running.
- The administrators both servers must have `rippled` [installed](../../installation/index.md) and running.
- The administrators of both servers must agree to cooperate and must be able to communicate. A public communications channel is fine because you don't need to share any secret information.
- The hub server must be able to receive incoming peer connections. For instructions on how to configure a firewall to allow this, see [Forward Ports for Peering](forward-ports-for-peering.html).
- Both servers must be configured to sync with the same [XRP Ledger network](parallel-networks.html), such as the production XRP Ledger, the Testnet, or the Devnet.
- The hub server must be able to receive incoming peer connections. For instructions on how to configure a firewall to allow this, see [Forward Ports for Peering](forward-ports-for-peering.md).
- Both servers must be configured to sync with the same [XRP Ledger network](../../../concepts/networks-and-servers/parallel-networks.md), such as the production XRP Ledger, the Testnet, or the Devnet.
## Steps
@@ -33,7 +33,7 @@ To use a peer reservation, complete the following steps:
The administrator of the stock server completes this step.
If you have already configured your server with a permanent node key pair value, you can skip ahead to [step 2: Communicate your node public key to the peer's admin](#2-communicate-the-stock-servers-node-public-key). (For example, setting up a permanent node key pair for each server is part of the process of [setting up a server cluster](cluster-rippled-servers.html).)
If you have already configured your server with a permanent node key pair value, you can skip ahead to [step 2: Communicate your node public key to the peer's admin](#2-communicate-the-stock-servers-node-public-key). (For example, setting up a permanent node key pair for each server is part of the process of [setting up a server cluster](cluster-rippled-servers.md).)
**Tip:** Setting up a permanent node key pair is optional, but makes it easier to keep the peer reservation set up if you need to erase your server's databases or move to a new machine. If you don't want to set up a permanent node key pair, you can use your server's automatically-generated node public key as reported in the `pubkey_node` field of the [server_info method][] response.
@@ -41,39 +41,47 @@ If you have already configured your server with a permanent node key pair value,
For example:
rippled validation_create
```
rippled validation_create
Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"status" : "success",
"validation_key" : "FAWN JAVA JADE HEAL VARY HER REEL SHAW GAIL ARCH BEN IRMA",
"validation_public_key" : "n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG",
"validation_seed" : "ssZkdwURFMBXenJPbrpE14b6noJSu"
}
}
Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"status" : "success",
"validation_key" : "FAWN JAVA JADE HEAL VARY HER REEL SHAW GAIL ARCH BEN IRMA",
"validation_public_key" : "n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG",
"validation_seed" : "ssZkdwURFMBXenJPbrpE14b6noJSu"
}
}
```
Save the `validation_seed` (your node seed value) and the `validation_public_key` value (your node public key )
2. Edit your `rippled`'s config file.
vim /etc/opt/ripple/rippled.cfg
```
vim /etc/opt/ripple/rippled.cfg
```
{% include '_snippets/conf-file-location.md' %}<!--_ -->
{% partial file="/_snippets/conf-file-location.md" /%}
3. Add a `[node_seed]` stanza using the `validation_seed` value you generated earlier.
For example:
[node_seed]
ssZkdwURFMBXenJPbrpE14b6noJSu
```
[node_seed]
ssZkdwURFMBXenJPbrpE14b6noJSu
```
**Warning:** All servers should have unique `[node_seed]` values. If you copy your config file to another server, be sure to remove or change the `[node_seed]` value. Keep your `[node_seed]` secret; if a malicious actor gains access to this value, they could use it to impersonate your server in XRP Ledger peer-to-peer communications.
4. Restart your `rippled` server:
systemctl restart rippled
```
systemctl restart rippled
```
### 2. Communicate the stock server's node public key
@@ -110,10 +118,9 @@ The administrator of the stock server completes this step.
Use the [connect method][] to connect your server to the hub server. For example:
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
{% tabs %}
{% tab label="WebSocket" %}
```
{
"command": "connect",
@@ -121,9 +128,9 @@ Use the [connect method][] to connect your server to the hub server. For example
"port": 51235
}
```
{% /tab %}
*JSON-RPC*
{% tab label="JSON-RPC" %}
```
{
"method": "connect",
@@ -135,15 +142,15 @@ Use the [connect method][] to connect your server to the hub server. For example
]
}
```
{% /tab %}
*Commandline*
{% tab label="Commandline" %}
```
rippled connect 169.54.2.151 51235
```
{% /tab %}
<!-- MULTICODE_BLOCK_END -->
{% /tabs %}
If the hub server's administrator has set up the peer reservation as described in the previous steps, this should automatically connect and remain connected as long as possible.
@@ -163,12 +170,12 @@ As a server administrator, you can manage the reservations your server has for o
## See Also
- **Concepts:**
- [Peer Protocol](peer-protocol.html)
- [Consensus](consensus.html)
- [Parallel Networks](parallel-networks.html)
- [Peer Protocol](../../../concepts/networks-and-servers/peer-protocol.md)
- [Consensus](../../../concepts/consensus-protocol/index.md)
- [Parallel Networks](../../../concepts/networks-and-servers/parallel-networks.md)
- **Tutorials:**
- [Capacity Planning](capacity-planning.html)
- [Troubleshooting `rippled`](troubleshoot-the-rippled-server.html)
- [Capacity Planning](../../installation/capacity-planning.md)
- [Troubleshooting `rippled`](../../troubleshooting/index.md)
- **References:**
- [peers method][]
- [peer_reservations_add method][]
@@ -176,10 +183,6 @@ As a server administrator, you can manage the reservations your server has for o
- [peer_reservations_list method][]
- [connect method][]
- [fetch_info method][]
- [Peer Crawler](peer-crawler.html)
- [Peer Crawler](../../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

8
content/infrastructure/configuration/server-modes/index.md
View File

@@ -1,9 +1,13 @@
---
html: server-modes.html
parent: configure-rippled.html
template: pagetype-category.html.jinja
metadata:
indexPage: true
blurb: Information on how to run a core server in different modes specialized for different purposes.
---
# Server Modes
The core XRP Ledger server can run in different modes specialized for different purposes.
The core XRP Ledger server can run in different modes specialized for different purposes.
{% child-pages /%}

32
content/infrastructure/configuration/server-modes/run-rippled-as-a-stock-server.md
View File

@@ -7,49 +7,45 @@ labels:
---
# 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 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](../../../introduction/software-ecosystem.md) 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)
- Connects to a [network of peers](../../../concepts/networks-and-servers/peer-protocol.md)
- Relays cryptographically signed [transactions](transactions.html)
- Relays cryptographically signed [transactions](../../../concepts/transactions/index.md)
- Maintains a local copy of the complete shared global [ledger](ledgers.html)
- Maintains a local copy of the complete shared global [ledger](../../../concepts/ledgers/index.md)
To participate in the [consensus process](consensus.html) as a validator, [run rippled as a validator](run-rippled-as-a-validator.html) instead.
To participate in the [consensus process](../../../concepts/consensus-protocol/index.md) as a validator, [run rippled as a validator](run-rippled-as-a-validator.md) 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).
The default package installation installs a stock server with a small amount of transaction history. For installation steps, see [Install `rippled`](../../installation/index.md).
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).
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](../data-retention/configure-online-deletion.md).
## Troubleshooting
For more information, see [Troubleshooting `rippled`](troubleshoot-the-rippled-server.html)
For more information, see [Troubleshooting `rippled`](../../troubleshooting/index.md)
## See Also
- **Concepts:**
- [XRP Ledger Overview](xrp-ledger-overview.html)
- [The `rippled` Server](xrpl-servers.html)
- [XRP Ledger Overview](/about/)
- [The `rippled` Server](../../../concepts/networks-and-servers/index.md)
- **Tutorials:**
- [Cluster rippled Servers](cluster-rippled-servers.html)
- [Install `rippled`](install-rippled.html)
- [Capacity Planning](capacity-planning.html)
- [Cluster rippled Servers](../peering/cluster-rippled-servers.md)
- [Install `rippled`](../../installation/index.md)
- [Capacity Planning](../../installation/capacity-planning.md)
- **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' %}
{% raw-partial file="/_snippets/common-links.md" /%}

134
content/infrastructure/configuration/server-modes/run-rippled-as-a-validator.md
View File

@@ -10,15 +10,15 @@ 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:
A [`rippled` server](../../../concepts/networks-and-servers/index.md) running in [validator mode](../../../concepts/networks-and-servers/rippled-server-modes.md) does everything a stock server does:
- Connects to a [network of peers](peer-protocol.html)
- Connects to a [network of peers](../../../concepts/networks-and-servers/peer-protocol.md)
- Relays cryptographically signed [transactions](transactions.html)
- Relays cryptographically signed [transactions](../../../concepts/transactions/index.md)
- Maintains a local copy of the complete shared global [ledger](ledgers.html)
- Maintains a local copy of the complete shared global [ledger](../../../concepts/ledgers/index.md)
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).
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](../../../concepts/consensus-protocol/consensus-principles-and-rules.md#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.
@@ -42,7 +42,7 @@ Strive to have your validator embody the following properties. Being a good vali
- **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.
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](../../installation/system-requirements.md), 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.
@@ -56,7 +56,7 @@ It is strongly recommended that operators use the list providers that are presen
## 2. Install a `rippled` server
For more information, see [Install `rippled`](install-rippled.html).
For more information, see [Install `rippled`](../../installation/index.md).
@@ -72,19 +72,25 @@ In a secure location **not** on your validator:
2. Generate a validator key pair using the `create_keys` command.
$ validator-keys create_keys
```
$ validator-keys create_keys
```
Sample output on Ubuntu:
Validator keys stored in /home/my-user/.ripple/validator-keys.json
```
Validator keys stored in /home/my-user/.ripple/validator-keys.json
This file should be stored securely and not shared.
This file should be stored securely and not shared.
```
Sample output on macOS:
Validator keys stored in /Users/my-user/.ripple/validator-keys.json
```
Validator keys stored in /Users/my-user/.ripple/validator-keys.json
This file should be stored securely and not shared.
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.
@@ -92,23 +98,27 @@ In a secure location **not** on your validator:
3. Generate a validator token using the `create_token` command.
$ validator-keys create_token --keyfile /PATH/TO/YOUR/validator-keys.json
```
$ validator-keys create_token --keyfile /PATH/TO/YOUR/validator-keys.json
```
Sample output:
Update rippled.cfg file with these values:
```
Update rippled.cfg file with these values:
# validator public key: nHUtNnLVx7odrz5dnfb2xpIgbEeJPbzJWfdicSkGyVw1eE5GpjQr
# validator public key: nHUtNnLVx7odrz5dnfb2xpIgbEeJPbzJWfdicSkGyVw1eE5GpjQr
[validator_token]
eyJ2YWxpZGF0aW9uX3NlY3J|dF9rZXkiOiI5ZWQ0NWY4NjYyNDFjYzE4YTI3NDdiNT
QzODdjMDYyNTkwNzk3MmY0ZTcxOTAyMzFmYWE5Mzc0NTdmYT|kYWY2IiwibWFuaWZl
c3QiOiJKQUFBQUFGeEllMUZ0d21pbXZHdEgyaUNjTUpxQzlnVkZLaWxHZncxL3ZDeE
hYWExwbGMyR25NaEFrRTFhZ3FYeEJ3RHdEYklENk9NU1l1TTBGREFscEFnTms4U0tG
bjdNTzJmZGtjd1JRSWhBT25ndTlzQUtxWFlvdUorbDJWMFcrc0FPa1ZCK1pSUzZQU2
hsSkFmVXNYZkFpQnNWSkdlc2FhZE9KYy9hQVpva1MxdnltR21WcmxIUEtXWDNZeXd1
NmluOEhBU1FLUHVnQkQ2N2tNYVJGR3ZtcEFUSGxHS0pkdkRGbFdQWXk1QXFEZWRGdj
VUSmEydzBpMjFlcTNNWXl3TFZKWm5GT3I3QzBrdzJBaVR6U0NqSXpkaXRROD0ifQ==
[validator_token]
eyJ2YWxpZGF0aW9uX3NlY3J|dF9rZXkiOiI5ZWQ0NWY4NjYyNDFjYzE4YTI3NDdiNT
QzODdjMDYyNTkwNzk3MmY0ZTcxOTAyMzFmYWE5Mzc0NTdmYT|kYWY2IiwibWFuaWZl
c3QiOiJKQUFBQUFGeEllMUZ0d21pbXZHdEgyaUNjTUpxQzlnVkZLaWxHZncxL3ZDeE
hYWExwbGMyR25NaEFrRTFhZ3FYeEJ3RHdEYklENk9NU1l1TTBGREFscEFnTms4U0tG
bjdNTzJmZGtjd1JRSWhBT25ndTlzQUtxWFlvdUorbDJWMFcrc0FPa1ZCK1pSUzZQU2
hsSkFmVXNYZkFpQnNWSkdlc2FhZE9KYy9hQVpva1MxdnltR21WcmxIUEtXWDNZeXd1
NmluOEhBU1FLUHVnQkQ2N2tNYVJGR3ZtcEFUSGxHS0pkdkRGbFdQWXk1QXFEZWRGdj
VUSmEydzBpMjFlcTNNWXl3TFZKWm5GT3I3QzBrdzJBaVR6U0NqSXpkaXRROD0ifQ==
```
On your validator:
@@ -118,11 +128,15 @@ On your validator:
2. Restart `rippled`.
$ sudo systemctl restart rippled.service
```
$ 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
```
$ 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.
@@ -140,12 +154,12 @@ This section describes three different configurations you can use to connect you
- [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).
For a comparison of these approaches, see [Pros and Cons of Peering Configurations](../../../concepts/networks-and-servers/peer-protocol.md#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.
This configuration connects your validator to the XRP Ledger network using [discovered peers](../../../concepts/networks-and-servers/peer-protocol.md#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/XRPLF/rippled/blob/develop/cfg/rippled-example.cfg) is delivered with this configuration.
@@ -156,11 +170,11 @@ This configuration connects your validator to the network through stock `rippled
_**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).
1. Set up stock `rippled` servers. For more information, see [Install rippled](../../installation/index.md).
2. Configure your validator and stock `rippled` servers to run in a [cluster](cluster-rippled-servers.html).
2. Configure your validator and stock `rippled` servers to run in a [cluster](../peering/cluster-rippled-servers.md).
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.
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](../../../concepts/networks-and-servers/peer-protocol.md#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.
@@ -172,27 +186,33 @@ _**To connect your validator to the XRP Ledger network using proxies:**_
5. Restart `rippled`.
$ sudo systemctl restart rippled.service
```
$ 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.
6. Use the [Peer Crawler](../../../references/http-websocket-apis/peer-port-methods/peer-crawler.md) 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
```
$ 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.
This configuration connects your validator to the network using three [public hubs](../../../concepts/networks-and-servers/rippled-server-modes.md#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
```
[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.
@@ -206,8 +226,10 @@ _**To connect your validator to the network using public hubs:**_
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
```
[peer_private]
1
```
**Warning:** Be sure that you don't publish your validator's IP address in other ways.
@@ -215,7 +237,9 @@ _**To connect your validator to the network using public hubs:**_
3. Restart `rippled`.
$ sudo systemctl restart rippled.service
```
$ sudo systemctl restart rippled.service
```
@@ -223,17 +247,17 @@ _**To connect your validator to the network using public hubs:**_
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.
- Use the [`peers`](../../../references/http-websocket-apis/admin-api-methods/peer-management-methods/peers.md) 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`.
- Use the [`server_info`](../../../references/http-websocket-apis/public-api-methods/server-info-methods/server_info.md) 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).
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](../../../references/http-websocket-apis/api-conventions/rippled-server-states.md) and [Get the `server_info`](../../troubleshooting/diagnosing-problems.md#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.
- Use the [`validators`](../../../references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/validators.md) 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.
@@ -251,7 +275,7 @@ 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.
2. Serve an [`xrp-ledger.toml`](../../../references/xrp-ledger-toml.md) file at your domain, and complete the [domain verification](../../../references/xrp-ledger-toml.md#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.
@@ -266,20 +290,16 @@ For information about how to revoke a master key pair you generated for your val
## See Also
- **Concepts:**
- [XRP Ledger Overview](xrp-ledger-overview.html)
- [The `rippled` Server](xrpl-servers.html)
- [XRP Ledger Overview](/about/)
- [The `rippled` Server](../../../concepts/networks-and-servers/index.md)
- **Tutorials:**
- [Cluster rippled Servers](cluster-rippled-servers.html)
- [Install `rippled`](install-rippled.html)
- [Capacity Planning](capacity-planning.html)
- [Cluster rippled Servers](../peering/cluster-rippled-servers.md)
- [Install `rippled`](../../installation/index.md)
- [Capacity Planning](../../installation/capacity-planning.md)
- **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' %}
{% raw-partial file="/_snippets/common-links.md" /%}

8
content/infrastructure/index.md
View File

@@ -1,9 +1,13 @@
---
html: infrastructure.html
parent: docs.html
template: pagetype-category.html.jinja
metadata:
indexPage: true
top_nav_grouping: Article Types
---
# Infrastructure
Install, configure, and manage the software that powers the XRP Ledger.
Install, configure, and manage the software that powers the XRP Ledger.
{% child-pages /%}

5
content/infrastructure/installation/build-on-linux-mac-windows.md
View File

@@ -13,7 +13,4 @@ Building `rippled` across various platforms such as Windows, Linux, or macOS req
To continue, proceed to [the latest `rippled` build instructions on GitHub](https://github.com/XRPLF/rippled/blob/develop/BUILD.md).
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

194
content/infrastructure/installation/build-run-rippled-in-reporting-mode.md
View File

@@ -9,13 +9,13 @@ top_nav_grouping: Popular Pages
---
# Build and Run `rippled` in Reporting Mode
[Reporting mode](rippled-server-modes.html) is a mode of the XRP Ledger core server specialized for serving [HTTP and WebSocket APIs](http-websocket-apis.html).
[Reporting mode](../../concepts/networks-and-servers/rippled-server-modes.md) is a mode of the XRP Ledger core server specialized for serving [HTTP and WebSocket APIs](../../references/http-websocket-apis/index.md).
In reporting mode, the server does not connect to the peer-to-peer network. Instead, it uses gRPC to get validated data from one or more trusted servers that are connected to the P2P network.
It can then efficiently handle API calls, reducing the load on `rippled` servers running in P2P mode.
{{ include_svg("img/reporting-mode-basic-architecture.svg", "Figure 1: Working of `rippled` in reporting mode") }}
[{% inline-svg file="/img/reporting-mode-basic-architecture.svg" /%}](/img/reporting-mode-basic-architecture.svg "Figure 1: Working of `rippled` in reporting mode")
The reporting mode of `rippled` uses two datastores:
@@ -31,7 +31,7 @@ Multiple reporting mode servers can share access to the same network accessible
### Prerequisites
1. Ensure that your system meets the [system requirements](system-requirements.html).
1. Ensure that your system meets the [system requirements](system-requirements.md).
**Note:** If you choose to use Cassandra as the database, the disk requirements for `rippled` will be lower as the data will not be stored on your local disk.
@@ -47,7 +47,9 @@ Multiple reporting mode servers can share access to the same network accessible
3. On macOS, you need to manually install the Cassandra cpp driver. On all other platforms, the Cassandra driver is built as part of the `rippled` build.
brew install cassandra-cpp-driver
```
brew install cassandra-cpp-driver
```
#### Install PostgreSQL
@@ -57,29 +59,35 @@ Multiple reporting mode servers can share access to the same network accessible
2. Connect to the PostgreSQL Database Server using `psql`, and create a user `newuser` and a database `reporting`.
psql postgres
CREATE ROLE newuser WITH LOGIN PASSWORD ‘password’;
ALTER ROLE newuser CREATEDB;
\q
psql postgres -U newuser
postgres=# create database reporting;
```
psql postgres
CREATE ROLE newuser WITH LOGIN PASSWORD ‘password’;
ALTER ROLE newuser CREATEDB;
\q
psql postgres -U newuser
postgres=# create database reporting;
```
**Install PostgreSQL on macOS**
1. Download and install PostgreSQL on macOS.
brew install postgres
brew services start postgres
```
brew install postgres
brew services start postgres
```
2. Connect to the PostgreSQL Database Server using `psql` and create a user `newuser` and a database `reporting`.
psql postgres
CREATE ROLE newuser WITH LOGIN PASSWORD ‘password’;
ALTER ROLE newuser CREATEDB;
\q
psql postgres -U newuser
postgres=# create database reporting;
```
psql postgres
CREATE ROLE newuser WITH LOGIN PASSWORD ‘password’;
ALTER ROLE newuser CREATEDB;
\q
psql postgres -U newuser
postgres=# create database reporting;
```
#### Install and Configure the Primary Persistent Datastore
@@ -89,9 +97,11 @@ Install Cassandra and then create a keyspace for `rippled`, with replication. <!
While a replication factor of 3 is recommended, when running locally, replication is not needed and you can set `replication_factor` to 1.
$ cqlsh [host] [port]
> CREATE KEYSPACE `rippled` WITH REPLICATION =
{'class' : 'SimpleStrategy', 'replication_factor' : 1 };
```
$ cqlsh [host] [port]
> CREATE KEYSPACE `rippled` WITH REPLICATION =
{'class' : 'SimpleStrategy', 'replication_factor' : 1 };
```
**NuDB**
@@ -104,29 +114,30 @@ NuDB is installed as part of your `rippled` build setup and does not require any
1. Build `rippled` for reporting mode on [Ubuntu or macOS](https://github.com/XRPLF/rippled/blob/release/BUILD.md).
<!-- MULTICODE_BLOCK_START -->
{% tabs %}
*Linux*
```{% label="Linux" %}
wget https://github.com/Kitware/CMake/releases/download/v3.16.3/cmake-3.16.3-Linux-x86_64.sh
sudo sh cmake-3.16.3-Linux-x86_64.sh --prefix=/usr/local --exclude-subdir
cmake -B build -Dreporting=ON -DCMAKE_BUILD_TYPE=Debug
cmake --build build --parallel $(nproc)
```
wget https://github.com/Kitware/CMake/releases/download/v3.16.3/cmake-3.16.3-Linux-x86_64.sh
sudo sh cmake-3.16.3-Linux-x86_64.sh --prefix=/usr/local --exclude-subdir
cmake -B build -Dreporting=ON -DCMAKE_BUILD_TYPE=Debug
cmake --build build --parallel $(nproc)
```{% label="macOS" %}
cmake -B build -G "Unix Makefiles" -Dreporting=ON -DCMAKE_BUILD_TYPE=Debug
cmake --build build --parallel $(nproc)
```
*macOS*
cmake -B build -G "Unix Makefiles" -Dreporting=ON -DCMAKE_BUILD_TYPE=Debug
cmake --build build --parallel $(nproc)
<!-- MULTICODE_BLOCK_END -->
{% /tabs %}
2. Create a configuration file to run `rippled` in reporting mode.
Make a copy of the example config file, `rippled-example.cfg`, and save it as `rippled-reporting-mode.cfg` in a location that enables you to run `rippled` as a non-root user. For example:
mkdir -p $HOME/.config/ripple
cp <RIPPLED_SOURCE>/cfg/rippled-example.cfg $HOME/.config/ripple/rippled-reporting-mode.cfg
```
mkdir -p $HOME/.config/ripple
cp <RIPPLED_SOURCE>/cfg/rippled-example.cfg $HOME/.config/ripple/rippled-reporting-mode.cfg
```
3. Edit rippled-reporting-mode.cfg to set necessary file paths. The user you plan to run `rippled` as must have write permissions to all of the paths you specify here.
@@ -142,75 +153,89 @@ NuDB is installed as part of your `rippled` build setup and does not require any
1. Uncomment the `[reporting]` stanza or add a new one:
[reporting]
etl_source
read_only=0
```
[reporting]
etl_source
read_only=0
```
2. List the `rippled` sources (ETL sources) to extract data from. These `rippled` servers must have gRPC enabled.
NOTE: Only include servers that you trust as reporting mode does not connect to the P2P network and hence cannot verify that the data actually matches the network consensus ledger.
[etl_source]
source_grpc_port=50051
source_ws_port=6006
source_ip=127.0.0.1
```
[etl_source]
source_grpc_port=50051
source_ws_port=6006
source_ip=127.0.0.1
```
5. Configure the databases
1. Specify the Postgres DB for `[ledger_tx_tables]`:
[ledger_tx_tables]
conninfo = postgres://newuser:password@127.0.0.1/reporting
use_tx_tables=1
```
[ledger_tx_tables]
conninfo = postgres://newuser:password@127.0.0.1/reporting
use_tx_tables=1
```
2. Specify the database for `[node_db]`.
<!-- MULTICODE_BLOCK_START -->
{% tabs %}
*NuDB*
```{% label="NuDB" %}
[node_db]
type=NuDB
path=/home/ubuntu/ripple/
[node_db]
type=NuDB
path=/home/ubuntu/ripple/
[ledger_history]
1000000
```
[ledger_history]
1000000
```{% label="Cassandra" %}
[node_db]
type=Cassandra
*Cassandra*
[ledger_history]
1000000
```
[node_db]
type=Cassandra
[ledger_history]
1000000
<!-- MULTICODE_BLOCK_END -->
{% /tabs %}
6. Modify the configuration for `rippled` to open up ports.
1. Open the public websocket port:
[port_ws_admin_local]
port = 6006
ip = 127.0.0.1
admin = 127.0.0.1
protocol = ws
```
[port_ws_admin_local]
port = 6006
ip = 127.0.0.1
admin = 127.0.0.1
protocol = ws
```
2. Open the gRPC port:
[port_grpc]
port = 60051
ip = 0.0.0.0
```
[port_grpc]
port = 60051
ip = 0.0.0.0
```
3. Add a secured gateway to the IP of your reporting system:
secure_gateway = 127.0.0.1
```
secure_gateway = 127.0.0.1
```
7. Run `rippled` in reporting mode:
./rippled --conf /home/ubuntu/.config/ripple/rippled-reporting-example.cfg
```
./rippled --conf /home/ubuntu/.config/ripple/rippled-reporting-example.cfg
```
### What to Expect
@@ -280,22 +305,22 @@ Loading: "/home/ubuntu/.config/ripple/rippled-reporting-example.cfg"
2021-Dec-09 21:31:53.291048 UTC NetworkOPs:NFO STATE->full
2021-Dec-09 21:31:53.291192 UTC Application:FTL Startup RPC:
{
"command" : "log_level",
"severity" : "debug"
"command" : "log_level",
"severity" : "debug"
}
2021-Dec-09 21:31:53.291347 UTC RPCHandler:DBG RPC call log_level completed in 2.2e-08seconds
2021-Dec-09 21:31:53.291440 UTC Application:FTL Result:
{
"warnings" :
[
{
"id" : 1004,
"message" : "This is a reporting server. The default behavior of a reporting server is to only return validated data. If you are looking for not yet validated data, include \"ledger_index : current\" in your request, which will cause this server to forward the request to a p2p node. If the forward is successful the response will include \"forwarded\" : \"true\""
}
]
"warnings" :
[
{
"id" : 1004,
"message" : "This is a reporting server. The default behavior of a reporting server is to only return validated data. If you are looking for not yet validated data, include \"ledger_index : current\" in your request, which will cause this server to forward the request to a p2p node. If the forward is successful the response will include \"forwarded\" : \"true\""
}
]
}
@@ -332,7 +357,7 @@ The answer depends on the location of your primary data store. If you use Cassan
Lastly, the P2P mode server only needs to keep very recent history, while the reporting mode server keeps long term history.
For more information on system requirements to run `rippled`, see the [`rippled` system requirements](system-requirements.html).
For more information on system requirements to run `rippled`, see the [`rippled` system requirements](system-requirements.md).
**How can I confirm the validity of the data that comes from the PostgreSQL or Cassandra database?**
@@ -342,7 +367,4 @@ When `rippled` runs in reporting mode, it only serves validated data from the ET
Technically, you *can* directly access the database if you want. However, the data is stored as binary blobs and you have to decode the blobs to access the data in them. This makes traditional SQL queries much less useful since they cannot find and filter the individual fields of the data.
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

45
content/infrastructure/installation/capacity-planning.md
View File

@@ -10,7 +10,7 @@ labels:
This document describes configuration, network, and hardware recommendations that you can use to tune and optimize the performance of an XRP Ledger server.
The load on an XRP Ledger server varies based on multiple factors. One is the activity in the network. The total size of data in the shared ledger and the total volume of transactions being sent vary based on organic factors throughout the global XRP Ledger community. Another factor is API usage; different types of [API calls](http-websocket-apis.html) put different load on the server. The performance characteristics can be very different between servers that provide a public API, provide a private API to specific integration software, or provide no API at all.
The load on an XRP Ledger server varies based on multiple factors. One is the activity in the network. The total size of data in the shared ledger and the total volume of transactions being sent vary based on organic factors throughout the global XRP Ledger community. Another factor is API usage; different types of [API calls](../../references/http-websocket-apis/index.md) put different load on the server. The performance characteristics can be very different between servers that provide a public API, provide a private API to specific integration software, or provide no API at all.
You should consider these factors to ensure that your server has the capacity to handle XRP Ledger network activity today and in the future.
@@ -25,7 +25,7 @@ The settings in this section are parameters in the `rippled.cfg` file. You can a
### Node Size
The `[node_size]` parameter should match the overall hardware capacity of your server. You can omit this parameter to have the server automatically choose an appropriate setting based on the system's total RAM and number of CPU threads. You can set this value explicitly if the automatic setting is wrong for your system, for example if some of the system's RAM or threads need to be set aside for other software, or the amounts reported by the operating system are inaccurate. (This can occur in some containers.) [Updated in: rippled 1.8.1][]
The `[node_size]` parameter should match the overall hardware capacity of your server. You can omit this parameter to have the server automatically choose an appropriate setting based on the system's total RAM and number of CPU threads. You can set this value explicitly if the automatic setting is wrong for your system, for example if some of the system's RAM or threads need to be set aside for other software, or the amounts reported by the operating system are inaccurate. (This can occur in some containers.) {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.8.1" %}Updated in: rippled 1.8.1{% /badge %}
As a general rule, you should always use the largest node size your available RAM can support. See the following table for recommended settings.
@@ -43,7 +43,7 @@ To tune your server, it may be useful to start with `tiny` and increase the size
| 32 GB | `large` | **Not recommended.** In practice, this setting performs worse than `huge` in most circumstances. Always use `huge` if you want stability. |
| 64 GB | `huge` | Recommended for production servers. |
If you set the `[node_size]` parameter to an invalid value, the [server fails to start](server-wont-start.html#bad-node_size-value).
If you set the `[node_size]` parameter to an invalid value, the [server fails to start](../troubleshooting/server-wont-start.md#bad-node_size-value).
### Node DB Type
@@ -97,7 +97,7 @@ online_delete=2000
advisory_delete=0
```
Adjust the `path` to the directory where you want to keep the ledger store on disk. Adjust the `online_delete` and `advisory_delete` settings as desired for your configuration. For more details about these settings, see [Configure Online Deletion](configure-online-deletion.html) and [Configure Advisory Deletion](configure-advisory-deletion.html).
Adjust the `path` to the directory where you want to keep the ledger store on disk. Adjust the `online_delete` and `advisory_delete` settings as desired for your configuration. For more details about these settings, see [Configure Online Deletion](../configuration/data-retention/configure-online-deletion.md) and [Configure Advisory Deletion](../configuration/data-retention/configure-advisory-deletion.md).
### Log Level
@@ -113,7 +113,7 @@ Each server in the XRP Ledger network performs all of the transaction processing
### Recommendation
See [System Requirements](system-requirements.html) for a summary of the recommended hardware specs.
See [System Requirements](system-requirements.md) for a summary of the recommended hardware specs.
#### CPU Utilization and Virtualization
<!-- STYLE_OVERRIDE: utilization -->
@@ -131,9 +131,9 @@ The speed of storage is one of the most important factors in a server's capacity
#### Disk Space
The `[node_db]` stanza controls the server's _ledger store_, which holds [ledger history](ledger-history.html). The amount of disk space you need depends on how much history you plan to keep available locally. An XRP Ledger server does not need to store more than the most recent 256 ledger versions to follow the consensus process and report the complete state of the ledger, but you can only query your server for transactions that executed in ledger versions it has stored locally. Configure the `path` of the `[node_db]` to point to your chosen storage location for the ledger store.
The `[node_db]` stanza controls the server's _ledger store_, which holds [ledger history](../../concepts/networks-and-servers/ledger-history.md). The amount of disk space you need depends on how much history you plan to keep available locally. An XRP Ledger server does not need to store more than the most recent 256 ledger versions to follow the consensus process and report the complete state of the ledger, but you can only query your server for transactions that executed in ledger versions it has stored locally. Configure the `path` of the `[node_db]` to point to your chosen storage location for the ledger store.
You can control how much data you keep with [online deletion](online-deletion.html); the default config file has the server keep the latest 2000 ledger versions. Without online deletion, the server's disk requirements grow without bounds.
You can control how much data you keep with [online deletion](../configuration/data-retention/online-deletion.md); the default config file has the server keep the latest 2000 ledger versions. Without online deletion, the server's disk requirements grow without bounds.
The following table approximates the requirements for different amounts of history, at the time of writing (2023-07-19):
@@ -152,18 +152,18 @@ These numbers are estimates. They depend on several factors, most importantly th
The `online_delete` setting tells the server how many ledger versions to keep after deleting old history. You should plan for enough disk space to store twice that many ledger versions at maximum (right before online deletion runs).
For instructions on how to change the amount of history you keep, see [Configure Online Deletion](configure-online-deletion.html).
For instructions on how to change the amount of history you keep, see [Configure Online Deletion](../configuration/data-retention/configure-online-deletion.md).
The `[database_path]` configures separate bookkeeping databases: these include transaction data as well as some runtime configurations.
As a general rule, you can safely delete the database files (both the ledger store and the bookkeeping databases) for a `rippled` server when it isn't running; this clears any stored ledger history the server has, but it can re-acquire that data from the network. However, if you delete the `wallet.db` file in the `[database_path]`, you must manually reapply runtime configuration changes such as [amendment votes](configure-amendment-voting.html) and [peer reservations](use-a-peer-reservation.html).
As a general rule, you can safely delete the database files (both the ledger store and the bookkeeping databases) for a `rippled` server when it isn't running; this clears any stored ledger history the server has, but it can re-acquire that data from the network. However, if you delete the `wallet.db` file in the `[database_path]`, you must manually reapply runtime configuration changes such as [amendment votes](../configuration/configure-amendment-voting.md) and [peer reservations](../configuration/peering/use-a-peer-reservation.md).
If you want to contribute to storing ledger history but you do not have enough disk space to store full history, you can use the [History Sharding](history-sharding.html) feature to store a randomized range of ledgers in a separate shard store. History sharding is configured in the `[shard_db]` stanza.
If you want to contribute to storing ledger history but you do not have enough disk space to store full history, you can use the [History Sharding](../configuration/data-retention/history-sharding.md) feature to store a randomized range of ledgers in a separate shard store. History sharding is configured in the `[shard_db]` stanza.
##### Amazon Web Services
Amazon Web Services (AWS) is a popular virtualized hosting environment. You can run `rippled` in AWS, but do not use Elastic Block Storage (EBS). See [System Requirements](system-requirements.html). <!-- SPELLING_IGNORE: ebs, aws -->
Amazon Web Services (AWS) is a popular virtualized hosting environment. You can run `rippled` in AWS, but do not use Elastic Block Storage (EBS). See [System Requirements](system-requirements.md). <!-- SPELLING_IGNORE: ebs, aws -->
AWS instance stores (`ephemeral` storage) provide suitable performance, but you may lose data in some circumstances, including when you start/stop an instance. This may be acceptable, since an individual XRP Ledger server can usually re-acquire lost ledger history from its peers. Configuration settings should be stored on more permanent storage.
@@ -175,7 +175,7 @@ Memory requirements are mainly a function of the `node_size` configuration setti
#### Network
Any enterprise or carrier-class data center should have enough network bandwidth to support running XRP Ledger servers. The actual bandwidth necessary varies significantly based on the current transaction volume in the network. Server behavior (such as backfilling [ledger history](ledger-history.html)) also affects network use. Consumer-grade home internet is generally not enough to run a reliable server.
Any enterprise or carrier-class data center should have enough network bandwidth to support running XRP Ledger servers. The actual bandwidth necessary varies significantly based on the current transaction volume in the network. Server behavior (such as backfilling [ledger history](../../concepts/networks-and-servers/ledger-history.md)) also affects network use. Consumer-grade home internet is generally not enough to run a reliable server.
During exceptionally high periods of transaction volume, some operators have reported that their servers have completely saturated a 100 megabit/s network link, so a gigabit network interface is required for reliable performance.
@@ -188,26 +188,23 @@ Here are examples of observed uncompressed network bandwidth use for common task
| Serve historical ledger and transaction reports | 100 Mbps up |
| Start up `rippled` | 20 Mbps down |
You can save bandwidth by [enabling compression on peer-to-peer communications](enable-link-compression.html), at a cost of higher CPU. Many hardware configurations have spare CPU capacity during normal use, so this can be an economical option if your network bandwidth is limited.
You can save bandwidth by [enabling compression on peer-to-peer communications](../configuration/peering/enable-link-compression.md), at a cost of higher CPU. Many hardware configurations have spare CPU capacity during normal use, so this can be an economical option if your network bandwidth is limited.
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Consensus](consensus.html)
- [The `rippled` Server](../../concepts/networks-and-servers/index.md)
- [Consensus](../../concepts/consensus-protocol/index.md)
- **Tutorials:**
- [Configure rippled](configure-rippled.html)
- [Configure Online Deletion](configure-online-deletion.html) - Adjust how many historical ledger versions your server should keep at a time.
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
- [Configure rippled](../configuration/index.md)
- [Configure Online Deletion](../configuration/data-retention/configure-online-deletion.md) - Adjust how many historical ledger versions your server should keep at a time.
- [Troubleshoot rippled](../troubleshooting/index.md)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`rippled` Commandline Usage](commandline-usage.html)
- [rippled API Reference](../../references/http-websocket-apis/index.md)
- [`rippled` Commandline Usage](../commandline-usage.md)
- [logrotate method][] - Closes and reopens the server's debug log so you can rotate it with standard tools.
- [server_info method][] - General information about the server including sync status and how many historical ledger versions it has available on disk.
- [get_counts method][] - Additional health information, especially how many objects of various types it holds in RAM.
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

8
content/infrastructure/installation/index.md
View File

@@ -2,9 +2,13 @@
html: install-rippled.html
parent: infrastructure.html
top_nav_name: Install & Configure
template: pagetype-category.html.jinja
metadata:
indexPage: true
blurb: Install and update XRP Ledger servers including the core server, rippled, and API server, Clio.
---
# Installation
Install and update XRP Ledger servers including the core server, rippled, and API server, Clio.
Install and update XRP Ledger servers including the core server, rippled, and API server, Clio.
{% child-pages /%}

114
content/infrastructure/installation/install-clio-on-ubuntu.md
View File

@@ -16,7 +16,7 @@ These instructions install a binary that has been compiled by Ripple. For instru
Before you install Clio, you must meet the following requirements.
- Ensure that your system meets the [system requirements](system-requirements.html).
- Ensure that your system meets the [system requirements](system-requirements.md).
**Note:** Clio has the same system requirements as the `rippled` server, except Clio needs less disk space to store the same amount of ledger history.
@@ -26,69 +26,91 @@ Before you install Clio, you must meet the following requirements.
- If you choose to persist Clio data, run Cassandra in a Docker container and specify an empty directory to store Clio data:
docker run --rm -it --network=host --name cassandra -v $PWD/cassandra_data:/var/lib/
cassandra cassandra:4.0.4
```
docker run --rm -it --network=host --name cassandra -v $PWD/cassandra_data:/var/lib/
cassandra cassandra:4.0.4
```
- If you do not wish to persist Clio data, run the following command:
docker run --rm -it --network=host --name cassandra cassandra:4.0.4
```
docker run --rm -it --network=host --name cassandra cassandra:4.0.4
```
- You need gRPC access to one or more `rippled` servers in P2P mode. The `rippled` servers can either be local or remote, but you must trust them. The most reliable way to do this is to [install `rippled` yourself](install-rippled.html).
- You need gRPC access to one or more `rippled` servers in P2P mode. The `rippled` servers can either be local or remote, but you must trust them. The most reliable way to do this is to [install `rippled` yourself](index.md).
## Installation Steps
1. Update repositories:
sudo apt -y update
```
sudo apt -y update
```
**Tip:** If you have already installed an up-to-date version of `rippled` on the same machine, you can skip the following steps for adding Ripple's package repository and signing key, which are the same as in the `rippled` install process. Resume from step 5, "Fetch the Ripple repository."
2. Install utilities:
sudo apt -y install apt-transport-https ca-certificates wget gnupg
```
sudo apt -y install apt-transport-https ca-certificates wget gnupg
```
3. Add Ripple's package-signing GPG key to your list of trusted keys:
sudo mkdir /usr/local/share/keyrings/
wget -q -O - "https://repos.ripple.com/repos/api/gpg/key/public" | gpg --dearmor > ripple-key.gpg
sudo mv ripple-key.gpg /usr/local/share/keyrings
```
sudo mkdir /usr/local/share/keyrings/
wget -q -O - "https://repos.ripple.com/repos/api/gpg/key/public" | gpg --dearmor > ripple-key.gpg
sudo mv ripple-key.gpg /usr/local/share/keyrings
```
4. Check the fingerprint of the newly-added key:
gpg /usr/local/share/keyrings/ripple-key.gpg
```
gpg /usr/local/share/keyrings/ripple-key.gpg
```
The output should include an entry for Ripple such as the following:
gpg: WARNING: no command supplied. Trying to guess what you mean ...
pub rsa3072 2019-02-14 [SC] [expires: 2026-02-17]
C0010EC205B35A3310DC90DE395F97FFCCAFD9A2
uid TechOps Team at Ripple <techops+rippled@ripple.com>
sub rsa3072 2019-02-14 [E] [expires: 2026-02-17]
```
gpg: WARNING: no command supplied. Trying to guess what you mean ...
pub rsa3072 2019-02-14 [SC] [expires: 2026-02-17]
C0010EC205B35A3310DC90DE395F97FFCCAFD9A2
uid TechOps Team at Ripple <techops+rippled@ripple.com>
sub rsa3072 2019-02-14 [E] [expires: 2026-02-17]
```
In particular, make sure that the fingerprint matches. (In the above example, the fingerprint is on the third line, starting with `C001`.)
4. Add the appropriate Ripple repository for your operating system version:
echo "deb [signed-by=/usr/local/share/keyrings/ripple-key.gpg] https://repos.ripple.com/repos/rippled-deb focal stable" | \
sudo tee -a /etc/apt/sources.list.d/ripple.list
```
echo "deb [signed-by=/usr/local/share/keyrings/ripple-key.gpg] https://repos.ripple.com/repos/rippled-deb focal stable" | \
sudo tee -a /etc/apt/sources.list.d/ripple.list
```
The above example is appropriate for **Ubuntu 20.04 Focal Fossa**.
5. Fetch the Ripple repository.
sudo apt -y update
```
sudo apt -y update
```
6. Install the Clio software package. There are two options:
- To run `rippled` on the same machine, install the `clio` package, which sets up both servers:
sudo apt -y install clio
```
sudo apt -y install clio
```
- To run Clio on a separate machine from `rippled`, install the `clio-server` package, which sets up Clio only:
sudo apt -y install clio-server
```
sudo apt -y install clio-server
```
7. If you are running `rippled` on a separate machine, modify your Clio config file to point to it. You can skip this step if you used the `clio` package to install both on the same machine.
@@ -96,14 +118,16 @@ Before you install Clio, you must meet the following requirements.
1. Edit the Clio server's config file to modify the connection information for the `rippled` server. The package installs this file at `/opt/clio/etc/config.json`.
"etl_sources":
[
{
"ip":"127.0.0.1",
"ws_port":"6006",
"grpc_port":"50051"
}
]
```
"etl_sources":
[
{
"ip":"127.0.0.1",
"ws_port":"6006",
"grpc_port":"50051"
}
]
```
This includes:
@@ -119,28 +143,36 @@ Before you install Clio, you must meet the following requirements.
* Open a port to accept unencrypted WebSocket connections.
[port_ws_public]
port = 6005
ip = 0.0.0.0
protocol = ws
```
[port_ws_public]
port = 6005
ip = 0.0.0.0
protocol = ws
```
* Open a port to handle gRPC requests and specify the IP(s) of Clio server(s) in the `secure_gateway` entry.
[port_grpc]
port = 50051
ip = 0.0.0.0
secure_gateway = 127.0.0.1
```
[port_grpc]
port = 50051
ip = 0.0.0.0
secure_gateway = 127.0.0.1
```
**Tip:** If you are not running Clio on the same machine as `rippled`, change the `secure_gateway` in the example stanza to use the IP address of the Clio server.
8. Enable and start the Clio systemd service.
sudo systemctl enable clio
```
sudo systemctl enable clio
```
9. Start the `rippled` and Clio servers.
sudo systemctl start rippled
sudo systemctl start clio
```
sudo systemctl start rippled
sudo systemctl start clio
```
If you are starting with a fresh database, Clio needs to download the full ledger. This can take some time. If you are starting both servers for the first time, it can take even longer because Clio waits for `rippled` to sync before extracting ledgers.
@@ -151,4 +183,4 @@ Before you install Clio, you must meet the following requirements.
## See Also
- **Concepts:**
- [The Clio Server](the-clio-server.html)
- [The Clio Server](../../concepts/networks-and-servers/the-clio-server.md)

114
content/infrastructure/installation/install-rippled-on-centos-rhel-with-yum.md
View File

@@ -14,7 +14,7 @@ These instructions install a binary that has been compiled by Ripple.
## Prerequisites
Before you install `rippled`, you must meet the [System Requirements](system-requirements.html).
Before you install `rippled`, you must meet the [System Requirements](system-requirements.md).
## Installation Steps
@@ -27,88 +27,94 @@ Before you install `rippled`, you must meet the [System Requirements](system-req
- `unstable` for pre-release builds (`release` branch)
- `nightly` for experimental/development builds (`develop` branch)
<!-- MULTICODE_BLOCK_START -->
{% tabs %}
*Stable*
```{% label="Stable" %}
cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
[ripple-stable]
name=XRP Ledger Packages
enabled=1
gpgcheck=0
repo_gpgcheck=1
baseurl=https://repos.ripple.com/repos/rippled-rpm/stable/
gpgkey=https://repos.ripple.com/repos/rippled-rpm/stable/repodata/repomd.xml.key
REPOFILE
```
cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
[ripple-stable]
name=XRP Ledger Packages
enabled=1
gpgcheck=0
repo_gpgcheck=1
baseurl=https://repos.ripple.com/repos/rippled-rpm/stable/
gpgkey=https://repos.ripple.com/repos/rippled-rpm/stable/repodata/repomd.xml.key
REPOFILE
```{% label="Pre-release" %}
cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
[ripple-unstable]
name=XRP Ledger Packages
enabled=1
gpgcheck=0
repo_gpgcheck=1
baseurl=https://repos.ripple.com/repos/rippled-rpm/unstable/
gpgkey=https://repos.ripple.com/repos/rippled-rpm/unstable/repodata/repomd.xml.key
REPOFILE
```
*Pre-release*
```{% label="Development" %}
cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
[ripple-nightly]
name=XRP Ledger Packages
enabled=1
gpgcheck=0
repo_gpgcheck=1
baseurl=https://repos.ripple.com/repos/rippled-rpm/nightly/
gpgkey=https://repos.ripple.com/repos/rippled-rpm/nightly/repodata/repomd.xml.key
REPOFILE
```
cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
[ripple-unstable]
name=XRP Ledger Packages
enabled=1
gpgcheck=0
repo_gpgcheck=1
baseurl=https://repos.ripple.com/repos/rippled-rpm/unstable/
gpgkey=https://repos.ripple.com/repos/rippled-rpm/unstable/repodata/repomd.xml.key
REPOFILE
*Development*
cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
[ripple-nightly]
name=XRP Ledger Packages
enabled=1
gpgcheck=0
repo_gpgcheck=1
baseurl=https://repos.ripple.com/repos/rippled-rpm/nightly/
gpgkey=https://repos.ripple.com/repos/rippled-rpm/nightly/repodata/repomd.xml.key
REPOFILE
<!-- MULTICODE_BLOCK_END -->
{% /tabs %}
2. Fetch the latest repo updates:
sudo yum -y update
```
sudo yum -y update
```
3. Install the new `rippled` package:
sudo yum install rippled
```
sudo yum install rippled
```
4. Reload systemd unit files:
sudo systemctl daemon-reload
```
sudo systemctl daemon-reload
```
5. Configure the `rippled` service to start on boot:
sudo systemctl enable rippled.service
```
sudo systemctl enable rippled.service
```
6. Start the `rippled` service:
sudo systemctl start rippled.service
```
sudo systemctl start rippled.service
```
## Next Steps
{% include '_snippets/post-rippled-install.md' %}<!--_ -->
{% partial file="/_snippets/post-rippled-install.md" /%}
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Consensus](consensus.html)
- [The `rippled` Server](../../concepts/networks-and-servers/index.md)
- [Consensus](../../concepts/consensus-protocol/index.md)
- **Tutorials:**
- [Configure rippled](configure-rippled.html)
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
- [Get Started with the rippled API](get-started-using-http-websocket-apis.html)
- [Configure rippled](../configuration/index.md)
- [Troubleshoot rippled](../troubleshooting/index.md)
- [Get Started with the rippled API](../../tutorials/get-started/get-started-using-http-websocket-apis.md)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`rippled` Commandline Usage](commandline-usage.html)
- [rippled API Reference](../../references/http-websocket-apis/index.md)
- [`rippled` Commandline Usage](../commandline-usage.md)
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

92
content/infrastructure/installation/install-rippled-on-ubuntu.md
View File

@@ -14,44 +14,56 @@ These instructions install a binary that has been compiled by Ripple.
## Prerequisites
Before you install `rippled`, you must meet the [System Requirements](system-requirements.html).
Before you install `rippled`, you must meet the [System Requirements](system-requirements.md).
## Installation Steps
1. Update repositories:
sudo apt -y update
```
sudo apt -y update
```
2. Install utilities:
sudo apt -y install apt-transport-https ca-certificates wget gnupg
```
sudo apt -y install apt-transport-https ca-certificates wget gnupg
```
3. Add Ripple's package-signing GPG key to your list of trusted keys:
sudo install -m 0755 -d /etc/apt/keyrings && \
wget -qO- https://repos.ripple.com/repos/api/gpg/key/public | \
sudo gpg --dearmor -o /etc/apt/keyrings/ripple.gpg
```
sudo install -m 0755 -d /etc/apt/keyrings && \
wget -qO- https://repos.ripple.com/repos/api/gpg/key/public | \
sudo gpg --dearmor -o /etc/apt/keyrings/ripple.gpg
```
4. Check the fingerprint of the newly-added key:
gpg --show-keys /etc/apt/keyrings/ripple.gpg
```
gpg --show-keys /etc/apt/keyrings/ripple.gpg
```
The output should include an entry for Ripple such as the following:
pub rsa3072 2019-02-14 [SC] [expires: 2026-02-17]
C0010EC205B35A3310DC90DE395F97FFCCAFD9A2
uid TechOps Team at Ripple <techops+rippled@ripple.com>
sub rsa3072 2019-02-14 [E] [expires: 2026-02-17]
```
pub rsa3072 2019-02-14 [SC] [expires: 2026-02-17]
C0010EC205B35A3310DC90DE395F97FFCCAFD9A2
uid TechOps Team at Ripple <techops+rippled@ripple.com>
sub rsa3072 2019-02-14 [E] [expires: 2026-02-17]
```
In particular, make sure that the fingerprint matches. (In the above example, the fingerprint is on the second line, starting with `C001`.)
5. Add the appropriate Ripple repository for your operating system version:
echo "deb [signed-by=/etc/apt/keyrings/ripple.gpg] https://repos.ripple.com/repos/rippled-deb focal stable" | \
sudo tee -a /etc/apt/sources.list.d/ripple.list
```
echo "deb [signed-by=/etc/apt/keyrings/ripple.gpg] https://repos.ripple.com/repos/rippled-deb focal stable" | \
sudo tee -a /etc/apt/sources.list.d/ripple.list
```
The above example is appropriate for **Ubuntu 20.04 Focal Fossa**. For other operating systems, replace the word `focal` with one of the following:
@@ -70,23 +82,31 @@ Before you install `rippled`, you must meet the [System Requirements](system-req
6. Update the package index to include Ripple's repo and install `rippled`.
sudo apt -y update && sudo apt -y install rippled
```
sudo apt -y update && sudo apt -y install rippled
```
7. Check the status of the `rippled` service:
systemctl status rippled.service
```
systemctl status rippled.service
```
The `rippled` service should start automatically. If not, you can start it manually:
sudo systemctl start rippled.service
```
sudo systemctl start rippled.service
```
8. Optional: allow `rippled` to bind to privileged ports.
This allows you to serve incoming API requests on port 80 or 443. (If you want to do so, you must also update the config file's port settings.)
sudo setcap 'cap_net_bind_service=+ep' /opt/ripple/bin/rippled
```
sudo setcap 'cap_net_bind_service=+ep' /opt/ripple/bin/rippled
```
9. Optional: configure core dumps
@@ -94,42 +114,44 @@ Before you install `rippled`, you must meet the [System Requirements](system-req
By default Ubuntu is not configured to produce core files useful for debugging crashes.
First run:
ulimit -c unlimited
```
ulimit -c unlimited
```
Now run `sudo systemctl edit rippled`. The default editor should open and add
[Service]
LimitCORE=infinity
```
[Service]
LimitCORE=infinity
```
This creates the file `/etc/systemd/system/rippled.service.d/override.conf` and configures the OS to save core dumps, without changing the service file provided by the `rippled` package. If your server crashes, you can find the core dump in `/var/lib/apport/coredump/`. To load the core dump for inspection, use a command such as the following:
gdb /opt/ripple/bin/rippled /var/lib/apport/coredump/core
```
gdb /opt/ripple/bin/rippled /var/lib/apport/coredump/core
```
**Note:** To debug a core file this way, you must have the `rippled-dbgsym` package installed, and you need permission to read files in the core dump directory.
## Next Steps
{% include '_snippets/post-rippled-install.md' %}
<!--_ -->
{% partial file="/_snippets/post-rippled-install.md" /%}
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Consensus](consensus.html)
- [The `rippled` Server](../../concepts/networks-and-servers/index.md)
- [Consensus](../../concepts/consensus-protocol/index.md)
- **Tutorials:**
- [Configure rippled](configure-rippled.html)
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
- [Get Started with the rippled API](get-started-using-http-websocket-apis.html)
- [Configure rippled](../configuration/index.md)
- [Troubleshoot rippled](../troubleshooting/index.md)
- [Get Started with the rippled API](../../tutorials/get-started/get-started-using-http-websocket-apis.md)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`rippled` Commandline Usage](commandline-usage.html)
- [rippled API Reference](../../references/http-websocket-apis/index.md)
- [`rippled` Commandline Usage](../commandline-usage.md)
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

86
content/infrastructure/installation/rippled-1-3-migration-instructions.md
View File

@@ -13,56 +13,68 @@ This document provides migration steps for upgrading on supported platforms:
- [CentOS or Red Hat Enterprise Linux (RHEL)](#migration-on-centos-or-red-hat-enterprise-linux-rhel)
- [Ubuntu Linux](#migration-on-ubuntu-linux)
For other platforms, see the updated instructions for compiling from source. ([Ubuntu](build-run-rippled-ubuntu.html), [macOS](build-run-rippled-macos.html), or [Windows](https://github.com/XRPLF/rippled/tree/develop/Builds/VisualStudio2017))
For other platforms, see the updated instructions for compiling from source. ([Ubuntu](build-on-linux-mac-windows.md), [macOS](build-on-linux-mac-windows.md), or [Windows](https://github.com/XRPLF/rippled/tree/develop/Builds/VisualStudio2017))
## Migration on CentOS or Red Hat Enterprise Linux (RHEL)
Ripple's official RPM repository and instructions for using it have changed. If you have [automatic updates](update-rippled-automatically-on-linux.html) enabled, your system should perform the migration automatically. To migrate manually from the old repository to the new one, complete the following steps:
Ripple's official RPM repository and instructions for using it have changed. If you have [automatic updates](update-rippled-automatically-on-linux.md) enabled, your system should perform the migration automatically. To migrate manually from the old repository to the new one, complete the following steps:
1. Stop the `rippled` server.
$ sudo systemctl stop rippled.service
```
$ sudo systemctl stop rippled.service
```
2. Remove the old Ripple repository package.
$ sudo rpm -e ripple-repo
```
$ sudo rpm -e ripple-repo
```
The `rippled-repo` package is now **DEPRECATED**. The package has been updated one last time for version 1.3.1. In the future, any changes to the repositories will require manual changes to the `ripple.repo` file. <!-- STYLE_OVERRIDE: will -->
3. Add Ripple's new yum repository:
$ cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
[ripple-stable]
name=XRP Ledger Packages
baseurl=https://repos.ripple.com/repos/rippled-rpm/stable/
enabled=1
gpgcheck=0
gpgkey=https://repos.ripple.com/repos/rippled-rpm/stable/repodata/repomd.xml.key
repo_gpgcheck=1
REPOFILE
```
$ cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
[ripple-stable]
name=XRP Ledger Packages
baseurl=https://repos.ripple.com/repos/rippled-rpm/stable/
enabled=1
gpgcheck=0
gpgkey=https://repos.ripple.com/repos/rippled-rpm/stable/repodata/repomd.xml.key
repo_gpgcheck=1
REPOFILE
```
4. Install the new `rippled` package:
$ sudo yum install rippled
```
$ sudo yum install rippled
```
Version 1.3.1 does not require any changes to your config files (`rippled.cfg` and `validators.txt`). This update procedure leaves your existing config files in place.
5. Reload systemd unit files:
$ sudo systemctl daemon-reload
```
$ sudo systemctl daemon-reload
```
6. Start the `rippled` service:
$ sudo systemctl start rippled.service
```
$ sudo systemctl start rippled.service
```
**Warning:** If you use [automatic updates](update-rippled-automatically-on-linux.html), they should continue working after performing this migration process. However, **the `ripple-repo` package is now deprecated**. As a consequence, in the future, any changes to Ripple's repositories may require you to manually update your repos file.
**Warning:** If you use [automatic updates](update-rippled-automatically-on-linux.md), they should continue working after performing this migration process. However, **the `ripple-repo` package is now deprecated**. As a consequence, in the future, any changes to Ripple's repositories may require you to manually update your repos file.
## Migration on Ubuntu Linux
Prior to version 1.3, the supported way to install `rippled` on Ubuntu Linux was using Alien to install the RPM package. Starting with `rippled` v1.3.1, Ripple provides a native package for Ubuntu and Debian Linux, which is the recommended way of installing it. If you already have the RPM package installed, complete the [installation steps](install-rippled-on-ubuntu.html) to upgrade the package and switch over to the native APT (`.deb`) package.
Prior to version 1.3, the supported way to install `rippled` on Ubuntu Linux was using Alien to install the RPM package. Starting with `rippled` v1.3.1, Ripple provides a native package for Ubuntu and Debian Linux, which is the recommended way of installing it. If you already have the RPM package installed, complete the [installation steps](install-rippled-on-ubuntu.md) to upgrade the package and switch over to the native APT (`.deb`) package.
If you have made any changes to your config files (`/opt/ripple/etc/rippled.cfg` and `/opt/ripple/etc/validators.txt`), `apt` may prompt you during installation asking if you want to overwrite your config files with the newest versions from the packages. Version 1.3 does not require any changes to the config file, so you can safely keep your existing config files unchanged.
@@ -70,43 +82,47 @@ After installing the native APT package for 1.3, you need to reload/restart the
1. Reload systemd unit files:
$ sudo systemctl daemon-reload
```
$ sudo systemctl daemon-reload
```
2. Restart the `rippled` service:
$ sudo systemctl restart rippled.service
```
$ sudo systemctl restart rippled.service
```
If you no longer need Alien for any other packages, you may optionally uninstall it and its dependencies using the following steps:
1. Uninstall Alien:
$ sudo apt -y remove alien
```
$ sudo apt -y remove alien
```
2. Uninstall unused dependencies:
$ sudo apt -y autoremove
```
$ sudo apt -y autoremove
```
### Automatic Updates
The `rippled` v1.3 package includes an updated auto-update script that works on Ubuntu and Debian Linux. For more information, see [Update `rippled` Automatically on Linux](update-rippled-automatically-on-linux.html).
The `rippled` v1.3 package includes an updated auto-update script that works on Ubuntu and Debian Linux. For more information, see [Update `rippled` Automatically on Linux](update-rippled-automatically-on-linux.md).
## See Also
- **[`rippled` v1.3.1 Release Notes](https://github.com/XRPLF/rippled/releases/1.3.1)**
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Consensus](consensus.html)
- [The `rippled` Server](../../concepts/networks-and-servers/index.md)
- [Consensus](../../concepts/consensus-protocol/index.md)
- **Tutorials:**
- [Update Automatically on Linux](update-rippled-automatically-on-linux.html)
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
- [Get Started with the rippled API](get-started-using-http-websocket-apis.html)
- [Update Automatically on Linux](update-rippled-automatically-on-linux.md)
- [Troubleshoot rippled](../troubleshooting/index.md)
- [Get Started with the rippled API](../../tutorials/get-started/get-started-using-http-websocket-apis.md)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`rippled` Commandline Usage](commandline-usage.html)
- [rippled API Reference](../../references/http-websocket-apis/index.md)
- [`rippled` Commandline Usage](../commandline-usage.md)
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

22
content/infrastructure/installation/system-requirements.md
View File

@@ -21,7 +21,7 @@ For a validator in AWS, consider `z1d.2xlarge` with an extra 1 TB disk for loggi
## Minimum Specifications
**Caution:** These specifications are not enough to reliably [stay synced with Mainnet](server-doesnt-sync.html). For production use, follow the recommended specifications above.
**Caution:** These specifications are not enough to reliably [stay synced with Mainnet](../troubleshooting/server-doesnt-sync.md). For production use, follow the recommended specifications above.
For testing purposes, you can run an XRP Ledger server on commodity hardware with the following minimum requirements:
@@ -43,19 +43,15 @@ A `rippled` server relies on maintaining the correct time. It is recommended tha
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Consensus](consensus.html)
- [The `rippled` Server](../../concepts/networks-and-servers/index.md)
- [Consensus](../../concepts/consensus-protocol/index.md)
- **Tutorials:**
- [Capacity Planning](capacity-planning.html) - More information on the recommended specifications and planning for production needs
- [Install `rippled`](install-rippled.html)
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
- [Capacity Planning](capacity-planning.md) - More information on the recommended specifications and planning for production needs
- [Install `rippled`](index.md)
- [Troubleshoot rippled](../troubleshooting/index.md)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`rippled` Commandline Usage](commandline-usage.html)
- [rippled API Reference](../../references/http-websocket-apis/index.md)
- [`rippled` Commandline Usage](../commandline-usage.md)
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

32
content/infrastructure/installation/update-rippled-automatically-on-linux.md
View File

@@ -10,21 +10,25 @@ labels:
On Linux, you can set up `rippled` to automatically upgrade to the latest version with a one-time `cron` configuration. Ripple recommends enabling automatic updates if possible.
These instructions assume you have already installed `rippled` [from the `yum` repository (CentOS/RedHat)](install-rippled-on-centos-rhel-with-yum.html) or [using `apt` (Ubuntu/Debian)](install-rippled-on-ubuntu.html).
These instructions assume you have already installed `rippled` [from the `yum` repository (CentOS/RedHat)](install-rippled-on-centos-rhel-with-yum.md) or [using `apt` (Ubuntu/Debian)](install-rippled-on-ubuntu.md).
To set up automatic updates, complete the following steps:
1. Check that `/opt/ripple/etc/update-rippled-cron` exists. If it does not, update manually ([CentOS/Red Hat](update-rippled-manually-on-centos-rhel.html) or [Ubuntu/Debian](update-rippled-manually-on-ubuntu.html)).
1. Check that `/opt/ripple/etc/update-rippled-cron` exists. If it does not, update manually ([CentOS/Red Hat](update-rippled-manually-on-centos-rhel.md) or [Ubuntu/Debian](update-rippled-manually-on-ubuntu.md)).
2. Create a symlink in your `cron.d` folder to the `/opt/ripple/etc/update-rippled-cron` config file:
sudo ln -s /opt/ripple/etc/update-rippled-cron /etc/cron.d/
```
sudo ln -s /opt/ripple/etc/update-rippled-cron /etc/cron.d/
```
This configuration runs a script to update the installed `rippled` package within an hour of each new release. To avoid network instability from too many servers updating at the same time, this script does not automatically restart the server, so it continues to run the old version until it restarts. [Updated in: rippled 1.8.1][]
This configuration runs a script to update the installed `rippled` package within an hour of each new release. To avoid network instability from too many servers updating at the same time, this script does not automatically restart the server, so it continues to run the old version until it restarts. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.8.1" %}Updated in: rippled 1.8.1{% /badge %}
3. **Whenever a new release comes out,** you must manually restart the `rippled` service to switch to the updated software.
sudo systemctl restart rippled.service
```
sudo systemctl restart rippled.service
```
**Caution:** In the future, it is possible that changes to Ripple's repositories may require manual intervention to update the URLs where your script searches for updates. Stay tuned to the [XRP Ledger Blog](/blog/) or the [ripple-server mailing list](https://groups.google.com/forum/#!forum/ripple-server) for announcements on any required changes.
@@ -32,18 +36,14 @@ To set up automatic updates, complete the following steps:
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Consensus](consensus.html)
- [The `rippled` Server](../../concepts/networks-and-servers/index.md)
- [Consensus](../../concepts/consensus-protocol/index.md)
- **Tutorials:**
- [Capacity Planning](capacity-planning.html)
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
- [Capacity Planning](capacity-planning.md)
- [Troubleshoot rippled](../troubleshooting/index.md)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`rippled` Commandline Usage](commandline-usage.html)
- [rippled API Reference](../../references/http-websocket-apis/index.md)
- [`rippled` Commandline Usage](../commandline-usage.md)
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

54
content/infrastructure/installation/update-rippled-manually-on-centos-rhel.md
View File

@@ -8,9 +8,9 @@ labels:
---
# Update Manually on CentOS/Red Hat
This page describes how to update manually to the latest release of `rippled` on CentOS or Red Hat Enterprise Linux. Ripple recommends setting up [automatic updates](update-rippled-automatically-on-linux.html) instead, where possible.
This page describes how to update manually to the latest release of `rippled` on CentOS or Red Hat Enterprise Linux. Ripple recommends setting up [automatic updates](update-rippled-automatically-on-linux.md) instead, where possible.
These instructions assume you have already [installed `rippled` from the `yum` repository](install-rippled-on-centos-rhel-with-yum.html).
These instructions assume you have already [installed `rippled` from the `yum` repository](install-rippled-on-centos-rhel-with-yum.md).
**Tip:** To perform these steps all at once, you can run the `/opt/ripple/bin/update-rippled.sh` script, which is included with the `rippled` package. This script should be run as a `sudo` user.
@@ -18,46 +18,50 @@ To update manually, complete the following steps:
1. If you are upgrading to `rippled` 1.7.0 from an earlier version, re-add the repository to get Ripple's updated GPG key. Otherwise, skip this step:
$ cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
[ripple-stable]
name=XRP Ledger Packages
enabled=1
gpgcheck=0
repo_gpgcheck=1
baseurl=https://repos.ripple.com/repos/rippled-rpm/stable
gpgkey=https://repos.ripple.com/repos/rippled-rpm/stable/repodata/repomd.xml.key
REPOFILE
```
$ cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
[ripple-stable]
name=XRP Ledger Packages
enabled=1
gpgcheck=0
repo_gpgcheck=1
baseurl=https://repos.ripple.com/repos/rippled-rpm/stable
gpgkey=https://repos.ripple.com/repos/rippled-rpm/stable/repodata/repomd.xml.key
REPOFILE
```
1. Download and install the latest `rippled` package:
$ sudo yum update rippled
```
$ sudo yum update rippled
```
This update procedure leaves your existing config files in place.
2. Reload the `systemd` unit files:
$ sudo systemctl daemon-reload
```
$ sudo systemctl daemon-reload
```
3. Restart the `rippled` service:
$ sudo service rippled restart
```
$ sudo service rippled restart
```
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Consensus](consensus.html)
- [The `rippled` Server](../../concepts/networks-and-servers/index.md)
- [Consensus](../../concepts/consensus-protocol/index.md)
- **Tutorials:**
- [`rippled` v1.3.x Migration Instructions](rippled-1-3-migration-instructions.html) <!-- Note: remove when versions older than v1.3 are basically extinct -->
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
- [`rippled` v1.3.x Migration Instructions](rippled-1-3-migration-instructions.md) <!-- Note: remove when versions older than v1.3 are basically extinct -->
- [Troubleshoot rippled](../troubleshooting/index.md)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`rippled` Commandline Usage](commandline-usage.html)
- [rippled API Reference](../../references/http-websocket-apis/index.md)
- [`rippled` Commandline Usage](../commandline-usage.md)
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

52
content/infrastructure/installation/update-rippled-manually-on-ubuntu.md
View File

@@ -8,14 +8,18 @@ labels:
---
# Update Manually on Ubuntu or Debian
This page describes how to update manually to the latest release of `rippled` on Ubuntu Linux. These instructions assume you have already [installed `rippled` using the native package](install-rippled-on-ubuntu.html). Ripple recommends setting up [automatic updates](update-rippled-automatically-on-linux.html) instead, where possible.
This page describes how to update manually to the latest release of `rippled` on Ubuntu Linux. These instructions assume you have already [installed `rippled` using the native package](install-rippled-on-ubuntu.md). Ripple recommends setting up [automatic updates](update-rippled-automatically-on-linux.md) instead, where possible.
> **Caution:** Ripple renewed the GPG key used to sign binary packages shortly before the release of v1.7.0. If you are upgrading from a version earlier than 1.7.0, you must first download and manually trust the updated public key as follows:
>
> wget -q -O - "https://repos.ripple.com/repos/api/gpg/key/public" | \
> sudo apt-key add -
>
> For more information, see the [`rippled` 1.7.0 release notes](https://xrpl.org/blog/2021/rippled-1.7.0.html#upgrading-special-action-required).
{% admonition type="warning" name="Caution" %}
Ripple renewed the GPG key used to sign binary packages shortly before the release of v1.7.0. If you are upgrading from a version earlier than 1.7.0, you must first download and manually trust the updated public key as follows:
```
wget -q -O - "https://repos.ripple.com/repos/api/gpg/key/public" | \
sudo apt-key add -
```
For more information, see the [`rippled` 1.7.0 release notes](https://xrpl.org/blog/2021/rippled-1.7.0.html#upgrading-special-action-required).
{% /admonition %}
**Tip:** To perform these steps all at once, you can run the `/opt/ripple/bin/update-rippled.sh` script, which is included with the `rippled` package and is compatible with Ubuntu and Debian. This script should be run as a `sudo` user.
@@ -23,36 +27,40 @@ To update manually, complete the following steps:
1. Update repositories:
$ sudo apt -y update
```
$ sudo apt -y update
```
2. Upgrade the `rippled` package:
$ sudo apt -y upgrade rippled
```
$ sudo apt -y upgrade rippled
```
3. Reload the `systemd` unit files:
$ sudo systemctl daemon-reload
```
$ sudo systemctl daemon-reload
```
4. Restart the `rippled` service:
$ sudo service rippled restart
```
$ sudo service rippled restart
```
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Consensus](consensus.html)
- [The `rippled` Server](../../concepts/networks-and-servers/index.md)
- [Consensus](../../concepts/consensus-protocol/index.md)
- **Tutorials:**
- [`rippled` v1.3.x Migration Instructions](rippled-1-3-migration-instructions.html) <!-- Note: remove when versions older than v1.3 are basically extinct -->
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
- [`rippled` v1.3.x Migration Instructions](rippled-1-3-migration-instructions.md) <!-- Note: remove when versions older than v1.3 are basically extinct -->
- [Troubleshoot rippled](../troubleshooting/index.md)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`rippled` Commandline Usage](commandline-usage.html)
- [rippled API Reference](../../references/http-websocket-apis/index.md)
- [`rippled` Commandline Usage](../commandline-usage.md)
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

11
content/infrastructure/testing-and-auditing/advance-the-ledger-in-stand-alone-mode.md
View File

@@ -13,11 +13,11 @@ In [stand-alone mode][], `rippled` does not communicate to other members of the
rippled ledger_accept --conf=/path/to/rippled.cfg
```
In stand-alone mode, `rippled` makes no distinction between a "closed" ledger version and a "validated" ledger version. (For more information about the difference, see [The XRP Ledger Consensus Process](consensus.html).)
In stand-alone mode, `rippled` makes no distinction between a "closed" ledger version and a "validated" ledger version. (For more information about the difference, see [The XRP Ledger Consensus Process](../../concepts/consensus-protocol/index.md).)
Whenever `rippled` closes a ledger, it reorders the transactions according to a deterministic but hard-to-game algorithm. (This is an important part of consensus, since transactions may arrive at different parts of the network in different order.) When using `rippled` in stand-alone mode, you should manually advance the ledger before submitting a transaction that depends on the result of a transaction from a different address. Otherwise, the two transactions might be executed in reverse order when the ledger is closed.
**Note:** You can safely submit multiple transactions from a single address to a single ledger, because `rippled` sorts transactions from the same address in ascending order by [`Sequence` number](transaction-common-fields.html).
**Note:** You can safely submit multiple transactions from a single address to a single ledger, because `rippled` sorts transactions from the same address in ascending order by [`Sequence` number](../../references/protocol/transactions/common-fields.md).
## See Also
@@ -25,9 +25,6 @@ Whenever `rippled` closes a ledger, it reorders the transactions according to a
- **References:**
- [ledger_accept method][]
- [server_info method][]
- [`rippled` Commandline Usage](commandline-usage.html)
- [`rippled` Commandline Usage](../commandline-usage.md)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

8
content/infrastructure/testing-and-auditing/index.md
View File

@@ -1,9 +1,13 @@
---
html: use-stand-alone-mode.html
parent: infrastructure.html
template: pagetype-category.html.jinja
metadata:
indexPage: true
blurb: For new features and experiments, you can use Stand-Alone Mode to test features with a full network.
---
# Testing and Auditing
For new features and experiments, you can use Stand-Alone Mode to test features with a full network.
For new features and experiments, you can use Stand-Alone Mode to test features with a full network.
{% child-pages /%}

17
content/infrastructure/testing-and-auditing/load-a-saved-ledger-in-stand-alone-mode.md
View File

@@ -7,9 +7,9 @@ labels:
---
# Load a Saved Ledger in Stand-Alone Mode
You can start a `rippled` server in [Stand-Alone Mode](rippled-server-modes.html) using a [historical ledger version](ledgers.html) that was previously saved to disk. For example, if your `rippled` server was previously synced with any XRP Ledger peer-to-peer network including [the production Mainnet, the Testnet, or the Devnet](parallel-networks.html), you can load any ledger version your server had available.
You can start a `rippled` server in [Stand-Alone Mode](../../concepts/networks-and-servers/rippled-server-modes.md) using a [historical ledger version](../../concepts/ledgers/index.md) that was previously saved to disk. For example, if your `rippled` server was previously synced with any XRP Ledger peer-to-peer network including [the production Mainnet, the Testnet, or the Devnet](../../concepts/networks-and-servers/parallel-networks.md), you can load any ledger version your server had available.
Loading a historical ledger version is useful for "replaying" a ledger to verify that transactions were processed according to the rules of the network, or to compare the results of processing transaction sets with different [amendments](amendments.html) enabled. In the unlikely event that [an attack against the XRP Ledger's consensus mechanism](consensus-protections.html) caused unwanted effects to the shared ledger state, a consensus of validators could "roll back" to a known-good network state starting with this process.
Loading a historical ledger version is useful for "replaying" a ledger to verify that transactions were processed according to the rules of the network, or to compare the results of processing transaction sets with different [amendments](../../concepts/networks-and-servers/amendments.md) enabled. In the unlikely event that [an attack against the XRP Ledger's consensus mechanism](../../concepts/consensus-protocol/consensus-protections.md) caused unwanted effects to the shared ledger state, a consensus of validators could "roll back" to a known-good network state starting with this process.
**Caution:** As `rippled` is updated to newer versions, amendments are retired and become core functions of the ledger, which can affect how transactions are processed. To produce historically accurate results, you need to replay ledgers using the version of `rippled` the transaction was processed in.
@@ -29,7 +29,7 @@ Use the [server_info method][] to check the state of your server relative to the
* `proposing`
* `validating`
For more information, see [Possible Server States](rippled-server-states.html).
For more information, see [Possible Server States](../../references/http-websocket-apis/api-conventions/rippled-server-states.md).
## 3. (Optional) Retrieve specific ledger versions.
@@ -63,7 +63,7 @@ rippled -a --load --ledger 19860944 --conf=/path/to/rippled.cfg
This makes the saved ledger version the "current" (open) ledger for the server when it starts.
For more information on the options you can use when starting `rippled` in stand-alone mode, see [Commandline Usage: Stand-Alone Mode Options](commandline-usage.html#stand-alone-mode-options).
For more information on the options you can use when starting `rippled` in stand-alone mode, see [Commandline Usage: Stand-Alone Mode Options](../commandline-usage.md#stand-alone-mode-options).
## 6. Manually advance the ledger.
@@ -81,11 +81,8 @@ This puts the transactions in canonical order and processes them to make a close
- **References:**
- [ledger_accept method][]
- [server_info method][]
- [`rippled` Commandline Usage](commandline-usage.html)
- [`rippled` Commandline Usage](../commandline-usage.md)
- **Use Cases:**
- [Contribute Code to the XRP Ledger](contribute-code.html)
- [Contribute Code to the XRP Ledger](../../resources/contribute-code/contribute-code.md)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

530
content/infrastructure/testing-and-auditing/run-private-network-with-docker.md
View File

@@ -27,7 +27,7 @@ In this tutorial, you will learn:
The following diagram shows a high-level overview of the containerized private network that you will set up.
{{ include_svg("img/xrp-ledger-private-network-docker.svg", "Figure 1: Diagram of a three node containerized private ledger network") }}
[{% inline-svg file="/img/xrp-ledger-private-network-docker.svg" /%}](/img/xrp-ledger-private-network-docker.svg "Figure 1: Diagram of a three node containerized private ledger network")
## Prerequisites
@@ -39,56 +39,72 @@ Generate the keys for **each** of your validator nodes by using the `validator-k
1. In your terminal, run the following to execute commands within the `rippled` Docker container shell:
docker run -it --entrypoint /bin/bash xrpllabsofficial/xrpld:latest
```
docker run -it --entrypoint /bin/bash xrpllabsofficial/xrpld:latest
```
**Note:** For Apple M1 or M2 chips, run `docker run -it --platform linux/amd64 --entrypoint /bin/bash xrpllabsofficial/xrpld:latest` instead.
Sample output:
root@7732bd585b14:/#
```
root@7732bd585b14:/#
```
2. Generate a validator keypair using the `create_keys` command.
cd /opt/ripple/bin &&
./validator-keys create_keys --keyfile /PATH/TO/YOUR/validator-<NUMBER>-keys.json
```
cd /opt/ripple/bin &&
./validator-keys create_keys --keyfile /PATH/TO/YOUR/validator-<NUMBER>-keys.json
```
Sample output:
Validator keys stored in /PATH/TO/YOUR/validator-<NUMBER>-keys.json
```
Validator keys stored in /PATH/TO/YOUR/validator-<NUMBER>-keys.json
This file should be stored securely and not shared.
This file should be stored securely and not shared.
```
**Warning:** In a production or test environment you should follow best practices always and store the generated keys in a secure, offline, and recoverable location, such as an encrypted USB flash drive. However, as this tutorial is an example of a local development setup, storing the keys on your computer is sufficient.
3. Copy the **public_key** value from the JSON output, and store it in a text file on your computer.
cat /PATH/TO/YOUR/validator-<NUMBER>-keys.json
```
cat /PATH/TO/YOUR/validator-<NUMBER>-keys.json
```
Sample output:
{
"key_type" : "ed25519",
"public_key" : "nHD9jtA9y1nWC2Fs1HeRkEisqV3iFpk12wHmHi3mQxQwUP1ywUKs",
"revoked" : false,
"secret_key" : "paLsUUm9bRrvNBPpvJQ4nF7vdRTZyDNofGMMYs9EDeEKeNJa99q",
"token_sequence" : 0
}
```
{
"key_type" : "ed25519",
"public_key" : "nHD9jtA9y1nWC2Fs1HeRkEisqV3iFpk12wHmHi3mQxQwUP1ywUKs",
"revoked" : false,
"secret_key" : "paLsUUm9bRrvNBPpvJQ4nF7vdRTZyDNofGMMYs9EDeEKeNJa99q",
"token_sequence" : 0
}
```
4. Create a validator token using the `create_token` command.
./validator-keys create_token --keyfile /PATH/TO/YOUR/validator-<NUMBER>-keys.json
```
./validator-keys create_token --keyfile /PATH/TO/YOUR/validator-<NUMBER>-keys.json
```
Copy the token value from the output and save it in a text file on your computer. For example:
[validator_token]
eyJ2YWxpZGF0aW9uX3NlY3J|dF9rZXkiOiI5ZWQ0NWY4NjYyNDFjYzE4YTI3NDdiNT
QzODdjMDYyNTkwNzk3MmY0ZTcxOTAyMzFmYWE5Mzc0NTdmYT|kYWY2IiwibWFuaWZl
c3QiOiJKQUFBQUFGeEllMUZ0d21pbXZHdEgyaUNjTUpxQzlnVkZLaWxHZncxL3ZDeE
hYWExwbGMyR25NaEFrRTFhZ3FYeEJ3RHdEYklENk9NU1l1TTBGREFscEFnTms4U0tG
bjdNTzJmZGtjd1JRSWhBT25ndTlzQUtxWFlvdUorbDJWMFcrc0FPa1ZCK1pSUzZQU2
hsSkFmVXNYZkFpQnNWSkdlc2FhZE9KYy9hQVpva1MxdnltR21WcmxIUEtXWDNZeXd1
NmluOEhBU1FLUHVnQkQ2N2tNYVJGR3ZtcEFUSGxHS0pkdkRGbFdQWXk1QXFEZWRGdj
VUSmEydzBpMjFlcTNNWXl3TFZKWm5GT3I3QzBrdzJBaVR6U0NqSXpkaXRROD0ifQ==
```
[validator_token]
eyJ2YWxpZGF0aW9uX3NlY3J|dF9rZXkiOiI5ZWQ0NWY4NjYyNDFjYzE4YTI3NDdiNT
QzODdjMDYyNTkwNzk3MmY0ZTcxOTAyMzFmYWE5Mzc0NTdmYT|kYWY2IiwibWFuaWZl
c3QiOiJKQUFBQUFGeEllMUZ0d21pbXZHdEgyaUNjTUpxQzlnVkZLaWxHZncxL3ZDeE
hYWExwbGMyR25NaEFrRTFhZ3FYeEJ3RHdEYklENk9NU1l1TTBGREFscEFnTms4U0tG
bjdNTzJmZGtjd1JRSWhBT25ndTlzQUtxWFlvdUorbDJWMFcrc0FPa1ZCK1pSUzZQU2
hsSkFmVXNYZkFpQnNWSkdlc2FhZE9KYy9hQVpva1MxdnltR21WcmxIUEtXWDNZeXd1
NmluOEhBU1FLUHVnQkQ2N2tNYVJGR3ZtcEFUSGxHS0pkdkRGbFdQWXk1QXFEZWRGdj
VUSmEydzBpMjFlcTNNWXl3TFZKWm5GT3I3QzBrdzJBaVR6U0NqSXpkaXRROD0ifQ==
```
5. Repeat steps **2-4** for the remaining validator nodes. Once you have generated the keys and tokens for _all_ validators, enter `exit` in your terminal to exit the Docker container.
@@ -102,17 +118,21 @@ This section describes how to configure the validator nodes in your network.
On your computer, create the directories for all nodes in the private network, and their respective configuration folders.
xrpl-private-network/
├── validator_1/
│ └── config
├── validator_2/
│ └── config
└── validator_3/
└── config
```
xrpl-private-network/
├── validator_1/
│ └── config
├── validator_2/
│ └── config
└── validator_3/
└── config
```
In your terminal, run the following command to create the directories:
mkdir -p xrpl-private-network/{validator_1/config,validator_2/config,validator_3/config}
```
mkdir -p xrpl-private-network/{validator_1/config,validator_2/config,validator_3/config}
```
### Create the validator configuration files
@@ -122,113 +142,117 @@ For each validator node, follow these steps:
2. Copy the information from the `rippled.cfg` template below into the file.
[server]
port_rpc_admin_local
port_rpc
port_ws_admin_local
port_ws_public
port_peer
# ssl_key = /etc/ssl/private/server.key
# ssl_cert = /etc/ssl/certs/server.crt
```
[server]
port_rpc_admin_local
port_rpc
port_ws_admin_local
port_ws_public
port_peer
# ssl_key = /etc/ssl/private/server.key
# ssl_cert = /etc/ssl/certs/server.crt
[port_rpc_admin_local]
port = 5005
ip = 127.0.0.1
admin = 127.0.0.1
protocol = http
[port_rpc_admin_local]
port = 5005
ip = 127.0.0.1
admin = 127.0.0.1
protocol = http
[port_ws_admin_local]
port = 6006
ip = 127.0.0.1
admin = 127.0.0.1
protocol = ws
[port_ws_admin_local]
port = 6006
ip = 127.0.0.1
admin = 127.0.0.1
protocol = ws
[port_ws_public]
port = 80
ip = 0.0.0.0
protocol = ws
[port_ws_public]
port = 80
ip = 0.0.0.0
protocol = ws
[port_peer]
port = 51235
ip = 0.0.0.0
protocol = peer
[port_peer]
port = 51235
ip = 0.0.0.0
protocol = peer
[port_rpc]
port = 51234
ip = 0.0.0.0
admin = 127.0.0.1
protocol = https, http
[port_rpc]
port = 51234
ip = 0.0.0.0
admin = 127.0.0.1
protocol = https, http
[node_size]
small
# tiny
# small
# medium
# large
# huge
[node_size]
small
# tiny
# small
# medium
# large
# huge
[node_db]
type=NuDB
path=/var/lib/rippled/db/nudb
advisory_delete=0
[node_db]
type=NuDB
path=/var/lib/rippled/db/nudb
advisory_delete=0
# How many ledgers do we want to keep (history)?
# Integer value that defines the number of ledgers
# between online deletion events
online_delete=256
# How many ledgers do we want to keep (history)?
# Integer value that defines the number of ledgers
# between online deletion events
online_delete=256
[ledger_history]
# How many ledgers do we want to keep (history)?
# Integer value (ledger count)
# or (if you have lots of TB SSD storage): 'full'
256
[ledger_history]
# How many ledgers do we want to keep (history)?
# Integer value (ledger count)
# or (if you have lots of TB SSD storage): 'full'
256
[database_path]
/var/lib/rippled/db
[database_path]
/var/lib/rippled/db
[debug_logfile]
/var/log/rippled/debug.log
[debug_logfile]
/var/log/rippled/debug.log
[sntp_servers]
time.windows.com
time.apple.com
time.nist.gov
pool.ntp.org
[sntp_servers]
time.windows.com
time.apple.com
time.nist.gov
pool.ntp.org
[ips_fixed]
validator_1 51235
validator_2 51235
validator_3 51235
[ips_fixed]
validator_1 51235
validator_2 51235
validator_3 51235
[validators_file]
validators.txt
[validators_file]
validators.txt
[rpc_startup]
{ "command": "log_level", "severity": "warning" }
# severity (order: lots of information .. only errors)
# debug
# info
# warn
# error
# fatal
[rpc_startup]
{ "command": "log_level", "severity": "warning" }
# severity (order: lots of information .. only errors)
# debug
# info
# warn
# error
# fatal
[ssl_verify]
0
[ssl_verify]
0
[validator_token]
<Add your validator token here>
[validator_token]
<Add your validator token here>
```
3. Add the generated validator token that you created at the [beginning](#generate-the-validator-keys) of the tutorial. For example:
[validator_token]
eyJtYW5pZmVzdCI6IkpBQUFBQUZ4SWUwcVd3ZnpLZ2tacWJTL01QVGxHVXlOeTVJZ2kzYzlG
V1JvTDFIMGoydkNobk1oQTBOc2RHeFNXbWF6b0xkdU5NeDVmaVVZU2h3bjk2SnpSaUFReFJz
cENuR2dka1l3UkFJZ1dLazV4cklSN3FNRWd1UmJwOTRrN0E0QnBOZmwrT2VYUm92bTNIOGtS
YkVDSUZXYmVocHd5ZS9UWFpZRGYwUEgwTkxjN2I1cWNEOXUvbzVYUjA4YW1pUEJjQkpBYjEw
NE95bG5IS0JSZTJmRW1qSVVjT24vZ2ZacE44bXdhZ1dGbUxlemc2RFRLL0hpTVkyektNQ3l0
aksreHpHNWpjc3JlS3k5Q29sRGtpKzk3V0JHQ2c9PSIsInZhbGlkYXRpb25fc2VjcmV0X2tl
eSI6IjZFNTNFQjA1M0IwNEM1RTczNDc4M0VCMEU0RTBFOTg1NDVDNDQ0QzI3OTBFQjdBMzA2
NUQzMUVBOTU1QjQyMTIifQ==
```
[validator_token]
eyJtYW5pZmVzdCI6IkpBQUFBQUZ4SWUwcVd3ZnpLZ2tacWJTL01QVGxHVXlOeTVJZ2kzYzlG
V1JvTDFIMGoydkNobk1oQTBOc2RHeFNXbWF6b0xkdU5NeDVmaVVZU2h3bjk2SnpSaUFReFJz
cENuR2dka1l3UkFJZ1dLazV4cklSN3FNRWd1UmJwOTRrN0E0QnBOZmwrT2VYUm92bTNIOGtS
YkVDSUZXYmVocHd5ZS9UWFpZRGYwUEgwTkxjN2I1cWNEOXUvbzVYUjA4YW1pUEJjQkpBYjEw
NE95bG5IS0JSZTJmRW1qSVVjT24vZ2ZacE44bXdhZ1dGbUxlemc2RFRLL0hpTVkyektNQ3l0
aksreHpHNWpjc3JlS3k5Q29sRGtpKzk3V0JHQ2c9PSIsInZhbGlkYXRpb25fc2VjcmV0X2tl
eSI6IjZFNTNFQjA1M0IwNEM1RTczNDc4M0VCMEU0RTBFOTg1NDVDNDQ0QzI3OTBFQjdBMzA2
NUQzMUVBOTU1QjQyMTIifQ==
```
Each validator node must have its own unique token.
@@ -242,10 +266,12 @@ For each node, follow these steps:
2. Copy the public keys from the `validator-keys.json` files that you generated at the [beginning](#generate-the-validator-keys) of the tutorial.
3. Add the public keys of _all_ the validators. For example:
[validators]
nHBgaEDL8buUECuk4Rck4QBYtmUgbAoeYJLpWLzG9iXsznTRYrQu
nHBCHX7iLDTyap3LumqBNuKgG7JLA5tc6MSJxpLs3gjkwpu836mY
nHU5STUKTgWdreVqJDx6TopLUymzRUZshTSGcWNtjfByJkYdiiRc
```
[validators]
nHBgaEDL8buUECuk4Rck4QBYtmUgbAoeYJLpWLzG9iXsznTRYrQu
nHBCHX7iLDTyap3LumqBNuKgG7JLA5tc6MSJxpLs3gjkwpu836mY
nHU5STUKTgWdreVqJDx6TopLUymzRUZshTSGcWNtjfByJkYdiiRc
```
## Start the Network
@@ -257,51 +283,55 @@ To start running your private network, follow these steps:
1. Create a `docker-compose.yml` file in the root of the private network directory, `xrpl-private-network`, and add the following content:
version: "3.9"
services:
validator_1:
platform: linux/amd64
container_name: validator_1
image: "xrpllabsofficial/xrpld"
ports:
- "8001:80"
- "5006:5005"
- "4001:6006"
- "9001:51235"
volumes:
- ./validator_1/config:/config/
validator_2:
platform: linux/amd64
container_name: validator_2
image: "xrpllabsofficial/xrpld"
ports:
- "8002:80"
- "5007:5005"
- "4002:6006"
- "9002:51235"
volumes:
- ./validator_2/config:/config/
validator_3:
platform: linux/amd64
container_name: validator_3
image: "xrpllabsofficial/xrpld"
ports:
- "8003:80"
- "5008:5005"
- "4003:6006"
- "9003:51235"
volumes:
- ./validator_3/config:/config/
```
version: "3.9"
services:
validator_1:
platform: linux/amd64
container_name: validator_1
image: "xrpllabsofficial/xrpld"
ports:
- "8001:80"
- "5006:5005"
- "4001:6006"
- "9001:51235"
volumes:
- ./validator_1/config:/config/
validator_2:
platform: linux/amd64
container_name: validator_2
image: "xrpllabsofficial/xrpld"
ports:
- "8002:80"
- "5007:5005"
- "4002:6006"
- "9002:51235"
volumes:
- ./validator_2/config:/config/
validator_3:
platform: linux/amd64
container_name: validator_3
image: "xrpllabsofficial/xrpld"
ports:
- "8003:80"
- "5008:5005"
- "4003:6006"
- "9003:51235"
volumes:
- ./validator_3/config:/config/
```
The `volumes` key in each `service` represents the location where your config files are stored. For example, `./validator_1/config:/config/` maps the `/validator_1/config` directory on your host computer to `/config/` in the Docker container. Any changes made in the host directory will be reflected in the container automatically.
2. From your terminal, in the location where you created the `docker-compose.yml` file, run `docker-compose up -d`. You should see a similar output to the one below:
[+] Running 4/4
✔ Network xrpl-private-network_default Created 0.0s
✔ Container validator_3 Started 0.5s
✔ Container validator_1 Started 0.5s
✔ Container validator_2 Started 0.5s
```
[+] Running 4/4
✔ Network xrpl-private-network_default Created 0.0s
✔ Container validator_3 Started 0.5s
✔ Container validator_1 Started 0.5s
✔ Container validator_2 Started 0.5s
```
## Verify the Network
@@ -311,47 +341,59 @@ Now that the private ledger network is up, you need to verify that **each** vali
2. Run the `rippled server_info` command to check the state of the validator:
rippled server_info | grep server_state
```
rippled server_info | grep server_state
```
Sample Output:
"server_state" : "proposing"
```
"server_state" : "proposing"
```
**Note:** If the state is not updated to **proposing**, repeat step **2** after a few minutes as the ledger can take some time to update.
3. Verify the number of peers connected to the validator.
rippled server_info | grep peers
```
rippled server_info | grep peers
```
Sample Output:
"peers" : 2
```
"peers" : 2
```
4. Run the following command to check the genesis account information:
rippled account_info rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh validated strict
```
rippled account_info rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh validated strict
```
Sample Output:
{
"result" : {
"account_data" : {
"Account" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
"Balance" : "100000000000000000",
"Flags" : 0,
"LedgerEntryType" : "AccountRoot",
"OwnerCount" : 0,
"PreviousTxnID" : "0000000000000000000000000000000000000000000000000000000000000000",
"PreviousTxnLgrSeq" : 0,
"Sequence" : 1,
"index" : "2B6AC232AA4C4BE41BF49D2459FA4A0347E1B543A4C92FCEE0821C0201E2E9A8"
},
"ledger_hash" : "CFCEFB049A71E26DE812529ABB212F330FAF583A98FE073F14713B0644D7CEE9",
"ledger_index" : 10181,
"status" : "success",
"validated" : true
}
```
{
"result" : {
"account_data" : {
"Account" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
"Balance" : "100000000000000000",
"Flags" : 0,
"LedgerEntryType" : "AccountRoot",
"OwnerCount" : 0,
"PreviousTxnID" : "0000000000000000000000000000000000000000000000000000000000000000",
"PreviousTxnLgrSeq" : 0,
"Sequence" : 1,
"index" : "2B6AC232AA4C4BE41BF49D2459FA4A0347E1B543A4C92FCEE0821C0201E2E9A8"
},
"ledger_hash" : "CFCEFB049A71E26DE812529ABB212F330FAF583A98FE073F14713B0644D7CEE9",
"ledger_index" : 10181,
"status" : "success",
"validated" : true
}
}
```
5. To leave the Docker container shell, enter `exit` in the terminal.
@@ -361,60 +403,68 @@ Perform a **test** transaction to ensure you can send money to an account.
1. In your terminal, run the the following command to submit a transaction:
docker exec -it validator_1 \
rippled submit 'snoPBrXtMeMyMHUVTgbuqAfg1SUTb' '{ "Account": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", "Amount": "1000000000", "Destination": "r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs", "TransactionType": "Payment", "Fee": "10" }'
```
docker exec -it validator_1 \
rippled submit 'snoPBrXtMeMyMHUVTgbuqAfg1SUTb' '{ "Account": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", "Amount": "1000000000", "Destination": "r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs", "TransactionType": "Payment", "Fee": "10" }'
```
Sample Output:
{
"result" : {
"engine_result" : "tesSUCCESS",
"engine_result_code" : 0,
"engine_result_message" : "The transaction was applied. Only final in a validated ledger.",
"status" : "success",
"tx_blob" : "1200002280000000240000000161400000003B9ACA0068400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074463044022057CCEED351A4278F35C13FD104A55338DC8F48C1F9902D58045A4CD0CE89C92A0220184026BD3B1E2C21239017CAF1BBF683 35EDC57F6F98D952E263763DE449561B8114B5F762798A53D543A014CAF8B297CFF8F2F937E883145988EBB744055F4E8BDC7F67FD53EB9FCF961DC0",
"tx_json" : {
"Account" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
"Amount" : "1000000000",
"Destination" : "r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs",
"Fee" : "10",
"Flags" : 2147483648,
"Sequence" : 1,
"SigningPubKey" : "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
"TransactionType" : "Payment",
"TxnSignature" : "3044022057CCEED351A4278F35C13FD104A55338DC8F48C1F9902D58045A4CD0CE89C92A0220184026BD3B1E2C21239017CAF1BBF68335EDC57F6F98D952E263763DE449561B",
"hash" : "EB516738841794B24819C68273E0F853A3D234350E6534F7F2841F620CE99437"
}
```
{
"result" : {
"engine_result" : "tesSUCCESS",
"engine_result_code" : 0,
"engine_result_message" : "The transaction was applied. Only final in a validated ledger.",
"status" : "success",
"tx_blob" : "1200002280000000240000000161400000003B9ACA0068400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074463044022057CCEED351A4278F35C13FD104A55338DC8F48C1F9902D58045A4CD0CE89C92A0220184026BD3B1E2C21239017CAF1BBF683 35EDC57F6F98D952E263763DE449561B8114B5F762798A53D543A014CAF8B297CFF8F2F937E883145988EBB744055F4E8BDC7F67FD53EB9FCF961DC0",
"tx_json" : {
"Account" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
"Amount" : "1000000000",
"Destination" : "r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs",
"Fee" : "10",
"Flags" : 2147483648,
"Sequence" : 1,
"SigningPubKey" : "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
"TransactionType" : "Payment",
"TxnSignature" : "3044022057CCEED351A4278F35C13FD104A55338DC8F48C1F9902D58045A4CD0CE89C92A0220184026BD3B1E2C21239017CAF1BBF68335EDC57F6F98D952E263763DE449561B",
"hash" : "EB516738841794B24819C68273E0F853A3D234350E6534F7F2841F620CE99437"
}
}
}
}
```
2. For each validator, verify that the destination account `r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs` has 1000000000 XRP. For example:
docker exec -it validator_1 \
rippled account_info r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs validated strict
```
docker exec -it validator_1 \
rippled account_info r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs validated strict
```
Sample Output:
{
"result" : {
"account_data" : {
"Account" : "r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs",
"Balance" : "1000000000",
"Flags" : 0,
"LedgerEntryType" : "AccountRoot",
"OwnerCount" : 0,
"PreviousTxnID" : "EB516738841794B24819C68273E0F853A3D234350E6534F7F2841F620CE99437",
"PreviousTxnLgrSeq" : 36,
"Sequence" : 1,
"index" : "0F2E4615AE24EEF58EE82BD1E67D237234ED41BFC8B7885630B7AC05082E97AA"
},
"ledger_hash" : "6F9F54903CC4546F7A426CD78AFD68D907F5DC40B1780DF31A662CF65920E49C",
"ledger_index" : 51,
"status" : "success",
"validated" : true
}
}
```
{
"result" : {
"account_data" : {
"Account" : "r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs",
"Balance" : "1000000000",
"Flags" : 0,
"LedgerEntryType" : "AccountRoot",
"OwnerCount" : 0,
"PreviousTxnID" : "EB516738841794B24819C68273E0F853A3D234350E6534F7F2841F620CE99437",
"PreviousTxnLgrSeq" : 36,
"Sequence" : 1,
"index" : "0F2E4615AE24EEF58EE82BD1E67D237234ED41BFC8B7885630B7AC05082E97AA"
},
"ledger_hash" : "6F9F54903CC4546F7A426CD78AFD68D907F5DC40B1780DF31A662CF65920E49C",
"ledger_index" : 51,
"status" : "success",
"validated" : true
}
}
```
All validator nodes should respond with the same balance of 1000000000 XRP for the `r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs` account.
## Stop the Network
@@ -424,20 +474,24 @@ If you wish to stop running the private network:
1. In your terminal, go to the `xrpl-private-network` directory.
2. Run the following command to shut down the network:
docker-compose down
```
docker-compose down
```
Sample Output:
[+] Running 4/4
✔ Container validator_3 Removed 1.7s
✔ Container validator_1 Removed 1.6s
✔ Container validator_2 Removed 1.6s
✔ Network xrpl-private-network_default Removed 0.0s
```
[+] Running 4/4
✔ Container validator_3 Removed 1.7s
✔ Container validator_1 Removed 1.6s
✔ Container validator_2 Removed 1.6s
✔ Network xrpl-private-network_default Removed 0.0s
```
## See Also
- **Networks and Servers:**
- [Peer Protocol](peer-protocol.html)
- [Peer Protocol](../../concepts/networks-and-servers/peer-protocol.md)
- **References:**
- [XRPL Testnet Setup Scripts for Docker](https://github.com/UNIC-IFF/xrpl-docker-testnet)

27
content/infrastructure/testing-and-auditing/start-a-new-genesis-ledger-in-stand-alone-mode.md
View File

@@ -15,9 +15,9 @@ In stand-alone mode, you can have `rippled` create a new genesis ledger. This pr
rippled -a --start --conf=/path/to/rippled.cfg
```
For more information on the options you can use when starting `rippled` in stand-alone mode, see [Commandline Usage: Stand-Alone Mode Options](commandline-usage.html#stand-alone-mode-options).
For more information on the options you can use when starting `rippled` in stand-alone mode, see [Commandline Usage: Stand-Alone Mode Options](../commandline-usage.md#stand-alone-mode-options).
In a genesis ledger, the [genesis address](addresses.html#special-addresses) holds all 100 billion XRP. The keys of the genesis address are [hardcoded](https://github.com/XRPLF/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184) as follows:
In a genesis ledger, the [genesis address](../../concepts/accounts/addresses.md#special-addresses) holds all 100 billion XRP. The keys of the genesis address are [hardcoded](https://github.com/XRPLF/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184) as follows:
**Address:** `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh`
@@ -25,26 +25,23 @@ In a genesis ledger, the [genesis address](addresses.html#special-addresses) hol
## Settings in New Genesis Ledgers
In a new genesis ledger, the hard-coded default [Reserve](reserves.html) is **200 XRP** minimum for funding a new address, with an increment of **50 XRP** per object in the ledger. These values are higher than the current reserve requirements of the production network. (See also: [Fee Voting](fee-voting.html))
In a new genesis ledger, the hard-coded default [Reserve](../../concepts/accounts/reserves.md) is **200 XRP** minimum for funding a new address, with an increment of **50 XRP** per object in the ledger. These values are higher than the current reserve requirements of the production network. (See also: [Fee Voting](../../concepts/consensus-protocol/fee-voting.md))
By default, a new genesis ledger has no [amendments](amendments.html) enabled. If you start a new genesis ledger with `--start`, the genesis ledger contains an [EnableAmendment pseudo-transaction](enableamendment.html) to turn on all amendments natively supported by the `rippled` server, except for amendments that you explicitly disable in the config file. The effects of those amendments are available starting from the very next ledger version. (Reminder: in stand-alone mode, you must [advance the ledger manually](advance-the-ledger-in-stand-alone-mode.html).) [New in: rippled 0.50.0][]
By default, a new genesis ledger has no [amendments](../../concepts/networks-and-servers/amendments.md) enabled. If you start a new genesis ledger with `--start`, the genesis ledger contains an [EnableAmendment pseudo-transaction](../../references/protocol/transactions/pseudo-transaction-types/enableamendment.md) to turn on all amendments natively supported by the `rippled` server, except for amendments that you explicitly disable in the config file. The effects of those amendments are available starting from the very next ledger version. (Reminder: in stand-alone mode, you must [advance the ledger manually](advance-the-ledger-in-stand-alone-mode.md).) {% badge href="https://github.com/XRPLF/rippled/releases/tag/0.50.0" %}New in: rippled 0.50.0{% /badge %}
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [`rippled` Server Modes](rippled-server-modes.html)
- [Parallel Networks](parallel-networks.html)
- [Amendments](amendments.html)
- [Fee Voting](fee-voting.html)
- [The `rippled` Server](../../concepts/networks-and-servers/index.md)
- [`rippled` Server Modes](../../concepts/networks-and-servers/rippled-server-modes.md)
- [Parallel Networks](../../concepts/networks-and-servers/parallel-networks.md)
- [Amendments](../../concepts/networks-and-servers/amendments.md)
- [Fee Voting](../../concepts/consensus-protocol/fee-voting.md)
- **References:**
- [ledger_accept method][]
- [server_info method][]
- [`rippled` Commandline Usage](commandline-usage.html)
- [`rippled` Commandline Usage](../commandline-usage.md)
- **Use Cases:**
- [Contribute Code to the XRP Ledger](contribute-code-to-rippled.html)
- [Contribute Code to the XRP Ledger](../../resources/contribute-code/contribute-code.md)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

7
content/infrastructure/testing-and-auditing/test-amendments.md
View File

@@ -14,13 +14,14 @@ You can test how `rippled` behaves before proposed amendments are fully enabled
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_
{% tabs %}
{% tab label="Example" %}
```
[features]
MultiSign
TrustSetAuth
```
{% /tab %}
<!-- MULTICODE_BLOCK_END -->
{% /tabs %}

138
content/infrastructure/troubleshooting/diagnosing-problems.md
View File

@@ -11,8 +11,8 @@ If you are having problems with `rippled`, the first step is to collect more inf
See the following pages for some common categories of problems, their causes, and fixes:
- If your server does not start (such as crashing or otherwise shutting down automatically), see **[rippled Server Won't Start](server-wont-start.html)**.
- If your server starts, but does not reliably sync or remain synced to the XRP Ledger network, see **[rippled Server Doesn't Sync](server-doesnt-sync.html)**.
- If your server does not start (such as crashing or otherwise shutting down automatically), see **[rippled Server Won't Start](server-wont-start.md)**.
- If your server starts, but does not reliably sync or remain synced to the XRP Ledger network, see **[rippled Server Doesn't Sync](server-doesnt-sync.md)**.
The rest of this document suggests steps for diagnosing problems that happen while your server is up and running (including if the process is active but unable to sync with the network).
@@ -27,63 +27,67 @@ rippled server_info
The response to this command has a lot of information, which is documented along with the [server_info method][].
For troubleshooting purposes, the most important fields are (from most commonly used to least):
- **`server_state`** - Most of the time, this field should show `proposing` for a server that is [configured as a validator](run-rippled-as-a-validator.html), or `full` for a non-validating server. The value `connected` means that the server can communicate with the rest of the peer-to-peer network, but it does not yet have enough data to track progress of the shared ledger state. Normally, syncing to the state of the rest of the ledger takes about 5-15 minutes after starting.
- **`server_state`** - Most of the time, this field should show `proposing` for a server that is [configured as a validator](../configuration/server-modes/run-rippled-as-a-validator.md), or `full` for a non-validating server. The value `connected` means that the server can communicate with the rest of the peer-to-peer network, but it does not yet have enough data to track progress of the shared ledger state. Normally, syncing to the state of the rest of the ledger takes about 5-15 minutes after starting.
- If your server remains in the `connected` state for hours, or returns to the `connected` state after being in the `full` or `proposing` states, that usually indicates that your server cannot keep up with the rest of the network. The most common bottlenecks are disk I/O, network bandwidth, and RAM.
- For example, the following server state information shows a healthy server that took less than 3 minutes to sync (split between the `disconnected`, `connected`, and `syncing` states), and is currently in the fully-synced `proposing` state, where it has remained for approximately 90 minutes:
$ ./rippled server_info
Loading: "/etc/opt/ripple/rippled.cfg"
2020-Jan-03 22:49:32.834134358 HTTPClient:NFO Connecting to 127.0.0.1:5005
```
$ ./rippled server_info
Loading: "/etc/opt/ripple/rippled.cfg"
2020-Jan-03 22:49:32.834134358 HTTPClient:NFO Connecting to 127.0.0.1:5005
{
"result" : {
"info" : {
... (trimmed) ...
"server_state" : "proposing",
"server_state_duration_us" : "5183282365",
"state_accounting" : {
"connected" : {
"duration_us" : "126164786",
"transitions" : 1
},
"disconnected" : {
"duration_us" : "2111321",
"transitions" : 1
},
"full" : {
"duration_us" : "5183282365",
"transitions" : 1
},
"syncing" : {
"duration_us" : "5545604",
"transitions" : 1
},
"tracking" : {
"duration_us" : "0",
"transitions" : 1
}
},
... (trimmed) ...
{
"result" : {
"info" : {
... (trimmed) ...
"server_state" : "proposing",
"server_state_duration_us" : "5183282365",
"state_accounting" : {
"connected" : {
"duration_us" : "126164786",
"transitions" : 1
},
"disconnected" : {
"duration_us" : "2111321",
"transitions" : 1
},
"full" : {
"duration_us" : "5183282365",
"transitions" : 1
},
"syncing" : {
"duration_us" : "5545604",
"transitions" : 1
},
"tracking" : {
"duration_us" : "0",
"transitions" : 1
}
}
},
... (trimmed) ...
}
}
}
```
If you do not have a `full` or `proposing` state, then your server has not yet synced to the network. If your server shows multiple transitions between the same states (`transitions` is 2 or more), that indicates that your server lost sync with the network. It's a problem if you have many transitions in a short period of time; it's OK if you have a few transitions over a long period of time, because some fluctuations in internet connectivity are unavoidable. The amount of time in individual states (`duration_us`) compared with total uptime (`server_state_duration_us`) can also tell you how well your server is staying synced. After about 24 hours of uptime, if less than 99% of your server's total runtime is spent in the `full` or `proposing` states, you may want to investigate possible sources of instability.
- For help debugging syncing issues, see [Server Doesn't Sync](server-doesnt-sync.html).
- For help debugging syncing issues, see [Server Doesn't Sync](server-doesnt-sync.md).
- **`complete_ledgers`** - This field shows which [ledger indexes](basic-data-types.html#ledger-index) your server has complete ledger data for. Healthy servers usually have a single range of recent ledgers, such as `"12133424-12133858"`.
- **`complete_ledgers`** - This field shows which [ledger indexes](../../references/protocol/data-types/basic-data-types.md#ledger-index) your server has complete ledger data for. Healthy servers usually have a single range of recent ledgers, such as `"12133424-12133858"`.
- If you have a disjoint set of complete ledgers such as `"11845721-12133420,12133424-12133858"`, that could indicate that your server has had intermittent outages or has temporarily fallen out of sync with the rest of the network. The most common causes for this are insufficient disk I/O or network bandwidth.
- Normally, a `rippled` server downloads recent ledger history from its peers. If gaps in your ledger history persist for more than a few hours, you may not be connected to any peers who have the missing data. If this occurs, you can force your server to try and peer with one of Ripple's full-history public servers by adding the following stanza to your config file and restarting:
[ips_fixed]
s2.ripple.com 51235
```
[ips_fixed]
s2.ripple.com 51235
```
- **`amendment_blocked`** - This field is normally omitted from the `server_info` response. If this field appears with the value `true`, then the network has approved an [amendment](amendments.html) for which your server doesn't have an implementation. Most likely, you can fix this by [updating rippled](install-rippled.html) to the latest version. You can also use the [feature method][] to see what amendment IDs are currently enabled and which one(s) your server does and does not support.
- **`amendment_blocked`** - This field is normally omitted from the `server_info` response. If this field appears with the value `true`, then the network has approved an [amendment](../../concepts/networks-and-servers/amendments.md) for which your server doesn't have an implementation. Most likely, you can fix this by [updating rippled](../installation/index.md) to the latest version. You can also use the [feature method][] to see what amendment IDs are currently enabled and which one(s) your server does and does not support.
- **`peers`** - This field indicates how many other servers in the XRP Ledger peer-to-peer network your server is connected to. Healthy servers typically show between 5 and 50 peers, unless explicitly configured to connect only to certain peers.
@@ -107,7 +111,7 @@ The `rippled` executable returns the following message if it wasn't able to conn
This generally indicates one of several problems:
- The `rippled` server is starting up, or is not running at all. Check the status of the service; if it is running, wait a few seconds and try again.
- You may need to pass different [parameters to the `rippled` commandline client](commandline-usage.html#client-mode-options) to connect to your server.
- You may need to pass different [parameters to the `rippled` commandline client](../commandline-usage.md#client-mode-options) to connect to your server.
- The `rippled` server may be configured not to accept JSON-RPC connections.
@@ -115,35 +119,37 @@ This generally indicates one of several problems:
[By default,](https://github.com/XRPLF/rippled/blob/master/cfg/rippled-example.cfg#L1139-L1142) `rippled` writes the server's debug log to the file `/var/log/rippled/debug.log`. The location of the debug log can differ based on your server's config file. If you start the `rippled` service directly (instead of using `systemctl` or `service` to start it), it also prints log messages to the console by default.
The default config file sets the log level to severity "warning" for all categories of log messages by internally using the [log_level method][] during startup. You can control the verbosity of the debug log [using the `--silent` commandline option during startup](commandline-usage.html#verbosity-options) and with the [log_level method][] while the server is running. (See the `[rpc_startup]` stanza of the config file for settings.)
The default config file sets the log level to severity "warning" for all categories of log messages by internally using the [log_level method][] during startup. You can control the verbosity of the debug log [using the `--silent` commandline option during startup](../commandline-usage.md#verbosity-options) and with the [log_level method][] while the server is running. (See the `[rpc_startup]` stanza of the config file for settings.)
It is normal for a `rippled` the server to print many warning-level (`WRN`) messages during startup and a few warning-level messages from time to time later on. You can **safely ignore** most warnings in the first 5 to 15 minutes of server startup.
For a more thorough explanation of various types of log messages, see [Understanding Log Messages](understanding-log-messages.html).
For a more thorough explanation of various types of log messages, see [Understanding Log Messages](understanding-log-messages.md).
## Info Collection Script
If you have problems diagnosing the problem, or you are unable to resolve the problem with any of the common fixes, you may want to ask for help in a support forum or the [GitHub issues](https://github.com/XRPLF/rippled/issues). When asking for help, you can use an info collection script to gather information about your system to help others diagnose the issue.
The official package installation (for [Ubuntu/Debian](install-rippled-on-ubuntu.html) or [CentOS/RedHat](install-rippled-on-centos-rhel-with-yum.html)) installs such a script by default, to `/opt/ripple/bin/getRippledInfo`. [New in: rippled 1.5.0][] If you compiled `rippled` yourself, you can find the same script [in the `rippled` source code repository](https://github.com/XRPLF/rippled/blob/develop/bin/getRippledInfo).
The official package installation (for [Ubuntu/Debian](../installation/install-rippled-on-ubuntu.md) or [CentOS/RedHat](../installation/install-rippled-on-centos-rhel-with-yum.md)) installs such a script by default, to `/opt/ripple/bin/getRippledInfo`. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.5.0" %}New in: rippled 1.5.0{% /badge %} If you compiled `rippled` yourself, you can find the same script [in the `rippled` source code repository](https://github.com/XRPLF/rippled/blob/develop/bin/getRippledInfo).
To use the script:
1. Run the script while `rippled` is running.
$ /opt/ripple/bin/getRippledInfo
```
$ /opt/ripple/bin/getRippledInfo
####################################################
rippled info has been gathered. Please copy the
contents of /tmp/ripple_info.Xo8Xr/rippled_info.md
to a github gist at https://gist.github.com/
####################################################
rippled info has been gathered. Please copy the
contents of /tmp/ripple_info.Xo8Xr/rippled_info.md
to a github gist at https://gist.github.com/
PLEASE REVIEW THIS FILE FOR ANY SENSITIVE DATA
BEFORE POSTING! We have tried our best to omit
any sensitive information from this file, but you
should verify before posting.
####################################################
PLEASE REVIEW THIS FILE FOR ANY SENSITIVE DATA
BEFORE POSTING! We have tried our best to omit
any sensitive information from this file, but you
should verify before posting.
####################################################
```
The script collects the output of many commands and writes them to a temporary file. The filename is randomized with a string of letters and numbers (case-sensitive), for example: `/tmp/ripple_info.Xo8Xr/rippled_info.md`
@@ -152,7 +158,9 @@ To use the script:
The script attempts to scrub sensitive information from the output, such as validator keys or tokens. However, you should still check the output before posting publicly, as a precaution. For example, the script outputs detailed information about your server hardware, and you may want to remove some sections for privacy reasons. Use a text editor to read the output file and to remove anything you don't want to post.
nano /tmp/ripple_info.Xo8Xr/rippled_info.md
```
nano /tmp/ripple_info.Xo8Xr/rippled_info.md
```
3. Upload the output file where others can see it.
@@ -162,19 +170,15 @@ To use the script:
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Amendments](amendments.html)
- [The `rippled` Server](../../concepts/networks-and-servers/index.md)
- [Amendments](../../concepts/networks-and-servers/amendments.md)
- **Tutorials:**
- [Capacity Planning](capacity-planning.html)
- [Configure rippled](configure-rippled.html)
- [Capacity Planning](../installation/capacity-planning.md)
- [Configure rippled](../configuration/index.md)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`rippled` Commandline Usage](commandline-usage.html)
- [rippled API Reference](../../references/http-websocket-apis/index.md)
- [`rippled` Commandline Usage](../commandline-usage.md)
- [log_level method][]
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

100
content/infrastructure/troubleshooting/fix-sqlite-tx-db-page-size-issue.md
View File

@@ -6,7 +6,7 @@ status: removed
---
# Fix SQLite Transaction Database Page Size Issue
`rippled` servers with full [ledger history](ledger-history.html) (or a very large amount of transaction history) and a database that was initially created with a `rippled` version earlier than 0.40.0 (released January 2017) may encounter a problem with their SQLite database page size that stops the server from operating properly. Servers that store only recent transaction history (the default configuration) and servers whose database files were created with `rippled` version 0.40.0 and later are not likely to have this problem. <!-- STYLE_OVERRIDE: encounter -->
`rippled` servers with full [ledger history](../../concepts/networks-and-servers/ledger-history.md) (or a very large amount of transaction history) and a database that was initially created with a `rippled` version earlier than 0.40.0 (released January 2017) may encounter a problem with their SQLite database page size that stops the server from operating properly. Servers that store only recent transaction history (the default configuration) and servers whose database files were created with `rippled` version 0.40.0 and later are not likely to have this problem. <!-- STYLE_OVERRIDE: encounter -->
This document describes steps to detect and correct this problem if it occurs.
@@ -16,7 +16,7 @@ This document describes steps to detect and correct this problem if it occurs.
The capacity of the SQLite database is a result of the database's _page size_ parameter, which cannot be easily changed after the database is created. (For more information on SQLite's internals, see [the official SQLite documentation](https://www.sqlite.org/fileformat.html).) The database can reach its capacity even if there is still free space on the disk and filesystem where it is stored. As described in the [Fix](#fix) below, reconfiguring the page size to avoid this problem requires a somewhat time-consuming migration process. <!-- STYLE_OVERRIDE: easily -->
**Tip:** Full history is not necessary for most use cases. Servers with full transaction history may be useful for long-term analysis and archive purposes or as a precaution against disasters. For a less resource-intense way to contribute to the storage of transaction history, see [History Sharding](history-sharding.html).
**Tip:** Full history is not necessary for most use cases. Servers with full transaction history may be useful for long-term analysis and archive purposes or as a precaution against disasters. For a less resource-intense way to contribute to the storage of transaction history, see [History Sharding](../configuration/data-retention/history-sharding.md).
## Detection
@@ -71,23 +71,27 @@ Terminating thread doJob: AcquisitionDone: unhandled
## Fix
You can fix this issue using `rippled` on supported Linux systems according to the steps described in this document. In the case of a full-history server with system specs approximately matching the [recommended hardware configuration](capacity-planning.html#recommendation-1), the process may take more than two full days.
You can fix this issue using `rippled` on supported Linux systems according to the steps described in this document. In the case of a full-history server with system specs approximately matching the [recommended hardware configuration](../installation/capacity-planning.md#recommendation-1), the process may take more than two full days.
### Prerequisites
- You must be running **[rippled version 1.1.0][New in: rippled 1.1.0] or later**.
- [Upgrade rippled](install-rippled.html) to the latest stable version before starting this process.
- [Upgrade rippled](../installation/index.md) to the latest stable version before starting this process.
- You can check what version of `rippled` you have installed locally by running the following command:
rippled --version
```
rippled --version
```
- You must have enough free space to temporarily store a second copy of the transaction database, in a directory that is writable by the `rippled` user. This free space does not need to be in the same filesystem as the existing transaction database.
The transaction database is stored in the `transaction.db` file in the folder specified by your configuration's `[database_path]` setting. You can check the size of this file to see how much free space you need. For example:
ls -l /var/lib/rippled/db/transaction.db
```
ls -l /var/lib/rippled/db/transaction.db
```
### Migration Process
@@ -97,78 +101,108 @@ To migrate your transaction database to a larger page size, perform the followin
2. Create a folder to store temporary files during the migration process.
mkdir /tmp/rippled_txdb_migration
```
mkdir /tmp/rippled_txdb_migration
```
3. Grant the `rippled` user ownership of the temporary folder so it can write files there. (This is not necessary if your temporary folder is somewhere the `rippled` user already has write access to.)
chown rippled /tmp/rippled_txdb_migration
```
chown rippled /tmp/rippled_txdb_migration
```
4. Confirm that your temporary folder has enough free space to store a copy of the transaction database.
For example, compare the `Avail` output from the `df` command to the [size of your `transaction.db` file](#prerequisites).
df -h /tmp/rippled_txdb_migration
```
df -h /tmp/rippled_txdb_migration
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 5.4T 2.6T 2.6T 50% /tmp
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 5.4T 2.6T 2.6T 50% /tmp
```
5. If `rippled` is still running, stop it:
sudo systemctl stop rippled
```
sudo systemctl stop rippled
```
6. Open a `screen` session (or other similar tool) so that the process does not stop when you log out:
screen
```
screen
```
7. Become the `rippled` user:
sudo su - rippled
```
sudo su - rippled
```
8. Run `rippled` executable directly, providing the `--vacuum` command with the path to the temporary directory:
/opt/ripple/bin/rippled -q --vacuum /tmp/rippled_txdb_migration
```
/opt/ripple/bin/rippled -q --vacuum /tmp/rippled_txdb_migration
```
The `rippled` executable immediately displays the following message:
VACUUM beginning. page_size: 1024
```
VACUUM beginning. page_size: 1024
```
9. Wait for the process to complete. This can take more than two full days.
When the process is complete, the `rippled` executable displays the following message, then exits:
VACUUM finished. page_size: 4096
```
VACUUM finished. page_size: 4096
```
While you wait, you can detach your `screen` session by pressing **CTRL-A**, then **D**. Later, you can reattach your screen session with a command such as the following:
screen -x -r
```
screen -x -r
```
When the process is over, exit the screen session:
exit
```
exit
```
For more information on the `screen` command, see [the official Screen User's Manual](https://www.gnu.org/software/screen/manual/screen.html) or any of the other many resources available online.
10. Restart the `rippled` service.
sudo systemctl start rippled
```
sudo systemctl start rippled
```
11. Confirm that the `rippled` service started successfully.
You can use the [commandline interface](get-started-using-http-websocket-apis.html#commandline) to check the server status (unless you have configured your server not to accept JSON-RPC requests). For example:
You can use the [commandline interface](../../tutorials/get-started/get-started-using-http-websocket-apis.md#commandline) to check the server status (unless you have configured your server not to accept JSON-RPC requests). For example:
/opt/ripple/bin/rippled server_info
```
/opt/ripple/bin/rippled server_info
```
For a description of the expected response from this command, see the [server_info method][] documentation.
12. Watch the server's debug log to confirm that the `SQLite page size` is now 4096:
tail -F /var/log/rippled/debug.log
```
tail -F /var/log/rippled/debug.log
```
The [periodic log message](#proactive-detection) should also show significantly more free pages and free pages than it did before the migration.
13. Optionally, you may now remove the temporary folder you created for the migration process.
rm -r /tmp/rippled_txdb_migration
```
rm -r /tmp/rippled_txdb_migration
```
If you mounted additional storage to hold the temporary copy of the transaction database, you can unmount and remove it now.
@@ -176,18 +210,14 @@ To migrate your transaction database to a larger page size, perform the followin
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Ledger History](ledger-history.html)
- [The `rippled` Server](../../concepts/networks-and-servers/index.md)
- [Ledger History](../../concepts/networks-and-servers/ledger-history.md)
- **Tutorials:**
- [Understanding Log Messages](understanding-log-messages.html)
- [Configure Full History](configure-full-history.html)
- [Understanding Log Messages](understanding-log-messages.md)
- [Configure Full History](../configuration/data-retention/configure-full-history.md)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`rippled` Commandline Usage](commandline-usage.html)
- [rippled API Reference](../../references/http-websocket-apis/index.md)
- [`rippled` Commandline Usage](../commandline-usage.md)
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

25
content/infrastructure/troubleshooting/health-check-interventions.md
View File

@@ -7,7 +7,7 @@ labels:
---
# Health Check Interventions
The [Health Check method](health-check.html) can be used by automated monitoring to recognize when a `rippled` server is not healthy and prompt interventions such as restarting the server or alerting a human administrator.
The [Health Check method](../../references/http-websocket-apis/peer-port-methods/health-check.md) can be used by automated monitoring to recognize when a `rippled` server is not healthy and prompt interventions such as restarting the server or alerting a human administrator.
Infrastructure monitoring, and reliability engineering more generally, is an advanced discipline that involves using multiple sources of data to make decisions in context. This document provides some suggestions for how to use the health check most effectively, but these recommendations are only meant as guidelines as part of a larger strategy.
@@ -25,8 +25,8 @@ Certain server configurations may always report a `warning` status even when ope
Some examples of special cases that may occur include:
- A [private peer](peer-protocol.html#private-peers) typically has a very small number of peer-to-peer connections to known servers only, but the health check reports a warning on the `peers` metric if the server is connected to 7 or fewer peers. You should know the exact number of peers your server is configured to have and check for that value.
- On a [parallel or test network](parallel-networks.html) where new transactions are not being sent continuously, the network waits up to 20 seconds for new transactions before attempting to validate a new ledger version, but the health check reports a warning on the `validated_ledger` metric if the latest validated ledger is 7 or more seconds old. If you are running `rippled` on a non-production network, you may want to ignore `warning` messages for this metric unless you know that there should be transactions being regularly sent. You may still want to alert on the `critical` level of 20 seconds, because the XRP Ledger protocol is designed to validate new ledger versions at least once every 20 seconds even if there are no new transactions to process.
- A [private peer](../../concepts/networks-and-servers/peer-protocol.md#private-peers) typically has a very small number of peer-to-peer connections to known servers only, but the health check reports a warning on the `peers` metric if the server is connected to 7 or fewer peers. You should know the exact number of peers your server is configured to have and check for that value.
- On a [parallel or test network](../../concepts/networks-and-servers/parallel-networks.md) where new transactions are not being sent continuously, the network waits up to 20 seconds for new transactions before attempting to validate a new ledger version, but the health check reports a warning on the `validated_ledger` metric if the latest validated ledger is 7 or more seconds old. If you are running `rippled` on a non-production network, you may want to ignore `warning` messages for this metric unless you know that there should be transactions being regularly sent. You may still want to alert on the `critical` level of 20 seconds, because the XRP Ledger protocol is designed to validate new ledger versions at least once every 20 seconds even if there are no new transactions to process.
## Suggested Interventions
@@ -43,7 +43,7 @@ The following sections suggest some common interventions you may want to attempt
### Redirect Traffic
A common reliability technique is to run a pool of redundant servers through one or more load-balancing proxies. You can do this with `rippled` servers, but should not do this with [validators](rippled-server-modes.html). In some cases, the load balancers can monitor the health of servers in their pools and direct traffic only to the servers that are currently reporting themselves as healthy. This allows servers to recover from being temporarily overloaded and automatically rejoin the pool of active servers.
A common reliability technique is to run a pool of redundant servers through one or more load-balancing proxies. You can do this with `rippled` servers, but should not do this with [validators](../../concepts/networks-and-servers/rippled-server-modes.md). In some cases, the load balancers can monitor the health of servers in their pools and direct traffic only to the servers that are currently reporting themselves as healthy. This allows servers to recover from being temporarily overloaded and automatically rejoin the pool of active servers.
Redirecting traffic away from a server that is unhealthy is an appropriate response, especially for servers that report a `health` status of `warning`. Servers in the `critical` range may need more significant interventions.
@@ -70,11 +70,11 @@ A stronger intervention is to restart the entire machine.
### Upgrade
If the server reports `"amendment_blocked": true` in the health check, this indicates that the XRP Ledger has enabled a [protocol amendment](amendments.html) that your server does not understand. As a precaution against misinterpreting the revised rules of the network in a way that causes you to lose money, such servers become "amendment blocked" instead of operating normally.
If the server reports `"amendment_blocked": true` in the health check, this indicates that the XRP Ledger has enabled a [protocol amendment](../../concepts/networks-and-servers/amendments.md) that your server does not understand. As a precaution against misinterpreting the revised rules of the network in a way that causes you to lose money, such servers become "amendment blocked" instead of operating normally.
To resolve being amendment blocked, [update your server](install-rippled.html) to a newer software version that understands the amendment.
To resolve being amendment blocked, [update your server](../installation/index.md) to a newer software version that understands the amendment.
Also, software bugs can cause a server to get [stuck not syncing](server-doesnt-sync.html). In this case, the `server_state` metric is likely to be in a warning or critical state. If you are not using the latest stable release, you should upgrade to get the latest fixes for any known issues that could cause this.
Also, software bugs can cause a server to get [stuck not syncing](server-doesnt-sync.md). In this case, the `server_state` metric is likely to be in a warning or critical state. If you are not using the latest stable release, you should upgrade to get the latest fixes for any known issues that could cause this.
### Investigate Network
@@ -97,7 +97,7 @@ In this case, the necessary interventions may involve changes to other systems,
If the outage is caused by a hardware failure or by higher load than the hardware is capable of handling, you may need to replace some components or even the entire server.
The amount of load on a server in the XRP Ledger depends in part on transaction volume in the network, which varies organically. Load also depends on your usage pattern. See [Capacity Planning](capacity-planning.html) for how to plan the appropriate hardware and settings for your situation.
The amount of load on a server in the XRP Ledger depends in part on transaction volume in the network, which varies organically. Load also depends on your usage pattern. See [Capacity Planning](../installation/capacity-planning.md) for how to plan the appropriate hardware and settings for your situation.
Warning or critical values for the following [metrics][] may indicate insufficient hardware:
@@ -110,8 +110,7 @@ Warning or critical values for the following [metrics][] may indicate insufficie
<!--{# common link defs #}-->
[metrics]: health-check.html#response-format
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
[metrics]: ../../references/http-websocket-apis/peer-port-methods/health-check.md#response-format
{% raw-partial file="/_snippets/common-links.md" /%}

8
content/infrastructure/troubleshooting/index.md
View File

@@ -1,9 +1,13 @@
---
html: troubleshoot-the-rippled-server.html
parent: infrastructure.html
template: pagetype-category.html.jinja
metadata:
indexPage: true
blurb: Troubleshoot all kinds of problems with the rippled server.
---
# Troubleshooting
Troubleshoot all kinds of problems with the rippled server.
Troubleshoot all kinds of problems with the rippled server.
{% child-pages /%}

64
content/infrastructure/troubleshooting/server-doesnt-sync.md
View File

@@ -7,9 +7,9 @@ labels:
---
# rippled Server Doesn't Sync
This page explains possible reasons [a `rippled` server](xrpl-servers.html) may start successfully, but get stuck in a ["connected" state](rippled-server-states.html) without ever fully connecting to the network. (If the server crashes during or shortly after startup, see [Server Won't Start](server-wont-start.html) instead.)
This page explains possible reasons [a `rippled` server](../../concepts/networks-and-servers/index.md) may start successfully, but get stuck in a ["connected" state](../../references/http-websocket-apis/api-conventions/rippled-server-states.md) without ever fully connecting to the network. (If the server crashes during or shortly after startup, see [Server Won't Start](server-wont-start.md) instead.)
These instructions assume you have [installed `rippled`](install-rippled.html) on a supported platform.
These instructions assume you have [installed `rippled`](../installation/index.md) on a supported platform.
## Normal Syncing Behavior
@@ -17,7 +17,7 @@ These instructions assume you have [installed `rippled`](install-rippled.html) o
Syncing with the network normally takes about 5 to 15 minutes. During that time, the server does several things:
- Loads a recommended validator list (for example, from `vl.ripple.com`) to determine which validators it trusts.
- [Discovers peer servers](peer-protocol.html#peer-discovery) and connects to them.
- [Discovers peer servers](../../concepts/networks-and-servers/peer-protocol.md#peer-discovery) and connects to them.
- Listens to its trusted validators to find which ledger hashes have been recently validated.
- Downloads the full latest ledger from its peers, and uses that to build its internal database of ledger data.
- Collects newly-broadcast transactions and attempts to apply them to its in-progress ledger.
@@ -29,14 +29,14 @@ If the server is unable to keep up with the network while doing these tasks, the
Many syncing issues can be resolved by restarting the server. No matter why it didn't sync the first time, it may succeed on the second try.
If the [server_info method][] shows a [`server_state`](rippled-server-states.html) other than `proposing` or `full` and a `server_state_duration_us` of more than `900000000` (15 minutes in microseconds), then you should shut down the `rippled` service, wait a few seconds, and start it again. Optionally, restart the entire machine.
If the [server_info method][] shows a [`server_state`](../../references/http-websocket-apis/api-conventions/rippled-server-states.md) other than `proposing` or `full` and a `server_state_duration_us` of more than `900000000` (15 minutes in microseconds), then you should shut down the `rippled` service, wait a few seconds, and start it again. Optionally, restart the entire machine.
If the problem persists, check the other possibilities listed on this page. If none of them seem to apply, [open an issue in the `rippled` repository](https://github.com/XRPLF/rippled/issues) and add the "Syncing issue" label.
## Usual Causes of Syncing Issues
The most common cause of syncing issues is not meeting the [system requirements](system-requirements.html). The three most common shortfalls are:
The most common cause of syncing issues is not meeting the [system requirements](../installation/system-requirements.md). The three most common shortfalls are:
- **Slow disks.** You need a consistently fast solid state disk (SSD). Cloud providers like AWS usually don't guarantee disk performance, because it depends on hardware shared with other customers.
- **Insufficient RAM.** The memory requirements vary depending on several factors including ones that are hard to predict like network load and how people use the XRP Ledger, so it's good to have more than the minimum system requirements.
@@ -47,7 +47,7 @@ If you are having trouble remaining synced, double-check that your server meets
## Couldn't Load Validator List
The default configuration uses a recommended list of validators retrieved from `vl.ripple.com`. This list is signed by Ripple's cryptographic key pair and has a built-in expiration date. If your server cannot download the list from `vl.ripple.com` for some reason, your server does not choose a set of trusted validators and cannot determine which possible ledgers to declare as valid. (If you are connected to [the testnet or another parallel network](parallel-networks.html), your server uses a list of trusted validators for that network instead.)
The default configuration uses a recommended list of validators retrieved from `vl.ripple.com`. This list is signed by Ripple's cryptographic key pair and has a built-in expiration date. If your server cannot download the list from `vl.ripple.com` for some reason, your server does not choose a set of trusted validators and cannot determine which possible ledgers to declare as valid. (If you are connected to [the testnet or another parallel network](../../concepts/networks-and-servers/parallel-networks.md), your server uses a list of trusted validators for that network instead.)
The `validator_list` block in the [server_info method][] response shows the status of your validator list including its expiration date. If you have a list, but it's expired, it's possible that your server had connectivity to the validator list site before but hasn't been able to connect lately, so your current list expired while your server was unable to download a more updated list.
@@ -58,9 +58,9 @@ You can also use the [validator_list_sites method][] to get more detailed inform
## Not Enough Peers
If your server does not connect to enough [peer servers](peer-protocol.html), it may not be able to download enough data to remain synced with the network as the network continues processing new transactions. This can happen if your network connection is unreliable, or if you configure your server as a [private server](peer-protocol.html#private-peers) without adding enough reliable fixed peers.
If your server does not connect to enough [peer servers](../../concepts/networks-and-servers/peer-protocol.md), it may not be able to download enough data to remain synced with the network as the network continues processing new transactions. This can happen if your network connection is unreliable, or if you configure your server as a [private server](../../concepts/networks-and-servers/peer-protocol.md#private-peers) without adding enough reliable fixed peers.
Use the [peers method][] to get information about your server's current peers. If you have exactly 10 or 11 peers, that may indicate that your firewall is blocking incoming peer connections. [Set up port forwarding](forward-ports-for-peering.html) to allow more incoming connections. If your server is configured as a private server, double-check the contents and syntax of the `[ips_fixed]` stanza in your config file, and add more proxies or public hubs if possible.
Use the [peers method][] to get information about your server's current peers. If you have exactly 10 or 11 peers, that may indicate that your firewall is blocking incoming peer connections. [Set up port forwarding](../configuration/peering/forward-ports-for-peering.md) to allow more incoming connections. If your server is configured as a private server, double-check the contents and syntax of the `[ips_fixed]` stanza in your config file, and add more proxies or public hubs if possible.
## Corrupt Databases
@@ -69,31 +69,39 @@ In rare cases, corrupt data saved in your `rippled` server's internal databases
As a test, you can temporarily change the paths to your server's databases as long as you have enough free space to re-download the current ledger and store other settings.
**Note:** When you change the database paths, the server does not load some saved settings, such as the server's current [node key pair][] and [peer reservations](peer-protocol.html#fixed-peers-and-peer-reservations). If changing the database paths fixes your server' syncing problems, you may want to re-create some of these settings.
**Note:** When you change the database paths, the server does not load some saved settings, such as the server's current [node key pair][] and [peer reservations](../../concepts/networks-and-servers/peer-protocol.md#fixed-peers-and-peer-reservations). If changing the database paths fixes your server' syncing problems, you may want to re-create some of these settings.
1. Stop the `rippled` server if it is running.
$ sudo systemctl stop rippled
```
$ sudo systemctl stop rippled
```
2. Create new empty folders to hold the fresh databases.
$ mkdir /var/lib/rippled/db_new/
$ mkdir /var/lib/rippled/db_new/nudb
```
$ mkdir /var/lib/rippled/db_new/
$ mkdir /var/lib/rippled/db_new/nudb
```
3. Edit the config file to use the new paths. Be sure to change the `path` field of the `[node_db]` stanza **and** the value of the `[database_path]` stanza.
[node_db]
type=NuDB
path=/var/lib/rippled/db_new/nudb
```
[node_db]
type=NuDB
path=/var/lib/rippled/db_new/nudb
[database_path]
/var/lib/rippled/db_new
[database_path]
/var/lib/rippled/db_new
```
{% include '_snippets/conf-file-location.md' %}<!--_ -->
{% partial file="/_snippets/conf-file-location.md" /%}
4. Start the `rippled` server again.
$ sudo systemctl start rippled
```
$ sudo systemctl start rippled
```
If the server successfully syncs using the fresh databases, you can delete the folders that hold the old databases. You may also want to check for hardware failures, especially to your disk and RAM.
@@ -101,20 +109,18 @@ As a test, you can temporarily change the paths to your server's databases as lo
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Peer Protocol](peer-protocol.html)
- [Technical FAQ](technical-faq.html)
- [The `rippled` Server](../../concepts/networks-and-servers/index.md)
- [Peer Protocol](../../concepts/networks-and-servers/peer-protocol.md)
- [Technical FAQ](../../faq.md)
- **Tutorials:**
- [Understanding Log Messages](understanding-log-messages.html)
- [Capacity Planning](capacity-planning.html)
- [Understanding Log Messages](understanding-log-messages.md)
- [Capacity Planning](../installation/capacity-planning.md)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [rippled API Reference](../../references/http-websocket-apis/index.md)
- [peers method][]
- [server_info method][]
- [validator_list_sites method][]
<!-- SPELLING_IGNORE: aws -->
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

6
content/infrastructure/troubleshooting/server-is-amendment-blocked.md
View File

@@ -9,7 +9,7 @@ labels:
Servers which are amendment blocked can't determine the validity of a ledger, submit or process transactions, or participate in the consensus process.
One of the first signs that your `rippled` server is [amendment blocked](amendments.html#amendment-blocked-servers) is an `amendmentBlocked` error that is returned when you submit a transaction. Here's an example `amendmentBlocked` error:
One of the first signs that your `rippled` server is [amendment blocked](../../concepts/networks-and-servers/amendments.md#amendment-blocked-servers) is an `amendmentBlocked` error that is returned when you submit a transaction. Here's an example `amendmentBlocked` error:
```json
{
@@ -65,7 +65,7 @@ The easiest solution is to update to the latest version of `rippled`, but depend
To determine if you can unblock your `rippled` server by upgrading to a version older than the newest version, find out which features are blocking your server and then look up the `rippled` version that supports the blocking features.
To find out which features are blocking your `rippled` server, use the [`feature`](feature.html) admin command. Look for features that have:
To find out which features are blocking your `rippled` server, use the [`feature`](../../references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/feature.md) admin command. Look for features that have:
```
"enabled" : true
@@ -129,4 +129,4 @@ In this example, conflicts with the following features are causing your `rippled
* `F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064`
To look up which `rippled` version supports these features, see [Known Amendments](known-amendments.html).
To look up which `rippled` version supports these features, see [Known Amendments](../../resources/known-amendments.md).

60
content/infrastructure/troubleshooting/server-wont-start.md
View File

@@ -7,9 +7,9 @@ labels:
---
# rippled Server Won't Start
This page explains possible reasons [the `rippled` server](xrpl-servers.html) does not start and how to fix them.
This page explains possible reasons [the `rippled` server](../../concepts/networks-and-servers/index.md) does not start and how to fix them.
These instructions assume you have [installed `rippled`](install-rippled.html) on a supported platform.
These instructions assume you have [installed `rippled`](../installation/index.md) on a supported platform.
## File Descriptors Limit
@@ -25,22 +25,30 @@ This occurs because the system has a security limit on the number of files a sin
1. Add the following lines to the end of your `/etc/security/limits.conf` file:
* soft nofile 65536
* hard nofile 65536
```
* soft nofile 65536
* hard nofile 65536
```
2. Check that the [hard limit on number of files that can be opened](https://ss64.com/bash/ulimit.html) is now `65536`:
ulimit -Hn
```
ulimit -Hn
```
The command should output `65536`.
3. Try starting `rippled` again.
systemctl start rippled
```
systemctl start rippled
```
4. If `rippled` still does not start, open `/etc/sysctl.conf` and append the following kernel-level setting:
fs.file-max = 65536
```
fs.file-max = 65536
```
## Failed to open /etc/opt/ripple/rippled.cfg
@@ -62,7 +70,7 @@ Possible solutions:
**Tip:** The `rippled` repository contains [an example `rippled.cfg` file](https://github.com/XRPLF/rippled/blob/master/cfg/rippled-example.cfg) which is provided as the default config when you do an RPM installation. If you do not have the file, you can copy it from there.
- Specify the path to your preferred config file using the `--conf` [commandline option](commandline-usage.html).
- Specify the path to your preferred config file using the `--conf` [commandline option](../commandline-usage.md).
## Failed to open validators file
@@ -84,11 +92,13 @@ Possible solutions:
- Edit your `rippled.cfg` file and remove the `[validators_file]` setting. Add validator settings directly to your `rippled.cfg` file. For example:
[validator_list_sites]
https://vl.ripple.com
```
[validator_list_sites]
https://vl.ripple.com
[validator_list_keys]
ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
[validator_list_keys]
ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
```
## Cannot create database path
@@ -173,22 +183,22 @@ An error such as the following indicates that the `rippled.cfg` file has an impr
Terminating thread rippled: main: unhandled N5beast14BadLexicalCastE 'std::bad_cast'
```
Valid parameters for the `node_size` field are `tiny`, `small`, `medium`, `large`, or `huge`. For more information see [Node Size](capacity-planning.html#node-size).
Valid parameters for the `node_size` field are `tiny`, `small`, `medium`, `large`, or `huge`. For more information see [Node Size](../installation/capacity-planning.md#node-size).
## Shard path missing
An error such as the following indicates that the `rippled.cfg` has an incomplete [history sharding](history-sharding.html) configuration:
An error such as the following indicates that the `rippled.cfg` has an incomplete [history sharding](../configuration/data-retention/history-sharding.md) configuration:
```text
Terminating thread rippled: main: unhandled St13runtime_error 'shard path missing'
```
If your config includes a `[shard_db]` stanza, it must contain a `path` field, which points to a directory where `rippled` can write the data for the shard store. This error means the `path` field is missing or located in the wrong place. Check for extra whitespace or typos in your config file, and compare against the [Shard Configuration Example](configure-history-sharding.html#2-edit-rippledcfg).
If your config includes a `[shard_db]` stanza, it must contain a `path` field, which points to a directory where `rippled` can write the data for the shard store. This error means the `path` field is missing or located in the wrong place. Check for extra whitespace or typos in your config file, and compare against the [Shard Configuration Example](../configuration/data-retention/configure-history-sharding.md#2-edit-rippledcfg).
## Unsupported shard store type: RocksDB
RocksDB is no longer supported as a backend for [history sharding](history-sharding.html). If you have an existing configuration that defines a RocksDB shard store, the server fails to start. [New in: rippled 1.3.1][]
RocksDB is no longer supported as a backend for [history sharding](../configuration/data-retention/history-sharding.md). If you have an existing configuration that defines a RocksDB shard store, the server fails to start. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.3.1" %}New in: rippled 1.3.1{% /badge %}
In this case, the process dies shortly after the log startup command, with a message such as the following appearing earlier in the output log:
@@ -206,18 +216,16 @@ To fix this problem, do one of the following, then restart the server:
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Technical FAQ](technical-faq.html)
- [The `rippled` Server](../../concepts/networks-and-servers/index.md)
- [Technical FAQ](../../faq.md)
- **Tutorials:**
- [Understanding Log Messages](understanding-log-messages.html)
- [Capacity Planning](capacity-planning.html)
- [Understanding Log Messages](understanding-log-messages.md)
- [Capacity Planning](../installation/capacity-planning.md)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`rippled` Commandline Usage](commandline-usage.html)
- [rippled API Reference](../../references/http-websocket-apis/index.md)
- [`rippled` Commandline Usage](../commandline-usage.md)
- [server_info method][]
<!-- SPELLING_IGNORE: cfg, node_size -->
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}

75
content/infrastructure/troubleshooting/understanding-log-messages.md
View File

@@ -7,9 +7,9 @@ labels:
---
# Understanding Log Messages
The following sections describe some of the most common types of log messages that can appear in a [`rippled` server's](xrpl-servers.html) debug log and how to interpret them.
The following sections describe some of the most common types of log messages that can appear in a [`rippled` server's](../../concepts/networks-and-servers/index.md) debug log and how to interpret them.
This is an important step in [Diagnosing Problems](diagnosing-problems.html) with `rippled`.
This is an important step in [Diagnosing Problems](diagnosing-problems.md) with `rippled`.
## Log Message Structure
@@ -26,7 +26,7 @@ Each line represents one log entry, with the following parts in order, separated
1. The date the log entry was written, such as `2020-Jul-08`.
2. The time the log entry was written, such as `20:12:12.075081020`.
3. The time zone indicator `UTC`. (Log dates are always in UTC.) [New in: rippled 1.5.0][]
3. The time zone indicator `UTC`. (Log dates are always in UTC.) {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.5.0" %}New in: rippled 1.5.0{% /badge %}
4. The log partition and severity, such as `LoadMonitor:WRN`.
5. The log message, such as `Job: sweep run: 1172ms wait: 0ms`.
@@ -45,13 +45,13 @@ Throw<std::runtime_error>
Terminating thread rippled: main: unhandled St13runtime_error
```
If your server always crashes on startup, see [Server Won't Start](server-wont-start.html) for possible cases.
If your server always crashes on startup, see [Server Won't Start](server-wont-start.md) for possible cases.
If your server crashes randomly during operation or as a result of particular commands, make sure you are [updated](install-rippled.html) to the latest `rippled` version. If you are on the latest version and your server is still crashing, check the following:
If your server crashes randomly during operation or as a result of particular commands, make sure you are [updated](../installation/index.md) to the latest `rippled` version. If you are on the latest version and your server is still crashing, check the following:
- Is your server running out of memory? On some systems, `rippled` may be terminated by the Out Of Memory (OOM) Killer or another monitor process.
- If your server is running in a shared environment, are other users or administrators causing the machine or service to be restarted? For example, some hosted providers automatically kill any service that uses a large amount of a shared machine's resources for an extended period of time.
- Does your server meet the [minimum requirements](system-requirements.html) to run `rippled`? What about the [recommendations for production servers](system-requirements.html#recommended-specifications)?
- Does your server meet the [minimum requirements](../installation/system-requirements.md) to run `rippled`? What about the [recommendations for production servers](../installation/system-requirements.md#recommended-specifications)?
If none of the above apply, please report the issue to Ripple as a security-sensitive bug. If Ripple can reproduce the crash, you may be eligible for a bounty. See <https://ripple.com/bug-bounty/> for details.
@@ -73,7 +73,7 @@ Occasional messages of this type do not usually indicate a problem. If this type
## async_send failed
The following log message indicates that [StatsD export](configure-statsd.html) failed:
The following log message indicates that [StatsD export](../configuration/configure-statsd.md) failed:
```text
Collector:ERR async_send failed: Connection refused
@@ -97,7 +97,7 @@ The following message indicates that the server has detected that it is running
LedgerMaster:ERR Check for upgrade: A majority of trusted validators are running a newer version.
```
This is not strictly a problem, but an old server version is likely to become [amendment blocked](amendments.html#amendment-blocked-servers). You should [update `rippled`](install-rippled.html) to the latest stable version. (If you are connected to [devnet](parallel-networks.html), update to the latest nightly version instead.)
This is not strictly a problem, but an old server version is likely to become [amendment blocked](../../concepts/networks-and-servers/amendments.md#amendment-blocked-servers). You should [update `rippled`](../installation/index.md) to the latest stable version. (If you are connected to [devnet](../../concepts/networks-and-servers/parallel-networks.md), update to the latest nightly version instead.)
## Connection reset by peer
@@ -118,7 +118,7 @@ A large number of these messages around the same time may indicate a problem, su
## Consumer entry dropped with balance at or above drop threshold
The following log message indicates that a client to the server's public API has been dropped as a result of [rate limiting](rate-limiting.html):
The following log message indicates that a client to the server's public API has been dropped as a result of [rate limiting](../../references/http-websocket-apis/api-conventions/rate-limiting.md):
```text
Resource:WRN Consumer entry 169.55.164.21 dropped with balance 15970 at or above drop threshold 15000
@@ -128,7 +128,7 @@ The entry contains the IP address of the client that exceeded its rate limit, an
If you see frequent messages from the same IP address, you may want to block those IP addresses from your network to reduce the load on your server's public API. (For example, you may be able to configure your firewall to block those IP addresses.)
To avoid being dropped by rate limiting on your own server, [connect as an admin](get-started-using-http-websocket-apis.html#admin-access).
To avoid being dropped by rate limiting on your own server, [connect as an admin](../../tutorials/get-started/get-started-using-http-websocket-apis.md#admin-access).
## InboundLedger 11 timeouts for ledger
@@ -136,7 +136,7 @@ To avoid being dropped by rate limiting on your own server, [connect as an admin
InboundLedger:WRN 11 timeouts for ledger 8265938
```
This indicates that your server is having trouble requesting specific ledger data from its peers. If the [ledger index](basic-data-types.html#ledger-index) is much lower than the most recent validated ledger's index as reported by the [server_info method][], this probably indicates that your server is downloading a [history shard](history-sharding.html).
This indicates that your server is having trouble requesting specific ledger data from its peers. If the [ledger index](../../references/protocol/data-types/basic-data-types.md#ledger-index) is much lower than the most recent validated ledger's index as reported by the [server_info method][], this probably indicates that your server is downloading a [history shard](../configuration/data-retention/history-sharding.md).
This is not strictly a problem, but if you want to acquire ledger history faster, you can configure `rippled` to connect to peers with full history by adding or editing the `[ips_fixed]` config stanza and restarting the server. For example, to always try to connect to one of Ripple's full-history servers:
@@ -154,7 +154,7 @@ Log messages such as the following indicate that the server is requesting ledger
InboundLedger:WRN Want: 5AE53B5E39E6388DBACD0959E5F5A0FCAF0E0DCBA45D9AB15120E8CDD21E019B
```
This is normal if your server is syncing, backfilling, or downloading [history shards](history-sharding.html).
This is normal if your server is syncing, backfilling, or downloading [history shards](../configuration/data-retention/history-sharding.md).
## LoadMonitor Job
@@ -194,7 +194,7 @@ type=RocksDB
## No hash for fetch pack
Messages such as the following are caused by a bug in `rippled` v1.1.0 and earlier when downloading historical ledgers for [history sharding](history-sharding.html):
Messages such as the following are caused by a bug in `rippled` v1.1.0 and earlier when downloading historical ledgers for [history sharding](../configuration/data-retention/history-sharding.md):
```text
2018-Aug-28 22:56:21.397076850 LedgerMaster:ERR No hash for fetch pack. Missing Index 7159808
@@ -205,20 +205,20 @@ These can be safely ignored.
## Not deleting
Messages such as the following occur when [online deletion is interrupted](online-deletion.html#interrupting-online-deletion):
Messages such as the following occur when [online deletion is interrupted](../configuration/data-retention/online-deletion.md#interrupting-online-deletion):
```text
SHAMapStore:WRN Not deleting. state: syncing. age 25s
```
The `state` indicates the [server state](rippled-server-states.html). The `age` indicates how many seconds since the last validated ledger was closed. (A healthy age for the last validated ledger is 7 seconds or less.)
The `state` indicates the [server state](../../references/http-websocket-apis/api-conventions/rippled-server-states.md). The `age` indicates how many seconds since the last validated ledger was closed. (A healthy age for the last validated ledger is 7 seconds or less.)
During startup, these messages are normal and can be safely ignored. At other times, messages like this usually indicate that the server does not meet the [system requirements](system-requirements.html), especially disk I/O, to run online deletion at the same time as everything else the server is doing.
During startup, these messages are normal and can be safely ignored. At other times, messages like this usually indicate that the server does not meet the [system requirements](../installation/system-requirements.md), especially disk I/O, to run online deletion at the same time as everything else the server is doing.
## Potential Censorship
Log messages such as the following are issued when the XRP Ledger detects potential transaction censorship. For more information about these log messages and the transaction censorship detector, see [Transaction Censorship Detection](transaction-censorship-detection.html).
Log messages such as the following are issued when the XRP Ledger detects potential transaction censorship. For more information about these log messages and the transaction censorship detector, see [Transaction Censorship Detection](../../concepts/networks-and-servers/transaction-censorship-detection.md).
**Warning Message**
@@ -235,7 +235,7 @@ LedgerConsensus:ERR Potential Censorship: Eligible tx E08D6E9754025BA2534A787076
## rotating validatedSeq
This message indicates that [online deletion](online-deletion.html) has started running:
This message indicates that [online deletion](../configuration/data-retention/online-deletion.md) has started running:
```text
SHAMapStore:WRN rotating validatedSeq 54635511 lastRotated 54635255 deleteInterval 256 canDelete_ 4294967295
@@ -248,9 +248,9 @@ The log message contains values describing the current online deletion run. Each
| Keyword | Value | Description |
|:-----------------|:-----------------|:---------------------------------------|
| `validatedSeq` | [Ledger Index][] | The current validated ledger version. |
| `lastRotated` | [Ledger Index][] | The end of the ledger range in the ["old" (read-only) database](online-deletion.html#how-it-works). Online deletion deletes this ledger version and earlier. |
| `deleteInterval` | Number | How many ledger versions to keep after online deletion. The [`online_delete` setting](online-deletion.html#configuration) controls this value. |
| `canDelete_` | [Ledger Index][] | The newest ledger version that the server is allowed to delete, if using [advisory deletion](online-deletion.html#advisory-deletion). If not using advisory deletion, this value is ignored. |
| `lastRotated` | [Ledger Index][] | The end of the ledger range in the ["old" (read-only) database](../configuration/data-retention/online-deletion.md#how-it-works). Online deletion deletes this ledger version and earlier. |
| `deleteInterval` | Number | How many ledger versions to keep after online deletion. The [`online_delete` setting](../configuration/data-retention/online-deletion.md#configuration) controls this value. |
| `canDelete_` | [Ledger Index][] | The newest ledger version that the server is allowed to delete, if using [advisory deletion](../configuration/data-retention/online-deletion.md#advisory-deletion). If not using advisory deletion, this value is ignored. |
When online deletion finishes, it writes the following log message:
@@ -265,7 +265,7 @@ If the server falls out of sync while running online deletion, it interrupts onl
## Shard: No such file or directory
Log messages such as the following can occur when you have [history sharding](history-sharding.html) enabled:
Log messages such as the following can occur when you have [history sharding](../configuration/data-retention/history-sharding.md) enabled:
```text
ShardStore:ERR shard 1804: No such file or directory
@@ -288,8 +288,8 @@ Log messages such as the following occur when the server sees a validation messa
Validations:WRN Unable to determine hash of ancestor seq=3 from ledger hash=00B1E512EF558F2FD9A0A6C263B3D922297F26A55AEB56A009341A22895B516E seq=12133675
```
{% include '_snippets/unsynced_warning_logs.md' %}
<!--_ -->
{% partial file="/_snippets/unsynced_warning_logs.md" /%}
## [veto_amendments] section in config file ignored
@@ -301,7 +301,7 @@ Log messages such as the following occur when your `rippled.cfg` file contains
Amendments:WRN [veto_amendments] section in config file ignored in favor of data in db/wallet.db.
```
To resolve this error, remove the `[amendments]` and `[veto_amendments]` stanzas from your config file. For more information, see [Amendment Voting](amendments.html#amendment-voting).
To resolve this error, remove the `[amendments]` and `[veto_amendments]` stanzas from your config file. For more information, see [Amendment Voting](../../concepts/networks-and-servers/amendments.md#amendment-voting).
## View of consensus changed during open
@@ -314,8 +314,8 @@ LedgerConsensus:WRN 96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC7
LedgerConsensus:WRN {"accepted":true,"account_hash":"89A821400087101F1BF2D2B912C6A9F2788CC715590E8FA5710F2D10BF5E3C03","close_flags":0,"close_time":588812130,"close_time_human":"2018-Aug-28 22:55:30.000000000","close_time_resolution":30,"closed":true,"hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_index":"3","parent_close_time":588812070,"parent_hash":"5F5CB224644F080BC8E1CC10E126D62E9D7F9BE1C64AD0565881E99E3F64688A","seqNum":"3","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
```
{% include '_snippets/unsynced_warning_logs.md' %}
<!--_ -->
{% partial file="/_snippets/unsynced_warning_logs.md" /%}
## We are not running on the consensus ledger
@@ -324,26 +324,23 @@ LedgerConsensus:WRN {"accepted":true,"account_hash":"89A821400087101F1BF2D2B912C
NetworkOPs:WRN We are not running on the consensus ledger
```
{% include '_snippets/unsynced_warning_logs.md' %}
<!--_ -->
{% partial file="/_snippets/unsynced_warning_logs.md" /%}
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Technical FAQ](technical-faq.html)
- [The `rippled` Server](../../concepts/networks-and-servers/index.md)
- [Technical FAQ](../../faq.md)
- **Tutorials:**
- [Diagnosing Problems](diagnosing-problems.html)
- [Capacity Planning](capacity-planning.html)
- [Diagnosing Problems](diagnosing-problems.md)
- [Capacity Planning](../installation/capacity-planning.md)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`rippled` Commandline Usage](commandline-usage.html)
- [rippled API Reference](../../references/http-websocket-apis/index.md)
- [`rippled` Commandline Usage](../commandline-usage.md)
- [server_info method][]
<!-- SPELLING_IGNORE: oom, async_send, statsd, inboundledger, loadmonitor, validatedseq -->
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}
{% raw-partial file="/_snippets/common-links.md" /%}