Set the akaunting lifecycle to eol: the updaters stop proposing bumps for
it and the CI deploy matrix leaves it out, as for the other eol roles.
The role keeps shipping for existing deployments. The root README overview
drops it, as it does for every eol role.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- test_prefix_grouped_files: files/sql/store_database.sql and
store_layout.sql become files/sql/store/database.sql and layout.sql.
- test_file_spot: test_store_guard.py builds the vars path with
ROLE_FILE_VARS_MAIN instead of a hard-coded "vars" / "main.yml" chain.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
test_prefix_grouped_files rejects sibling files that share a delimiter-
bounded prefix: tasks/utils/bucket_list.yml and bucket_policy.yml become
tasks/utils/bucket/list.yml and policy.yml, and the includes follow.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Discourse v2026.10.0 removed LlmModel#toggle_companion_user; bot users now
belong to AI agents (discourse/discourse 5e11656cae, "Gate AI bot user
provisioning on feature settings"). The AI gateway registration still
called it and failed with "undefined method 'toggle_companion_user' for an
instance of LlmModel" (PR #1239, Nextcloud#7).
The role does not need the companion user: verify.rb.j2 checks the binding
through LlmModel.enabled_chat_bot_ids, which v2026.10.0 still derives from
SiteSetting.ai_bot_enabled_llms, and the registration sets that setting.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The akaunting service is built from the akaunting/docker repository
(ref master), whose Dockerfile downloads the latest Akaunting release into
/var/www/html, the shared data volume. Since 2026-10-26 that Dockerfile
builds on php:8.2, and Akaunting 3.3.0 (released 2026-10-27) requires
PHP >= 8.2.
The swarm setup job instead ran the upstream tag akaunting/akaunting:3.1.21
(PHP 8.1.34) against the same volume. It executed the 3.3.0 code there and
failed with "Ask your hosting provider to use PHP 8.2.0 or higher" (main
run 40507642995, Akaunting#0). Compose mode was unaffected because its
setup uses `compose run akaunting`, i.e. the built image.
Read the image from the service spec and start the setup job with it, so
code and runtime always come from the same build. Drop the now unused
AKAUNTING_IMAGE/AKAUNTING_VERSION vars.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Follow-up to the v1.0.0 port, closing holes a review and a local run found:
- WebUI sign-in: WebUI v2 sends an http:// client-metadata-document id
on the onion origin, which Stalwart v1.0.0 rejects (unknown http ids
get no CIMD fallback, trusted hosts require TLS). The recovery admin
under SSO hit the same wall with the bare id 'stalwart-webui'. Register
a public first-party x:OAuthClient 'stalwart-webui' with the WebUI's
callback and login URIs on the served origin, and always inject it as
the Application's oauthClientId. Native sign-in now shows Stalwart's
consent step; test-login-native.js clicks it and also runs under SSO.
- Store guard: the previous guard only checked a running 0.16 server; a
local run showed v1 writing into a 0.16 store whose server was stopped.
The guard now reads the store whenever one exists (shared: pg_database,
dedicated: volume) and fails on the 0.16 bigint layout. A host marker
written at the end of a successful v1 deploy lets restores and
redeploys with a stopped dedicated database pass; without the marker,
a stopped dedicated database fails with an explicit message instead of
a masked psql error. Queries retry while the database recovers.
- README: WebUI sign-in, guard semantics, restore and redeploy.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Follow-up to the bucket-policy deny, closing holes two reviews found:
- Scope: the policy was only applied during a consumer's own deploy, so a
provider-only or partial deploy left other buckets without it. Every
provider deploy now converges all existing consumer buckets, and a
consumer's provisioning applies it right after creating the bucket.
- Ownership: our statement is identified by Sid DenyAnonymousRead; a
public bucket loses only that statement, operator statements survive.
- Errors: only a 404 NoSuchBucketPolicy means "no policy"; any other
status fails the read loudly.
- Credentials: curl expands the admin credential itself via --variable
instead of --user "$VAR", which put it on curl's argv and in the
host's ps.
- Curl runs through the repository's curl filter with timeouts, the
read-only tasks run in check mode, and bucket names are parsed exactly
instead of by substring.
- README: corrected embedded-mode authentication and documented the
convergence.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
SeaweedFS 4.49+ honours a public-read object or bucket ACL on an unsigned
GET/HEAD/list even in a bucket the platform treats as private
(seaweedfs/seaweedfs#11605). Since consumers hold WriteAcp, an app could
expose objects through the public S3 API domain just by sending
x-amz-acl: public-read.
Put a bucket policy on every non-public consumer bucket that denies
s3:Get* and s3:List* to principal "*" when aws:username is null. SeaweedFS
evaluates that deny before any AllUsers grant; signed and presigned
requests carry an IAM user ARN, so aws:username is set and they are not
affected. Public buckets keep their anonymous Read grant, and a bucket
that turns public gets our deny lifted again. Embedded sidecars publish
no port and are left as they are.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Stalwart v1.0.0 rejects unknown JMAP properties ("Invalid property" ->
notCreated/notUpdated), validates OIDC tokens more strictly and refuses to
open a data store from before 1.0. Port the role and protect existing
installs:
- Milter: hostname/timeoutConnect/timeoutCommand/timeoutData become
host/connectTimeout/commandTimeout/dataTimeout; the existing milter is
looked up by host.
- Onion relay route: address becomes host.
- OIDC directory: requireAudience is gone. Set skipAudienceValidation and
unscopedTokens=interoperable on create and update, so Keycloak tokens
(no Stalwart audience, no mail scope) keep working for the WebUI and
Roundcube XOAUTH2.
- WebUI: send oauthClientId only with SSO enabled; without SSO the WebUI
falls back to its own client metadata document.
- Store guard: before anything changes, a running Stalwart whose table u
still has the 0.16 bigint layout stops the deploy and points to the
stalwart-migrate steps, which the README now documents under
"Upgrading from 0.16".
- Updater: pin the WebUI git_tags source to v2.* to match server 1.x.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Context Agent 2.10.0 (bumped in #1219) moved to a multi-stage image whose
runtime stage ships no curl ("no vim, no git, no curl, no pipx/poetry",
nextcloud/context_agent Dockerfile at v2.10.0). The curl healthcheck then
fails with `exec: "curl": executable file not found in $PATH`, the task
never leaves `starting`, and the swarm converge wait gives up on
nextcloud_context_agent (main run 40401200083, Nextcloud#2).
Switch to the http_status flavor, which speaks HTTP over bash's
/dev/tcp and still requires a 2xx/3xx answer from /heartbeat.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Stalwart server v1.0.0 and WebUI v2.0.0 only work as a pair:
- WebUI v2.0.0 declares minServerVersion 1.0.0.
- Server v1.0.0 rejects a bundle without the manifest that only WebUI 2.x
ships ("Application bundle does not contain a manifest").
The separate bumps in #1227 (server only) and #1223 (WebUI only) were
each broken on their own, so this commit carries both.
WebUI v2.0.0 also dropped the hardcoded 'stalwart-webui' fallback client
id. Without an oauth-client-id meta tag (or CIMD support at the IdP) it
shows "Sign-in is not configured" and never redirects. That is the
test-sso.js failure in Jenkins#0 of #1223. Set the Application record's
oauthClientId to the configured Keycloak client so the server injects the
meta tag on unpack.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
SeaweedFS 4.49 (seaweedfs/seaweedfs#11592) authorizes a PutObject that
carries x-amz-acl as s3:PutObjectAcl as well. The consumer identities
only held Read/Write/List/Tagging, so every app that sends an ACL on
upload (Nextcloud, Fider and Pixelfed with private, Mastodon, PeerTube,
BookWyrm and Baserow with public-read) got AccessDenied after the 4.48 -> 4.51
bump in #1226. Main run 40401200083 failed Fider#0, BookWyrm#0,
Baserow#0, Pixelfed#0 and Nextcloud#0/#4/#8 on it.
Add WriteAcp to the s3.json identities and to the sidecar s3.configure
grant.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
