From 4dcdfc3dc316057aba514a0a8c4e8101c034b2d7 Mon Sep 17 00:00:00 2001 From: Quentin Dufour Date: Tue, 21 Sep 2021 12:35:06 +0200 Subject: [PATCH] typo --- _posts/2021-09-14-synapse-media-storage-provider.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_posts/2021-09-14-synapse-media-storage-provider.md b/_posts/2021-09-14-synapse-media-storage-provider.md index 9df1618..420257e 100644 --- a/_posts/2021-09-14-synapse-media-storage-provider.md +++ b/_posts/2021-09-14-synapse-media-storage-provider.md @@ -149,7 +149,7 @@ And now, all of our media are successfully sent on our S3 target. My guess is that each media is first written on the local filesystem and then sent on S3. Because GlusterFS is slow and error prone, some exceptions or timeouts may be risen before the file is uploaded to S3. -At least, we now considere the problem as solved. +At least, we now consider the problem as solved. We only need one more step: regulargy cleaning up the local filesystem to not fill our RAM. @@ -187,7 +187,7 @@ To use it, you must set the following environment variables: I presented the "native" way to handle media on Matrix Synapse but there is also a community managed project named [`matrix-media-repo`](https://docs.t2bot.io/matrix-media-repo) with a slightly different goal. The author wanted to have a common media repository for multiple servers to reduce storage costs. -matrix-media-repo works is not implementation independent: instead, it shadows the matrix endpoint used for the media `/_matrix/media` and thus is compatible with any matrix server, like dendrite or conduit. Its main advantage over our solution is that it does not have this mandatory cache, it can directly upload and serve from a S3 backend, simplifying the management. +matrix-media-repo is not implementation independent: instead, it shadows the matrix endpoint used for the media `/_matrix/media` and thus is compatible with any matrix server, like dendrite or conduit. Its main advantage over our solution is that it does not have this mandatory cache, it can directly upload and serve from a S3 backend, simplifying the management. Depending on your reverse proxy, it might be possible that if `matrix-media-repo` is down, users are redirected to the original endpoint that should not be used anymore, leading to loss of data and strange behaviors. It seems that [an option](https://github.com/matrix-org/synapse/blob/v1.42.0/synapse/config/server.py#L265-L269) in Synapse allows to deactivate the media-repo, it might save you some time if it works.