Without `filter = sshd` and after restarting the service I see this error in Fail2Ban's logs (`/var/log/fail2ban.log`):
```
2022-11-03 11:24:36,225 fail2ban.transmitter [1283507]: ERROR Jail 'sshd-ddos' skipped, because of wrong configuration: Unable to read the filter 'sshd-ddos'
```
I added the statement as per [this article](https://serverfault.com/a/1050315) and it worked.
Assuming that this documentation is run inside the /live (Mastodon home directory), the current link is broken.
The proposed change fixes this error and thus refers to the tootctl inside the bin directory
* Improve scaling documentation for Streaming
This reorganizes the documentation a little bit, adds information about the templates systemd files, and some reference numbers for concurrent streaming connections.
* Update content/en/admin/scaling.md
* Add section on Streaming Server metrics to Scaling.md
* Improve the documentation about the parameters of the email sent by mastodon smtp client.
---------
Co-authored-by: lhp22 <louishp@protonmail.com>
Co-authored-by: Andy Piper <andypiper@users.noreply.github.com>
* clarify effects of suspending users and server
There's a lot of confusion about how suspending affects existing follow relationships and some moderators assume the follow relationships will be restored when a remote account (or entire server) is un-suspended within the 30-day time window
* Correction of docs about server suspension
Co-authored-by: Claire <claire.github-309c@sitedethib.com>
---------
Co-authored-by: Claire <claire.github-309c@sitedethib.com>
The current rbenv is 3.0.6 - I received an error when following these steps which said the expected version is 3.0.6. After updating to 3.0.6, the installation was successful.
This documentation has I believe one very confusing point: It uses two times `YOUR_S3_HOSTNAME` in the nginx configuration example, however the second time it looks like you actually have to use `YOUR_BUCKET_NAME.YOUR_S3_HOSTNAME`.
## Explanation
Mastodon is using path-style requests to S3 which looks like this:
https://s3.region-code.amazonaws.com/bucket-name/key-name
Once you enable the new virtual host nginx file using the current indications, the path-style request which goes to amazon looks like this:
https://s3.region-code.amazonaws.com/key-name
In other words, the bucket name is not being sent S3 and the images break.
This is because the current instructions make it seem like the header Host name is not including the bucket
`proxy_set_header Host YOUR_S3_HOSTNAME;`
With the current path-style request integration, one must use the bucket name in the Host header for this to work, hence the proposed change to
`proxy_set_header Host YOUR_BUCKET_NAME.YOUR_S3_HOSTNAME;`
