pub/charts
1
0
Fork 0
Code Issues Pull requests Releases Packages 19 Activity Actions

matrix-synapse: Update documentation slightly

Browse source
This commit is contained in:
Alexander Olofsson 2021-12-09 11:23:25 +01:00
parent 6c0e125fb9
commit a733b9dbf1
No known key found for this signature in database
GPG key ID: D439C9470CB04C73
2 changed files with 14 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
charts/matrix-synapse/README.md
View file

@ -30,13 +30,13 @@ Refer to [the main Synapse docs](https://github.com/matrix-org/synapse/blob/mast
For the simplest possible Matrix install, you can run your Synapse install on the root of the domain you wish in your MXIDs. For the simplest possible Matrix install, you can run your Synapse install on the root of the domain you wish in your MXIDs.
If you - for instance - own the domain `chosenin.space` and want to run Matrix on it, you would simply install the chart as; If you - for instance - own the domain `chosenin.space` and want to run Matrix on it, you would simply install the chart as;
helm install matrix-synapse ananace/matrix-synapse --set serverName=chosenin.space --set wellknown.enabled=true helm install matrix-synapse ananace-charts/matrix-synapse --set serverName=chosenin.space --set wellknown.enabled=true
This would set up Synapse with client-server and federation both exposed on `chosenin.space/_matrix`, as well as a tiny lighttpd server that responds to federation lookups on `chosenin.space/.well-known/matrix/server`. This would set up Synapse with client-server and federation both exposed on `chosenin.space/_matrix`, as well as a tiny lighttpd server that responds to federation lookups on `chosenin.space/.well-known/matrix/server`.
You can also use this to run a Synapse on a subdomain, with said subdomain as part of your MXIDs; (`@user:matrix.chosenin.space` in this case) You can also use this to run a Synapse on a subdomain, with said subdomain as part of your MXIDs; (`@user:matrix.chosenin.space` in this case)
helm install matrix-synapse ananace/matrix-synapse --set serverName=matrix.chosenin.space --set wellknown.enabled=true helm install matrix-synapse ananace-charts/matrix-synapse --set serverName=matrix.chosenin.space --set wellknown.enabled=true
### On separate subdomain ### On separate subdomain
@ -44,7 +44,7 @@ If - on the other hand - you own the domain `example.com`, want your MXIDs in th
For DNS, you could install the chart as; For DNS, you could install the chart as;
helm install matrix-synapse ananace/matrix-synapse --set serverName=example.com --set publicServerName=matrix.example.com helm install matrix-synapse ananace-charts/matrix-synapse --set serverName=example.com --set publicServerName=matrix.example.com
This will add federation endpoints to `example.com`, along with client endpoints on `matrix.example.com`. For this to work, you will need to have valid certs for both `example.com` as well as `matrix.example.com` for your Synapse to use. This will add federation endpoints to `example.com`, along with client endpoints on `matrix.example.com`. For this to work, you will need to have valid certs for both `example.com` as well as `matrix.example.com` for your Synapse to use.
To get federation working with such a setup, you would also need to add an SRV record to your DNS - for example; To get federation working with such a setup, you would also need to add an SRV record to your DNS - for example;
@ -53,7 +53,7 @@ To get federation working with such a setup, you would also need to add an SRV r
If you want to use a well-known file for federation instead of an SRV record, then your install might look more like; If you want to use a well-known file for federation instead of an SRV record, then your install might look more like;
helm install matrix-synapse ananace/matrix-synapse --set serverName=example.com --set publicServerName=matrix.example.com --set wellknown.enabled=true helm install matrix-synapse ananace-charts/matrix-synapse --set serverName=example.com --set publicServerName=matrix.example.com --set wellknown.enabled=true
With well-known federation, your client-to-server/public host is the one that needs to handle both client and federation traffic. On your main domain you'll instead only need something that can respond with a JSON file on the URL `example.com/.well-known/matrix/server` - which the included wellknown server will gladly do for you. With well-known federation, your client-to-server/public host is the one that needs to handle both client and federation traffic. On your main domain you'll instead only need something that can respond with a JSON file on the URL `example.com/.well-known/matrix/server` - which the included wellknown server will gladly do for you.
Additionally, when using well-known federation, your Synapse cert only needs to be valid for `matrix.example.com`. Additionally, when using well-known federation, your Synapse cert only needs to be valid for `matrix.example.com`.

19
charts/matrix-synapse/values.yaml
View file

@ -22,6 +22,16 @@ image:
## ##
# fullnameOverride: "" # fullnameOverride: ""
## The Matrix domain name, this is what will be used for the domain part in
## your MXIDs.
##
# serverName: 'example.com'
## The public Matrix server name, this will be used for any public URLs
## in config as well as for client API links in the ingress.
# publicServerName: 'matrix.example.com'
## The source of the signing key used by Synapse in federation. ## The source of the signing key used by Synapse in federation.
## ##
signingkey: signingkey:
@ -56,15 +66,6 @@ signingkey:
# cpu: 100m # cpu: 100m
# memory: 250Mi # memory: 250Mi
## The Matrix domain name, this is what will be used for the domain part in
## your MXIDs.
##
# serverName: 'example.com'
## The public Matrix server name, this will be used for any public URLs
## in config as well as for client API links in the ingress.
# publicServerName: 'matrix.example.com'
## Matrix configuration values that affect other parts of the chart, for any ## Matrix configuration values that affect other parts of the chart, for any
## value not handled by this block, you will want to instead set it in ## value not handled by this block, you will want to instead set it in
## extraConfig below. ## extraConfig below.