While Docker isn't officially supported by Hometown, leaving the
Mastodon 3.5.5 Docker configuration in place with the new 4.0.2 code is
a bad idea. At minimum, you'll have a stale Node install that's months
behind on security updates. There are some minor tweaks to the default
configuration, but they're flagged by comments so they're easy to revert
or modify as necessary.
# Running Hometown on Docker
I'll by typing up my own longer blog post in due time, but there's no
harm dropping a cheat sheet here. By following this outline, I was able
to upgrade a Hometown 1.0.8 install to 1.1.0 with nothing worse than a
minute or two of downtime.
My configuration uses the GitHub repository as its source, rather than
images drawn from DockerHub. I like to tweak and fiddle with my setup,
especially the themes, and I'm happy to sacrifice some disk space for
the privilege.
## Installing from Scratch
This is by far the easiest approach, you just follow [one
of](https://gist.github.com/TrillCyborg/84939cd4013ace9960031b803a0590c4)
the [existing
guides](https://sleeplessbeastie.eu/2022/05/02/how-to-take-advantage-of-docker-to-install-mastodon/)
for running Mastodon via Docker, pause after you've set up
`.env.production`, add any Hometown-specific features to it [as per the
Wiki](https://github.com/hometown-fork/hometown/wiki), then resume what
the guide says to do.
If you're enabling ElastiSearch, the second of the two guides has some
additional actions you'll need to do, plus be aware of [this
bug](https://github.com/mastodon/mastodon/issues/18625) in Mastodon
which can quietly block ES from working at all.
## Upgrading from Hometown 1.0.8
Here's how I accomplished this. I committed any leftover changes, then
ran these commands from the non-Docker instructions in the root of my
local Hometown repository:
```
git remote update
git checkout v4.0.2+hometown-1.1.0
```
This "wiped out" my customizations, but as I committed them all to a
branch I can reconstruct them later via diffs. I then ran:
```
sudo docker-compose build
```
to build the new image. The old image will continue running in the
background, as per usual. I like adding `2>&1 | less` to the end and
mashing `PgDn`, as if a compilation error happens it almost invariably
requires scrolling back a few screens to find the issue.
If the build succeeded, we're almost clear to start the dangerous
portion. If you're running on the cloud, now would be a great time to
take a snapshot. Whatever the case, you should back up the existing
database. If you haven't changed the defaults from the Dockerfile, then
```
sudo docker exec -it hometown_db_1 pg_dump -U postgres -Fc postgres > hometown.db.dump
```
should do the trick. If you have changed the defaults, you may need to
use `sudo docker ps` to figure out the name of the PostgreSQL image to
swap in place of "hometown_db_1", then browse through `.env.production`
to extract the username to place after `-U` and the database name to
place after `-Fc`. The Hometown docs don't say how to restore the
database should the process go South, but after reading a manpage or two
I think the magic words are roughly
```
sudo docker exec -it hometown_db_1 pg_restore -U postgres --clean --if-exists -d postgres < hometown.db.dump
```
Now we're ready for the scary "you could destroy everything" part. All
the earlier commands are trivial to roll back, but after this point any
delay could cause data corruption. As per the Hometown docs, run the
pre-deployment database migrations.
```
sudo docker-compose run -e SKIP_POST_DEPLOYMENT_MIGRATIONS=true -e RAILS_ENV=production --rm web bundle exec rails db:migrate
```
where `web` is the name of the webserver image in `docker-compose.yml`.
The docs state you should precompile all assets next, but I'm 95% sure
they were already built when you ran `sudo docker-compose build`. If
you're paranoid and want to be absolutely sure precompilation is done,
then at this stage run:
```
sudo docker-compose run -e RAILS_ENV=production --rm web bundle exec rails assets:precompile
```
Here, the Hometown docs say you should run the post-deployment
migrations. In Docker-ese:
```
sudo docker-compose run -e RAILS_ENV=production --rm web bundle exec rails db:migrate
```
Finally, we need to stop the old images and spin up the new ones. Run:
```
sudo docker-compose up -d
```
and give Docker some time to finish rotating. A quick `sudo docker ps`
should confirm the new images are booting up, and in a short while
(10-15 seconds for the teeny-tiny instance I manage) you should be back
to fully functional.
This will allow Docker to be automatically check the health of services.
Docker won't do anything other than showing the state in the output of
"docker-compose ps" by default, but some management tools may watch for
container health events.
Here's what my local instance looks like right now:
Name Command State Ports
-------------------------------------------------------------------------------------------------------------
mastodon_db_1 docker-entrypoint.sh postgres Up (healthy)
mastodon_es_1 /usr/local/bin/docker-entr ... Up (healthy)
mastodon_redis_1 docker-entrypoint.sh redis ... Up (healthy)
mastodon_redis_cache_1 docker-entrypoint.sh redis ... Up (healthy)
mastodon_sidekiq_1 /sbin/tini -- bundle exec ... Up 3000/tcp, 4000/tcp
mastodon_streaming_1 /sbin/tini -- yarn start Up (healthy) 3000/tcp, 127.0.0.1:4000->4000/tcp
mastodon_web_1 /sbin/tini -- bash -c rm - ... Up (healthy) 127.0.0.1:3000->3000/tcp, 4000/tcp
#7780 means that asset compilation happens as a build step.
Having the assets and packs volumes defined in `docker-compose.yml` breaks this. For people who run under Docker Compose, I believe this will fix their CSS (which even running the asset recompilation separately did not).
If Mastodon accesses to the hidden service via transparent proxy, it's needed to avoid checking whether it's a private address, since `.onion` is resolved to a private address.
I was previously using the `HIDDEN_SERVICE_VIA_TRANSPARENT_PROXY` to provide that function. However, I realized that using `HIDDEN_SERVICE_VIA_TRANSPARENT_PROXY` is redundant, since this specification is always used with `ALLOW_ACCESS_TO_HIDDEN_SERVICE`. Therefore, I decided to integrate the setting of `HIDDEN_SERVICE_VIA_TRANSPARENT_PROXY` into` ALLOW_ACCESS_TO_HIDDEN_SERVICE`.
Both of yarn and npm are used in Mastodon, but the combined usage requires
a redundant dependency and may lead to data inconsistency.
Considering that yarn has autoclean feature which npm does not have,
this change replaces all npm usage with yarn.
This change requires documentation update. Most notably, the following
command must be executed before assets precompilation if any system
dependency of node-sass has changed:
yarn install --force --pure-lockfile
* Add full-text search for authorized statuses
- Search API will return statuses that match the query
- Only for logged in users
- Only if you are author of the status,
- Or you were mentioned in it
- Or you favourited or reblogged it
- Configuration over `ES_ENABLED`, `ES_HOST`, `ES_PORT`, `ES_PREFIX`
- Run `rails chewy:deploy` to create & populate index
Fix#5880Fix#4293Fix#1152
* Add commented out docker-compose configuration for ES container
* Optimize index import, filter search results
* Add basic normalization to the index
* Add better stemming and normalization to the index
* Skip webfinger request if search query includes both @ and a space
* Fix code style
* Visually separate search result sections
* Fix code style issues
PostgreSQL10 has been released, but upgrading from older versions needs dump/restore. If you pull new version without those handling, db service will fail to launch.
To prevent accidentally upgrading, and as a recommended version, this patch specifies PostgreSQL and Redis version.
* Switch docker-compose to version 3.
It allow possibility to Deploy Mastodon in a Swarm cluster directly from the compose file.
* switch to compose v3 without depend.
* Replace browserify with webpack
* Add react-intl-translations-manager
* Do not minify in development, add offline-plugin for ServiceWorker background cache updates
* Adjust tests and dependencies
* Fix production deployments
* Fix tests
* More optimizations
* Improve travis cache for npm stuff
* Re-run travis
* Add back support for custom.scss as before
* Remove offline-plugin and babili
* Fix issue with Immutable.List().unshift(...values) not working as expected
* Make travis load schema instead of running all migrations in sequence
* Fix missing React import in WarningContainer. Optimize rendering performance by using ImmutablePureComponent instead of
React.PureComponent. ImmutablePureComponent uses Immutable.is() to compare props. Replace dynamic callback bindings in
<UI />
* Add react definitions to places that use JSX
* Add Procfile.dev for running rails, webpack and streaming API at the same time
* enable commented volume in docker-compose.yml
* Disable unworking Nginx root directory && Mitigating the HTTPoxy Vulnerability
* add my instance to the list
* enable GZIP on nginx.conf
* readd root /home/mastodon/live/public;
must be added to the Sidekiq invokation in your systemd file
The pull queue will handle link crawling, thread resolving, and OStatus
processing. Such tasks are more likely to hang for a longer time (due to
network requests) so it is more sensible to not make the "in-house" tasks
wait for them.
work flawlessly was a nightmare). WARNING: This commit makes the web UI connect to the streaming API instead
of ActionCable like before. This means that if you are upgrading, you should set that up beforehand.
hjhornbeck
Darius Kazemi
Claire
Shlee
Markus Petzsch
Yamagishi Kazutoshi
Su Yang
Matej Ľach
Eugen Rochko
Fabian Schlenz
Sir-Boops
Ben Lubar
luzpaz
ThibG
Aaron Brady
MIYAGI Hikaru
J Yeary
Isatis
Valentin Lorentz
Akihiko Odaki
unarist
Valentin Ouvrard
Pierre Ozoux
Valentin_NC
Wonderfall