mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-12-06 17:27:57 +00:00
Fix links for rippled server tuts
This commit is contained in:
mDuo13
@@ -8,4 +8,10 @@ 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).)
|
||||
|
||||
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](reference-transaction-format.html#common-fields).
|
||||
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).
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
@@ -184,7 +184,7 @@ Watchdog: Launching child 1
|
||||
|
||||
* Now that you have a stock `rippled` server running, you may want to consider running it as a validating server. For information about validating servers and why you might want to run one, see the [rippled Setup Tutorial](install-rippled.html).
|
||||
|
||||
* For information about communicating with your `rippled` server using the `rippled` API, see the [`rippled` API reference](reference-rippled.html).
|
||||
* For information about communicating with your `rippled` server using the `rippled` API, see the [`rippled` API reference](rippled-api.html).
|
||||
|
||||
* As a development best practice, you may want to build a `rippled` `.deb` file. For more information, see _Ubuntu Packaging Guide_: [Packaging New Software](http://packaging.ubuntu.com/html/packaging-new-software.html).
|
||||
|
||||
|
||||
@@ -17,3 +17,8 @@ To enable clustering, change the following sections of your [config file](https:
|
||||
* Generate a unique seed (using the [validation_create method][]) for each of your servers, and configure it under the `[node_seed]` section. The `rippled` server uses this key to sign its messages to other servers in the peer-to-peer network.
|
||||
|
||||
* Add the public keys (for peer communication) of each of your other servers under the `[cluster_nodes]` section.
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
@@ -57,3 +57,8 @@ When you load a ledger with `--ledger` in stand-alone mode, it goes to the curre
|
||||
```
|
||||
rippled ledger_accept --conf=/path/to/rippled.cfg
|
||||
```
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
@@ -1,3 +0,0 @@
|
||||
# Manage the rippled Server
|
||||
|
||||
This category encompasses various procedures for running stable and effective `rippled` servers.
|
||||
@@ -2,18 +2,18 @@
|
||||
|
||||
Running a `rippled` validator that participates in the Consensus process is simple:
|
||||
|
||||
1. [Enable validation](#validator-setup) on your `rippled` server.
|
||||
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](#properties-of-a-good-validator) for best practices.
|
||||
* Also see [Properties of a Good Validator](the-rippled-server.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.](#installing-rippled)
|
||||
1. [Install a `rippled` server.](install-rippled.html)
|
||||
|
||||
2. Generate a validator key pair:
|
||||
|
||||
@@ -38,11 +38,11 @@ See [the `validator-keys-tool` GitHub repository](https://github.com/ripple/vali
|
||||
|
||||
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.](#validator-setup)
|
||||
1. [Set up the `rippled` validator.](run-rippled-as-a-validator.html)
|
||||
|
||||
2. [Set up one or more stock `rippled` servers.](#installing-rippled)
|
||||
2. [Set up one or more stock `rippled` servers.](install-rippled.html)
|
||||
|
||||
3. Configure the validator and stock `rippled` servers to be [clustered](#clustering) with each other.
|
||||
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.
|
||||
|
||||
@@ -840,3 +840,8 @@ The [ripple.txt](https://wiki.ripple.com/Ripple.txt) standard provides a way to
|
||||
For example, if you run a validating `rippled` server, you can use ripple.txt to publish the public key of your validating server. You can also publish information about what currencies your gateway issues, and which XRP Ledger addresses you control, to protect against impostors or confusion.
|
||||
|
||||
<!-- STYLE_OVERRIDE: gateway, gateways -->
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
@@ -306,7 +306,7 @@ A user named Charlie wants to deposit 50,000 XRP to Alpha Exchange. Doing this i
|
||||
|
||||
1. Charlie submits a payment of 50,000 XRP (by using [RippleAPI](rippleapi-reference.html) or similar software) to Alpha Exchange's [cold wallet](#accounts).
|
||||
|
||||
a. Charlie adds an identifier (in this case, `789`) to the payment to associate it with his account at Alpha Exchange. This is called a [_destination tag_](become-an-xrp-ledger-gateway.html#source-and-destination-tags). (To use this, Alpha Exchange should have set the asfRequireDest flag on all of its accounts to require all incoming payments to have a destination tag like Charlie's. For more information, see [AccountSet Flags](reference-transaction-format.html#accountset-flags)).
|
||||
a. Charlie adds an identifier (in this case, `789`) to the payment to associate it with his account at Alpha Exchange. This is called a [_destination tag_](become-an-xrp-ledger-gateway.html#source-and-destination-tags). (To use this, Alpha Exchange should have set the asfRequireDest flag on all of its accounts to require all incoming payments to have a destination tag like Charlie's. For more information, see [AccountSet Flags](accountset.html#accountset-flags)).
|
||||
|
||||
2. The software at Alpha Exchange detects the incoming payment, and recognizes `789` as the destination tag for Charlie’s account.
|
||||
|
||||
|
||||
@@ -791,7 +791,7 @@ pages:
|
||||
|
||||
# TODO: identify your accounts with ripple.txt (to come later)
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/manage-the-rippled-server.md
|
||||
- name: Manage the rippled Server
|
||||
html: manage-the-rippled-server.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
|
||||
Reference in New Issue
Block a user