Added tiny bit of worker configuration.

matrix/draupnir/README.md

@@ -54,7 +54,7 @@ Copy it to `production.yaml` and change what you must.
 | Option | Value | Meaning |
 | :---- | :---- | :---- |
 | `homeserverUrl` | `http://localhost:8008` | Where to communicate with Synapse |
-| `rawHomeserverUrl` | `https://vm02199.example.com` | Same as `server_name` |
+| `rawHomeserverUrl` | `https://matrix.example.com` | Same as `server_name` |
 | `accessToken` | access token | Copy from login session |
 | `password` | password | Password for the account |
 | `dataPath` | `/opt/Draupnir/datastorage` | Storage |
@@ -79,7 +79,51 @@ displayReports: true
 ```
 
 For this to work (for reports to reach Draupnir) you'll need to configure
-nginx...
+nginx to forward requests for reports to Draupnir:
 
 ```
+location ~ ^/_matrix/client/(r0|v3)/rooms/([^/]*)/report/(.*)$ {
+    # The r0 endpoint is deprecated but still used by many clients.
+    # As of this writing, the v3 endpoint is the up-to-date version.
+    
+    # Alias the regexps, to ensure that they're not rewritten.
+    set $room_id $2;
+    set $event_id $3;
+    proxy_pass http://[::1]:8082/api/1/report/$room_id/$event_id;
+}
 
+# Reports that need to reach Synapse (not sure if this is used)
+location /_synapse/admin/v1/event_reports {
+    proxy_pass http://localhost:8008;
+    proxy_set_header X-Forwarded-For $remote_addr;
+    proxy_set_header X-Forwarded-Proto $scheme;
+    proxy_set_header Host $host;
+    client_max_body_size 50M;
+    proxy_http_version 1.1;
+    
+location ~ ^/_synapse/admin/v1/rooms/([^/]*)/context/(.*)$ {
+    set $room_id $2;
+    set $event_id $3;
+    proxy_pass http://localhost:8008/_synapse/admin/v1/rooms/$room_id/context/$event_id;
+    proxy_set_header X-Forwarded-For $remote_addr;
+    proxy_set_header X-Forwarded-Proto $scheme;
+    proxy_set_header Host $host;
+    client_max_body_size 50M;
+    proxy_http_version 1.1;
+}
+```
+
+# Rate limiting
+
+Normal users are rate limited, to prevent them from flooding the server. Draupnir
+is meant to stop those events, but if it it itself rate limited, it won't work
+all that well.
+
+How rate limiting is configured server-wide is documented in [Synapse's
+documentation](https://element-hq.github.io/synapse/latest/usage/configuration/config_documentation.html?highlight=ratelimiting#ratelimiting).
+Overriding is, unfortunately, not something you can easily configure in the
+configuration files. You'll have to do that in the database itself:
+
+```
+INSERT INTO ratelimit_override VALUES ('@draupnir:example.com', 0, 0);
+```

matrix/synapse/monolithic/README.md

@@ -1,10 +0,0 @@
----
-gitea: none
-include_toc: true
----
-
-# Standard, monolithic configuration
-
-This configuration will be enough for most installations.
-
-

matrix/synapse/workers.md

@@ -0,0 +1,99 @@
+---
+gitea: none
+include_toc: true
+---
+
+# Worker-based setup
+
+Very busy servers are brought down because a single thread can't keep up with
+the load. So you want to create several threads for different types of work.
+
+See this [Matrix blog](https://matrix.org/blog/2020/11/03/how-we-fixed-synapse-s-scalability/)
+for some background information.
+
+
+# Redis
+
+First step is to install Redis.
+
+```
+apt install redis-server
+```
+
+For less overhead we use a UNIX socket instead of a network connection to
+localhost. Disable the TCP listener and enable the socket in
+`/etc/redis/redis.conf`:
+
+```
+port 0
+
+unixsocket /run/redis/redis-server.sock
+unixsocketperm 770
+```
+
+Our matrix user (`matrix-synapse`) has to be able to read from and write to
+that socket, which is created by Redis and owned by `redis:redis`, so we add
+user `matrix-synapse` to the group `redis`.
+
+```
+adduser matrix-synapse redis
+```
+
+Restart Redis for these changes to take effect. Check if port 6379 is no
+longer active, and if the socketfile `/run/redis/redis-server.sock` exists.
+
+
+# Synapse
+
+First, create the directory where all the socket files for workers will come,
+and give it the correct user, group and permission:
+
+```
+mkdir /run/matrix-synapse
+dpkg-statoverride --add --update matrix-synapse matrix-synapse 0770 /run/matrix-synapse
+```
+
+Add a replication listener:
+
+```
+listeners:
+
+  ...
+
+  - path: /run/matrix-synapse/replication.sock
+    mode: 0660
+    type: http
+    resources:
+      - names:
+        - replication 
+```
+
+Check if the socket is created and has the correct permissions. Now point
+Synapse at Redis in `conf.d/redis.yaml`:
+
+```
+redis:
+  enabled: true
+  path: /run/redis/redis-server.sock
+```
+
+Check if Synapse can connect to Redis via the socket, you should find log
+entries like this:
+
+```
+synapse.replication.tcp.redis - 292 - INFO - sentinel - Connecting to redis server UNIXAddress('/run/redis/redis-server.sock')
+synapse.util.httpresourcetree - 56 - INFO - sentinel - Attaching <synapse.replication.http.ReplicationRestResource object at 0x7f95f850d150> to path b'/_synapse/replication'
+synapse.replication.tcp.redis - 126 - INFO - sentinel - Connected to redis
+synapse.replication.tcp.redis - 138 - INFO - subscribe-replication-0 - Sending redis SUBSCRIBE for ['matrix.example.com/USER_IP', 'matrix.example.com']
+synapse.replication.tcp.redis - 141 - INFO - subscribe-replication-0 - Successfully subscribed to redis stream, sending REPLICATE command
+synapse.replication.tcp.redis - 146 - INFO - subscribe-replication-0 - REPLICATE successfully sent
+```
+
+
+# Workers
+
+Workers are Synapse instances that perform a single job (or a set of jobs).
+Their configuration goes into `/etc/matrix-synapse/workers`, which we have to
+create first.
+
+

matrix/synapse/workers/README.md

@@ -1,11 +0,0 @@
----
-gitea: none
-include_toc: true
----
-
-# Advanced configuration with workers
-
-This configuration allows optimizing performance, meant for big, busy
-installations.
-
-