Merge pull request #384 from jhaaaa/rippled-serv-landing

fix rippled server landing

content/concepts/complex-payment-types/escrow.md

@@ -43,7 +43,7 @@ Escrow provides strong guarantees that are best suited for high-value, low-quant
 
 Conditional payments have been enabled by the ["Escrow" Amendment](known-amendments.html#escrow) to the XRP Ledger Consensus Protocol since 2017-03-31. A previous version of the same functionality was available on the [Ripple Test Net](https://ripple.com/build/ripple-test-net/) by the name "Suspended Payments" (SusPay) in 2016.
 
-When testing in [stand-alone mode](stand-alone-mode.html), you can force the Escrow feature to be enabled locally regardless of the amendment status. Add the following stanza to your `rippled.cfg`:
+When testing in [stand-alone mode](rippled-server-modes.html#reasons-to-run-a-rippled-server-in-stand-alone-mode), you can force the Escrow feature to be enabled locally regardless of the amendment status. Add the following stanza to your `rippled.cfg`:
 
     [features]
     Escrow

content/concepts/consensus-network/amendments.md

@@ -10,7 +10,7 @@ For a complete list of known amendments, their statuses, and IDs, see: [Known Am
 
 ## Background
 
-Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. If some _validators_ (`rippled` servers [participating in consensus](the-rippled-server.html#reasons-to-run-a-validator)) have upgraded to a new version of the software while other validators use the old version, this could cause anything from minor inconveniences to full outages. In the minor case, a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot build it using the transaction processing rules they already know. In the worst case, [the consensus process][] might be unable to validate new ledger versions because servers with different rules could not reach a consensus on the exact ledger to build.
+Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. If some _validators_ (`rippled` servers [participating in consensus](rippled-server-modes.html#reasons-to-run-a-validator)) have upgraded to a new version of the software while other validators use the old version, this could cause anything from minor inconveniences to full outages. In the minor case, a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot build it using the transaction processing rules they already know. In the worst case, [the consensus process][] might be unable to validate new ledger versions because servers with different rules could not reach a consensus on the exact ledger to build.
 
 Amendments solve this problem, so that new features can be enabled only when enough validators support those features.
 
@@ -221,7 +221,7 @@ To look up which `rippled` version supports these features, see [Known Amendment
 
 If you want to see how `rippled` behaves with an amendment enabled, before that amendment gets enabled on the production network, you can run use `rippled`'s configuration file to forcibly enable a feature. This is intended for development purposes only.
 
-Because other members of the consensus network probably do not have the feature enabled, you should not use this feature while connecting to the production network. While testing with features forcibly enabled, you should run `rippled` in [Stand-Alone Mode](stand-alone-mode.html).
+Because other members of the consensus network probably do not have the feature enabled, you should not use this feature while connecting to the production network. While testing with features forcibly enabled, you should run `rippled` in [Stand-Alone Mode](rippled-server-modes.html#reasons-to-run-a-rippled-server-in-stand-alone-mode).
 
 To forcibly enable a feature, add a `[features]` stanza to your `rippled.cfg` file. In this stanza, add the short names of the features to enable, one per line. For example:
 

content/concepts/payment-system-basics/transaction-basics/transaction-basics.md

@@ -49,7 +49,7 @@ Sending a transaction to the XRP Ledger involves several steps:
 3. Submit a transaction to a `rippled` server. If the transaction is properly formed, the server provisionally applies the transaction to its current version of the ledger and relays the transaction to other members of the peer-to-peer network.
 4. The [consensus process](https://ripple.com/build/ripple-ledger-consensus-process/) determines which provisional transactions get included in the next validated ledger.
 5. The `rippled` servers apply those transactions to the previous ledger in a canonical order and share their results.
-6. If enough [trusted validators](the-rippled-server.html#reasons-to-run-a-validator) created the exact same ledger, that ledger is declared _validated_ and the [results of the transactions](transaction-results.html) in that ledger are immutable.
+6. If enough [trusted validators](rippled-server-modes.html#reasons-to-run-a-validator) created the exact same ledger, that ledger is declared _validated_ and the [results of the transactions](transaction-results.html) in that ledger are immutable.
 
 
 ### Example Unsigned Transaction

content/concepts/the-rippled-server/clustering.md

@@ -1,6 +1,6 @@
 # Clustering
 
-If you are running multiple [`rippled` servers](the-rippled-server.html) in a single datacenter, you can configure those servers into a cluster to maximize efficiency. Running your `rippled` servers in a cluster provides the following benefits:
+If you are running multiple `rippled` servers in a single datacenter, you can configure those servers into a cluster to maximize efficiency. Running your `rippled` servers in a cluster provides the following benefits:
 
 - Clustered `rippled` servers share the work of cryptography. If one server has verified the authenticity of a message, the other servers in the cluster trust it and do not re-verify.
 - Clustered servers share information about peers and API clients that are misbehaving or abusing the network. This makes it harder to attack all servers of the cluster at once.

content/concepts/the-rippled-server/peer-protocol.md

@@ -160,7 +160,7 @@ Response:
 
 You can use the `[peer_private]` stanza of the `rippled` config file to request that peer servers do not report your IP address in the Peer Crawler response. Servers you do not control can be modified not to respect this setting. However, you can use this to hide the IP addresses of `rippled` servers you control that _only_ connect to peers you control (using `[ips_fixed]` and a firewall). In this way, you can use public rippled servers you control as proxies for your private rippled servers.
 
-To protect an important [validating server](the-rippled-server.html#types-of-rippled-servers), Ripple recommends configuring one or more public tracking servers to act as proxies, while the validating server is protected by a firewall and only connects to the public tracking servers.
+To protect an important [validating server](rippled-server-modes.html), Ripple recommends configuring one or more public tracking servers to act as proxies, while the validating server is protected by a firewall and only connects to the public tracking servers.
 
 <!--{# TODO: network diagram of private peers #}-->
 

content/concepts/the-rippled-server/rippled-server-modes.md

@@ -1,8 +1,4 @@
-# The rippled Server
-
-`rippled` is the core peer-to-peer server that manages the XRP Ledger. This section covers concepts that help you learn the "what" and "why" behind fundamental aspects of the `rippled` server.
-
-## Types of rippled Servers
+# rippled Server Modes
 
 The `rippled` server software can run in several modes depending on its configuration, including:
 
@@ -12,6 +8,7 @@ The `rippled` server software can run in several modes depending on its configur
 
 You can also run the `rippled` executable as a client application for accessing [`rippled` APIs](rippled-api.html) locally. (Two instances of the same binary can run side-by-side in this case; one as a server, and the other running briefly as a client and then terminating.)
 
+
 ## Reasons to Run a Stock Server
 
 There are lots of reasons you might want to run your own `rippled` server, but most of them can be summarized as: you can trust your own server, you have control over its workload, and you're not at the mercy of others to decide when and how you can access it. Of course, you must practice good network security to protect your server from malicious hackers.
@@ -35,6 +32,7 @@ Not all `rippled` servers need to be validators: trusting more servers from the
 
 If your organization runs a validating server, you may also run one or more stock servers, to balance the computing load of API access, or as a proxy between your validation server and the outside network.
 
+
 ### Properties of a Good Validator
 
 There are several properties that define a good validator. The more of these properties your server embodies, the more reason others have to include your server in their list of trusted validators:
@@ -49,3 +47,17 @@ There are several properties that define a good validator. The more of these pro
     * Setting up [Domain Verification](run-rippled-as-a-validator.html#domain-verification) is a good start.
 
 At present, Ripple (the company) cannot recommend any validators aside from those in the default validator list. However, we are collecting data on other validators and building tools to report on their performance. For metrics on validators, see the [XRPCharts Validator Registry](https://xrpcharts.ripple.com/#/validators).
+
+
+## Reasons to Run a `rippled` Server in Stand-Alone Mode
+
+You can run `rippled` in stand-alone mode without a consensus of trusted servers. In stand-alone mode, `rippled` does not communicate with any other servers in the XRP Ledger peer-to-peer network, but you can do most of the same actions on your local server only. Stand-alone provides a method for testing `rippled` behavior without being tied to the live network. For example, you can [test the effects of Amendments](amendments.html#testing-amendments) before those Amendments have gone into effect across the decentralized network.
+
+When you run `rippled` in stand-alone mode, you have to tell it what ledger version to start from:
+
+* Create a [new genesis ledger](start-a-new-genesis-ledger-in-stand-alone-mode.html) from scratch.
+* [Load an existing ledger version](load-a-saved-ledger-in-stand-alone-mode.html) from disk.
+
+**Caution:** In stand-alone mode, you must [manually advance the ledger](advance-the-ledger-in-stand-alone-mode.html).
+
+{% include '_snippets/rippled_versions.md' %}

content/concepts/the-rippled-server/stand-alone-mode.md

@@ -1,12 +0,0 @@
-# Stand-Alone Mode
-
-You can run `rippled` in stand-alone mode without a consensus of trusted servers. In stand-alone mode, `rippled` does not communicate with any other servers in the XRP Ledger peer-to-peer network, but you can do most of the same actions on your local server only. Stand-alone provides a method for testing `rippled` behavior without being tied to the live network. For example, you can [test the effects of Amendments](amendments.html#testing-amendments) before those Amendments have gone into effect across the decentralized network.
-
-When you run `rippled` in stand-alone mode, you have to tell it what ledger version to start from:
-
-* Create a [new genesis ledger](start-a-new-genesis-ledger-in-stand-alone-mode.html) from scratch.
-* [Load an existing ledger version](load-a-saved-ledger-in-stand-alone-mode.html) from disk.
-
-**Caution:** In stand-alone mode, you must [manually advance the ledger](advance-the-ledger-in-stand-alone-mode.html).
-
-{% include '_snippets/rippled_versions.md' %}

content/references/rippled-api/admin-rippled-methods/key-generation-methods/validation_create.md

@@ -1,7 +1,7 @@
 # validation_create
 [[Source]<br>](https://github.com/ripple/rippled/blob/315a8b6b602798a4cff4d8e1911936011e12abdb/src/ripple/rpc/handlers/ValidationCreate.cpp "Source")
 
-Use the `validation_create` command to generate the keys for a rippled [validator](the-rippled-server.html#reasons-to-run-a-validator). Similar to the [wallet_propose method][], this command makes no real changes, but only generates a set of keys in the proper format.
+Use the `validation_create` command to generate the keys for a rippled [validator](rippled-server-modes.html#reasons-to-run-a-validator). Similar to the [wallet_propose method][], this command makes no real changes, but only generates a set of keys in the proper format.
 
 _The `validation_create` method is an [admin method](admin-rippled-methods.html) that cannot be run by unprivileged users._
 

content/tutorials/manage-account-settings/set-up-multi-signing.md

@@ -18,7 +18,7 @@ This tutorial demonstrates how to enable multi-signing for an address.
 
 You need an XRP Ledger address that can send transactions, and has enough XRP available. Multi-signing requires more than the usual amount of XRP for the [account reserve](reserves.html) and [transaction cost](transaction-cost.html), increasing with the number of signers and signatures you use.
 
-If you started `rippled` in [stand-alone mode](stand-alone-mode.html) with a new genesis ledger, you must:
+If you started `rippled` in [stand-alone mode](rippled-server-modes.html#reasons-to-run-a-rippled-server-in-stand-alone-mode) with a new genesis ledger, you must:
 
 1. Generate keys for a new address, or reuse keys you already have.
 2. Submit a Payment transaction to fund the new address from the genesis account. (Send at least 100,000,000 [drops of XRP][].)

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

@@ -6,7 +6,7 @@ Running a `rippled` validator that participates in the Consensus process is simp
     * 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](the-rippled-server.html#properties-of-a-good-validator) for best practices.
+    * Also see [Properties of a Good Validator](rippled-server-modes.html#properties-of-a-good-validator) for best practices.
 
 
 ## Validator Setup

content/use-cases/run-a-rippled-validator.md

@@ -8,7 +8,7 @@ Each `rippled` server (not running in stand-alone mode) connects to a network of
 
 <span class="use-case-step-num">{{n.next()}}</span>
 <!-- <span class="use-case-step-length">(1 hour)</span> -->
-## [Understand what it means to run a validator](the-rippled-server.html#reasons-to-run-a-validator)
+## [Understand what it means to run a validator](rippled-server-modes.html#reasons-to-run-a-validator)
 
 If you or your organization relies on the XRP Ledger, it is in your interest to run a validator to participate in the consensus process and provide a trusted validator that supports the ongoing decentralization of the XRP Ledger.
 

dactyl-config.yml

@@ -453,7 +453,7 @@ pages:
         targets:
           - local
 
-    -   md: concepts/the-rippled-server/the-rippled-server.md
+    -   name: The rippled Server
         html: the-rippled-server.html
         funnel: Docs
         doc_type: Concepts
@@ -463,6 +463,15 @@ pages:
         targets:
             - local
 
+    -   md: concepts/the-rippled-server/rippled-server-modes.md
+        html: rippled-server-modes.html
+        funnel: Docs
+        doc_type: Concepts
+        category: The rippled Server
+        blurb: Learn about rippled server modes, including stock servers, validator servers, and rippled servers run in stand-alone mode.
+        targets:
+            - local
+
     -   md: concepts/the-rippled-server/clustering.md
         html: clustering.html
         funnel: Docs
@@ -490,16 +499,6 @@ pages:
         targets:
             - local
 
-    -   md: concepts/the-rippled-server/stand-alone-mode.md
-        html: stand-alone-mode.html
-        funnel: Docs
-        doc_type: Concepts
-        category: The rippled Server
-        blurb: Stand-alone mode provides a way to test rippled servers without connecting to a network of peers.
-        targets:
-            - local
-
-
 # Tutorials --------------------------------------------------------------------
 
     -   name: Tutorials