This adds an empty `relay_api` section to the sample configuration. For SQLite environments, or others where a `database.connection_string` is needed for each section, there should be an entry in the configuration sample as a basis. This PR also changes the "Configuring Dendrite" documentation in that respect. The requirement was introduced in #2917. When upgrading dendrite, it will complain about `relay_api.database.connection_string` not being configured. ### Pull Request Checklist <!-- Please read https://matrix-org.github.io/dendrite/development/contributing before submitting your pull request --> * [x] I have added Go unit tests or [Complement integration tests](https://github.com/matrix-org/complement) for this PR _or_ I have justified why this PR doesn't need tests * [x] Pull request includes a [sign off below using a legally identifiable name](https://matrix-org.github.io/dendrite/development/contributing#sign-off) _or_ I have already signed off privately Signed-off-by: `Alex Kirk <akirk@users.noreply.github.com>`
4.7 KiB
title | parent | nav_order | permalink |
---|---|---|---|
Configuring Dendrite | Installation | 7 | /installation/configuration |
Configuring Dendrite
A YAML configuration file is used to configure Dendrite. A sample configuration file is present in the top level of the Dendrite repository:
You will need to duplicate the sample, calling it dendrite.yaml
for example, and then
tailor it to your installation. At a minimum, you will need to populate the following
sections:
Server name
First of all, you will need to configure the server name of your Matrix homeserver. This must match the domain name that you have selected whilst configuring the domain name delegation.
In the global
section, set the server_name
to your delegated domain name:
global:
# ...
server_name: example.com
Server signing keys
Next, you should tell Dendrite where to find your server signing keys.
In the global
section, set the private_key
to the path to your server signing key:
global:
# ...
private_key: /path/to/matrix_key.pem
JetStream configuration
Monolith deployments can use the built-in NATS Server rather than running a standalone server. If you want to use a standalone NATS Server anyway, you can also configure that too.
Built-in NATS Server
In the global
section, under the jetstream
key, ensure that no server addresses are
configured and set a storage_path
to a persistent folder on the filesystem:
global:
# ...
jetstream:
in_memory: false
storage_path: /path/to/storage/folder
topic_prefix: Dendrite
Standalone NATS Server
To use a standalone NATS Server instance, you will need to configure addresses
field
to point to the port that your NATS Server is listening on:
global:
# ...
jetstream:
addresses:
- localhost:4222
topic_prefix: Dendrite
You do not need to configure the storage_path
when using a standalone NATS Server instance.
In the case that you are connecting to a multi-node NATS cluster, you can configure more than
one address in the addresses
field.
Database connections
Configuring database connections varies based on the database configuration that you chose.
Global connection pool
If you want to use a single connection pool to a single PostgreSQL database, then you must
uncomment and configure the database
section within the global
section:
global:
# ...
database:
connection_string: postgres://user:pass@hostname/database?sslmode=disable
max_open_conns: 100
max_idle_conns: 5
conn_max_lifetime: -1
You must then remove or comment out the database
sections from other areas of the
configuration file, e.g. under the app_service_api
, federation_api
, key_server
,
media_api
, mscs
, relay_api
, room_server
, sync_api
and user_api
blocks, otherwise
these will override the global
database configuration.
Per-component connections (all other configurations)
If you are are using SQLite databases or separate PostgreSQL
databases per component, then you must instead configure the database
sections under each
of the component blocks ,e.g. under the app_service_api
, federation_api
, key_server
,
media_api
, mscs
, relay_api
, room_server
, sync_api
and user_api
blocks.
For example, with PostgreSQL:
room_server:
# ...
database:
connection_string: postgres://user:pass@hostname/dendrite_component?sslmode=disable
max_open_conns: 10
max_idle_conns: 2
conn_max_lifetime: -1
... or with SQLite:
room_server:
# ...
database:
connection_string: file:roomserver.db
max_open_conns: 10
max_idle_conns: 2
conn_max_lifetime: -1
Full-text search
Dendrite supports experimental full-text indexing using Bleve. It is configured in the sync_api
section as follows.
Depending on the language most likely to be used on the server, it might make sense to change the language
used when indexing, to ensure the returned results match the expectations. A full list of possible languages can be found here.
sync_api:
# ...
search:
enabled: false
index_path: "./searchindex"
language: "en"
Other sections
There are other options which may be useful so review them all. In particular, if you are
trying to federate from your Dendrite instance into public rooms then configuring the
key_perspectives
(like matrix.org
in the sample) can help to improve reliability
considerably by allowing your homeserver to fetch public keys for dead homeservers from
another living server.