2021-05-07 11:34:21 +00:00
|
|
|
# Mastodon
|
|
|
|
|
|
2023-02-15 00:30:24 +00:00
|
|
|
> Your self-hosted, globally interconnected microblogging community
|
2021-05-07 11:34:21 +00:00
|
|
|
|
|
|
|
|
<!-- metadata -->
|
2021-11-21 19:23:35 +00:00
|
|
|
* **Category**: Apps
|
2023-02-15 00:30:24 +00:00
|
|
|
* **Status**: 1
|
2021-11-21 19:23:35 +00:00
|
|
|
* **Image**: [`tootsuite/mastodon`](https://hub.docker.com/r/tootsuite/mastodon)
|
2023-02-15 00:30:24 +00:00
|
|
|
* **Healthcheck**: No
|
|
|
|
|
* **Backups**: No
|
|
|
|
|
* **Email**: Yes
|
|
|
|
|
* **Tests**: No
|
|
|
|
|
* **SSO**: Yes
|
2021-05-07 11:34:21 +00:00
|
|
|
<!-- endmetadata -->
|
|
|
|
|
|
2023-02-15 00:30:24 +00:00
|
|
|
## Quick start
|
2021-05-07 11:34:21 +00:00
|
|
|
|
2023-02-15 00:30:24 +00:00
|
|
|
Mastodon expects secrets to be formatted in a very specific way, so please
|
|
|
|
|
choose "No" when prompted to generate secrets for `abra app new mastodon`. The
|
|
|
|
|
secrets must be generated outside of `abra` and that is achieved in step 2. See
|
|
|
|
|
the [`abra.sh`](./abra.sh) for more.
|
2021-05-28 10:54:02 +00:00
|
|
|
|
2023-02-15 00:30:24 +00:00
|
|
|
1. `abra app new mastodon`
|
|
|
|
|
1. `abra app cmd <domain> secrets --local`
|
2023-02-17 08:51:09 +00:00
|
|
|
1. `abra app secret insert <domain> smtp_password v1 <password>`
|
|
|
|
|
1. `abra app config <domain>` (uncomment SMTP details)
|
2023-02-15 00:30:24 +00:00
|
|
|
1. `abra app deploy <domain>`
|
2023-02-17 08:51:09 +00:00
|
|
|
1. `abra app cmd <domain> streaming setup`
|
2021-05-28 10:54:02 +00:00
|
|
|
|
2023-02-15 00:37:57 +00:00
|
|
|
Then, on your host (outside of the containers), you'll need to fix permissions
|
2023-02-15 00:50:59 +00:00
|
|
|
for the volume (see [#10](https://git.coopcloud.tech/coop-cloud/mastodon/issues/10)):
|
2021-05-28 10:54:02 +00:00
|
|
|
|
|
|
|
|
```
|
2023-02-15 00:37:57 +00:00
|
|
|
chown -R 991:991 /var/lib/docker/volumes/<domain>_app/_data
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
And finally, within the `app` container, create an admin account:
|
|
|
|
|
|
|
|
|
|
```
|
2023-02-17 08:51:09 +00:00
|
|
|
abra app cmd <domain> admin -- <username> <email>
|
2021-05-28 13:19:58 +00:00
|
|
|
```
|
2023-02-15 00:47:06 +00:00
|
|
|
|
2023-02-15 01:00:37 +00:00
|
|
|
## Tips & tricks
|
2023-02-15 00:47:06 +00:00
|
|
|
|
|
|
|
|
### Auto-complete is not working?
|
|
|
|
|
|
|
|
|
|
Check the sidekiq logs (`/sidekiq/retries`), is a bunch of stuff failing? What
|
|
|
|
|
is the error?
|
|
|
|
|
|
|
|
|
|
If it looks anything like `blocked by: [FORBIDDEN/12/index read-only / allow
|
|
|
|
|
delete (api)];` then it might mean that your elastic search service has put
|
|
|
|
|
itself into "read-only" state. This could be due to running close to no free
|
|
|
|
|
disk space one time. ES doesn't undo this state, even when you have more free
|
|
|
|
|
disk space once more, so you need to handle this manually:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
abra app run <domain> es bash
|
|
|
|
|
curl -XPUT -H "Content-Type: application/json" http://localhost:9200/_all/_settings -d '{"index.blocks.read_only_allow_delete": null}'
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Then head back to the sidekiq retries panel and retry one job. You should see
|
|
|
|
|
the ticket of retries go down by one if if passed. Then you can "retry all" and
|
|
|
|
|
they should get scheduled & run.
|
