The migration chain starts mastodon-search-deploy.service immediately, but the systemd_unit resource was declared later in the recipe, so the unit did not exist yet and systemctl failed with 'Unit not found'.
The stamp files' lazy git call ran as root, which git rejects on the mastodon-owned repository (dubious ownership), silently writing an empty stamp. Use execute resources with the mastodon user instead so git works and the revision is recorded.
The mastodon user's home was /opt/mastodon, i.e. the clone destination, so writing the SSH deploy key into ~/.ssh made the directory non-empty and Chef's git resource silently skipped cloning (it only clones into an empty directory). Use a dedicated /home/mastodon home for the user and keep the clone destination separate. Also clear a non-git (partial) clone destination before cloning.
Bundler 4 (shipped with Ruby 4) removed --deployment. Use 'bundle config set --local deployment true' (frozen + vendor/bundle) and the 'without' setting instead, in the Mastodon, akkounts and liquor-cabinet cookbooks.
The repository is private, so use git@gitea.kosmos.org with a read-only deploy key stored in credentials/mastodon (repo_deploy_key). The pinned gitea host key is an attribute.
Split the deployment into kosmos-mastodon::build (checkout + bundle/yarn/assets, no database) and kosmos-mastodon::deploy (migrations + services), dispatched by the new 'build' attribute. Both phases are idempotent per checked-out revision via stamps, and the migration/restart/search-index chain is now triggered by the deployed revision instead of the git resource, so it still runs when the build was pre-staged.
The shared backup cookbook hardcodes postgresql-client-12, which does not exist on Ubuntu 24.04. Drop the Mastodon backup recipe and its role inclusion; the PostgreSQL standby is the safety net. The backup cookbook itself is still used by other services.
Ubuntu 24.04's system Python is externally managed (PEP 668) and refuses pip installs. Also bump LibreTranslate from 1.3.8 to 1.9.6, since the former pulls ctranslate2 2.24.0 which has no Python 3.12 wheels.
The java cookbook's openjdk recipe unconditionally adds the dead openjdk-r PPA on Ubuntu and cannot be told not to, which breaks on Ubuntu 24.04. Elasticsearch 7.x ships a bundled JDK and no JAVA_HOME is configured, so no system Java is needed.
Mastodon 4.4+ can create/upgrade the Elasticsearch indices and mappings without importing data. Do that synchronously during the deployment so search does not fail on a missing index, then populate the (potentially very long) import via a systemd unit started with --no-block so the maintenance window is not extended.
Add a kosmos-mastodon::dependencies recipe with everything needed to run Mastodon (Node, Ruby, libvips, Elasticsearch, packages) but without the app deployment. The default recipe includes it and only runs the deployment when node['kosmos-mastodon']['deploy'] is true, so a VM can be prepared ahead of a maintenance window.
Stop using the local redisio instance and connect to the external Redis cluster (redis_server role, db 2, password from the credentials data bag) instead. Remove the redisio service dependencies from the systemd units and drop the redisio cookbook dependency.
Bump the production branch to 4.7 and adjust for the changes between 4.3 and 4.7:
- Node 24.21.0 and Ruby 4.0.7 (via ruby-build v20260924)
- Redis 7.4.11 (Mastodon 4.5 requires >= 7.0)
- Replace ImageMagick with libvips (required since 4.6) and libidn11 with libidn
- Split database migrations into pre-/post-deployment phases and rebuild
the Elasticsearch accounts index mappings (required since 4.4)
- Remove the OTP_SECRET environment variable (removed in 4.4)
- Disable email subscriptions (new optional feature in 4.6) and force the
default locale (DEFAULT_LOCALE no longer overrides it since 4.4)
- Add the new fasp Sidekiq queue
- Enable corepack for yarn instead of the removed no-arg 'corepack prepare'
raucao