matrix-synapse: Change config for server names
This makes a lot of default setups much simpler to deploy
This commit is contained in:
parent
3a7f3cb319
commit
73a9542625
6 changed files with 43 additions and 26 deletions
|
@ -28,13 +28,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.
|
||||
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 --set config.serverName=chosenin.space --set wellknown.enabled=true
|
||||
helm install 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`.
|
||||
|
||||
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 --set config.serverName=matrix.chosenin.space --set wellknown.enabled=true
|
||||
helm install matrix-synapse --set serverName=matrix.chosenin.space --set wellknown.enabled=true
|
||||
|
||||
### On separate subdomain
|
||||
|
||||
|
@ -42,17 +42,21 @@ If - on the other hand - you own the domain `example.com`, want your MXIDs in th
|
|||
|
||||
For DNS, you could install the chart as;
|
||||
|
||||
helm install matrix-synapse --set config.serverName=example.com --set config.publicBaseUrl=https://matrix.example.com --set ingress.includeServerName=false --set ingress.hosts={example.com} --set ingress.csHosts={matrix.example.com}
|
||||
helm install matrix-synapse --set serverName=example.com --set publicServerName=matrix.example.com
|
||||
|
||||
This will add only federation endpoints to `example.com`, along with client endpoints on `matrix.example.com`. You will also 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 need to add an SRV record to your DNS - for example;
|
||||
`_matrix._tcp.example.com 10 1 443 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.
|
||||
To get federation working with such a setup, you would also need to add an SRV record to your DNS - for example;
|
||||
|
||||
If you want to use a well-known file for federation instead, then your install might look more like;
|
||||
_matrix._tcp.example.com 10 1 443 matrix.example.com
|
||||
|
||||
helm install matrix-synapse --set config.serverName=example.com --set config.publicBaseUrl=https://matrix.example.com --set wellknown.enabled=true --set wellknown.host=matrix.example.com --set ingress.includeServerName=false --set ingress.hosts={matrix.example.com} --set ingress.csHosts={matrix.example.com} --set ingress.wkHosts={example.com}
|
||||
If you want to use a well-known file for federation instead of an SRV record, then your install might look more like;
|
||||
|
||||
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 do.
|
||||
When using well-known federation, your Synapse cert would only need to be valid for `matrix.example.com`.
|
||||
helm install 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.
|
||||
Additionally, when using well-known federation, your Synapse cert only needs to be valid for `matrix.example.com`.
|
||||
|
||||
|
||||
|
||||
More advanced setups can be made using `ingress.hosts`, `ingress.csHosts`, and `ingress.wkHosts` for server-server, client-server, and well-known endpoints respectively.
|
||||
Alternatively, you can use your own ingress setup, or switch the main service to `LoadBalancer` and add a TLS listener.
|
||||
|
|
|
@ -34,7 +34,7 @@ data:
|
|||
## Server ##
|
||||
|
||||
server_name: {{ required "You need to specify a server name" .Values.config.serverName | quote }}
|
||||
public_baseurl: {{ .Values.config.publicBaseurl | default (printf "https://%s" .Values.config.serverName) | quote }}
|
||||
public_baseurl: {{ .Values.config.publicBaseurl | default (printf "https://%s" (.Values.config.publicServerName | default .Values.config.serverName)) | quote }}
|
||||
pid_file: /homeserver.pid
|
||||
web_client: False
|
||||
soft_file_limit: 0
|
||||
|
|
|
@ -29,7 +29,7 @@ spec:
|
|||
rules:
|
||||
{{- $csHosts := .Values.ingress.csHosts }}
|
||||
{{- if .Values.ingress.includeServerName }}
|
||||
{{- $csHosts = concat (list .Values.config.serverName) $csHosts }}
|
||||
{{- $csHosts = concat (list (.Values.config.publicServerName | default .Values.config.serverName)) $csHosts }}
|
||||
{{- end }}
|
||||
{{- $s2sHosts := .Values.ingress.hosts }}
|
||||
{{- if .Values.ingress.includeServerName }}
|
||||
|
|
|
@ -8,8 +8,8 @@ metadata:
|
|||
spec:
|
||||
type: ClusterIP
|
||||
ports:
|
||||
- port: 8008
|
||||
targetPort: http
|
||||
- port: {{ .Values.serviceport | default 8008 }}
|
||||
targetPort: {{ .Values.service.targetPort | default "http" }}
|
||||
protocol: TCP
|
||||
name: http
|
||||
selector:
|
||||
|
|
|
@ -39,5 +39,5 @@ data:
|
|||
"content-type" => "application/json"
|
||||
)
|
||||
server.json: |-
|
||||
{{ dict "m.server" (printf "%s:%d" (.Values.wellknown.host | default .Values.config.serverName) (.Values.wellknown.port | default 443)) | toJson | indent 4 }}
|
||||
{{ dict "m.server" (printf "%s:%d" (.Values.wellknown.host | default (.Values.config.publicServerName | default .Values.config.serverName)) (.Values.wellknown.port | default 443)) | toJson | indent 4 }}
|
||||
{{- end }}
|
||||
|
|
|
@ -36,19 +36,23 @@ signingkey:
|
|||
# existingSecret:
|
||||
# existingSecretKey: signing.key
|
||||
|
||||
## Common Matrix configuration values, for any value not handled by this block,
|
||||
## you will want to instead set it in extraConfig.
|
||||
##
|
||||
config:
|
||||
## The Matrix domain name, this is what will be used for the domain part in
|
||||
## your MXIDs.
|
||||
##
|
||||
# serverName: 'example.com'
|
||||
|
||||
## The publicly accessible URL for the Synapse instance, will default to
|
||||
## https://<serverName>.
|
||||
## 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'
|
||||
|
||||
## Common Matrix configuration values, for any value not handled by this block,
|
||||
## you will want to instead set it in extraConfig.
|
||||
##
|
||||
# publicBaseurl: 'https://example.com'
|
||||
config:
|
||||
## The publicly accessible URL for the Synapse instance, will default to
|
||||
## https://<publicServerName>.
|
||||
##
|
||||
# publicBaseurl: 'https://matrix.example.com'
|
||||
|
||||
## The size of the event cache.
|
||||
##
|
||||
|
@ -143,8 +147,8 @@ synapse:
|
|||
# - name: SYNAPSE_CACHE_FACTOR
|
||||
# value: "2"
|
||||
|
||||
## Configuration for the pod security policy, Synapse will by default run as its
|
||||
## own user, even if not set.
|
||||
## Configuration for the pod security policy, Synapse will by always run as
|
||||
## its own user, even if not set.
|
||||
## Note that changing this may also require you to use the volumePermission
|
||||
## helper depending on your storage.
|
||||
##
|
||||
|
@ -541,8 +545,17 @@ volumePermissions:
|
|||
# memory: 128Mi
|
||||
# cpu: 100m
|
||||
|
||||
## The K8s ingress configuration, this will be quite heavily used in order to set
|
||||
## up all routing necessary for use with a sharded Synapse instance.
|
||||
## Configuration for the main Synapse service.
|
||||
## To use TLS inside Synapse itself, add an TLS listener, and change the ports
|
||||
## configured in here.
|
||||
##
|
||||
service:
|
||||
type: ClusterIP
|
||||
port: 8008
|
||||
targetPort: http
|
||||
|
||||
## The K8s ingress configuration, this will be quite heavily used in order to
|
||||
## set up all routing necessary for use with a sharded Synapse instance.
|
||||
## If you're not using a Ingress compatible K8s ingress, you will need to set up
|
||||
## your own routing instead.
|
||||
##
|
||||
|
|
Loading…
Reference in a new issue