occ config:app:set asks for a confirmation when it is given a type, and
without a terminal it aborts with exit code 1. The typed Talk server
lists from the previous commit therefore stopped the deploy at the
plugin configuration.
Entries with a type are now written with --no-interaction. Measured on a
live Nextcloud 35 with dummy values: stun_servers, turn_servers and
recording_servers are stored as arrays, Talk lists exactly the written
servers, and a second identical call leaves the value alone.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
ruff format rewraps the read-back line in test_repository.py, and ruff
check reports the nested with in test_fetch.py as SIM117. Both fail
lint-python.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The sources of nginx and etherpad carried 1.29 and 2.4.2 as literals.
Upstream keeps both in docker-compose.tmpl.yml, not in repos/tags, so a
change there would have left the proposed tag on the old value while the
image updater no longer watches these pins.
Both sources now read repos/tags and the compose template and take the
value from the image line.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
An http_regex source read one document, so a tag whose parts upstream
keeps in two files could only carry the second part as a literal. Every
pin also fetched its document on its own: a failed request left one pin
of a release behind while the others moved.
url now takes a list whose bodies are searched as one text, and every
document is fetched once per run, so all pins that read it resolve against
the same snapshot. The HTTP reads move into utils/update/fetch.py.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The repository updater assigns ref: lines to entities by position: every
entity that pins a value takes the next line carrying that value. A ref
that declares its own source was dropped before it took its line, so a
second entity pinning the same value was given the sourced entity's line,
and an update of it would have rewritten the wrong ref.
A sourced ref now takes its line first and is skipped afterwards, the
same order the nocheck marker already follows.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The security-analyst page never calls the roles API, so the response wait timed out in CI. The non-admin tiers now check that the user stays inside the Wazuh app, sees a non-empty page and sees neither the role list nor the create-role button. Failure messages include the page URL and text.
Talk 25, the release for Nextcloud 35, reads stun_servers and
turn_servers through the typed app config and declares both as arrays.
Talk 24 read them as JSON strings. The role wrote them without a type,
so on Nextcloud 35 the Talk settings showed no STUN and no TURN server
although the deploy had set both.
A plugin configuration entry may now carry a type, which is passed to
occ config:app:set. The three Talk server lists use it. Entries without
a type are written as before.
Not yet run against a live Nextcloud 35.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Nextcloud 35 has no app store release of BPM Files and News yet, and the
role skips an addon it cannot install. Their tests ran anyway and failed
on the missing app. Recognize installs on 35, but its test trips over a
second element with the id it looks for.
An addon test runs only for an addon that is enabled and required. With
required set to false the three addons are still installed whenever a
compatible release exists, and their tests no longer run. metadata is
declared the same way already.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
One test asserts ansible_host lands on the given address, the other
that a missing member raises. Either would have caught the UNREACHABLE run
before it was dispatched.
keep_address left ansible_host alone, and the lab never sets it: the
docker connection uses inventory_hostname as the container name. Switching to
SSH without writing an address made ssh resolve 'web-app-gitea-swarm-mgr-01'
through DNS, and run 37617424998 died UNREACHABLE on all three nodes in 13
minutes.
switch_to_mesh now takes the addresses to dial. A member missing from the
mapping raises instead of falling back to its mesh address, because that
fallback would have produced the meshed arm under the other arm's name - a
wrong number rather than a failed run.
The ref and the fifteen image pins are one upstream release, but the image
updater moved the Docker tags alone while the ref never moved, because
bigbluebutton/docker publishes its releases as branches and the repository
updater reads tags. 759a1aa4d0 stopped the split with fifteen
nocheck: docker-version markers, which also stopped every bump.
The ref and every pin of the set now name upstream's release manifest on
the default branch as their source: repos/tags for the versions,
docker-compose.tmpl.yml for periodic. freeswitch, nginx and etherpad
assemble their compound tags from it. One resolver run proposes the whole
set, and the markers are gone.
The pinned versions do not change. Upstream's v3.0.39 is still an open
pull request (bigbluebutton/docker#397).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A pin that names its own upstream in an update: block was still collected
by the image updater or, for a ref, by the repository updater. Those raise
it to the newest tag of its registry or repository, which for a component
of a release is not the release's value. A tag built from several upstream
values, such as <freeswitch>-<bigbluebutton>, could not be resolved at
all: the resolver takes one capture and keeps a pin on its suffix.
The image updater now skips a version and the repository updater a ref
that declares a source for itself. An http_regex source accepts a template
over the pattern's named groups, and a templated pin moves whenever the
assembled value changes, its suffix included.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The web frontend, the controller and the recorder were pinned to v2.9.0,
v0.34.1 and v0.16.2, a mix of the 26.2 and the 26.1 line, and excluded
from the image updater with nocheck: docker-version. Nothing moved them.
They now sit on the set OpenTalk publishes as product version 26.2.1 in
ot-setup (v2.9.2, v0.34.5, v0.17.5), and each pin names that bundle as its
version source, so the three move together with the next product version.
The markers are gone.
Recorder v0.17 no longer reads recording jobs from RabbitMQ or logs in
with an OIDC service account. The controller starts recordings on the
recorder's REST API and both sides authenticate with API keys:
recorder.toml.j2 names the controller and the recorder's own key,
controller.toml.j2 enables roomserver.modules.recording, the secret
recorder_api_secret replaces recorder_oidc_client_secret and the Keycloak
client opentalk-recorder is no longer created.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A pin that names its own upstream in an update: block was still collected
by the image updater, which raises it to the newest tag of its registry.
For a component of a release bundle that tag is not the bundle's, so the
two updaters would propose different versions for the same line and such
a pin had to carry nocheck: docker-version.
The image updater now skips a version that declares a source for itself.
The source resolver alone bumps it.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The image updater raised nine BigBlueButton images to v3.0.39 and
webrtc-sfu to v2.24.0, while the role still generates its compose file
from bigbluebutton/docker at ref v3.0.23. compose.override.yml.j2 runs
every sub-service on the pinned version, so bbb-web v3.0.39 started
against the v3.0.23 template, found no USE_INSECURE_ETHERPAD and
restarted until hlth-container failed web-app-nextcloud#11 in run
37705983036.
The versions are back on the set that repos/tags of v3.0.23 names. All
fifteen components of the upstream compose now carry
nocheck: docker-version, because upstream publishes its releases as
branches: the ref updater reads tags and never moves the ref, so the
image updater alone would split the set again.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Under SSO the role tried to let applications relay without SMTP AUTH by
widening the relay rule to the private networks. The rule compared the
peer address to the text of a CIDR, which never matches, so an
application could reach local mailboxes but got "550 5.1.2 Relay not
allowed" for every external recipient. Repairing the comparison would
have opened a relay, because published ports, Tor and the swarm mesh all
hand outside clients an address inside those networks.
Stalwart checks app passwords before it asks the external directory, so
a bot can authenticate while the directory is OIDC. With SSO enabled the
role now creates one app password per bot, acting for that account as
the recovery admin, and stores it in the token store the SMTP password
is already read from. A bot gets a new one when its entry is deleted in
Stalwart or its token is removed.
The relay rule is back to authenticated sessions only. The lookup loses
its SSO relay branch and the role its submission_via_relay flag, so an
SSO deployment submits on 465 with AUTH like every other one.
The role's CLI test now fails when an unauthenticated session is given
an external recipient, or when the bot credential is refused one.
Closes#793
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The tor gate that 312d09e290 put into the services.yml of web-app-seaweedfs
and web-svc-coturn never took effect on a deployed round. Both roles pin
the same flags to a literal true in variant 0, the round writes those pins
into the inventory, and an inventory value wins over the expression in
services.yml.
Measured on a compose round of web-app-matrix variant 0 with tor: the
inventory carried prometheus enabled true for both roles, so both stayed
in the Prometheus target list and the spec failed on the missing
web-app-seaweedfs label and probe.
Variant 0 now carries the gate itself for prometheus on both roles and
for logout and dashboard on seaweedfs, the three flags 312d09e290 names.
The bond-baseline and variants-coverage guards require a literal true in
variant 0 for these blocks, so they carry the same markers the frontend
block of seaweedfs already has, for the same reason.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The role advertised `matrix-synapse:9000` to Prometheus in both flavors.
That container only exists in the compose flavor. In the ansible flavor,
which is the default, Synapse runs inside the `matrix` container and had
no metrics listener, so the scrape target was down on every deployment
that pairs Matrix with Prometheus.
The ansible flavor now enables the Synapse metrics listener on 9100 and
the declaration names port and service per flavor, so the target is
`matrix:9100` there and stays `matrix-synapse:9000` in the compose
flavor.
This is the metrics part of b3e0dce578 on `feature/store-i18n`, without
the addon switch that branch introduces around it.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
`native_metrics_target` was a Jinja filter, so it could not read
DEPLOYMENT_MODE: filters see no Ansible variables. It returned
`<services.<key>.name>:<port>` unconditionally, which is `matrix-synapse:9000`
for matrix. Compose serves that name; swarm does not, because `docker stack
deploy` ignores `container_name` and the alias never exists. This repository
says as much itself, through `lookup('compose_only', 'container_name', ...)`.
The target was therefore scraped and refused, and `playwright.spec.js:274`
reported `web-app-matrix: 1 matching target(s) reporting up != 1`, meaning one
matching target whose `up` value is not 1.
It becomes a lookup that delegates host resolution to `scrape_target`, which
was already mode-aware, so exactly one plugin knows the difference between the
two modes. The port has to be handed over explicitly: matrix exposes metrics on
9000 while `services.synapse.ports.internal.http` is 8008, so the existing
internal-port lookup cannot serve this case on its own.
`scrape_target` now refuses `port` together with an explicit `port_kind`.
Before, `port` won silently and the error text still named the
`ports.internal.<port_kind>` path that the call had never consulted.
`native_metrics_apps` drops an app that pins itself to compose through
`compose_mode_force` while the cluster runs swarm, because the scrape target
would then name the wrong object. Only the literal case: matrix declares that
override as a Jinja expression over its flavour, which this lookup cannot
resolve from the scraping role's variable scope, so variant 0 on swarm stays a
latent mismatch.
The two comment lines claiming `container_name:port` went with the change;
after it they state the opposite of what the code does.
Verified by mutation: with the swarm branch of `scrape_target` disabled, the
new test emits `matrix-synapse:9000`, the exact string CI reported.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A variant that pins `services.tor.enabled: true` while enabling a role whose
own `meta/services.yml` pins `tor.enabled: false` declares a combination the
deployment cannot hold. The role rides no node onion, so on that round its
surface lives at a clearnet host no onion browser reaches, and the dashboard's
`frame-src 'self' http://*.<onion>` forbids embedding it outright. Run
36651124458 job 109692287333 shows the result: five specs fail at once,
dashboard tile, matomo tracker, css injection, logout and the coturn metric
label, all on hosts that are the only non-onion ones in the whole job.
web-app-nextcloud variant 11 was such a round: bigbluebutton on, tor on, while
bigbluebutton declares no onion. Variant 8 already answers the identical
question for PeerTube (65538c40da, "clearnet, because the OIDC plugin rejects a
plaintext onion issuer"), so variant 11 now does the same. With that,
bigbluebutton never meets a tor node and needs no consumer gates of its own.
Two roles keep a gate, for reasons that differ from each other:
web-app-seaweedfs is not clearnet-only. It deploys on tor as the object store
other roles reach over the internal network, and only its browser frontend is
off there, which `frontend.enabled` on main already says. Its logout, dashboard
and prometheus declarations claimed a surface that round does not deploy, so
they take the same gate the file's own frontend and sso blocks use.
web-svc-coturn belongs on a tor node and cannot serve one: STUN/TURN runs on
UDP plus a 20000-port relay range that no onion descriptor can publish, and its
only HTTP is a gateway answering a plaintext OK. Deploying it is right,
advertising it as a prometheus consumer is not, because that scrape goes
through the browser path. It is exempt from the rule itself, since it claims no
visitable surface, and its `dynamic-flag` markers now carry the reasons the
rule's own message asks for; one of the four was a duplicate of the line below
it and is gone.
The lint states the rule. It found these five pairings on its own, matching a
hand count made before it existed, and reports none after the variant fix.
`test_sso_variant_requires_tor` covers the complementary half, every variant of
a role that has an onion must pin it on, and exempts the clearnet-only role
itself; this rule covers the consumers that bind one. The suppression marker
belongs on the bound role when the reason is that role's own shape, because a
consumer-side marker would also silence every other clearnet role in the file.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
test_workflow_references matched the path .github/workflows/<file>.yml
wherever it appeared, including inside a link to another GitHub
repository. Requirement 037 cites the publish workflow of
koala73/worldmonitor, so the lint searched this tree for docker-publish.yml
and failed test-lint.
A github.com/<owner>/<repo>/ URL that does not point at infinito-nexus/core
is now removed from the line before the patterns run. The rest of the line
is still checked, and so is every own URL, relative path and API path. The
dispatch target check is unchanged.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
provision_ai_gateway.php and provision_mcp.php shared a prefix inside one
directory, which test_prefix_grouped_files rejects. Both move into
files/php/provision/ as ai_gateway.php and mcp.php, the layout
web-app-n8n already uses for its Python provisioning scripts.
The two lookups that feed the scripts to the container follow, and the
unit test moves to its mirrored path as provision/AiGatewayTest.php.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
