* List the actual accounts that would have been culled during a dry run.
Otherwise, the dry run mode is basically useless.
* Prevent unreachable domains from inheriting the previous status code.
* Update CHANGELOG.md for #10460.
Do not start a session if the current user is not logged in for public-facing pages.
Mark pages that don't care about sessions as publicly cacheable.
Keep the max age as 0 so proxies and browsers will still try to retrieve an updated version but can still fall back to the stale version if the site is down or too slow.
Fixes#9035.
- Always run apt update before any other apt command. (This fixes
incremental builds failing if a remote package is updated.)
- Only copy dependency lists before installing dependencies. (This means
editing code doesn't force all dependencies to be re-downloaded.)
- Delete cache in the same layer that it is created. (Otherwise,
deleting cache *increases* the size of the image on non-squashed
builds.)
- Move the installation of some static dependencies to *before* Mastodon
code is imported to Docker.
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
Right now, this includes three endpoints: host-meta, webfinger, and change-password.
host-meta and webfinger are publicly available and do not use any authentication. Nothing bad can be done by accessing them in a user's browser.
change-password being CORS-enabled will only reveal the URL it redirects to (which is /auth/edit) but not anything about the actual /auth/edit page, because it does not have CORS enabled.
The documentation for hosting an instance on a different domain should also be updated to point out that Access-Control-Allow-Origin: * should be set at a minimum for the /.well-known/host-meta redirect to allow browser-based non-proxied instance discovery.