Fix links for rippled server tuts

content/tutorials/manage-the-rippled-server/advance-the-ledger-in-stand-alone-mode.md

@@ -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' %}

content/tutorials/manage-the-rippled-server/build-run-rippled-ubuntu.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).
 

content/tutorials/manage-the-rippled-server/cluster-rippled-servers.md

@@ -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' %}

content/tutorials/manage-the-rippled-server/load-a-saved-ledger-in-stand-alone-mode.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' %}

content/tutorials/manage-the-rippled-server/manage-the-rippled-server.md

@@ -1,3 +0,0 @@
-# Manage the rippled Server
-
-This category encompasses various procedures for running stable and effective `rippled` servers.

content/tutorials/manage-the-rippled-server/run-rippled-as-a-validator.md

@@ -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.