Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
synapse
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container registry
Model registry
Monitor
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Maunium
synapse
Commits
61b457e3
Unverified
Commit
61b457e3
authored
5 years ago
by
Brendan Abolivier
Browse files
Options
Downloads
Patches
Plain Diff
Incorporate review
parent
a0d2f9d0
No related branches found
No related tags found
No related merge requests found
Changes
2
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
docs/delegate.md
+9
-13
9 additions, 13 deletions
docs/delegate.md
docs/federate.md
+8
-8
8 additions, 8 deletions
docs/federate.md
with
17 additions
and
21 deletions
docs/delegate.md
+
9
−
13
View file @
61b457e3
# Delegation
For a more flexible configuration, you can hav
e
`
server
_name`
res
ources (eg:
`@user:example.com`
) served by a different host and
port (eg:
`synapse.
example.com:44
3`
)
.
Without configuring delegation, homeservers will expect th
e server
res
ponsible for resources using e.g.
`example.com`
as their
`server_name`
(e.g.
`@user:example.com`
) to be served at
`
example.com:
8
44
8`
.
Without configuring delegation, the matrix federation will
expect to find your server via
`example.com:8448`
. The following methods
allow you retain a
`server_name`
of
`example.com`
so that your user IDs, room
aliases, etc continue to look like
`*:example.com`
, whilst having your
federation traffic routed to a different server (e.g.
`synapse.example.com`
).
Delegation is a Matrix feature allowing a homeserver admin to retain a
`server_name`
of
`example.com`
so that your user IDs, room aliases, etc
continue to look like
`*:example.com`
, whilst having your federation
traffic routed to a different server and/or port (e.g.
`synapse.example.com:443`
).
## .well-known delegation
...
...
@@ -38,11 +37,8 @@ should return:
Note, specifying a port is optional. If no port is specified, then it defaults
to 8448.
Most installations will not need to configure .well-known. However, it can be
useful in cases where the admin is hosting on behalf of someone else and
therefore cannot gain access to the necessary certificate. With .well-known,
federation servers will check for a valid TLS certificate for the delegated
hostname (in our example:
`synapse.example.com`
).
With .well-known, federation servers will check for a valid TLS certificate
for the delegated hostname (in our example:
`synapse.example.com`
).
## SRV DNS record delegation
...
...
This diff is collapsed.
Click to expand it.
docs/federate.md
+
8
−
8
View file @
61b457e3
...
...
@@ -17,13 +17,13 @@ on port 8448. The preferred way to do that is by using a reverse proxy,
see
[
reverse_proxy.md
](
<
reverse_proxy.md
>
)
for instructions on how to
correctly set one up.
In some cases you might not want Synapse
to be running
on the machine that
has
the
`server_name`
as its public DNS hostname, or federation
traffic
t
o use port than 8448 (e.g. you want to use
`example.com`
as your
`server_name`
but want Synapse to be reachable on
`synapse.example.com:443`
). This ca
n
b
e
d
on
e using delegation, which allows an admin to dictate where federation
traffic should be sent, see
[
delegate.md
](
<
delegate.md
>
)
for instructions on
how to set this up.
In some cases you might not want
to run
Synapse on the machine that
has
the
`server_name`
as its public DNS hostname, or
you might want
federation
t
raffic to use a different port than 8448. For example, you might want to
have your user names look like
`@user:example.com`
, but you want to ru
n
Synaps
e on
`synapse.example.com`
on port 443. This can be done using
delegation, which allows an admin to control where federation traffic should
be sent. See
[
delegate.md
](
delegate.md
)
for instructions on
how to set this up.
Once federation has been configured, you should be able to join a room over
federation. A good place to start is
`#synapse:matrix.org`
- a room for
...
...
@@ -31,7 +31,7 @@ Synapse admins.
## Troubleshooting
You can use the
[
federation tester
](
<
https://matrix.org/federationtester
>
)
You can use the
[
federation tester
](
https://matrix.org/federationtester
)
to check if your homeserver is configured correctly. Alternatively try the
[
JSON API used by the federation tester
](
https://matrix.org/federationtester/api/report?server_name=DOMAIN
)
.
Note that you'll have to modify this URL to replace
`DOMAIN`
with your
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment