This repository contains the documentation and configuration necessary to run a Raiden Service Bundle.
Current release: Latest
The Raiden Network uses a federation of Matrix servers as its transport layer and a set of services for improved usability. This set of services is called the Raiden Service Bundle. To ensure reliability, availability and neutrality it is desirable that those services are being operated by multiple independent entities.
Therefore we provide this repository which allows easy setup of such a service bundle. It uses docker and docker-compose for easy installation and upgrades.
Currently only this single-server configuration is supported; in the future we may also provide configurations with services split among multiple servers.
- docker
- docker-compose
- Synapse
- Postgres
- Traefik
- Raiden Services (Pathfinding, Monitoring)
+-------------------+
| |
| Raiden clients |
| |
+---------+---------+
|https://
==========|==========
|
+---------v---------+ Federation to
| +-+--------------------> other Raiden
| Traefik | | Matrix servers
| |-+---------+----------------------+
+---------+-------+-+ | |
| | | |
+---------v-------v-+ +-----v----------------+ +---v-----------------+
| | | | | |
| Synapse | | Raiden Pathfinding | | Raiden Monitoring |
| | | | | |
+---------+---------+ +-------------------+--+ +-+-------------------+
| | |
+---------v---------+ +-v- - - v -+
| | |
| Postgres | ETH_RPC |
| | |
+-------------------+ + - - - - - +
We use Traefik as a reverse proxy and also utilize its capability of automatically provisioning Let's Encrypt TLS certificates.
The Synapse server is being run in the so-called split worker configuration which increases throughput.
The database stores the message data. Since the transport layer is considered ephemeral in Raiden it is not necessary to arrange for backups of the database data.
After a successful deployment the following ports will be in use:
- 80 - HTTP
- Redirects to HTTPS
- Let's Encrypt HTTP challenge for certificate provisioning
- 443 - HTTPS
- Synapse (on subdomain
transport.$<SERVER_NAME>
)- Client API access
- Server-to-Server federation
- Raiden Pathfinding Server (on subdomain
pfs.$<SERVER_NAME>
) - Metrics export (IP restricted, see below)
- Synapse (on subdomain
Minimum recommended for a production setup:
- 16 GiB RAM
- 8 Cores
- 50 GiB SSD
Note: The default Postgres configuration assumes 16GiB of system RAM
- Docker >= 17.12
- docker-compose >= 1.21.0
- A domain (or subdomain) for exclusive use by this server
- To ensure acceptable performance the server should be reserved for exclusive use by the RSB.
-
Provision a server that meets the hardware and software requirements listed above.
-
Ensure a domain (or subdomain) is available
Examples:
- raiden.somedomain.com
- raiden-service-bundle-somecompany.tld
-
Configure
A
(and optionallyAAAA
) DNS records for the domain pointing to the servers IP address(es) -
Configure a
CNAME
DNS record for*.<domain>
pointing back to<domain>
NOTE:
If you intend to use a subdomain it is important to be aware of the security implications. Sudomains share Cookies and Browser LocalStoarage with the apex domain. Therefore we strongly suggest that a subdomain is only used below an apex domain that does not host an application that relies on either Cookies or LocalStorage for security relevant purposes (e.g. user authentication).
NOTE:
This document will sometimes display release candidate versions, also known as pre-releases in the section below. You
can identify this, if there is an rcX
at the end of the version (E.g. 2019.03.0rc5
). When in doubt, always check against the
latest full release. If the version is
different from what you see below, you should stick to the "full release" and replace the version accordingly.
-
Clone the current release version of this repository to a suitable location on the server:
git clone -b 2021.06.0rc0 https://github.com/raiden-network/raiden-service-bundle.git
-
Copy
.env.template
to.env
and modify the values to fit your setup. Please read Configuring the.env
file for detailed information.- We would appreciate it if you allow us access to the monitoring interfaces
(to do that uncomment the default values of the
CIDR_ALLOW_METRICS
andCIDR_ALLOW_PROXY
settings). - We also recommend that you provide your own monitoring. The setup of which is currently out of scope of this document.
- Please read the disclaimers for the path finding and monitoring services carefully and uncomment the variables
<SERVICE>_ACCEPT_DISCLAIMER
if you agree. Note, that without agreement the services won't start.
- We would appreciate it if you allow us access to the monitoring interfaces
(to do that uncomment the default values of the
-
If you haven't done so before, run
./register-service-provider.sh register
(it uses configuration values from.env
). Please read the information provided Registering as a RSB Provider carefully before executing the script. -
Run
docker-compose up -d
to start all services- The services are configured to automatically restart in case of a crash or reboot
NOTE:
After a new RSB has been registered and added to the known_servers.main.yaml
file it can take up
to 24 hours for the information to propagate to existing RSB installations.
During this time some services will not yet be able to start successfully and log various error messages. This is expected behaviour and will resolve itself.
After the 24h have elapsed all services should run successfully. See verifying that the RSB is working below.
After cloning the repository the .env
file needs to be configured. A template named .env.template
is provided. Below you find a detailed list of the parameters to be set and their explanations.
SERVER_NAME
: The host domain without protocol prefixhttps://
respectivelyLETSENCRYPT_EMAIL
: Email addres to use when requesting LetsEncrypt certificatesCIDR_ALLOW_METRICS
: Metrics whitelist. IP address/network whitelists for access to non-public parts of the service. Uses CIDR notation. Separate multiple entries with commas. Example values: 10.0.0.0/16,10.1.2.3/32 or 10.1.2.3/32.CIDR_ALLOW_PROXY
: Proxy metrics / management interface whitelistWORKER_COUNT
: Number of worker processes to start, setting this to the number of CPUs is a good starting pointDATA_DIR
: Data dir location. Optional, defaults to ./data in the checkout directory.URL_KNOWN_FEDERATION_SERVERS
: URL to use to fetch federation whitelist - used only for testingKEYSTORE_FILE
: The keystore file which has to be located in ${DATA_DIR}/keystorePASSWORD
: Password to decrypt the keystore fileETH_RPC
: Ethereum RPC URLPFS_ACCEPT_DISCLAIMER
: TRUE or FALSE if you accept the Pathfinding Service disclaimer or not. Read the Disclaimer hereMS_ACCEPT_DISCLAIMER
: TRUE or FALSE if you accept the Monitoring Service disclaimer or not. Read the Disclaimer hereCHAIN_ID
: Chain ID of the connected Ethereum node.PFS_SERVICE_FEE
: The Pathfinding Service Fee to be paid for requestsPFS_OPERATOR
: Official Operator NamePFS_INFO_MESSAGE
: Info message. Will be displayed on info endpoint.LOG_LEVEL
: 'INFO' or 'DEBUG' recommended
For your newly deployed Raiden Service Bundle to be used by Raiden nodes it must be registered.
- Registering in the Services Registry On-Chain
- In order to register as a service provider you need to run the script
register-service-provider.sh
register
. - Make sure that you have configured a keystore file (
$KEYSTORE_FILE
in.env
). If not, the script will exit with an error and you cannot register as a service provider. - Make sure that the configured account has enough funding to register as a service provider.
You can check the registry contract for the current price of a slot.
You will find the price under
3. currentPrice
. To get the price in RDN divide the value by (10^18). The script will also inform you about price as well.
- Extending
known_servers/known_servers-production-v1.2.0.json
- In order to be whitelisted in the Matrix Federation, the list needs to be extended with your server name.
- Create an issue and submit the
domain / URL of the newly deployed server for inclusion in the list of known servers.
Please, state your server name as you have set
$SERVER_NAME
in your.env
file. - It may take up to 24 hours for the federation to accept the server as a new member. Please note, that until this moment, the pathfinding service and monitoring service cannot run properly as they need to use the broadcasting rooms. Once the new server is accepted as part of the federation, all services will restart automatically.
Besides the subcommand register
which can be used to register as a RSB provider, there are several other subcommands to interact with the service registry contract.
Commands:
- extend Extend the duration of a service registration
- info Show information about current registration and deposits
- register Registers the address of a service deployment with the
ServiceRegistry
. - withdraw Withdraw tokens deposited to the ServiceRegistry.
You can call register-service-provider.sh
<command>
to use them.
Check the status of the services by executing docker-compose ps
.
If any services are in a state other than Up
, Up (healthy)
or Exit 0
after the elapse of the 24h waiting period a configuration problem is the most likely cause.
See troubleshooting the RSB installation below in that case.
-
Matrix
- Check that the following endpoints return a successful response (HTTP status 200):
https://transport.<SERVER_NAME>/_matrix/client/versions
- Check that the following endpoints return a successful response (HTTP status 200):
-
PFS
-
Check that the
latest_committed_block
is increasing regularly:docker-compose logs --tail 100 pfs | grep latest_committed_block
-
Check that the following endpoint returns a successful response (HTTP status 200):
https://pfs.<SERVER_NAME>/api/v1/info
-
-
MS
-
Check that the
latest_confirmed_block
is increasing regularly:docker-compose logs --tail 100 ms | grep latest_confirmed_block
-
If you experience any unexpected behavior while installing the RSB, please do not hesitate to contact the development team. The fastet way to reach out to us is via the plublic Raiden Gitter channel. Otherwise, you can also open an issue in this repository with the predefined template for a bug report
To upgrade to a new release please refer to the upgrading document
for any
necessary configuration changes.
Afterwards run the following commands:
git fetch origin --tags
git reset --hard <new-release-tag>
docker-compose pull
docker-compose up -d
- A 'purger' service will run once a day, removing inactive users from global rooms to save disk space and processing performance.
- If necessary it will restart the
synapse
service to fetch an up-to-date whitelist of servers.
There is currently only some protection against Spam and / or DDoS attacks. This will be addressed in future updates.
The known servers the Raiden clients try to connect to are currently tracked in
the *.yml files in this repository. These lists are used by Raiden clients when
the --matrix-server=auto
(default) option is used, for automatically
selecting a transport server, based on response times. We intend to change this
in the future to use a decentralized scheme (for example an on-chain registry).
To report issues or request help with the setup please open an issue or contact us via email at contact@raiden.nework.
See CHANGELOG.md
.
The code and documentation in this repository are released under the MIT license.
This repository contains instructions to install third party software. Those are licensed as follows: