mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-30 08:35:50 +00:00
Reorg tutorials for managing rippled
- Incorporate macOS install instructions
This commit is contained in:
mDuo13
@@ -0,0 +1,87 @@
|
||||
# Cluster rippled Servers
|
||||
|
||||
If you run multiple `rippled` servers in the same data center, you can configure them in a [cluster](clustering.html) to maximize efficiency. To configure clustering:
|
||||
|
||||
1. For each of your servers, note the IP address of the server.
|
||||
|
||||
2. For each of your servers, generate a unique seed using the [validation_create method][].
|
||||
|
||||
For example, using the commandline interface:
|
||||
|
||||
$ 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"
|
||||
}
|
||||
}
|
||||
|
||||
Save the `validation_seed` and `validation_public_key` parameters from each response somewhere secure.
|
||||
|
||||
3. On each server, edit the [config file](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg), modifying the following sections:
|
||||
|
||||
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
|
||||
|
||||
This defines specific peer servers to which this server should always attempt to maintain a direct peer-to-peer connection.
|
||||
|
||||
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
|
||||
|
||||
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
|
||||
|
||||
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
|
||||
|
||||
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
|
||||
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"cluster" : {
|
||||
"n9McNsnzzXQPbg96PEUrrQ6z3wrvgtU4M7c97tncMpSoDzaQvPar": {
|
||||
"tag": "keynes",
|
||||
"age": 1
|
||||
},
|
||||
"n94UE1ukbq6pfZY9j54sv2A1UrEeHZXLbns3xK5CzU9NbNREytaa": {
|
||||
"tag": "friedman",
|
||||
"age": 1
|
||||
}
|
||||
},
|
||||
"peers" : [
|
||||
... (omitted) ...
|
||||
],
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,46 @@
|
||||
# Configure History Sharding
|
||||
|
||||
[History Sharding](history-sharding.html) lets servers contribute to preserving historical XRP Ledger data without each server needing to store the full history. By default, `rippled` servers do not store history shards.
|
||||
|
||||
**Tip:** While both validator and tracking (or stock) `rippled` servers can be configured to store history shards, Ripple recommends _not_ configuring validator `rippled` servers to store shards, to reduce overhead on those servers. If you run a validator and want to contribute to storing XRP Ledger history, Ripple recommends you run a separate `rippled` server with history sharding enabled.
|
||||
|
||||
To configure your `rippled` to store shards of ledger history, complete the following steps:
|
||||
|
||||
## 1. Determine how much space to allocate for the shard store
|
||||
|
||||
Before you configure your `rippled` server to store history shards, you must decide how much disk space to allocate to the history shard store. This also affects how much history you keep in the default ledger store. You should consider the following when deciding what size to configure your shard store:
|
||||
|
||||
- The ledger store (defined by the `[node_db]` stanza) is separate from the history shard store. The ledger store is required for all servers and _must_ contain a range of recent history, defined by how many ledgers to keep available in the `online_delete` parameter. (The default configuration stores the most recent 2000 ledgers.)
|
||||
- If you keep at least 2^15 ledgers (32768) in the ledger store, you can efficiently import chunks of recent history from the ledger store into the shard store.
|
||||
- The history shard store (defined by the `[shard_db]` stanza) is only required for storing history shards. The configuration stanza should be omitted from servers that do not store history shards. The size of the history shard store is defined in gigabytes in the `max_size_gb` parameter; the server attempts to use as much of this space as possible to store complete shards.
|
||||
- A shard consists of 2^14 ledgers (16384) and occupies approximately 200 MB to 4 GB based on the age of the shard. Older shards are smaller because there was less activity in the XRP Ledger at the time.
|
||||
- The history shard store and the ledger store _must_ be stored at different file paths. You can configure the ledger store and history store to be on different disks or partitions if desired.
|
||||
- It is possible but redundant to hold full ledger history in both the ledger store and the history shard store.
|
||||
- The time to acquire a shard, number of file handles needed by the `rippled` server, and memory cache usage is directly affected by the size of the shard.
|
||||
|
||||
## 2. Edit rippled.cfg
|
||||
|
||||
Edit your `rippled.cfg` file to add a `[shard_db]` stanza.
|
||||
|
||||
{% include '_snippets/conf-file-location.md' %}<!--_ -->
|
||||
|
||||
The following snippet shows an example of a `[shard_db]` stanza:
|
||||
|
||||
```
|
||||
[shard_db]
|
||||
type=NuDB
|
||||
path=/var/lib/rippled/db/shards/nudb
|
||||
max_size_gb=50
|
||||
```
|
||||
|
||||
**Tip:** Ripple recommends using NuDB for the shard store (`type=NuDB`). NuDB uses fewer file handles per shard than RocksDB. RocksDB uses memory that scales with the size of data it stores, which may require excessive memory overhead. However, NuDB is designed to be used with SSD drives and does not work with rotational disks.
|
||||
|
||||
For more information, reference the `[shard_db]` example in the [rippled.cfg configuration example](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg).
|
||||
|
||||
## 3. Restart the server
|
||||
|
||||
```
|
||||
systemctl restart rippled
|
||||
```
|
||||
|
||||
***TODO: is there an API method you can use to check that the server started and sharding was successfully enabled?***
|
||||
@@ -0,0 +1,35 @@
|
||||
# Enable Public Signing
|
||||
|
||||
[New in: rippled 1.1.0][] By default, the signing methods for `rippled` are limited to administrative connections. 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.
|
||||
|
||||
This enables the following methods to be used on "public" [JSON-RPC and WebSocket connections](get-started-with-the-rippled-api.html), if your server accepts them:
|
||||
|
||||
- [sign][sign method]
|
||||
- [sign_for][sign_for method]
|
||||
- [submit][submit method] (in "sign-and-submit" mode)
|
||||
|
||||
You **do not** need to enable public signing to use these methods from an admin connection.
|
||||
|
||||
**Caution:** Ripple does not recommend enabling public signing. Like the [wallet_propose method][], the signing commands do not perform any actions that would require administrative-level permissions, but restricting them to admin connections protects users from irresponsibly sending or receiving secret keys over unsecured communications, or to servers they do not control.
|
||||
|
||||
To enable public signing, perform the following steps:
|
||||
|
||||
1. Edit your `rippled`'s config file.
|
||||
|
||||
vim /etc/opt/ripple/rippled.cfg
|
||||
|
||||
{% include '_snippets/conf-file-location.md' %}<!--_ -->
|
||||
|
||||
2. Add the following stanza to your config file, and save the changes:
|
||||
|
||||
[signing_support]
|
||||
true
|
||||
|
||||
3. Restart your `rippled` server:
|
||||
|
||||
systemctl restart rippled
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,74 @@
|
||||
# Run rippled as a Validator
|
||||
|
||||
Running a `rippled` validator that participates in the Consensus process is simple:
|
||||
|
||||
1. [Enable validation](run-rippled-as-a-validator.html) on your `rippled` server.
|
||||
* At first, your server is an _untrusted validator_. Others can see the validations your server issues, but they disregard them in the consensus process.
|
||||
2. Share the public key with the public, especially other `rippled` operators.
|
||||
3. When other `rippled` operators add your public key to their list of trusted servers, you have become a _trusted validator_.
|
||||
* Also see [Properties of a Good Validator](rippled-server-modes.html#properties-of-a-good-validator) for best practices.
|
||||
|
||||
|
||||
## Validator Setup
|
||||
|
||||
The `validator-keys` tool (included in the `rippled` RPM) is the recommended means to securely generate and manage your validator keys.
|
||||
|
||||
1. [Install a `rippled` server.](install-rippled.html)
|
||||
|
||||
2. Generate a validator key pair:
|
||||
|
||||
$ /opt/ripple/bin/validator-keys create_keys
|
||||
|
||||
**Warning:** Store the generated `validator-keys.json` key file in a secure but recoverable location, such as an encrypted USB flash drive. Do not modify its contents.
|
||||
|
||||
3. Generate a validator token and edit your `rippled.cfg` file to add the `[validator_token]` value.
|
||||
|
||||
$ /opt/ripple/bin/validator-keys create_token --keyfile /path/to/your/validator-keys.json
|
||||
|
||||
If you had previously configured your validator without using the `validator-keys` tool, you must also delete the `[validation_seed]` from your `rippled.cfg` file. This changes your validator public key.
|
||||
|
||||
4. Start `rippled`:
|
||||
|
||||
$ sudo service rippled restart
|
||||
|
||||
See [the `validator-keys-tool` GitHub repository](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md) for more information about managing validator keys.
|
||||
|
||||
|
||||
## Public-Facing Server
|
||||
|
||||
To protect a production validator from [DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack) attacks, you can use a stock `rippled` server as a proxy between the validator and the outside network.
|
||||
|
||||
1. [Set up the `rippled` validator.](run-rippled-as-a-validator.html)
|
||||
|
||||
2. [Set up one or more stock `rippled` servers.](install-rippled.html)
|
||||
|
||||
3. Configure the validator and stock `rippled` servers to be [clustered](cluster-rippled-servers.html) with each other.
|
||||
|
||||
4. Make the following configuration changes to your validator:
|
||||
* Copy the `[ips_fixed]` list and paste it under `[ips]`. These fields should contain only the IP addresses and ports of the public-facing rippled(s). The validator connects to only these peers.
|
||||
* Change `[peer_private]` to `1` to prevent its IP address from being forwarded.
|
||||
|
||||
5. Configure the validator host machine's firewall to only accept inbound connections from its public-facing rippled(s).
|
||||
|
||||
Remember to restart `rippled` for config changes to take effect.
|
||||
|
||||
Take care not to publish the IP address of your validator.
|
||||
|
||||
|
||||
## Domain Verification
|
||||
|
||||
Network participants are unlikely to trust validators without knowing who is operating them. To address this concern, validator operators can associate their validator with a web domain that they control.
|
||||
|
||||
1. Find your validator public key by running the following on the validator server:
|
||||
|
||||
$ /opt/ripple/bin/rippled server_info -q | grep pubkey_validator
|
||||
|
||||
2. Sign the validator public key (from step 1) using the SSL private key used for your domain. The SSL private key file does not need to be stored on the validator server.
|
||||
|
||||
$ openssl dgst -sha256 -hex -sign /path/to/your/ssl.key <(echo <your-validator-public-key>)
|
||||
|
||||
3. Using `validator-keys` tool (included in the `rippled` RPM), sign the domain name:
|
||||
|
||||
$ /opt/ripple/bin/validator-keys --keyfile /path/to/your/validator-keys.json sign <your-domain-name>
|
||||
|
||||
4. To have the verified validator domain included on [XRP Charts](https://xrpcharts.ripple.com/#/validators), submit this [Google Form](https://docs.google.com/forms/d/e/1FAIpQLScszfq7rRLAfArSZtvitCyl-VFA9cNcdnXLFjURsdCQ3gHW7w/viewform) with your validator's information.
|
||||
Reference in New Issue
Block a user