mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-20 19:55:54 +00:00
manoj's feedback
This commit is contained in:
Jennifer Hasegawa
@@ -27,8 +27,6 @@ Amazon EC2's `m3.large` VM size may be appropriate depending on your workload. A
|
||||
|
||||
## Installation on Ubuntu with alien
|
||||
|
||||
<!--{# ***TODO: this doc states that ubuntu has received the highest level of QA and testing - so I moved it above centos and macOS install sections. Okay?*** #}-->
|
||||
|
||||
This section assumes that you are using Ubuntu 15.04 or later.
|
||||
|
||||
1. Install yum-utils and alien:
|
||||
@@ -60,6 +58,10 @@ This section assumes that you are using Ubuntu 15.04 or later.
|
||||
|
||||
$ sudo systemctl start rippled.service
|
||||
|
||||
8. Verify that `rippled` has started.
|
||||
|
||||
$ sudo systemctl status rippled
|
||||
|
||||
For next steps, see [Postinstall](#postinstall) and [Additional Configuration](#additional-configuration).
|
||||
|
||||
|
||||
@@ -83,6 +85,10 @@ This section assumes that you are using CentOS 7 or Red Hat Enterprise Linux 7.
|
||||
|
||||
$ sudo systemctl start rippled.service
|
||||
|
||||
5. Verify that `rippled` has started.
|
||||
|
||||
$ sudo systemctl status rippled
|
||||
|
||||
For next steps, see [Postinstall](#postinstall) and [Additional Configuration](#additional-configuration).
|
||||
|
||||
|
||||
@@ -90,9 +96,7 @@ For next steps, see [Postinstall](#postinstall) and [Additional Configuration](#
|
||||
|
||||
At this time, we don't recommend using the macOS platform for `rippled` production use. For production, consider using the [Ubuntu platform](#installation-on-ubuntu-with-alien), which has received the highest level of quality assurance and testing.
|
||||
|
||||
That said, macOS is suitable for many development and testing tasks.
|
||||
|
||||
This section assumes that you are using macOS X 10.0 or higher. ***TODO: okay?***
|
||||
That said, macOS is suitable for many development and testing tasks. `rippled` has been tested for use with macOS High Sierra up to 10.13.
|
||||
|
||||
{% set n = cycler(* range(1,99)) %}
|
||||
|
||||
@@ -114,51 +118,19 @@ This section assumes that you are using macOS X 10.0 or higher. ***TODO: okay?**
|
||||
|
||||
brew install git cmake pkg-config protobuf openssl ninja
|
||||
|
||||
{{n.next()}}. Install a supported version of Boost. Supported versions include Boost 1.67.x - 1.68.x. ***TODO: correctly stated supported versions? In the rippled repo, we say "Boost 1.67 or later is required." <-- Based on our discussion in this doc, I don't think this open-ended "later" part is true, is it?***
|
||||
{{n.next()}}. Install Boost 1.67.0. Currently, we support Boost 1.67 only.
|
||||
|
||||
Pick one of the following Boost installation methods: ***TODO: I provided the two options below because these are the most straightforward ways for a user to install one of the two supported versions of Boost. In the future, if there are more supported versions or more brew boost formalae, there may be more options to document.***
|
||||
brew install boost@1.67
|
||||
|
||||
* To install Boost 1.67.0, use `brew install boost@1.67`. ***TODO: When Boost 1.67.0 is no longer supported, we'll need to change this formula. Until then, the user will be able to use this command to get a supported version of Boost. `brew install boost` also installs 1.67.0, but as discussed, we don't want to provide the command because it won't always install 1.67.0 and may cause the user to install an unsupported version. There is no brew command to install 1.68 right now.***
|
||||
{{n.next()}}. Ensure that your `BOOST_ROOT` environment variable points to the directory created by the Boost installation. To find your Boost install directory, use `brew info boost`. Put this environment variable in your `.bash_profile` file so it's automatically set when you log in. For example:
|
||||
|
||||
* To install Boost 1.68.0, compile Boost yourself. ***TODO: When the supported versions change above, we can also change these instructions, if needed. It would be great to genericize - but the way that the Boost brew and compiles are working right now - being version-specific seems necessary to keep folks from inadvertently installing an unsupported version.***
|
||||
|
||||
1. Download [Boost 1.68.0](https://dl.bintray.com/boostorg/release/1.68.0/source/boost_1_68_0.tar.bz2) to an appropriate directory. ***TODO: okay to do it outside of CLI? If we want to give them CLI instructions, need to have them run `brew install wget` and then `wget https://dl.bintray.com/boostorg/release/1.68.0/source/boost_1_68_0.tar.bz2`.***
|
||||
|
||||
2. Extract `boost_1_68_0.tar.bz2`.
|
||||
|
||||
`tar xvzf boost_1_68_0.tar.bz2`
|
||||
|
||||
3. Change to the newly created `boost_1_68_0` directory.
|
||||
|
||||
`cd boost_1_68_0`
|
||||
|
||||
4. Prepare the Boost.Build system for use.
|
||||
|
||||
`./bootstrap.sh`
|
||||
|
||||
5. Build the separately-compiled Boost libraries. This may take about 10 minutes, depending on your hardware specs. 11:14
|
||||
|
||||
`./b2 cxxflags="-std=c++14" -j 4`
|
||||
|
||||
**Tip:** This example uses 4 processes to build in parallel. The best number of processes to use depends on how many CPU cores your hardware has available. Use `sysctl -n hw.ncpu` to get your CPU core count.
|
||||
|
||||
{{n.next()}}. Ensure that the `BOOST_ROOT` environment variable points to the directory created by your Boost installation. Put this environment variable in your `.bash_profile` file so it's automatically set when you log in.
|
||||
|
||||
* If you used Homebrew to install Boost, ensure that `BOOST_ROOT` is set to the location where Homebrew installed Boost. For example:
|
||||
|
||||
`export BOOST_ROOT=/usr/local/Cellar/boost/1.67.0_1`
|
||||
|
||||
To find your Boost install directory, use `brew info boost`.
|
||||
|
||||
* If you manually compiled and installed Boost, ensure that `BOOST_ROOT` is set to the location where you installed Boost. For example:
|
||||
|
||||
`export BOOST_ROOT=/Users/tblee/boost/boost_1_68_0`
|
||||
export BOOST_ROOT=/usr/local/Cellar/boost/1.67.0_1
|
||||
|
||||
{{n.next()}}. If you updated your `.bash_profile` file in the previous step, be sure to source it. For example:
|
||||
|
||||
source .bash_profile
|
||||
|
||||
{{n.next()}}. Clone the `rippled` source code into your desired location and access the `rippled` directory. To do this, you'll need to set up Git (installed earlier using Homebrew) and GitHub. For example, you'll need to create a GitHub account and set up your SSH key. For more information, see [Set up git](https://help.github.com/articles/set-up-git/). ***TODO: does this sound okay for introducing what a user may have to do to set up git and GitHub?***
|
||||
{{n.next()}}. Clone the `rippled` source code into your desired location and access the `rippled` directory. To do this, you'll need to set up Git (installed earlier using Homebrew) and GitHub. For example, you'll need to create a GitHub account and set up your SSH key. For more information, see [Set up git](https://help.github.com/articles/set-up-git/).
|
||||
|
||||
git clone git@github.com:ripple/rippled.git
|
||||
cd rippled
|
||||
@@ -169,13 +141,13 @@ This section assumes that you are using macOS X 10.0 or higher. ***TODO: okay?**
|
||||
|
||||
git checkout master
|
||||
|
||||
Or, you can checkout one of the tagged releases listed on [GitHub](https://github.com/ripple/rippled/releases).
|
||||
|
||||
If you want to test out the latest release candidate, checkout the `release` branch:
|
||||
|
||||
git checkout release
|
||||
|
||||
{{n.next()}}. In the `rippled` directory you just cloned, create your build directory and access it. ***TODO: Does this "In the rippled directory you just cloned" language make sense? I just want to tell the user where to create the build directory.*** For example:
|
||||
Or, you can checkout one of the tagged releases listed on [GitHub](https://github.com/ripple/rippled/releases).
|
||||
|
||||
{{n.next()}}. In the `rippled` directory you just cloned, create your build directory and access it. For example:
|
||||
|
||||
mkdir my_build
|
||||
cd my_build
|
||||
@@ -190,7 +162,7 @@ This section assumes that you are using macOS X 10.0 or higher. ***TODO: okay?**
|
||||
|
||||
cmake --build . -- -j 4
|
||||
|
||||
This example uses a `-j` parameter set to `4`, which uses four processes to build in parallel. The best number of processes to use depends on how many CPU cores your hardware has available. Use `sysctl -n hw.ncpu` to get your CPU core count.
|
||||
**Tip:** This example uses a `-j` parameter set to `4`, which uses four processes to build in parallel. The best number of processes to use depends on how many CPU cores your hardware has available. Use `sysctl -n hw.ncpu` to get your CPU core count.
|
||||
|
||||
{{n.next()}}. Run unit tests built into the server executable. This could take about 5 minutes, depending on your hardware specs. (optional, but recommended) <!--{# ***TODO: We should provide info about what to do if you get failures. What should the user do? PM looking into this.*** #}-->
|
||||
|
||||
@@ -201,7 +173,7 @@ This section assumes that you are using macOS X 10.0 or higher. ***TODO: okay?**
|
||||
mkdir -p /etc/opt/ripple ***TODO: changed this from ~/.config/ripple to match guidance coming in conf-file-location.md PR -- okay?***
|
||||
cp cfg/rippled-example.cfg /etc/opt/ripple/rippled.cfg
|
||||
|
||||
{{n.next()}}. Edit `rippled.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. ***TODO: I think we need to add this step to the centos and ubuntu tasks, correct? For centos and ubuntu, the config files are automatically placed in the correct directories, but the following paths still need to be manually updated to avoid permission issues, correct?***
|
||||
{{n.next()}}. Edit `rippled.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. ***TODO: We need to add this step to the centos and ubuntu tasks, correct? For centos and ubuntu, the config files are automatically placed in the correct directories, but the following paths still need to be manually checked/updated to ensure that there are no permission issues, correct?***
|
||||
|
||||
* Set the `[node_db]` path to the location where you want to store the ledger database.
|
||||
|
||||
@@ -221,15 +193,9 @@ This section assumes that you are using macOS X 10.0 or higher. ***TODO: okay?**
|
||||
|
||||
sudo ./rippled
|
||||
|
||||
For next steps, see [Postinstall](#postinstall) and [Additional Configuration](#additional-configuration).
|
||||
|
||||
|
||||
## Postinstall
|
||||
|
||||
It can take several minutes for `rippled` to sync with the rest of the network, during which time it outputs warnings about missing ledgers.
|
||||
|
||||
Here's an excerpt of what you can expect to see in your terminal: ***TODO: you'll see this in the CLI for the macOS install because we tell them to start the service using `sudo ./rippled`, but not for centos and ubuntu. For centos and ubuntu, we tell the user to start the service using `sudo systemctl start rippled.service`, which starts the service, but doesn't display a log of the service starting up. At least for first-time start up - would it make sense to give the user this start up command (sudo ./rippled) instead so that they can see it running? Perhaps in Postinstall we can give them the `sudo systemctl start rippled.service` command for when they want to start the service, but don't need to see the running log?***
|
||||
Here's an excerpt of what you can expect to see in your terminal:
|
||||
|
||||
```
|
||||
2018-Oct-26 18:21:39.593738 JobQueue:NFO Auto-tuning to 6 validation/transaction/proposal threads.
|
||||
2018-Oct-26 18:21:39.599634 Amendments:DBG Amendment 4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 is supported.
|
||||
2018-Oct-26 18:21:39.599874 Amendments:DBG Amendment 6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC is supported.
|
||||
@@ -265,11 +231,7 @@ Here's an excerpt of what you can expect to see in your terminal: ***TODO: you'l
|
||||
"command" : "log_level",
|
||||
"severity" : "warning"
|
||||
}
|
||||
|
||||
|
||||
2018-Oct-26 18:21:39.752079 Application:FTL Result: {}
|
||||
|
||||
|
||||
2018-Oct-26 18:22:33.013409 NetworkOPs:WRN We are not running on the consensus ledger
|
||||
2018-Oct-26 18:22:33.013875 LedgerConsensus:WRN Need consensus ledger 81804C95ADE119CC874572BAF24DB0C0D240AC58168597951B0CB64C4DA2C628
|
||||
2018-Oct-26 18:22:33.883648 LedgerConsensus:WRN View of consensus changed during open status=open, mode=wrongLedger
|
||||
@@ -279,6 +241,14 @@ Here's an excerpt of what you can expect to see in your terminal: ***TODO: you'l
|
||||
2018-Oct-26 18:23:03.034334 InboundLedger:WRN Want: 1C01EE79083DE5CE76F3634519D6364C589C4D48631CB9CD10FC2408F87684E2
|
||||
2018-Oct-26 18:23:03.034560 InboundLedger:WRN Want: 8CFE3912001BDC5B2C4B2691F3C7811B9F3F193E835D293459D80FBF1C4E684E
|
||||
2018-Oct-26 18:23:03.034750 InboundLedger:WRN Want: 8DFAD21AD3090DE5D6F7592B3821C3DA77A72287705B4CF98DC0F84D5DD2BDF8
|
||||
```
|
||||
|
||||
For next steps, see [Postinstall](#postinstall) and [Additional Configuration](#additional-configuration).
|
||||
|
||||
|
||||
## Postinstall
|
||||
|
||||
It can take several minutes for `rippled` to sync with the rest of the network, during which time it outputs warnings about missing ledgers.
|
||||
|
||||
<!--{# ***TODO: for the future, provide a reference for what the most common and unintuitive messages mean -- esp when signaling possible errors.*** #}-->
|
||||
|
||||
@@ -295,9 +265,9 @@ Once you have your stock `rippled` server running, you may want to consider runn
|
||||
|
||||
`rippled` should connect to the XRP Ledger with the default configurations. However, you can change your settings by editing the `rippled.cfg` file. For recommendations about configuration settings, see [Capacity Planning](capacity-planning.html).
|
||||
|
||||
Changes to the `[node_db]`, `[debug_logfile]`, or `[database_path]` sections may require you to give the `rippled` user and group ownership to your new configured path: ***TODO: I added [node_db] to this list - okay? When I try the following command, `chown -R rippled:rippled /var/lib/rippled/db/rocksdb`, I get `chown: rippled: illegal group name.` Is `rippled:rippled` just an example below -- or should there be a `rippled` group that is created by the build/install process?***
|
||||
Changes to the `[node_db]`, `[debug_logfile]`, or `[database_path]` sections may require you to give the `rippled` user and group ownership to your new configured path: ***TODO: I added [node_db] to this list - okay?***
|
||||
|
||||
$ chown -R rippled:rippled <configured path>
|
||||
$ chown -R rippled:rippled <configured path> ***TODO: Is `rippled:rippled` just an example value? When I run this command on macOS, I get `chown: rippled: illegal group name.` When I run it on centos, I get chown: changing ownership of ... : Operation not permitted***
|
||||
|
||||
Restart `rippled` for any configuration changes to take effect: ***TODO: when I try this on macOS, I get `sudo: service: command not found`. I don't think the `service` command exists for macOS. For macOS, can the user just stop (ctrl+c? Not sure if that is the proper way to stop the service) and start rippled (sudo ./rippled) instead? For centos and ubuntu, we use `sudo systemctl start rippled.service` to start the service - below should we use `sudo systemctl restart rippled.service` - just to be consistent?***
|
||||
|
||||
|
||||
Reference in New Issue
Block a user