Files
Warp/server/test/complement/entrypoint.sh
T
tajniak81andClaude Opus 5.5 a94794b866
CI / Test (ubuntu-latest) (push) Canceled after 0s
CI / Test (windows-latest) (push) Canceled after 0s
CI / Storage tests on PostgreSQL (push) Canceled after 0s
CI / Complement (federation off) (push) Canceled after 0s
CI / golangci-lint (push) Canceled after 0s
CI / Smoke test the binary (push) Canceled after 0s
Phase 9: application services and admin completion
Implements PLAN.md Phase 9. internal/appservice reads registration files
(appservice.config_files), matches namespaces the way Synapse does
(anchored at the start), and delivers events to each service as
transactions read from the roomserver's event stream at a cursor kept in
appservice_state. A transaction in flight is recorded, so after a restart
it is resent under the same ID; failures back off from 2s to 5m, and a
successful ping cuts the backoff short.

In the Client-Server API an as_token acts as the service's sender or, with
?user_id=, as any existing user in its namespace. Services register and
log in their users with m.login.application_service; exclusive user and
alias namespaces are refused to everybody else with M_EXCLUSIVE. Unknown
aliases and users in a namespace are asked of the service first. The
ping endpoint reports M_URL_NOT_SET, M_BAD_STATUS, M_CONNECTION_FAILED
and M_CONNECTION_TIMEOUT. Services' own requests, and their users' when
rate_limited is false, skip the rate limiter.

Users can change their password (POST /account/password) and deactivate
their account (POST /account/deactivate), both behind the password.
Deactivation revokes tokens, deletes devices, optionally erases the
profile and leaves every room through a new userapi.AccountObserver.

The admin API is complete: user detail, the admin flag, deactivation and
reactivation, password resets, devices, media quotas
(media.max_user_storage_bytes plus per-user overrides), registration
tokens with use limits and expiry (registration.require_token), server
notices (internal/servernotices, server_notices.*), an editor for the
federation allow/deny lists persisted in server_settings, a delivery view
of the application services, and an audit log of every change.

Migration 0011 adds the registration token, server notice room, media
quota, audit log and appservice cursor tables. Policy lists are now
returned sorted. The Complement entrypoint loads the registrations
Complement mounts in /complement/appservice.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-17 12:58:28 +02:00

91 lines
3.4 KiB
Bash
Executable File

#!/bin/sh
# Start Warp the way Complement needs it.
#
# There is no configuration file: every setting Warp has can come from a
# WARP_* environment variable, so the whole deployment is the few lines
# below. Complement may run this entrypoint more than once against the same
# container, so everything here is idempotent.
set -eu
DATA_DIR="${WARP_DATA_DIR:-/data}"
mkdir -p "$DATA_DIR"
# Complement names the homeservers hs1, hs2, ... and passes the name in.
export WARP_SERVER_NAME="${SERVER_NAME:-hs1}"
export WARP_PRIVATE_KEY="$DATA_DIR/signing.key"
export WARP_DB_DRIVER=sqlite
export WARP_DB_CONNECTION_STRING="file:$DATA_DIR/warp.db?_pragma=journal_mode(WAL)&_pragma=busy_timeout(10000)&_pragma=foreign_keys(1)"
export WARP_DB_AUTO_MIGRATE=true
export WARP_MEDIA_BASE_PATH="$DATA_DIR/media"
export WARP_LISTEN_ADDRESS=":8008"
# The suite registers and logs in constantly, all from the one address the
# test runner has. Rate limiting would turn that into a wall of
# M_LIMIT_EXCEEDED and tell us nothing about the server. Synapse's own
# Complement image does the same.
export WARP_RATE_LIMIT_ENABLED=false
# Open registration: the tests create their own users.
export WARP_REGISTRATION_ENABLED=true
# Federation stays off unless the profile asks for it: run.sh passes
# WARP_FEDERATION_ENABLED=true into the container for the federation
# profile.
export WARP_FEDERATION_ENABLED="${WARP_FEDERATION_ENABLED:-false}"
# Federation over TLS on 8448. Complement mounts a CA at /complement/ca and
# expects every homeserver of a run to present a certificate it signed;
# the same CA is what Warp trusts when it connects to the others, and to
# the servers Complement itself pretends to be.
CA_DIR=/complement/ca
if [ -f "$CA_DIR/ca.crt" ] && [ -f "$CA_DIR/ca.key" ]; then
if [ ! -f "$DATA_DIR/tls.crt" ]; then
openssl genrsa -out "$DATA_DIR/tls.key" 2048 2>/dev/null
openssl req -new -sha256 -key "$DATA_DIR/tls.key" \
-subj "/CN=$WARP_SERVER_NAME" -out "$DATA_DIR/tls.csr"
printf 'subjectAltName=DNS:%s\n' "$WARP_SERVER_NAME" > "$DATA_DIR/san.ext"
# The serial file goes in the data directory: the CA mount may be
# read-only.
openssl x509 -req -in "$DATA_DIR/tls.csr" \
-CA "$CA_DIR/ca.crt" -CAkey "$CA_DIR/ca.key" \
-CAserial "$DATA_DIR/ca.srl" -CAcreateserial \
-out "$DATA_DIR/tls.crt" -days 1 -sha256 -extfile "$DATA_DIR/san.ext" 2>/dev/null
fi
export WARP_LISTEN_FEDERATION_ADDRESS=":8448"
export WARP_TLS_CERT_FILE="$DATA_DIR/tls.crt"
export WARP_TLS_KEY_FILE="$DATA_DIR/tls.key"
export WARP_FEDERATION_TLS_CA_FILE="$CA_DIR/ca.crt"
fi
# Application services. Complement writes the registration file of every
# service a blueprint asks for into /complement/appservice; Warp reads
# them at startup like any other registration file.
AS_DIR=/complement/appservice
if [ -d "$AS_DIR" ]; then
files=""
for f in "$AS_DIR"/*.yaml; do
[ -f "$f" ] || continue
files="${files:+$files,}$f"
done
if [ -n "$files" ]; then
export WARP_APPSERVICE_CONFIG_FILES="$files"
fi
fi
# Complement captures the container's output, so text at debug level is the
# most useful thing to have when a test fails.
export WARP_LOG_LEVEL="${WARP_LOG_LEVEL:-debug}"
export WARP_LOG_FORMAT="${WARP_LOG_FORMAT:-text}"
if [ ! -f "$WARP_PRIVATE_KEY" ]; then
warp generate-keys --output "$WARP_PRIVATE_KEY"
fi
# Migrations also run on boot, but doing them here keeps a schema failure
# out of the request path and makes it obvious in the container log.
warp migrate
exec warp serve