mirror of
https://github.com/element-hq/synapse.git
synced 2024-12-14 11:57:44 +00:00
More renaming
This commit is contained in:
Erik Johnston
parent
32447b0ca1
commit
8613f7693e
24 changed files with 115 additions and 116 deletions
2
.github/CODEOWNERS
vendored
2
.github/CODEOWNERS
vendored
|
|
@ -1,2 +1,2 @@
|
|||
# Automatically request reviews from the synapse-core team when a pull request comes in.
|
||||
* @matrix-org/synapse-core
|
||||
* @element-hq/synapse-core
|
||||
|
|
|
|||
2
.github/workflows/docker.yml
vendored
2
.github/workflows/docker.yml
vendored
|
|
@ -58,7 +58,7 @@ jobs:
|
|||
with:
|
||||
images: |
|
||||
docker.io/matrixdotorg/synapse
|
||||
ghcr.io/matrix-org/synapse
|
||||
ghcr.io/element-hq/synapse
|
||||
flavor: |
|
||||
latest=false
|
||||
tags: |
|
||||
|
|
|
|||
|
|
@ -237,7 +237,7 @@ Alongside all that, join our developer community on Matrix:
|
|||
:alt: (Rendered documentation on GitHub Pages)
|
||||
:target: https://matrix-org.github.io/synapse/latest/
|
||||
|
||||
.. |license| image:: https://img.shields.io/github/license/matrix-org/synapse
|
||||
.. |license| image:: https://img.shields.io/github/license/element-hq/synapse
|
||||
:alt: (check license in LICENSE file)
|
||||
:target: LICENSE
|
||||
|
||||
|
|
|
|||
|
|
@ -16,14 +16,14 @@ create-missing = false
|
|||
|
||||
[output.html]
|
||||
# The URL visitors will be directed to when they try to edit a page
|
||||
edit-url-template = "https://github.com/matrix-org/synapse/edit/develop/{path}"
|
||||
edit-url-template = "https://github.com/element-hq/synapse/edit/develop/{path}"
|
||||
|
||||
# Remove the numbers that appear before each item in the sidebar, as they can
|
||||
# get quite messy as we nest deeper
|
||||
no-section-label = true
|
||||
|
||||
# The source code URL of the repository
|
||||
git-repository-url = "https://github.com/matrix-org/synapse"
|
||||
git-repository-url = "https://github.com/element-hq/synapse"
|
||||
|
||||
# The path that the docs are hosted on
|
||||
site-url = "/synapse/"
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Creating multiple stream writers with a bash script
|
||||
|
||||
This script creates multiple [stream writer](https://github.com/matrix-org/synapse/blob/develop/docs/workers.md#stream-writers) workers.
|
||||
This script creates multiple [stream writer](https://github.com/element-hq/synapse/blob/develop/docs/workers.md#stream-writers) workers.
|
||||
|
||||
Stream writers require both replication and HTTP listeners.
|
||||
|
||||
|
|
@ -71,7 +71,7 @@ cat << EXAMPLECONFIG
|
|||
# Don't forget to configure your reverse proxy and
|
||||
# necessary endpoints to their respective worker.
|
||||
|
||||
# See https://github.com/matrix-org/synapse/blob/develop/docs/workers.md
|
||||
# See https://github.com/element-hq/synapse/blob/develop/docs/workers.md
|
||||
# for more information.
|
||||
|
||||
# Remember: Under NO circumstances should the replication
|
||||
|
|
@ -102,7 +102,7 @@ You should receive an output similar to the following:
|
|||
# Don't forget to configure your reverse proxy and
|
||||
# necessary endpoints to their respective worker.
|
||||
|
||||
# See https://github.com/matrix-org/synapse/blob/develop/docs/workers.md
|
||||
# See https://github.com/element-hq/synapse/blob/develop/docs/workers.md
|
||||
# for more information
|
||||
|
||||
# Remember: Under NO circumstances should the replication
|
||||
|
|
|
|||
2
debian/control
vendored
2
debian/control
vendored
|
|
@ -18,7 +18,7 @@ Build-Depends:
|
|||
python3-venv,
|
||||
tar,
|
||||
Standards-Version: 3.9.8
|
||||
Homepage: https://github.com/matrix-org/synapse
|
||||
Homepage: https://github.com/element-hq/synapse
|
||||
|
||||
Package: matrix-synapse-py3
|
||||
Architecture: any
|
||||
|
|
|
|||
2
debian/templates
vendored
2
debian/templates
vendored
|
|
@ -5,7 +5,7 @@ _Description: Name of the server:
|
|||
servers via federation. This is normally the public hostname of the
|
||||
server running synapse, but can be different if you set up delegation.
|
||||
Please refer to the delegation documentation in this case:
|
||||
https://github.com/matrix-org/synapse/blob/master/docs/delegate.md.
|
||||
https://github.com/element-hq/synapse/blob/master/docs/delegate.md.
|
||||
|
||||
Template: matrix-synapse/report-stats
|
||||
Type: boolean
|
||||
|
|
|
|||
|
|
@ -161,8 +161,8 @@ RUN --mount=type=cache,target=/synapse/target,sharing=locked \
|
|||
FROM docker.io/library/python:${PYTHON_VERSION}-slim-bookworm
|
||||
|
||||
LABEL org.opencontainers.image.url='https://matrix.org/docs/projects/server/synapse'
|
||||
LABEL org.opencontainers.image.documentation='https://github.com/matrix-org/synapse/blob/master/docker/README.md'
|
||||
LABEL org.opencontainers.image.source='https://github.com/matrix-org/synapse.git'
|
||||
LABEL org.opencontainers.image.documentation='https://github.com/element-hq/synapse/blob/master/docker/README.md'
|
||||
LABEL org.opencontainers.image.source='https://github.com/element-hq/synapse.git'
|
||||
LABEL org.opencontainers.image.licenses='Apache-2.0'
|
||||
|
||||
RUN \
|
||||
|
|
|
|||
|
|
@ -78,7 +78,7 @@ The following environment variables are supported in `generate` mode:
|
|||
|
||||
## Postgres
|
||||
|
||||
By default the config will use SQLite. See the [docs on using Postgres](https://github.com/matrix-org/synapse/blob/develop/docs/postgres.md) for more info on how to use Postgres. Until this section is improved [this issue](https://github.com/matrix-org/synapse/issues/8304) may provide useful information.
|
||||
By default the config will use SQLite. See the [docs on using Postgres](https://github.com/element-hq/synapse/blob/develop/docs/postgres.md) for more info on how to use Postgres. Until this section is improved [this issue](https://github.com/element-hq/synapse/issues/8304) may provide useful information.
|
||||
|
||||
## Running synapse
|
||||
|
||||
|
|
@ -151,7 +151,7 @@ is suitable for local testing, but for any practical use, you will either need
|
|||
to use a reverse proxy, or configure Synapse to expose an HTTPS port.
|
||||
|
||||
For documentation on using a reverse proxy, see
|
||||
https://github.com/matrix-org/synapse/blob/master/docs/reverse_proxy.md.
|
||||
https://github.com/element.-hq/synapse/blob/master/docs/reverse_proxy.md.
|
||||
|
||||
For more information on enabling TLS support in synapse itself, see
|
||||
https://matrix-org.github.io/synapse/latest/setup/installation.html#tls-certificates. Of
|
||||
|
|
|
|||
|
|
@ -1,58 +1,58 @@
|
|||
# syntax=docker/dockerfile:1
|
||||
# This dockerfile builds on top of 'docker/Dockerfile-workers' in matrix-org/synapse
|
||||
# This dockerfile builds on top of 'docker/Dockerfile-workers' in element.-hq/synapse
|
||||
# by including a built-in postgres instance, as well as setting up the homeserver so
|
||||
# that it is ready for testing via Complement.
|
||||
#
|
||||
# Instructions for building this image from those it depends on is detailed in this guide:
|
||||
# https://github.com/matrix-org/synapse/blob/develop/docker/README-testing.md#testing-with-postgresql-and-single-or-multi-process-synapse
|
||||
# https://github.com/element.-hq/synapse/blob/develop/docker/README-testing.md#testing-with-postgresql-and-single-or-multi-process-synapse
|
||||
|
||||
ARG SYNAPSE_VERSION=latest
|
||||
# This is an intermediate image, to be built locally (not pulled from a registry).
|
||||
ARG FROM=matrixdotorg/synapse-workers:$SYNAPSE_VERSION
|
||||
|
||||
FROM $FROM
|
||||
# First of all, we copy postgres server from the official postgres image,
|
||||
# since for repeated rebuilds, this is much faster than apt installing
|
||||
# postgres each time.
|
||||
# First of all, we copy postgres server from the official postgres image,
|
||||
# since for repeated rebuilds, this is much faster than apt installing
|
||||
# postgres each time.
|
||||
|
||||
# This trick only works because (a) the Synapse image happens to have all the
|
||||
# shared libraries that postgres wants, (b) we use a postgres image based on
|
||||
# the same debian version as Synapse's docker image (so the versions of the
|
||||
# shared libraries match).
|
||||
RUN adduser --system --uid 999 postgres --home /var/lib/postgresql
|
||||
COPY --from=docker.io/library/postgres:13-bookworm /usr/lib/postgresql /usr/lib/postgresql
|
||||
COPY --from=docker.io/library/postgres:13-bookworm /usr/share/postgresql /usr/share/postgresql
|
||||
RUN mkdir /var/run/postgresql && chown postgres /var/run/postgresql
|
||||
ENV PATH="${PATH}:/usr/lib/postgresql/13/bin"
|
||||
ENV PGDATA=/var/lib/postgresql/data
|
||||
# This trick only works because (a) the Synapse image happens to have all the
|
||||
# shared libraries that postgres wants, (b) we use a postgres image based on
|
||||
# the same debian version as Synapse's docker image (so the versions of the
|
||||
# shared libraries match).
|
||||
RUN adduser --system --uid 999 postgres --home /var/lib/postgresql
|
||||
COPY --from=docker.io/library/postgres:13-bookworm /usr/lib/postgresql /usr/lib/postgresql
|
||||
COPY --from=docker.io/library/postgres:13-bookworm /usr/share/postgresql /usr/share/postgresql
|
||||
RUN mkdir /var/run/postgresql && chown postgres /var/run/postgresql
|
||||
ENV PATH="${PATH}:/usr/lib/postgresql/13/bin"
|
||||
ENV PGDATA=/var/lib/postgresql/data
|
||||
|
||||
# We also initialize the database at build time, rather than runtime, so that it's faster to spin up the image.
|
||||
RUN gosu postgres initdb --locale=C --encoding=UTF-8 --auth-host password
|
||||
# We also initialize the database at build time, rather than runtime, so that it's faster to spin up the image.
|
||||
RUN gosu postgres initdb --locale=C --encoding=UTF-8 --auth-host password
|
||||
|
||||
# Configure a password and create a database for Synapse
|
||||
RUN echo "ALTER USER postgres PASSWORD 'somesecret'" | gosu postgres postgres --single
|
||||
RUN echo "CREATE DATABASE synapse" | gosu postgres postgres --single
|
||||
# Configure a password and create a database for Synapse
|
||||
RUN echo "ALTER USER postgres PASSWORD 'somesecret'" | gosu postgres postgres --single
|
||||
RUN echo "CREATE DATABASE synapse" | gosu postgres postgres --single
|
||||
|
||||
# Extend the shared homeserver config to disable rate-limiting,
|
||||
# set Complement's static shared secret, enable registration, amongst other
|
||||
# tweaks to get Synapse ready for testing.
|
||||
# To do this, we copy the old template out of the way and then include it
|
||||
# with Jinja2.
|
||||
RUN mv /conf/shared.yaml.j2 /conf/shared-orig.yaml.j2
|
||||
COPY conf/workers-shared-extra.yaml.j2 /conf/shared.yaml.j2
|
||||
# Extend the shared homeserver config to disable rate-limiting,
|
||||
# set Complement's static shared secret, enable registration, amongst other
|
||||
# tweaks to get Synapse ready for testing.
|
||||
# To do this, we copy the old template out of the way and then include it
|
||||
# with Jinja2.
|
||||
RUN mv /conf/shared.yaml.j2 /conf/shared-orig.yaml.j2
|
||||
COPY conf/workers-shared-extra.yaml.j2 /conf/shared.yaml.j2
|
||||
|
||||
WORKDIR /data
|
||||
WORKDIR /data
|
||||
|
||||
COPY conf/postgres.supervisord.conf /etc/supervisor/conf.d/postgres.conf
|
||||
COPY conf/postgres.supervisord.conf /etc/supervisor/conf.d/postgres.conf
|
||||
|
||||
# Copy the entrypoint
|
||||
COPY conf/start_for_complement.sh /
|
||||
# Copy the entrypoint
|
||||
COPY conf/start_for_complement.sh /
|
||||
|
||||
# Expose nginx's listener ports
|
||||
EXPOSE 8008 8448
|
||||
# Expose nginx's listener ports
|
||||
EXPOSE 8008 8448
|
||||
|
||||
ENTRYPOINT ["/start_for_complement.sh"]
|
||||
ENTRYPOINT ["/start_for_complement.sh"]
|
||||
|
||||
# Update the healthcheck to have a shorter check interval
|
||||
HEALTHCHECK --start-period=5s --interval=1s --timeout=1s \
|
||||
CMD /bin/sh /healthcheck.sh
|
||||
# Update the healthcheck to have a shorter check interval
|
||||
HEALTHCHECK --start-period=5s --interval=1s --timeout=1s \
|
||||
CMD /bin/sh /healthcheck.sh
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ To enable this, first create templates for the policy and success pages.
|
|||
These should be stored on the local filesystem.
|
||||
|
||||
These templates use the [Jinja2](http://jinja.pocoo.org) templating language,
|
||||
and [docs/privacy_policy_templates](https://github.com/matrix-org/synapse/tree/develop/docs/privacy_policy_templates/)
|
||||
and [docs/privacy_policy_templates](https://github.com/element.-hq/synapse/tree/develop/docs/privacy_policy_templates/)
|
||||
gives examples of the sort of thing that can be done.
|
||||
|
||||
Note that the templates must be stored under a name giving the language of the
|
||||
|
|
|
|||
|
|
@ -14,11 +14,11 @@ b2dba0607`:
|
|||
Note how the commit comment explains clearly what is changing and why. Also
|
||||
note the *absence* of merge commits, as well as the absence of commits called
|
||||
things like (to pick a few culprits):
|
||||
[“pep8”](https://github.com/matrix-org/synapse/commit/84691da6c), [“fix broken
|
||||
test”](https://github.com/matrix-org/synapse/commit/474810d9d),
|
||||
[“oops”](https://github.com/matrix-org/synapse/commit/c9d72e457),
|
||||
[“typo”](https://github.com/matrix-org/synapse/commit/836358823), or [“Who's
|
||||
the president?”](https://github.com/matrix-org/synapse/commit/707374d5d).
|
||||
[“pep8”](https://github.com/element.-hq/synapse/commit/84691da6c), [“fix broken
|
||||
test”](https://github.com/element.-hq/synapse/commit/474810d9d),
|
||||
[“oops”](https://github.com/element.-hq/synapse/commit/c9d72e457),
|
||||
[“typo”](https://github.com/element.-hq/synapse/commit/836358823), or [“Who's
|
||||
the president?”](https://github.com/element.-hq/synapse/commit/707374d5d).
|
||||
|
||||
There are a number of reasons why keeping a clean commit history is a good
|
||||
thing:
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
## Streams
|
||||
|
||||
Synapse has a concept of "streams", which are roughly described in [`id_generators.py`](
|
||||
https://github.com/matrix-org/synapse/blob/develop/synapse/storage/util/id_generators.py
|
||||
https://github.com/element.-hq/synapse/blob/develop/synapse/storage/util/id_generators.py
|
||||
).
|
||||
Generally speaking, streams are a series of notifications that something in Synapse's database has changed that the application might need to respond to.
|
||||
For example:
|
||||
|
|
@ -11,12 +11,12 @@ For example:
|
|||
- The to-device stream reports when a device has a new [to-device message](https://spec.matrix.org/v1.7/client-server-api/#send-to-device-messaging).
|
||||
|
||||
See [`synapse.replication.tcp.streams`](
|
||||
https://github.com/matrix-org/synapse/blob/develop/synapse/replication/tcp/streams/__init__.py
|
||||
https://github.com/element.-hq/synapse/blob/develop/synapse/replication/tcp/streams/__init__.py
|
||||
) for the full list of streams.
|
||||
|
||||
It is very helpful to understand the streams mechanism when working on any part of Synapse that needs to respond to changes—especially if those changes are made by different workers.
|
||||
To that end, let's describe streams formally, paraphrasing from the docstring of [`AbstractStreamIdGenerator`](
|
||||
https://github.com/matrix-org/synapse/blob/a719b703d9bd0dade2565ddcad0e2f3a7a9d4c37/synapse/storage/util/id_generators.py#L96
|
||||
https://github.com/element.-hq/synapse/blob/a719b703d9bd0dade2565ddcad0e2f3a7a9d4c37/synapse/storage/util/id_generators.py#L96
|
||||
).
|
||||
|
||||
### Definition
|
||||
|
|
|
|||
|
|
@ -87,8 +87,8 @@
|
|||
|
||||
1. Restart Prometheus.
|
||||
|
||||
1. Consider using the [grafana dashboard](https://github.com/matrix-org/synapse/tree/master/contrib/grafana/)
|
||||
and required [recording rules](https://github.com/matrix-org/synapse/tree/master/contrib/prometheus/)
|
||||
1. Consider using the [grafana dashboard](https://github.com/element.-hq/synapse/tree/master/contrib/grafana/)
|
||||
and required [recording rules](https://github.com/element.-hq/synapse/tree/master/contrib/prometheus/)
|
||||
|
||||
## Monitoring workers
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ either the output of the module's `parse_config` static method (see below), or t
|
|||
configuration associated with the module in Synapse's configuration file.
|
||||
|
||||
See the documentation for the `ModuleApi` class
|
||||
[here](https://github.com/matrix-org/synapse/blob/master/synapse/module_api/__init__.py).
|
||||
[here](https://github.com/element.-hq/synapse/blob/master/synapse/module_api/__init__.py).
|
||||
|
||||
## When Synapse runs with several modules configured
|
||||
|
||||
|
|
|
|||
|
|
@ -115,7 +115,7 @@ A custom mapping provider must specify the following methods:
|
|||
|
||||
Synapse has a built-in OpenID mapping provider if a custom provider isn't
|
||||
specified in the config. It is located at
|
||||
[`synapse.handlers.oidc.JinjaOidcMappingProvider`](https://github.com/matrix-org/synapse/blob/develop/synapse/handlers/oidc.py).
|
||||
[`synapse.handlers.oidc.JinjaOidcMappingProvider`](https://github.com/element.-hq/synapse/blob/develop/synapse/handlers/oidc.py).
|
||||
|
||||
## SAML Mapping Providers
|
||||
|
||||
|
|
@ -202,4 +202,4 @@ A custom mapping provider must specify the following methods:
|
|||
|
||||
Synapse has a built-in SAML mapping provider if a custom provider isn't
|
||||
specified in the config. It is located at
|
||||
[`synapse.handlers.saml.DefaultSamlMappingProvider`](https://github.com/matrix-org/synapse/blob/develop/synapse/handlers/saml.py).
|
||||
[`synapse.handlers.saml.DefaultSamlMappingProvider`](https://github.com/element.-hq/synapse/blob/develop/synapse/handlers/saml.py).
|
||||
|
|
|
|||
|
|
@ -6,10 +6,10 @@ well as a `matrix-synapse-worker@` service template for any workers you
|
|||
require. Additionally, to group the required services, it sets up a
|
||||
`matrix-synapse.target`.
|
||||
|
||||
See the folder [system](https://github.com/matrix-org/synapse/tree/develop/docs/systemd-with-workers/system/)
|
||||
See the folder [system](https://github.com/element.-hq/synapse/tree/develop/docs/systemd-with-workers/system/)
|
||||
for the systemd unit files.
|
||||
|
||||
The folder [workers](https://github.com/matrix-org/synapse/tree/develop/docs/systemd-with-workers/workers/)
|
||||
The folder [workers](https://github.com/element.-hq/synapse/tree/develop/docs/systemd-with-workers/workers/)
|
||||
contains an example configuration for the `generic_worker` worker.
|
||||
|
||||
## Synapse configuration files
|
||||
|
|
@ -33,7 +33,7 @@ There is no need for a separate configuration file for the master process.
|
|||
## Set up
|
||||
|
||||
1. Adjust synapse configuration files as above.
|
||||
1. Copy the `*.service` and `*.target` files in [system](https://github.com/matrix-org/synapse/tree/develop/docs/systemd-with-workers/system/)
|
||||
1. Copy the `*.service` and `*.target` files in [system](https://github.com/element.-hq/synapse/tree/develop/docs/systemd-with-workers/system/)
|
||||
to `/etc/systemd/system`.
|
||||
1. Run `systemctl daemon-reload` to tell systemd to load the new unit files.
|
||||
1. Run `systemctl enable matrix-synapse.service`. This will configure the
|
||||
|
|
@ -74,7 +74,7 @@ systemctl restart matrix-synapse.target
|
|||
|
||||
**Optional:** If further hardening is desired, the file
|
||||
`override-hardened.conf` may be copied from
|
||||
[contrib/systemd/override-hardened.conf](https://github.com/matrix-org/synapse/tree/develop/contrib/systemd/)
|
||||
[contrib/systemd/override-hardened.conf](https://github.com/element.-hq/synapse/tree/develop/contrib/systemd/)
|
||||
in this repository to the location
|
||||
`/etc/systemd/system/matrix-synapse.service.d/override-hardened.conf` (the
|
||||
directory may have to be created). It enables certain sandboxing features in
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
Synapse uses parametrised templates to generate the content of emails it sends and
|
||||
webpages it shows to users.
|
||||
|
||||
By default, Synapse will use the templates listed [here](https://github.com/matrix-org/synapse/tree/master/synapse/res/templates).
|
||||
By default, Synapse will use the templates listed [here](https://github.com/element.-hq/synapse/tree/master/synapse/res/templates).
|
||||
Server admins can configure an additional directory for Synapse to look for templates
|
||||
in, allowing them to specify custom templates:
|
||||
|
||||
|
|
|
|||
|
|
@ -1068,7 +1068,7 @@ As announced with the release of [Synapse 1.47.0](#deprecation-of-the-user_may_c
|
|||
the deprecated `user_may_create_room_with_invites` module callback has been removed.
|
||||
|
||||
Modules relying on it can instead implement [`user_may_invite`](https://matrix-org.github.io/synapse/latest/modules/spam_checker_callbacks.html#user_may_invite)
|
||||
and use the [`get_room_state`](https://github.com/matrix-org/synapse/blob/872f23b95fa980a61b0866c1475e84491991fa20/synapse/module_api/__init__.py#L869-L876)
|
||||
and use the [`get_room_state`](https://github.com/element.-hq/synapse/blob/872f23b95fa980a61b0866c1475e84491991fa20/synapse/module_api/__init__.py#L869-L876)
|
||||
module API to infer whether the invite is happening while creating a room (see [this function](https://github.com/matrix-org/synapse-domain-rule-checker/blob/e7d092dd9f2a7f844928771dbfd9fd24c2332e48/synapse_domain_rule_checker/__init__.py#L56-L89)
|
||||
as an example). Alternately, modules can also implement [`on_create_room`](https://matrix-org.github.io/synapse/latest/modules/third_party_rules_callbacks.html#on_create_room).
|
||||
|
||||
|
|
@ -1124,7 +1124,7 @@ Any scripts still using the above APIs should be converted to use the
|
|||
The `user_may_create_room_with_invites` is deprecated and will be removed in a future
|
||||
version of Synapse. Modules implementing this callback can instead implement
|
||||
[`user_may_invite`](https://matrix-org.github.io/synapse/latest/modules/spam_checker_callbacks.html#user_may_invite)
|
||||
and use the [`get_room_state`](https://github.com/matrix-org/synapse/blob/872f23b95fa980a61b0866c1475e84491991fa20/synapse/module_api/__init__.py#L869-L876)
|
||||
and use the [`get_room_state`](https://github.com/element.-hq/synapse/blob/872f23b95fa980a61b0866c1475e84491991fa20/synapse/module_api/__init__.py#L869-L876)
|
||||
module API method to infer whether the invite is happening in the context of creating a
|
||||
room.
|
||||
|
||||
|
|
@ -1171,8 +1171,8 @@ Any scripts still using the above APIs should be converted to use the
|
|||
## User-interactive authentication fallback templates can now display errors
|
||||
|
||||
This may affect you if you make use of custom HTML templates for the
|
||||
[reCAPTCHA (`synapse/res/templates/recaptcha.html`)](https://github.com/matrix-org/synapse/tree/develop/synapse/res/templates/recaptcha.html) or
|
||||
[terms (`synapse/res/templates/terms.html`)](https://github.com/matrix-org/synapse/tree/develop/synapse/res/templates/terms.html) fallback pages.
|
||||
[reCAPTCHA (`synapse/res/templates/recaptcha.html`)](https://github.com/element.-hq/synapse/tree/develop/synapse/res/templates/recaptcha.html) or
|
||||
[terms (`synapse/res/templates/terms.html`)](https://github.com/element.-hq/synapse/tree/develop/synapse/res/templates/terms.html) fallback pages.
|
||||
|
||||
The template is now provided an `error` variable if the authentication
|
||||
process failed. See the default templates linked above for an example.
|
||||
|
|
@ -1671,7 +1671,7 @@ update your reverse proxy configuration to reflect this change.
|
|||
## New HTML templates
|
||||
|
||||
A new HTML template,
|
||||
[password_reset_confirmation.html](https://github.com/matrix-org/synapse/blob/develop/synapse/res/templates/password_reset_confirmation.html),
|
||||
[password_reset_confirmation.html](https://github.com/element.-hq/synapse/blob/develop/synapse/res/templates/password_reset_confirmation.html),
|
||||
has been added to the `synapse/res/templates` directory. If you are
|
||||
using a custom template directory, you may want to copy the template
|
||||
over and modify it.
|
||||
|
|
@ -1770,7 +1770,7 @@ New templates (`sso_auth_confirm.html`, `sso_auth_success.html`, and
|
|||
is configured to use SSO and a custom
|
||||
`sso_redirect_confirm_template_dir` configuration then these templates
|
||||
will need to be copied from
|
||||
[`synapse/res/templates`](https://github.com/matrix-org/synapse/tree/develop/synapse/res/templates) into that directory.
|
||||
[`synapse/res/templates`](https://github.com/element.-hq/synapse/tree/develop/synapse/res/templates) into that directory.
|
||||
|
||||
## Synapse SSO Plugins Method Deprecation
|
||||
|
||||
|
|
@ -1923,7 +1923,7 @@ included.
|
|||
Synapse will expect these files to exist inside the configured template
|
||||
directory, and **will fail to start** if they are absent. To view the
|
||||
default templates, see
|
||||
[synapse/res/templates](https://github.com/matrix-org/synapse/tree/master/synapse/res/templates).
|
||||
[synapse/res/templates](https://github.com/element.-hq/synapse/tree/master/synapse/res/templates).
|
||||
|
||||
## 3pid verification changes
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Request log format
|
||||
|
||||
HTTP request logs are written by synapse (see [`synapse/http/site.py`](https://github.com/matrix-org/synapse/tree/develop/synapse/http/site.py) for details).
|
||||
HTTP request logs are written by synapse (see [`synapse/http/site.py`](https://github.com/element.-hq/synapse/tree/develop/synapse/http/site.py) for details).
|
||||
|
||||
See the following for how to decode the dense data available from the default logging configuration.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,12 +3,12 @@
|
|||
It is possible to monitor much of the internal state of Synapse using [Prometheus](https://prometheus.io)
|
||||
metrics and [Grafana](https://grafana.com/).
|
||||
A guide for configuring Synapse to provide metrics is available [here](../../metrics-howto.md)
|
||||
and information on setting up Grafana is [here](https://github.com/matrix-org/synapse/tree/master/contrib/grafana).
|
||||
and information on setting up Grafana is [here](https://github.com/element.-hq/synapse/tree/master/contrib/grafana).
|
||||
In this setup, Prometheus will periodically scrape the information Synapse provides and
|
||||
store a record of it over time. Grafana is then used as an interface to query and
|
||||
present this information through a series of pretty graphs.
|
||||
|
||||
Once you have grafana set up, and assuming you're using [our grafana dashboard template](https://github.com/matrix-org/synapse/blob/master/contrib/grafana/synapse.json), look for the following graphs when debugging a slow/overloaded Synapse:
|
||||
Once you have grafana set up, and assuming you're using [our grafana dashboard template](https://github.com/element.-hq/synapse/blob/master/contrib/grafana/synapse.json), look for the following graphs when debugging a slow/overloaded Synapse:
|
||||
|
||||
## Message Event Send Time
|
||||
|
||||
|
|
@ -57,7 +57,7 @@ Cross-referencing this with the Eviction Rate graph, which shows that entries ar
|
|||
|
||||
|
||||
|
||||
we should probably consider raising the size of that cache by raising its cache factor (a multiplier value for the size of an individual cache). Information on doing so is available [here](https://github.com/matrix-org/synapse/blob/ee421e524478c1ad8d43741c27379499c2f6135c/docs/sample_config.yaml#L608-L642) (note that the configuration of individual cache factors through the configuration file is available in Synapse v1.14.0+, whereas doing so through environment variables has been supported for a very long time). Note that this will increase Synapse's overall memory usage.
|
||||
we should probably consider raising the size of that cache by raising its cache factor (a multiplier value for the size of an individual cache). Information on doing so is available [here](https://github.com/element.-hq/synapse/blob/ee421e524478c1ad8d43741c27379499c2f6135c/docs/sample_config.yaml#L608-L642) (note that the configuration of individual cache factors through the configuration file is available in Synapse v1.14.0+, whereas doing so through environment variables has been supported for a very long time). Note that this will increase Synapse's overall memory usage.
|
||||
|
||||
## Forward Extremities
|
||||
|
||||
|
|
@ -81,4 +81,3 @@ If you're still having performance problems with your Synapse instance and you'v
|
|||
tried everything you can, it may just be a lack of system resources. Consider adding
|
||||
more CPU and RAM, and make use of [worker mode](../../workers.md)
|
||||
to make use of multiple CPU cores / multiple machines for your homeserver.
|
||||
|
||||
|
|
|
|||
|
|
@ -1416,7 +1416,7 @@ kill -HUP [PID_OF_SYNAPSE_PROCESS]
|
|||
If you are running multiple workers, you must individually update the worker
|
||||
config file and send this signal to each worker process.
|
||||
|
||||
If you're using the [example systemd service](https://github.com/matrix-org/synapse/blob/develop/contrib/systemd/matrix-synapse.service)
|
||||
If you're using the [example systemd service](https://github.com/element.-hq/synapse/blob/develop/contrib/systemd/matrix-synapse.service)
|
||||
file in Synapse's `contrib` directory, you can send a `SIGHUP` signal by using
|
||||
`systemctl reload matrix-synapse`.
|
||||
|
||||
|
|
|
|||
|
|
@ -36,17 +36,17 @@ following documentation:
|
|||
* Read the [Contributing Guide](development/contributing_guide.md). It is meant
|
||||
to walk new contributors through the process of developing and submitting a
|
||||
change to the Synapse codebase (which is [hosted on
|
||||
GitHub](https://github.com/matrix-org/synapse)).
|
||||
GitHub](https://github.com/element.-hq/synapse)).
|
||||
|
||||
* Set up your [development
|
||||
environment](development/contributing_guide.md#2-what-do-i-need), then learn
|
||||
how to [lint](development/contributing_guide.md#run-the-linters) and
|
||||
[test](development/contributing_guide.md#8-test-test-test) your code.
|
||||
|
||||
* Look at [the issue tracker](https://github.com/matrix-org/synapse/issues) for
|
||||
* Look at [the issue tracker](https://github.com/element.-hq/synapse/issues) for
|
||||
bugs to fix or features to add. If you're new, it may be best to start with
|
||||
those labeled [good first
|
||||
issue](https://github.com/matrix-org/synapse/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22).
|
||||
issue](https://github.com/element.-hq/synapse/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22).
|
||||
|
||||
* Understand [how Synapse is
|
||||
built](development/internal_documentation/index.html), how to [migrate
|
||||
|
|
@ -58,7 +58,7 @@ following documentation:
|
|||
do so!
|
||||
|
||||
* And finally, contribute to this documentation! The source for which is
|
||||
[located here](https://github.com/matrix-org/synapse/tree/develop/docs).
|
||||
[located here](https://github.com/element.-hq/synapse/tree/develop/docs).
|
||||
|
||||
## Reporting a security vulnerability
|
||||
|
||||
|
|
|
|||
|
|
@ -4,6 +4,6 @@ set -e
|
|||
|
||||
# Fetch the current GitHub issue number, add one to it -- presto! The likely
|
||||
# next PR number.
|
||||
CURRENT_NUMBER=$(curl -s "https://api.github.com/repos/matrix-org/synapse/issues?state=all&per_page=1" | jq -r ".[0].number")
|
||||
CURRENT_NUMBER=$(curl -s "https://api.github.com/repos/element.-hq/synapse/issues?state=all&per_page=1" | jq -r ".[0].number")
|
||||
CURRENT_NUMBER=$((CURRENT_NUMBER+1))
|
||||
echo $CURRENT_NUMBER
|
||||
|
|
|
|||
Loading…
Reference in a new issue